Systems, methods, and devices associated with supporting interdependent reconfiguration messages

Abstract

A system include interdependent reconfiguration messages. For example, a WTRU may be configured to receive a first radio resource control (RRC) message. The first RRC message may indicate first configuration information and / or a first interdependency characteristic. The WTRU may set an interdependence RRC message timer based on an interdependence RRC message reception time duration. The WTRU may receive a second RRC message. The second RRC message may indicate second configuration information and / or a second interdependency characteristic. The WTRU may determine that the second RRC message is received before expiry of the interdependence RRC message timer. The WTRU may determine that message are interdependent based on the first interdependency characteristic and / or the second interdependency characteristic. Based on the interdependence RRC message timer and / or the first and / or second interdependency characteristic, the WTRU may update a parameter associated with the WTRU using the first configuration information or the second configuration information.

Description

SYSTEMS, METHODS, AND DEVICES ASSOCIATED WITH SUPPORTING INTERDEPENDENT RECONFIGURATION MESSAGESCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 540,515, filed September 26, 2023, the contents of which are hereby incorporated by reference herein.BACKGROUND

[0002] Mobile communications using wireless communications continues to evolve. A fifth generation of mobile communication radio access technology (RAT) may be referred to as 5G new radio (NR). A previous (legacy) generation of mobile communication RAT may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0003] Systems, methods, and devices may be used to support interdependent reconfiguration messages. A device (e.g., a wireless transmit / receive unit (WTRU)) may include a processor. The device may be configured to perform one or more of the following actions. The device may receive a first radio resource control (RRC) message from a distributed unit (DU) RRC entity. The first RRC message may indicate first configuration information and / or a first interdependency characteristic. In response to receiving the first RRC message, the device may set an interdependence RRC message timer based on an interdependence RRC message reception time duration. The device may receive a second RRC message from a control unit (CU) RRC entity. The second RRC message may indicate second configuration information and / or a second interdependency characteristic. The device may determine that a first condition and / or a second condition are satisfied. The first condition may be determined to be satisfied based on the second RRC message being received before expiry of the interdependence RRC message timer. The second condition may be determined to be satisfied based on the first interdependency characteristic and the second interdependency characteristic. The device may update, based on the determination that the first condition and the second condition are satisfied, a parameter associated with the WTRU using the first configuration information or the second configuration information.

[0004] The interdependence RRC message reception time duration may be preconfigured or may be received from the DU RRC entity. The determination that the second condition is satisfied may include a determination that the first interdependency characteristic and the second interdependency characteristic indicate a same value. The determination that the second condition is satisfied may comprise a determination that the first interdependency characteristic and the second interdependency characteristic indicate that the first RRC message and the second RRC message are interdependent.

[0005] The device may send a first reconfiguration message to the DU RRC entity and / or a second reconfiguration message to the CU RRC entity. The first reconfiguration message and / or the second reconfiguration message may include an indication that the parameter is updated. The parameter may include a first parameter and / or a second parameter. The device may update, based on the determination that the first condition and / or the second condition are satisfied, the first parameter using the first configuration information and / or the second parameter using the second configuration information.

[0006] The device may determine that a third condition is satisfied. The third condition may be determined to be satisfied based on a WTRU speed satisfying a threshold. The device may update, based on the determination that the first condition, the second condition, and / or the third condition are satisfied, the parameter associated with the WTRU using the second configuration information.

[0007] The device may update, based on the determination that the first condition and / or the second condition are satisfied, the parameter associated with the device using the first configuration information. The device may send a first reconfiguration message to the DU RRC entity and / or a second reconfiguration message to the CU RRC entity. The first reconfiguration message may include an indication that the parameter is updated based on the first configuration information, and / or the second reconfiguration message may include an indication that the parameter is not updated based on the second configuration information.

[0008] The device may update, based on the determination that the first condition and the second condition are satisfied, the parameter associated with the WTRU using the second configuration information. The device may determine that one or more error conditions have occurred within a duration of time associated with an error checking time value. The duration of time may begin at the time the parameter was updated using the second configuration information. The device may receive a set of configuration information from the CU RRC entity. The device may determine that the update of the parameter associated with the WTRU using the first configuration information or the second configuration information results in a reconfiguration failure. The device may determine a third configuration information from the set of configuration information, wherein the third configuration information is compatible with the first configuration information. The device may perform a second update of the parameter associated withthe WTRU using the first configuration or the third configuration. The device may receive a fallback configuration from the DU RRC entity or the CU RRC entity. The device may determine that a failure condition for performing a recovery procedure is satisfied. The failure condition may indicate at least one of a reconfiguration failure, an integrity verification failure, or a handover failure. The device may receive a reconfiguration message from the DU RRC entity. The device may perform another update of the parameter based on the fallback configuration.

[0009] Systems, methods, and devices may be used to support interdependent reconfiguration messages. For example, a WTRU may comprise a processor that may be configured to perform a method to support interdependent reconfiguration messages. At least one of a CU RRC entity and a first signal radio barer (SRB) may be determined. At least one of a DU RRC entity and a second SRB may be determined. A value may be determined for an interdependence RRC message reception time duration. A first RRC message may be received on the second SRB from the DU. The first RRC message may indicate an interdependency value. The first RRC message may be stored. An interdependence RRC message timer may be set to a duration of time using the value.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0012] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0013] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0014] FIG. 2 shows an example architecture that includes a control unit (CU) and a distributed unit (DU).

[0015] FIG. 3 shows an example CU that encapsulates an IE associated with the PHY / MAC / RLC configuration into an radio resource control (RRC) message, which may be sent back to the DU for transmission.

[0016] FIG. 4 shows an example RRC reconfiguration procedure.

[0017] FIG. 5 shows an example network architecture where the CU and the DU may be connected via an F1 interface.

[0018] FIG. 6 shows an example of network architecture where two RRC entities may exist.

[0019] FIG. 7 shows an example of split RRC architecture.

[0020] FIG. 8 shows an example of split RRC architecture.DETAILED DESCRIPTION

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

[0022] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a ON 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

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

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

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

[0026] More In example, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

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

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

[0032] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like.The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0036] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing,power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0040] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

[0045] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

[0047] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

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

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

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

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

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

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

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

[0056] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / ordetermined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0057] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0059] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0060] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel isbusy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

[0062] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

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

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

[0066] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

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

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

[0069] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernetbased, and the like.

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

[0071] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0072] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0074] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be testing equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0075] Reference to a timer herein may refer to a time, a time period, a tracking of time, a tracking of a period of time, a combination thereof, and / or the like. Reference to a timer expiration herein may refer to determining that the time has occurred or that the period of time has expired.

[0076] In examples, the term SpCell may refer to the PCell of the master cell group (MCG), or the PSCell of the secondary cell group (SCG), depending on whether the MAC entity is associated to the MCG or the SCG.

[0077] Systems, methods, and devices may be used to support interdependent reconfiguration messages. A device (e.g., a wireless transmit / receive unit (WTRU)) may include a processor. The device may be configured to perform one or more of the following actions. The device may receive a first radio resource control (RRC) message from a distributed unit (DU) RRC entity. The first RRC message may indicate first configuration information and / or a first interdependency characteristic. In response to receiving the first RRC message, the device may set an interdependence RRC message timer based on an interdependence RRC message reception time duration. The device may receive a second RRC message from a control unit (CU) RRC entity. The second RRC message may indicate second configuration information and / or a second interdependency characteristic. The device may determine that a first condition and / or a second condition are satisfied. The first condition may be determined to be satisfied based on the second RRC message being received before expiry of the interdependence RRC message timer. The second condition may be determined to be satisfied based on the first interdependency characteristic and the second interdependency characteristic. The device may update, based on the determination that the first condition and the second condition are satisfied, a parameter associated with the WTRU using the first configuration information or the second configuration information.

[0078] The interdependence RRC message reception time duration may be preconfigured or may be received from the DU RRC entity. The determination that the second condition is satisfied may include adetermination that the first interdependency characteristic and the second interdependency characteristic indicate a same value. The determination that the second condition is satisfied may comprises a determination that the first interdependency characteristic and the second interdependency characteristic indicate that the first RRC message and the second RRC message are interdependent.

[0079] The device may send a first reconfiguration message to the DU RRC entity and / or a second reconfiguration message to the CU RRC entity. The first reconfiguration message and / or the second reconfiguration message may include an indication that the parameter is updated. The parameter may include a first parameter and / or a second parameter. The device may update, based on the determination that the first condition and / or the second condition are satisfied, the first parameter using the first configuration information and / or the second parameter using the second configuration information.

[0080] The device may determine that a third condition is satisfied. The third condition may be determined to be satisfied based on a WTRU speed satisfying a threshold. The device may update, based on the determination that the first condition, the second condition, and / or the third condition are satisfied, the parameter associated with the WTRU using the second configuration information.

[0081] The device may update, based on the determination that the first condition and / or the second condition are satisfied, the parameter associated with the device using the first configuration information. The device may send a first reconfiguration message to the DU RRC entity and / or a second reconfiguration message to the CU RRC entity. The first reconfiguration message may include an indication that the parameter is updated based on the first configuration information, and / or the second reconfiguration message may include an indication that the parameter is not updated based on the second configuration information.

[0082] The device may update, based on the determination that the first condition and the second condition are satisfied, the parameter associated with the WTRU using the second configuration information. The device may determine that one or more error conditions have occurred within a duration of time associated with an error checking time value. The duration of time may begin at the time the parameter was updated using the second configuration information. The device may receive a set of configuration information from the CU RRC entity. The device may determine that the update of the parameter associated with the WTRU using the first configuration information or the second configuration information results in a reconfiguration failure. The device may determine a third configuration information from the set of configuration information, wherein the third configuration information is compatible with the first configuration information. The device may perform a second update of the parameter associated with the WTRU using the first configuration or the third configuration. The device may receive a fallback configuration from the DU RRC entity or the CU RRC entity. The device may determine that a failurecondition for performing a recovery procedure is satisfied. The failure condition may indicate at least one of a reconfiguration failure, an integrity verification failure, or a handover failure. The device may receive a reconfiguration message from the DU RRC entity. The device may perform another update of the parameter based on the fallback configuration.

[0083] Systems, methods, and devices may be used to support interdependent reconfiguration messages. For example, a WTRU may comprise a processor that may be configured to perform a method to support interdependent reconfiguration messages. At least one of a CU RRC entity and a first service signaling radio bearer (SRB) may be determined. At least one of a DU RRC entity and a second SRB may be determined. A value may be determined for an interdependence RRC message reception time duration. A first RRC message may be received on the second SRB) from the DU. The first RRC message may indicate an interdependency value. The first RRC message may be stored. An interdependence RRC message timer may be set to a duration of time, using the value.

[0084] In examples, a second RRC message, indicating the interdependency value, may be received from the CU before the expiration of the duration of time.

[0085] In examples, the first RRC message may be confirmed, and a configuration associated with at least the first RRC message and a second RRC message may be applied.

[0086] In examples, a first reconfiguration complete message may be sent using the first SRB, and a second reconfiguration complete message may be sent using the second SRB.

[0087] In examples, A WTRU may determine that the duration of time has expired. A first reconfiguration failure message may be sent using the first SRB, and a second reconfiguration failure message may be sent using the second SRB.

[0088] Based on a determination that the duration of time has expired, a message to request a reestablishment procedure may be sent.

[0089] Systems, methods, and devices may be used to provide a conditional application of a reconfiguration. For example, a WTRU may comprise a processor that may be configured to provide a conditional application of a reconfiguration. At least one of a CU RRC entity and a first SRB may be determined. At least one of a DU RRC entity and a second SRB may be determined. A first configuration associated with the CU may be determined. The configuration may indicate an error checking time value and may indicate one or more error conditions to be monitored. A first RRC message may be received on the second SRB from the DU. A second configuration associated with the RRC message may be determined. The second configuration may be applied. One or more error conditions may be determined to have occurred within a duration of time associated with the error checking time value. The duration of time may have begun at the time the second configuration was applied.

[0090] In examples, a measuring event may be triggered.

[0091] In examples, a radio link failure (RLF) condition may be triggered.

[0092] In examples, a reversion to a previous DU configuration may occur.

[0093] In examples, a first reconfiguration failure message using the first SRB may be sent and a second reconfiguration failure message using the second SRB may be sent.

[0094] In examples, an identity of the error condition may be indicated by the first reconfiguration failure message, and the identity of the error condition may be indicated by the second reconfiguration failure message.

[0095] Systems, methods, and devices may be provided for determining a dependent configuration. For example, a WTRU may be provided for determining a dependent configuration. The WTRU may comprise a processor. A first RRC message may be received, wherein the first RRC message may indicate a CU configuration. The CU configuration may be applied. A set of CU configurations may be received from the CU via a first SRB. The set of CU configurations may be associated with a cell. A second RRC message may be received from a DU via a second SRB. The second RRC message may indicate a DU configuration.

[0096] In examples, a WTRU may determine that applying the DU configuration and the CU configuration results in a reconfiguration failure.

[0097] In examples, a second CU configuration may be determined from the set of CU configurations. The second CU configuration may be compatible with the DU configuration (e.g., such that the application of the second CU configuration and the DU configuration may result in a successful RRC reconfiguration).

[0098] In examples, the second CU configuration may be applied.

[0099] In examples, the DU configuration may be applied.

[0100] In examples, a message may be sent to the CU via the first SRB, wherein the message may indicate the second CU configuration to the CU.

[0101] In examples, a second message may be sent to the DU via the second SRB., wherein the second message may indicate that an RRC configuration has been completed.

[0102] In examples, a WTRU may determine that an application of the CU configuration and the DU configuration may result in a successful reconfiguration. The CU configuration and the DU configuration may be applied, and a second message may be sent to the DU via the second SRB. The second message may indicate that an RRC reconfiguration is complete.

[0103] Systems, methods, and devices may be provided for determining a node for sending measurements. For example, a WTRU may be provided for determining a node for sending measurements.The WTRU may comprise a processor. A measurement configuration may be received from at least one of a CU or a DU. The measurement configuration may be associated with a serving cell and may indicate a condition to trigger a measurement event. A neighbor cell condition may be determined for a neighbor cell. The neighbor cell may be associated with a set of cells. A measurement of the neighbor cell may be determined.

[0104] In examples, a determination may be made that the measurement satisfies the condition to trigger a measurement event.

[0105] In examples, a measurement report may be conveyed to the DU via a SRB, wherein the DU may be associated with a serving cell, and wherein the measurement may be indicated by the measurement report, for example.

[0106] In examples, a measurement report may be conveyed to the CU via a SRB, wherein the CU may be associated with a serving cell, and wherein the measurement may be indicated by the measurement report.

[0107] Systems, methods, and devices may be provided for performing a re-establishment procedure. For example, a WTRU may be provided for performing a re-establishment procedure. The WTRU may comprise a processor. It may be determined that a condition for performing a re-establishment procedure with a DU has been satisfied. A SRB that is associated with the DU may be suspended. A cell reselection may be performed. A re-establishment request message may be sent to the DU using a second SRB.

[0108] In examples, a re-establishment message may be received from the DU. The security context of the DU may be updated based on the re-establishment message. The suspended SRB may be resumed. A message may be sent to the CU, which comprises information regarding the DU re-establishment.

[0109] In examples, a re-establishment message may be received from the CU. Based on this reestablishment message, a legacy radio resource control (RRC) re-establishment procedure may be performed.

[0110] In examples, it may be determined that a re-establishment failure has occurred, based on either a re-establishment failure message received from the DU or the expiration of a duration of time without reception of an RRC message in response to the re-establishment request message. A legacy RRC reestablishment procedure may be performed.

[0111] Systems, methods, and devices may be used to perform a fallback procedure following a reconfiguration failure. For example, a WTRU may be provided to perform a fallback procedure following a reconfiguration failure. The WTRU may include a processor. A fallback data unit configuration may be received from a CU or the DU using either a first SRB or a second SRB. A failure condition for performing a recovery procedure may be determined. The failure condition may indicate a reconfiguration failure, anintegrity verification failure, or a handover failure. A reconfiguration message may be received from the DU using the second SRB.

[0112] In examples, the recovery procedure may be performed when the failure condition is satisfied. The recovery procedure may include releasing the DU RRC or sending a request to release the DU RRC. The recovery procedure may also be performed when a confirmation is received.

[0113] In examples, the fallback configuration may be applied when the DU RRC is released. The WTRU may be configured in a single RRC entity mode. A message may be sent to a network entity by the processor. The message may indicate that the DU RRC has been released and may indicate a release cause value.

[0114] Interdependent RRC messages may be configured with the WTRU. Upon the reception of an interdependent RRC message, the WTRU may perform one or more actions. A configuration failure may be determined by a WTRU following an evaluated error that occurs after the configuration is applied. With respect to one node (DU / CU), a dependent configuration may be applied by a WTRU upon failure to apply a configuration provided by the other node (CU / DU). A HO command may be received by a WTRU from a CU or DU. The node to which to report the measurement may be determined by the properties of a triggered measurement event. With a condition (e.g., event) that changes the reporting node, a WTRU may be configured. Depending on the node to which measurements are reported, the contents of the measurement reports may vary. Based on conditions, the connection to the DU may be re-established by a WTRU. The DU RRC may be released by a WTRU configured based on a condition. A fallback to the previous or default DU RRC configuration may be implemented. An indication about DU RRC release or RRC reconfiguration rejection may be provided to the DU / CU.

[0115] A network architecture, which may be a 5G network architecture, may be provided. FIG. 2 shows an example architecture that includes a CU and a DU. The network architecture of a gNB in 5G may comprise a CU and DU separated by an F1 interface. From the protocol stack perspective, the role of the DU may be to manage the physical layer (PHY), radio link control (RLC), and MAC layer configurations of the UEs connected to the cells managed by the gNB. The role of the CU may be to manage the PDCP and SDAP configurations associated with the bearers, as well as the RRC protocol. The protocol stack of the CU / DU may be split.

[0116] FIG. 3 shows an example CU that encapsulates an IE associated with the PHY / MAC / RLC configuration into an RRC message, which may be sent back to the DU for transmission.

[0117] When configuring a WTRU, the RRC message may be generated by the CU.The configuration of the PHY / MAC / RLC may be determined by the DU, which sends the configuration to the CU. The CU mayencapsulate the IE associated with the PHY / MAC / RLC configuration into an RRC message, which is sent back to the DU for transmission.

[0118] Dual connectivity may be provided. In examples, a system, such as 5Gs, may allow the WTRU to be configured in dual connectivity (DC). In DC, the WTRU may be configured with a MCG and SCG. The MCG may comprise of the PCell (and potential SCells), which serves as the mobility anchor at the UE. The SCG may comprise of the PSCell (and potential SCells), which provides the WTRU with additional network resources via a different gNB / scheduler. The WTRU may be scheduled independently by the PCell and the PSCell.

[0119] Bearers for a WTRU in DC may be configured as MCG bearers, SCG bearers, or split bearers. MCG bearers send / receive data to / from the MCG. SCG bearers send / receive data to / from the SCG. Split bearers may route data to either MCG or SCG.

[0120] The WTRU may be configured with an RRC entity (e.g., single RRC entity) that may communicate with the RRC in the MN (e.g., the master) via SRB1 / SRB2. The WTRU may be configured with another SRB (e.g., SRB3) that may transmit / receive RRC messages from the RRC entity to the SN.

[0121] In examples, reconfiguration and error procedures may be provided. FIG. 4 shows an example RRC reconfiguration procedure.

[0122] RRC reconfiguration procedure is used to change the UE’s configuration parameters. The network may send an RRCReconfiguration message to the WTRU. If the WTRU is able to apply the configuration, it may respond with an RRCReconfigurationComplete message.

[0123] If the WTRU is unable to apply the RRC configuration, the WTRU may trigger an RRC connection re-establishment procedure. The WTRU triggers cell reselection. The WTRU may transmit an RRCReestablishmentRequest message, which includes the WTRU’s source cell C-radio network identifier (RNTI) and cell ID and an authentication code generated by the security parameters that were configured in the source cell. If the network is able to retrieve the WTRU’s context, the network may send an RRCReestablishment message, and may reconfigure the WTRU to maintain operation. If the reestablishment fails, the WTRU may move to IDLE and initiates initial cell selection.

[0124] One or more RRC reestablishment procedures may be provided. When the radio link is lost (e.g., RLF) or errors were detected (e.g., failure of the WTRU to execute the received reconfiguration, e.g., due to exceeding of WTRU capability, integrity verification failure), the WTRU may perform a cell reselection (e.g., chooses the best suitable cell similar to cell re-selection in I DLE / I NACTI VE operation) and may initiate the RRC reestablishment procedure by sending the RRCReestablishmentRequest message via the selected cell (e.g., newly selected cell). The selected cell may be the same cell that was serving the WTRU before the problem was detected (e.g., referred to as the source cell), it may be another cell that belong tothe same gNB that was also hosting the source cell, or it may be a cell belonging to a different gNB. Before the WTRU sends the RRCReestablishmentReqeust message it may reset the MAC, release carrier aggregation and dual connectivity configurations (e.g., if it was configured), and suspends one or more (e.g., all) radio bearers, (e.g., except for SRBO), as the RRCReestablishmentRequest message may be sent using SRBO (e.g., with no security) over the common control channel.

[0125] The message may include the identity of the WTRU (ReestabUE-ldentity) and the reestablishmentCause (e.g., whether the cause was a reconfiguration failure, handover failure, etc.).

[0126] The ReestabUE-ldentity may include the C-RNTI the WTRU was using before detecting the problem that triggered reestablishment, the physical cell ID of the source cell, and a security token known as a ShortMAC-l. The ShortMAC-l may be derived using the RRC security keys that were being used by the WTRU before the problem was detected. When the network gets the reestablishment request message, it may use the shortMAC-l to verify the user is indeed who it says it is (e.g., by generating the shortMAC-l itself for the WTRU that was using the indicated C-RNTI at the indicated source cell and comparing with the shortMAC-l that was provided by the WTRU).

[0127] If the WTRU’s context is retrieved by the network (e.g., target gNB that is receiving the WTRU’s reestablishment request was the same gNB as the source gNB because the WTRU has re-selected to the same source cell or to a cell belonging to the same gNB as that serving the source cell, or the target gNB is able to get the WTRU context from the source gNB, e.g., via the Xn interface between the two gNBs) and the identity of the WTRU was verified as above, then the target gNB may send an RRCReestablishment message to the WTRU. The message may be sent via SRB1 , but this message may be an (e.g., only) integrity protected but not ciphered / encrypted. The target gNB integrity may protect this message and may use a security context that is derived from the security context that it got from the source gNB for the concerned WTRU during context fetching and using a counter called nextHopChainingCount. This counter value may be included in the RRCReestablishment message, which may be used by the WTRU to derive the new security context the same way as that was performed by the target gNB, and thus may be able to integrity verify the message. The WTRU may be able to re-establish SRB1 and send the RRCReestablishmentComplete message in SRB1 (which may be both integrity protected and encrypted). One or more (e.g., all) other radio bearers (e.g., SRB2 which may be used for low priority control plane data such as NAS signaling, SRB4 which may be used for QoE reporting, and one or more data radio bearer (DRBs)) remain suspended. The WTRU may resume one or more of these radio bearers when it receives a further RRC Reconfiguration message following the sending of the RRCReestablishmentComplete message.

[0128] If the WTRU’s context is not retrieved by the network (e.g., target gNB has no interface with the source gNB, the WTRU identity verification didn’t succeed, e.g., the MAC-I generated by the network was different from the one that the WTRU supplied), the target gNB may send an RRCSetup message to the WTRU. The message may be sent via SRBO (e.g., with no security). The WTRU may release one or more (e.g., all) of the configuration(s) upon the reception of this message, and may act the same way on requesting a connection setup from scratch (e.g., RRCSetupRequest sent by the WTRU for establishing the connection while in IDLE state due to the arrival of UL data or reception of a paging from the network indicating arrival of DL data). The WTRU may respond with an RRCSetupComplete message (e.g., in SRB1), and further RRCReconfiguration message may be used to configure the other SRBs and all DRBs.

[0129] In examples, (e.g., some) enhancements were made to the re-establishment procedure, if the WTRU was configured with a conditional handover (e.g., a HO command that is to be executed when a target cell fulfills a radio condition, e.g., a threshold level above the source cell). Upon detecting a problem and initiating a re-establishment, the WTRU may first check to see if the cell it chooses after cell reselection is a target for any conditional handover (CHO) configuration. If so, the WTRU may directly apply the HO command associated with that target (e.g., it is not reasonable to go through the re-establishment procedure, subsequent reconfiguration, and so on, while the target cell is prepared for that WTRU and the WTRU has the target’s configuration available).

[0130] Mobility and LTM may be provided. In examples, in an attempt to reduce the latency associated with mobility, L1 / L2 triggered mobility (LTM) may be introduced. In LTM, MAC control element (CE) sent by the DU may be used to trigger mobility. The WTRU may be first configured with a set of candidates RRC configurations associated with different cells and perform L1 measurement reporting. Upon reception of a cell switch command, the WTRU triggers LTM by applying one of the stored candidates RRC configurations associated with the target cell.

[0131] FIG. 5 shows an example network architecture where the CU and the DU may be connected via an F1 Interface. In examples, an architecture, which may be a potential for 6G, is a split RRC network architecture. In example architectures, the CU and the DU may be connected via an F1 interface. RRC messages to the WTRU may be generated independently by the CU and the DU. For example, the CU may generate an RRC message to configure the PDCP and SDAP at the WTRU and send this to the WTRU via the DU (transparently to the DU). In examples, the DU may generate an RRC message to configure the RLC / MAC / PHY of the WTRU and send this message directly to the CU.

[0132] FIG. 6 shows an example network architecture where two RRC entities may exist. In examples, one realization of the architecture at the network may be presence of two different RRC entities or subfunctions, where an entity may communicate with the WTRU.

[0133] Issues with latency may be caused by the CU / DU architecture and its association with reconfiguration and mobility. Mobility failures and delays may be the result of multiple F1 exchanges that generate and transmit the RRC message to the WTRU.

[0134] This issue may be addressed by LTM, which may allow for the control of mobility to be taken over by the DU. The triggering of LTM may be done by a MAC CE. In examples where additional reconfigurations are autonomously performed by the DU, using a MAC CE may pose a security risk that may be not scalable.

[0135] The split RRC architecture tries to address the limitations of LTM by introducing a separate RRC protocol stack at the DU and the ability of the WTRU to communicate via RRC with either the CU or the DU. The architecture to split RRC may be that of DC, where the WTRU may send / receive RRC messages to the SCG on SRB3. There may be (e.g., some) differences between split RRC and DC as discussed herein.

[0136] The embodiments described herein may address a number of issues. For example, consistency of the WTRU’s configuration may be addressed. The WTRU may be configured with different parts of its RRC configuration by different nodes, where the different parts of the configuration have interdependencies. For example, applying one part of the reconfiguration without another part of the reconfiguration may result in an error condition at the WTRU (e.g., exceeding the WTRU’s capabilities, transmitting data with the wrong priority, etc.). Because the reconfiguration messages are transmitted separately, they may arrive at the WTRU at different times (e.g., due to failures / delays in the transmissions). For example, one node may transmit a configuration that results in the configuration transmitted by another node becoming obsolete / invalid.

[0137] How to ensure consistent RRC configuration at the WTRU when different (interdependent) parts of the RRC configuration are transmitted at different times / by different nodes or when one node overrides a configuration already transmitted by another node may be described herein.

[0138] For example, premature / unnecessary re-establishment may be addressed. Re-establishment is a costly procedure that may result in reset of one or more (e.g., all) of the protocol layers at the WTRU, flushing the buffers, etc. A WTRU may perform unnecessary re-establishment if the WTRU receives a reconfiguration that may request (e.g., require) communication with another node. In examples, the reestablishment of one or more (e.g., all) layers may not be requested (e.g., required), especially if the issue is limited to the DU.

[0139] Examples may avoid unnecessary re-establishment delay by re-establishing a (e.g., only) the protocol layers that are to be used, or avoid re-establishment resulting from inconsistent reconfiguration that may be solved otherwise.

[0140] For example, measurements and mobility may be addressed. In the split architecture, the DU may manage mobility between cells within the same DU, and the CU may manage mobility between cells of different DUs. To avoid the delay associated with handover, the WTRU may send measurement reports to the appropriate network node.

[0141] A WTRU may perform measurements / mobility configured by the appropriate network node and may consider that measurements / mobility may be applicable to different network nodes.

[0142] Inter-dependency of RRC messages may be described. A WTRU may wait for the reception of (e.g., two) interdependent messages (e.g., reconfiguration messages) or implicit / explicit confirmation before applying a configuration. A WTRU may be configured with a CU RRC entity and / or SRB (e.g., SRB1) and a DU RRC entity and / or SRB (e.g., SRBx). A WTRU may be configured with an interdependence RRC message reception time duration (e.g., by the CU). A WTRU may receive a first RRC message (e.g., on SRBx) from the DU. The first RRC message may include an interdependency value and / or indication (e.g., an interdependency characteristic). A WTRU may store the received first RRC message and may initiate an interdependence RRC message timer (e.g., the WTRU may initiate the interdependence RRC message timer based on the reception of the first RRC message). The timer value may be set to the configured interdependence RRC message reception time duration.

[0143] The WTRU may determine a confirmation of the first RRC message (e.g., determine that one or more conditions are satisfied as describe herein). For example, the WTRU may receive a second RRC message from the CU that includes the same interdependency value and / or indication corresponding to (e.g., is the same as the interdependency value and / or indication in) the first message, and / or a second RRC message with an interdependency value and / or indication is received within the configured interdependency RRC message reception time duration. If the confirmation of the first RRC message is determined by the WTRU (e.g., the second RRC message includes the interdependency characteristic value and / or indication, and / or the second message RRC message is received before expiration of the configured interdependence RRC message reception timer), the WTRU may apply configuration(s) in the first and / or second RRC message (e.g., if applicable). If the confirmation of the first RRC message is determined by the WTRU, the WTRU may send reconfiguration complete message(s), for example, two (e.g., separate) reconfiguration complete messages (e.g., one on SRB1 and one on SRBx).

[0144] If the confirmation of the first RRC message is not determined by the WTRU, for example, the time duration (e.g., the interdependence RRC message reception timer) has elapsed before a reception of a second interdependent RRC message, the WTRU may perform one or more of the following. The WTRU may send reconfiguration failure message(s), for example, two reconfiguration failure messages (e.g., one on SRB1 and one on SRBx). A reconfiguration message may indicate a (e.g., new) failure cause value(e.g., “unable to receive interdependent RRC message from CU / DU”). The WTRU may trigger a reestablishment procedure.

[0145] Temporary / Conditional application of a reconfiguration may be provided. A WTRU may determine whether to revert to a previous configuration based on an error condition occurring following application of a new configuration. A WTRU may be configured with a CU RRC entity and / or SRB (e.g., SRB1) and a DU RRC entity and / or SRB (e.g., SRBx). A WTRU may be configured with an error checking time and a configuration from the CU for checking one or more error conditions (e.g., measurement event, RLF-like trigger, etc.). A WTRU may receive a first RRC message on SRBx (e.g., from the DU) and apply the configuration in the RRC message.

[0146] If one or more of the configured error conditions occur within the configured error checking time from the time the configuration was applied, the WTRU may perform a number of actions. The WTRU may trigger a measurement event. The WTRU may trigger an RLF-like condition. The WTRU may revert to a determined DU configuration (e.g., previous, default, etc.). The WTRU may send (e.g., two) reconfiguration failure messages (e.g., one on SRB1 and one on SRBx), indicate a new failure cause value in a failure message (e.g., “Failure following DU reconfiguration”), and / or include the identity of the error condition.

[0147] WTRU determination of a dependent configuration may be provided. A WTRU may opportunistically determine or change a configuration at the CU following a configuration change at the DU, which may cause inconsistency in the full WTRU configuration. The WTRU may receive a first RRC message that includes a CU configuration and may apply the received configuration. The WTRU may receive a set of allowable or unallowable CU configurations for a cell from the CU through SRB1 , which may be stored.

[0148] The WTRU may receive a second RRC message on SRBx from the DU that includes a DU configuration. If applying the DU configuration along with the current first CU configuration results in a reconfiguration failure due to exceeding WTRU capabilities, the WTRU may choose to select and apply at least one of the allowable CU configurations that results in a successful RRC reconfiguration when both the CU and DU configurations are applied. The WTRU may apply the DU configuration from the second RRC message and transmit an identity that indicates the chosen CU configuration to the CU through SRB1 .

[0149] In examples, if applying the DU configuration does not lead to a reconfiguration failure, the WTRU may apply the DU configuration from the first RRC message. The WTRU may send an RRC reconfiguration complete message to the DU (e.g., on SRBx), indicating the completion of the reconfiguration process.

[0150] A WTRU may be provided for determining a node for transmitting one or more measurements.Whether a WTRU reports a measurement via a first or second SRB may depend on the neighbor cell thattriggered the measurement. The WTRU may receive a measurement configuration from the CU and / or DU of a serving cell, which may include a measurement event triggered when the neighbor cell becomes better than the serving cell. The WTRU may be configured (e.g., possibly by the CU), with at least a first set of cells and a measurement event configuration. If the neighbor cell that belongs to the first set of cells satisfies the condition of the measurement event, the WTRU may report the measurement to the DU of the serving cell (e.g., on SRBx). If the neighbor cell does not satisfy the condition of the measurement event, the WTRU may report the measurement to the CU of the serving cell (e.g., on SRB1).

[0151] A WTRU may perform a two-stage / node re-establishment procedure. A WTRU may perform a reestablishment procedure towards the DU based on the problem that initiated the re-establishment. If the procedure is not successful, the WTRU may conduct a legacy re-establishment towards the CU.

[0152] In examples, the WTRU may be configured with conditions to perform re-establishment with the DU (e.g., instead of the CU). These conditions may be based on RLF cause or if the re-establishment is triggered by DU RRC reconfiguration failure (e.g., among other examples). Based on determining that the conditions for performing re-establishment to the DU are met, the WTRU may suspend the radio bearers (e.g., only the radio bearers) associated with the DU (e.g., excluding SRBOx if configured). Cell reselection may be performed.

[0153] A re-establishment request message may be transmitted to the DU. This message may be sent via SRBOx or SRBO, and may include an indication that the message is intended for the DU. If the WTRU receives a re-establishment message from the DU, the security context of the DU may be updated according to the received message. One or more suspended DU radio bearers (e.g., such as SRBx), may be resumed. An indication about the DU re-establishment may be sent to the CU.

[0154] In examples, if the WTRU receives a re-establishment message from the CU, an RRC reestablishment (e.g., a legacy RRC re-establishment) may be performed according to the received reestablishment message from the CU. If the WTRU receives a re-establishment failure message from the DU or a configured time duration elapses without receiving an RRC message in response to the reestablishment request, an RRC re-establishment (e.g., a legacy RRC re-establishment) with the CU may be triggered. This may involve sending an RRCReestablishmentRequest via SRBO.

[0155] A WTRU may address a reconfiguration failure without re-establishment (e.g., fallback to a legacy single RRC entity). Under (e.g., some) conditions, a WTRU may perform a fallback to an RRC entity (e.g., single RRC entity) operation (e.g., a legacy operating) following a failed attempt to apply or execute a received reconfiguration message from the DU. The WTRU may receive and store a fallback DU / lower- layer configuration (e.g.., such as MAC / RLC / PHY), from various sources (e.g., such as the CU over SRB1 or from DU over SRBx).

[0156] In examples, conditions such as reconfiguration failure, integrity verification failure, handover failure, and the like, may be received by the WTRU. Based on detection of condition(s), the WTRU may release the DU RRC or request a release of the DU RRC. The WTRU may receive a reconfiguration message from the DU (e.g., on SRBx).

[0157] If the conditions to release or request a release of the DU RRC are fulfilled during or after applying the configuration, several actions may be taken by the WTRU. The WTRU may release the DU RRC or send a request to the network to release the DU RRC and may release the DU RRC upon receiving confirmation from the network. The stored fallback configuration for the lower layers may be applied by the WTRU, and operation in an RRC entity mode (e.g., a single RRC entity mode) may commence. The WTRU may send an indication to the network that the DU RRC has been released, including a release cause value.

[0158] Examples described herein may assume RRC control of a WTRU by network nodes (e.g., two separate network nodes such as a CU / DU) that may be reached via a cell (e.g., a single cell).The examples may apply to RRC signaling for different gNB, network nodes, cells, and the like.

[0159] Examples described herein may apply to RRC signaling associated with peer WTRUs. For example, one or more nodes (e.g., both nodes) may correspond to different WTRUs (e.g., in the context of WTRU-to-WTRU transmissions). In examples, a node may be a network node (e.g., gNB), and another node may be a WTRU. For example, an RRC protocol stack may be Uu reference signal received power (RSRP), while the other protocol stack may be PC5-RRC.

[0160] Common principles and observations may be provided. DC and split RRC may share (e.g., some) similarities as they both comprise of a WTRU being able to transmit / receive RRC messages and be able to be controlled via RRC terminated in (e.g., two) different network nodes. In both examples, the WTRU may be aware of the configuration that is associated with a node (e.g., each of the nodes). In DC, the MN may configure the WTRU on SRB1 and the SN may configure the WTRU on SRB3. In split RRC, the CU may configure the WTRU using SRB1 , and the DU may configure the WTRU using SRBx. Other examples of SRB1 and SRBx may be described herein.

[0161] There may be (e.g., some) differences between DC and split RRC. In examples, the assumption on the MAC entity and physical layer interface may be different. The physical path taken by the transmissions may be different. In DC, the WTRU may have one or more (e.g., two separate) MAC entities that communicate with the network via two different PHY interfaces (e.g., one for the MN and one for the SN). It may be possible for the MCG MAC entity to receive / deliver RRC messages destined for the SN (e.g., by having them transparently forwarded to the SN by the MN), but in this example, the RRC messagestructure may be different compared to the split RRC, as discussed herein. In split RRC, the WTRU may have a single MAC entity and may communicate to the network using a single PHY interface.

[0162] In examples, the RRC message structure may be different. In the case of DC where the WTRU sends / receives RRC signaling to / from the SN via the MCG, the WTRU may send / receive an RRC message to / from the MN and encapsulate within that message, an information element (IE) corresponding to the SN.

[0163] In the example of split RRC, CU and DU RRC messages may be sent independently, because they may be encrypted with different security keys. This may be modeled as different RRC entities at the WTRU, as described herein.

[0164] In examples, the cell connection(s) for the WTRU may be different. In DC, the WTRU may be connected to (e.g., two) different cells to communicate with the (e.g., two) nodes. The WTRU may communicate with the MN via the PCell and may communicate with the SN via the PSCell. The PCell and PSCell may be associated with separate schedulers. In split RRC, the WTRU may be connected to a (e.g., single) cell. Communication to either the DU or the CU may be made using the (e.g., same) cell which has a (e.g., single) scheduler. RRC communications to a (e.g., each) node may be transparent of each other. For example, the CU and the DU RRC transmissions may be encrypted with different security keys.

[0165] In examples, the portion of the RRC configuration that may be configured by a node’s (e.g., each node’s) RRC message / entity may be different in split RRC and DC. In DC, the MCG may change the PHY and MAC layer parameters associated with the MCG MAC entity. The SCG may change the PHY and MAC layer parameters associated with the SCG MAC entity. The MCG may reconfigure (e.g., only reconfigure) the MCG terminated split / non-split bearers, while the SCG may reconfigure (e.g., only reconfigure) the SCG terminated split / non-split bearers. In split RRC the DU may configure PHY, MAC, and the RLC entities of one or more (e.g., all) of the bearers at the WTRU. The CU may configure the PDCP and SDAP of one or more (e.g., all) of the bearers at the WTRU. The CU may configure the PHY, MAC, RLC, for example, the configuration may be provided by the DU to the CU via F1 . The DU may not be expected to be able to configure the PDCP and SDAP.

[0166] Modeling control plane architecture of split RRC at the WTRU may be provided. FIG. 7 shows an example split RRC architecture. In one modeling of the split RRC architecture, the WTRU may have independent RRC entities. An RRC entity (e.g., each RRC entity) may establish one or more SRBs to communicate with the CU and DU. An RRC entity (e.g., each RRC entity) may manage a set of RRC procedures associated with each RRC entity independently. In examples, an overall RRC entity controlling the interaction between the RRC procedures of an RRC entity may be included. In examples, the overall RRC entity may establish one or more SRBs that allow communication to be sent to both RRC entities at the network (e.g., an RRC message that may be read by the CU and the DU).

[0167] FIG. 8 shows an example split RRC architecture. In examples of the split RRC architecture, the WTRU may have an (e.g., single) RRC entity to interact with the CU and DU RRC entities. A set of procedures may be defined which are aware of the target / peer RRC entity at the network (CU or DU). The WTRU may establish separate SRBs for communicating with the CU and DU. In examples, the WTRU may communicate with the CU by transmitting RRC messages over a first one or more SRBs, and the WTRU may communicate with the DU by transmitting RRC messages over a second one or more SRBs. In examples, the WTRU may establish a third one or more SRBs which allow the WTRU to send RRC messages to both entities (e.g., simultaneously, e.g., an RRC message that may be read by the CU and the DU).

[0168] In examples of the split RRC architecture, the WTRU may have a (e.g., single) RRC entity to interact with the CU and DU RRC entities. A set of procedures may be defined which is aware of the target / peer RRC entity at the network (CU or DU). The WTRU may establish a set of SRBs for communicating with either CU or DU. An RRC message may be defined with an RRC message type that identifies the RRC message as an RRC message transmitted / intended by / for the CU and another RRC message type associated with the DU. In examples, a third RRC message type may be established to be intended to both the CU and the DU. Message type may comprise of an identifier in the RRC message. Message type may be tied to a specific RRC message, and the message itself may be tied to one of the types in the specification.

[0169] In examples, transmission intended to the CU and DU may be referred to as transmissions to SRBc and SRBd. While these terms may be associated with different SRB transmissions, it may be understood in the context of the examples described herein that they may mean RRC transmissions / receptions to / from CU or DU that apply to one of the modeling described herein. In examples, transmissions to SRBc and SRBd may correspond to using different logical channels (LCH) for the transmissions, using different security / encryption, using a different PDU header or PDU type, using a different RRC message, and the like.

[0170] Transmissions to SRBc and SRBd may use different logical channels for the transmissions. In examples, transmissions to CU and DU may be associated with transmitting over different logical channels. In examples, the logical channel IDs (LCIDs) associated with the CU / DU may be configured (e.g., in a system information broadcast (SIB) or dedicated RRC signaling). For example, the LCIDs associated with the CU / DU may be predefined.

[0171] Transmissions to SRBc and SRBd may use different security / encryption. For example, the WTRU may be configured with different security keys / parameters applicable to RRCtransmissions / receptions to / from the CU and DU. The WTRU may use a first key to encrypt / decrypt data associated with the CU, and a second key to encrypt / decrypt data associated with the DU.

[0172] Transmissions to SRBc and SRBd may use a different PDU header or PDU type. In examples, transmissions / receptions to / from CU and DU respectively may use a different protocol header (e.g., RLC header, PDCP header), or PDU type (e.g., PDCP type identifier in the protocol header).

[0173] Transmissions to SRBc and SRBd may use a different RRC message. Transmissions / receptions to / from CU and DU respectively may use different RRC messages defined in the specifications. For example, measurementReportCU may represent a measurement report transmitted to the CU, and measurementReportDU may represent a measurement report transmitted to the DU.

[0174] As described herein, the WTRU may initiate limited operational behavior and / or limited operational actions, which may comprise of one or more actions.

[0175] The WTRU may suspend / reset a subset of the protocol stack while continuing to run the other part. For example, the WTRU may suspend and / or reset the RLC / MAC / PHY but continue to run the PDCP and SDAP protocol layers. In examples, (e.g., new) packets generated by the upper layers may be ciphered / integrity protected and stored in the RLC buffers until RLC / MAC / PHY is restarted.

[0176] The WTRU may suspend one or more (e.g., all) user plane transmission and / or reception. For example, the WTRU may suspend one or more (e.g., all) user plane transmission and / or reception, but may continue to perform CP (e.g., RRC) transmission and / or reception.

[0177] The WTRU may suspend CP transmission and / or reception from one of the two entities (e.g., CU or DU). For example, the WTRU may suspend one or more RRC transmission / reception to the DU, but maintain RRC transmission / reception to the CU. In examples, the WTRU may suspend / reset the DU RRC entity and continue to operate (not suspend) the CU RRC entity, or vice versa.

[0178] The WTRU may suspend CP transmission to one or more (e.g., both) entities. For example, the WTRU may suspend both CU and DU RRC entities.

[0179] The WTRU may suspend transmission and / or reception from one or a subset of the bearers. For example, the WTRU may suspend transmission / reception on a subset of its bearers. The subset of bearers may be (pre)configured or predetermined by specifications. The subset of the bearers may be identified by the WTRU based on the bearers that are impacted by a change (e.g., in configuration) at the WTRU. For example, the WTRU may determine the subset of the bearers based on the bearers that have an impact from a change in configuration resulting from a received reconfiguration message from the gNB (e.g., when the reconfiguration changes the LCH parameters of one or more bearers).

[0180] A WTRU may be configured with a list of cells. The WTRU may receive a dedicated RRC message with a list of cell IDs (e.g., where such a list may be cell specific). The WTRU may receive the cell list from the SIB from the serving cell. The WTRU may receive the cell list as part of another RRC message (e.g., a measurement event configuration). A WTRU may derive the cell list based on the serving cell itself. In examples, the cell IDs of the cells in the cell list may be derived from the cell ID of the serving cell (e.g., a predefined or configured relationship).

[0181] Inter-dependency of RRC messages may be described. A WTRU may wait for the reception of (e.g., two) interdependent messages (e.g., reconfiguration messages) or implicit / explicit confirmation before applying a configuration. In examples, a WTRU may explicitly confirm reception of interdependent messages based on the reception of a second message that includes an interdependency characteristic as described herein. In examples, a WTRU may implicitly confirm reception of interdependent messages based on not receiving a conflicting message, e.g., within a time period. A WTRU may be configured with a CU RRC entity and / or SRB (e.g.,SRB1) and a DU RRC entity and / or SRB (e.g., SRBx). A WTRU may be configured with an interdependence RRC message reception time duration (e.g., by the CU). A WTRU may receive a first RRC message (e.g., on SRBx) from the DU. The first RRC message may include an interdependency value and / or indication (e.g., an interdependency characteristic). A WTRU may store the received first RRC message and may initiate an interdependence RRC message timer (e.g., the WTRU may initiate the interdependence RRC message timer based on the reception of the first RRC message). The timer value may be set to the configured interdependence RRC message reception time duration.

[0182] The WTRU may determine a confirmation of the first RRC message (e.g., determine that one or more conditions are satisfied as described herein). For example, the WTRU may receive a second RRC message from the CU that includes the interdependency value and / or indication corresponding to (e.g., is the same as the interdependency value and / or indication in) the first message, and / or the interdependency value and / or indication is received within the configured interdependency RRC message reception time duration. If the confirmation of the first RRC message is determined by the WTRU (e.g., the second RRC message includes the interdependency characteristic value and / or indication and / or the second RRC message is received before expiration of the configured interdependence RRC message reception timer), the WTRU may apply configuration(s) in the first and / or second RRC message (e.g., if applicable). If the confirmation of the first RRC message is determined by the WTRU, the WTRU may send reconfiguration complete message(s), for example, two (e.g., separate) reconfiguration complete messages (e.g., one on SRB1 and one on SRBx).

[0183] If the confirmation of the first RRC message is not determined by the WTRU, for example, the time duration (e.g., the interdependence RRC message reception timer) elapsed before a reception of asecond interdependent RRC message, the WTRU may perform one or more of the following. The WTRU may send reconfiguration failure message(s), for example two reconfiguration failure messages (e.g., one on SRB1 and one on SRBx). A reconfiguration failure message may indicate a (e.g., new) failure cause value (e.g., “unable to receive interdependent RRC message from CU / DU”). The WTRU may trigger a reestablishment procedure.

[0184] A WTRU may be configured with interdependent RRC messages. A WTRU may be configured with (e.g., receive configuration information via) RRC messages. The RRC messages may be received from different nodes (e.g., a first node and a second node, where the first and second node may be interchangeably referred to in examples herein as a CU or a DU). The RRC messages may be implicitly / explicitly identified as having an interdependence. The presence of an interdependence between RRC messages may affect behavior at the WTRU. In examples, the interdependence may impact if / when / how the WTRU applies (e.g., each) configuration(s), if / when / how the WTRU confirms that configuration(s) were received correctly, if / when / whether / how the WTRU performs a recovery procedure (e.g., in the case the configuration information was not applied correctly).

[0185] RRC messages from the CU and DU may include an identifier or a sequence number. Matching sequence numbers (e.g., or matching identifiers) may represent interdependent RRC messages. In examples, a first RRC message from the CU RRC including a first sequence number (e.g., “x”) may be interdependent with a second RRC message from the DU RRC including the same sequence number (e.g., “x”). If an RRC message received from a CU or a DU does not include a sequence number (e.g.., any sequence number), the WTRU may determine that the RRC message does not have an interdependence (e.g., any interdependence with another RRC message).

[0186] An RRC message (e.g., from the DU / CU) may include an interdependence indicator (e.g., as an IE in the RRC message). Based on the reception of an RRC message including an interdependence indicator, the WTRU may assume the subsequent message (e.g., from the CU / DU, potentially having the same interdependence indicator), may be the corresponding RRC message with an interdependence.

[0187] The WTRU may determine that an RRC message has an interdependence relationship based on the presence / absence of information in the RRC message. In examples, if an IE is present / not present in the RRC message, the WTRU may interpret the RRC message as an interdependent RRC message. In examples, an RRC message from the DU that does not include a configuration element associated with the CU (e.g., PDCP or SDAP configuration) may represent a first RRC message that has a relationship with a second RRC message that may be expected from the CU (e.g., may represent an RRC message having an interdependency with a second RRC message expected from the CU).

[0188] The WTRU may determine that an RRC message may have an interdependent relationship based on the reception of two RRC messages from multiple nodes (e.g., different nodes) that modify a parameter (e.g., the same parameter(s)), include the same IE(s), or modify a protocol layer (e.g., the same protocol layer). In examples, the WTRU may receive a first RRC message from the DU that modifies a PHY or MAC layer parameter, or that includes a PHY or MAC layer parameter. If the WTRU receives a second RRC message from the CU that also modifies the same parameter (e.g., the same PHY or MAC layer parameter), the WTRU may consider the second RRC message as having an interdependence on the first RRC message.

[0189] A WTRU behavior or action may depend on reception of an interdependence RRC message (e.g., reception of an interdependent RRC message). A WTRU may obtain a first RRC message (e.g., from the CU / DU) that may have an interdependence with a second RRC message (e.g., a corresponding RRC message to be received from the DU / CU). In examples, the WTRU may be configured with an interdependence timer. The WTRU may receive the interdependence timer (e.g., an indication of a value, such as a time duration) in signaling (e.g., dedicated signaling), for example from the CU or from the DU, where the received indication may be received prior to reception of a (e.g., any) interdependent RRC messages. The WTRU may receive the interdependence timer from (e.g., via) a SIB. The interdependence timer may be predefined.

[0190] Based on the reception of a first RRC message with an interdependence to a second RRC message, the WTRU may perform one or more actions. For example, the WTRU may wait for a corresponding RRC message from the other node (e.g., wait for a second RRC message from a second node such as a CU or a DU) prior to applying the configuration. In examples, following reception of a first RRC message from a first node associated with an interdependence relation, the WTRU may wait for reception of the corresponding RRC message from the other node before applying the configuration (e.g., the WTRU may wait for reception of the second interdependent RRC message from a second node before applying the configuration(s) indicated in the first and / or second RRC message). Successful reconfiguration may be dependent on reception and / or application of both dependent configurations prior to expiry of a timer. For example, the WTRU may start an interdependence timer upon reception of a first RRC message (e.g., from the DU) that has a dependency with a second RRC message (e.g., an expected message to be received from the CU). If the timer expires without reception of the second RRC message (e.g., without reception of the corresponding CU RRC message), the WTRU may initiate an error procedure. If the WTRU receives the second RRC message (e.g., the corresponding CU RRC message), the WTRU may apply both configurations (e.g., configurations associated with the first and second RRC message) andmay initiate a success procedure (e.g., possibly initiate a success procedure if both configurations are applied successfully).

[0191] The WTRU may wait to ensure that a cancellation message from the second node (e.g., the other node) is not received before applying the configuration(s) (e.g., before applying configuration(s) associated with the first and / or second RRC message). In examples, following reception of a message from a first node associated with an interdependence relation, the WTRU may wait for reception of (e.g., potential reception of) an interdependent message from a second node before applying the configuration (e.g., the configuration associated with the first RRC message). Absence of reception of a second RRC message from a second node (e.g., reception of a corresponding message from the other node) may correspond to successful reconfiguration.

[0192] For example, the WTRU may start an interdependence timer upon reception of a first RRC message (e.g., from the DU). The first RRC message may be associated with an interdependence with a second RRC message (e.g., another RRC message). In some examples, a second RRC message may not be associated with an interdependence (e.g., a second RRC message may not have an interdependence with a first RRC message, for example, the two messages do not have the same interdependency characteristic, and / or the like). In examples, the WTRU may initiate a timer based on the reception of a first RRC message from a node (e.g., based on any message received from a DU or a CU). If / when the timer expires without receiving a second RRC message from a second node (e.g., the other node such as the CU), the WTRU may apply the configuration (e.g., the WTRU may apply the configuration associated with the first RRC message) and / or initiate a success procedure (e.g., possibly initiate a success procedure). In some examples, if the WTRU receives a second RRC message from a second node (e.g., the WTRU receives a message from the other node such as the CU), the WTRU may initiate an error procedure. The message from the other node in this example may be a message (e.g., explicitly) indicating an error, or indicating cancellation of the previously received RRC message from the peer node (e.g., the second RRC message from the second node that triggers the WTRU to initiate an error procedure may indicate an error, or may indicate a cancellation of the first RRC message from the first node). For example, the RRC message that triggers an error procedure (e.g., the RRC message that triggers the WTRU to initiate an error procedure) may be interdependent with the received first RRC message. For example, the RRC message that triggers the WTRU to initiate an error procedure may configure the same RRC parameter(s) as the first RRC message. For example, the RRC message that triggers the WTRU to initiate an error procedure may include an IE indicating an interdependence as described herein.

[0193] The WTRU may apply the configuration (e.g., the WTRU may apply the configuration information associated with a first RRC message) while waiting to receive a second RRC message (e.g., a subsequentmessage). In examples, following reception of a first RRC message from a first node, the WTRU may apply (e.g., first apply) the configuration associated with the first RRC message and initiate a timer. Successful reconfiguration may depend on reception and / or application of a second RRC message from the second node prior to the expiry of the timer. For example, the WTRU may start an interdependence timer based on the reception and / or successful application of a first RRC message (e.g., from the DU) that has dependency with a second message (e.g., an expected message to be received from the CU). If the timer expires without reception of the second RRC message (e.g., the corresponding CU RRC message), the WTRU may initiate an error procedure. If the WTRU receives the second RRC message (e.g., the corresponding CU RRC message), the WTRU may apply both configurations (e.g., apply the configuration associated with the first and second RRC messages) and / or initiate a success procedure (e.g., possibly initiate a success procedure if both configurations are applied successfully). In examples, the WTRU may initiate a failure procedure (e.g., the WTRU may initiate a failure procedure if the first or second configuration is not applied successfully).

[0194] In examples, the WTRU may start an interdependence timer based on the failed application of a first RRC message, e.g., if the first RRC message is indicated as having a dependency (e.g., if the first RRC message includes an interdependency characteristic as described herein). If the WTRU receives a second RRC message (e.g., receives a configuration associated with the second RRC message) before the timer expires, and application of the first configuration and the second configuration are successful, the WTRU may assume a successful configuration (e.g., if the WTRU receives the second RRC message before expiration of the timer and application of a first and second configuration associated with the first and second RRC messages is successful, the WTRU may initiate a success procedure as described herein). In an example, the WTRU may initiate an error procedure (e.g., any error procedure discussed herein if one or more configurations are not applied successfully). In examples, a WTRU may have a (e.g., some) limited operational behavior as described herein, between the time in which the first configuration failed, and the second configuration was received and both configurations were successfully applied (e.g., a WTRU may have limited operational behavior, for example if a first configuration is applied on its own, the first configuration may fail (e.g., exceeds a WTRU capability), but if the first configuration and a second configuration are both applied, then they may both succeed (e.g., applying them both results in the WTRU not exceeding a capability)).

[0195] The WTRU may apply the configuration (e.g., the configuration associated with the first RRC message) and ensure that a second RRC message (e.g., a subsequent message) is not received. In examples, following reception of a first RRC message from a first node, the WTRU may first apply the configuration (e.g., the configuration associated with the first RRC message) and initiate a timer.Successful reconfiguration may depend on whether a second RRC message is received prior to expiry of the timer. For example, the WTRU may start an interdependence timer upon reception and / or successful application of a first RRC message (e.g., from the DU). If the timer expires without reception of a second RRC message (e.g., a corresponding CU RRC message), the WTRU may initiate a success procedure. If the WTRU receives the second RRC message (e.g., a corresponding CU RRC message) prior to timer expiry, the WTRU may initiate a failure procedure (e.g., as described herein).

[0196] The WTRU may ensure that the interdependent RRC messages are received in an order (e.g., a specific order). In examples, the WTRU may ensure that RRC messages having an interdependence are applied in an order (e.g., the WTRU may ensure that configuration(s) associated with a first and a second RRC message are applied in a specific order). An order may be indicated in the interdependent RRC message(s), or an order may be defined in specifications (e.g., a DU RRC message first). For example, the WTRU may receive a DU / CU RRC message including an interdependence of the DU / CU RRC message with a corresponding CU / DU RRC message. The WTRU may further receive an indication (e.g., in the DU / CU RRC message) that the CU / DU RRC message may be applied first. In examples, the WTRU may initiate a timer before applying the received DU / CU RRC message and wait for the corresponding CU / DU RRC message (e.g., wait for the interdependent CU / DU RRC message including a second configuration). If the CU / DU RRC message is received before the expiry of the timer, the WTRU may apply both configurations (e.g., possibly applying CU / DU first) and / or initiate a success procedure. If the timer expires, the WTRU may initiate an error procedure (e.g., the WTRU may initiate an error procedure if the timer expires before receiving the CU / DU RRC message).

[0197] In examples, if the WTRU receives a DU / CU RRC message indicating that the DU / CU RRC message may be applied first, the WTRU may apply the DU / CU RRC message (e.g., the WTRU may apply a configuration associated with the DU / CU RRC message (e.g., immediately) if the DU / CU RRC message indicates that the DU / CU RRC configuration is applied first). The WTRU may apply any of the above procedures (e.g., a success procedure, a failure procedure, etc.) with regards to reception of the interdependent CU / DU RRC message within the configured timer.

[0198] The WTRU may select a first or a second interdependent configuration to apply (e.g., the WTRU may select one of the two interdependent configurations associated with the first and second RRC messages to apply). In examples, a WTRU may receive interdependent configuration(s) and select a configuration and apply the selected configuration (e.g., select and apply one of two configurations). The WTRU may be configured with rules regarding which configuration to select. For example, the WTRU may apply the DU / CU configuration, or the WTRU may apply the DU / CU configuration if condition(s) are met (e.g., if some condition(s) are met). Condition(s) may include one or more of the conditions mentionedherein. For example, the WTRU may rely on a WTRU implementation to select between the DU or the CU (e.g., select a configuration associated with the DU or the CU).

[0199] The WTRU may, based on the reception of a first configuration from the DU / CU, receive an interdependent second configuration from the CU / DU (e.g., the WTRU may receive a first configuration via a first RRC message and a second configuration via a second RRC message). The WTRU may select the configuration(s) to apply and / or may initiate a success procedure.

[0200] A WTRU may select which of two interdependent received configurations to apply. A WTRU may receive two interdependent configurations and may determine which to apply or whether to apply both configurations. A WTRU may base such decisions on at least one of a WTRU capability, a power consumption, cell measurements, a WTRU location, a WTRU speed, a connection type, or a SIB broadcast by the cell.

[0201] In examples, a WTRU may base such decisions on capabilit(ies) of the WTRU. For example, a WTRU may select the configuration that meets its capabilities, which results in the use of the fewest of its capabilities, etc.

[0202] In examples, a WTRU may base such decisions on power consumption. For example, a WTRU may select the configuration that results in a minimum power consumption.

[0203] In examples, a WTRU may base such decisions on cell measurements. For example, a WTRU may select the configuration that results in performing measurements on the cells which are in the best condition at the time of reception of the configurations.

[0204] In examples, a WTRU may base such decisions on WTRU location. For example, a WTRU may be configured with locations / zones where it may prefer the DU configuration or the CU configuration (e.g., the WTRU selects the preferred configuration).

[0205] In examples, a WTRU may base such decisions on WTRU speed. For example, if the WTRU speed is above a threshold, the WTRU may select the CU configuration over the DU configuration.

[0206] In examples, a WTRU may base such decisions on connection type. For example, if a WTRU is connected on sidelink (e.g., via a relay), it may select the configuration from a first node over a second node (e.g., may select one node over another node).

[0207] In examples, a WTRU may base such decisions on a SIB broadcast by the cell. For example, if a WTRU received (e.g., specific) information from the cell (e.g., support of a feature, support of a parameter, etc.), it may select the RRC message from one node.

[0208] A WTRU may trigger (e.g., initiate) a success procedure as described herein. The WTRU may trigger a success procedure based on one or more conditions. A success procedure at the WTRU mayinclude at least one of: sending an RRC message (e.g., RRCReconfigurationComplete) to a node (e.g., each of the nodes); sending an RRC message (e.g., RRCReconfigurationComplete) to one of the nodes (e.g., sending an RRC message to one of two nodes); or sending a success message (e.g., RRCReconfigurationComplete) to one node and sending a failure message (e.g., RRCReconfigurationFailure) to a second node (e.g., depending on the configuration that the WTRU decides to apply).

[0209] In examples, a success procedure may include sending an RRC message (e.g., RRCReconfigurationComplete) to a node (e.g., sending an RRC message to each of the nodes). For example, based on the reception and / or application of the DU RRC message, the WTRU may send a first RRC message (e.g., reconfiguration complete) to the DU. For example, based on the reception and / or application of the CU RRC message, the WTRU may send a second RRC message (e.g., reconfiguration complete) to the CU. For example, the WTRU may send an RRC message to the CU and an RRC message to the DU after successful reception and / or application of both CU and DU RRC reconfiguration messages.

[0210] For example, the WTRU may send an RRC message to the CU and an RRC message to the DU after reception of an RRC reconfiguration message (e.g., after expiry of a timer, for example a timer associated with reception of the RRC reconfiguration message as described herein) from a first node (e.g., the DU), for example if an interdependent RRC message is not received from the second node (e.g., the CU) before expiry of a timer (e.g., before expiration of an interdependence RRC message timer).

[0211] For example, the WTRU may send a first RRC message to the DU after the WTRU receives and / or applies a first configuration (e.g., received from the DU). The WTRU may send a second RRC message to the CU following expiry of a timer after reception and / or application of the first received RRC message for example if an interdependent RRC message is not received from the CU during the period the timer is running.

[0212] In examples, a success procedure may include sending an RRC message (e.g., RRCReconfigurationComplete) to one node (e.g., only one of the nodes). For example, the WTRU may send an RRC message to a first node (e.g., the CU) after successful reception and / or application of both CU and DU RRC reconfiguration messages (e.g., a WTRU may successfully apply configurations associated with a first and a second RRC message, and send an RRC message (e.g., RRCReconfigurationComplete) to only the first or the second node).

[0213] For example, the WTRU may send an RRC message to a second node (e.g., the CU) after receiving an RRC reconfiguration message (e.g., after expiry of a timer, for example a timer associated with reception of the RRC reconfiguration message as described herein) from a first node (e.g., the DU), forexample, provided that an interdependent RRC message is not received from the second node (e.g., the CU) before expiry of a timer (e.g., an interdependence RRC message timer).

[0214] In examples, a success procedure may include sending a success message (e.g., RRCReconfigurationComplete) to a first node and a failure message (e.g., RRCReconfigurationFail ure) to a second node depending on the configuration the WTRU decides to apply. For example, after a WTRU receives two interdependent RRC messages (e.g., a first and a second RRC message from the CU and the DU), if the WTRU decides to apply the DU configuration, the WTRU may send a success message to the DU and a failure message to the CU, or if the WTRU decides to apply the CU configuration, the WTRU may send a success message to the CU and a failure message to the DU.

[0215] A WTRU may trigger (e.g., initiate) a failure procedure as described herein. The WTRU may trigger a failure procedure based on one or more conditions. A failure procedure at the WTRU may include one or more of: sending an RRC failure message (RRCReconfigurationFailure) to both nodes; sending an RRC failure message (RRCReconfigurationFailure) to a node (e.g., only one node), not applying the received configuration and keeping the current configuration; triggering a re-establishment procedure; or triggering a conditional mobility procedure.

[0216] A failure or success message may be sent (e.g., a failure or success message may include one or more aspects as described herein). The failure or success message may comprise one or more of a failure cause; an identity associated with an interdependence message; or a configuration provided to the WTRU by the other node.

[0217] A failure or success message may include a failure cause. An RRC reconfiguration failure message may include a failure cause related to interdependent RRC messages. The failure cause may indicate that the WTRU is unable to apply a configuration associated with a first received interdependent configuration (e.g., a first received interdependent configuration as part of a first RRC message). The failure cause may indicate that the WTRU is unable to apply a configuration associated with a second received interdependent configuration (e.g., a second received interdependent configuration as part of a second RRC message). The failure cause may indicate an expiry of a timer while waiting for reception of a second interdependent configuration. The failure cause may indicate that the WTRU failed to apply a second reconfiguration following a successful application of a first reconfiguration (e.g., the WTRU failed to apply a second configuration information following a successful application of a first configuration information). The failure cause may indicate that the WTRU failed to apply a first reconfiguration followed by a successful application of a second reconfiguration. The failure cause may indicate that the WTRU is unable to apply both configurations successfully.

[0218] A failure or success message may include an identity associated with an interdependence message (e.g., an identity of the failed message, possibly provided by the other node). For example, the WTRU may provide the CU or DU with an identifier received in the configuration message (e.g., received as part of the configuration information in the RRC message) from the DU or CU that caused the error, or the configuration that was applied successfully.

[0219] A failure or success message may include a configuration provided to the WTRU by a node (e.g., provided by the other node that sent an RRC message causing a failure). For example, the WTRU may provide the CU or DU with the configuration (e.g., or an index identifying the configuration) that was received from the DU or CU, that was last applied, that last triggered an error, or that is currently applied at the WTRU.

[0220] Temporary / Conditional application of a reconfiguration may be provided. A WTRU may determine whether to revert to a previous configuration based on an error condition occurring following application of a configuration (e.g., a new configuration). A WTRU may be configured with a CU RRC entity and / or SRB (e.g., SRB1) and a DU RRC entity and / or SRB (e.g., SRBx). A WTRU may be configured with an error checking time and a configuration from the CU for checking one or more error condition (e.g., measurement event, RLF-like trigger, etc.). A WTRU may receive a first RRC message (e.g., on SRBx from the DU) and apply the configuration in the RRC message.

[0221] If one or more of the configured error conditions occurs within the configured error checking time from the time the configuration was applied, the WTRU may perform a number of actions. The WTRU may trigger a measurement event. The WTRU may trigger an RLF-like condition. The WTRU may revert to a determined DU configuration (e.g., previous, default, etc.). The WTRU may send (e.g., two) reconfiguration failure messages (e.g., one on SRB1 and one on SRBx) and indicate a failure cause value in (e.g., a new failure cause value such as “Failure following DU reconfiguration”) and the identity of the error condition.

[0222] A WTRU may determine a configuration failure following an evaluated error occurring after the configuration is applied. In examples, a WTRU may detect a configuration failure following successfully applying the configuration (e.g., and initiating operation with that configuration) by detecting a configured error condition associated with the operation following application of the configuration. In examples, a WTRU may successfully apply a configuration. The configuration may be received from the CU or from the DU. For example, such configuration may be received from the DU and may configure RRC parameters associated with the DU (e.g., RLC, MAC, PHY). Following the successful application of the configuration, the WTRU may operate with the configuration (e.g., new configuration). The WTRU may, at successful application of the configuration, begin to monitor for an error condition. The WTRU may determine that theconfiguration is failed if the monitored error condition is met (e.g., possibly within some configured time of reception / application of the configuration).

[0223] One or more error conditions may be monitored. A WTRU may be configured with one or more error conditions to monitor upon reception / application of a configuration (e.g., possibly where the configuration is associated with an interdependency). The error conditions may be predefined in the specification. The error conditions may be further configured by RRC (e.g., by one of the two nodes, possibly by an RRC configuration that is not subject to checking for error conditions). The WTRU may monitor for one or multiple such error conditions. The error conditions may be monitored for one or more (e.g., all) reconfigurations the WTRU applies. For example, the WTRU may monitor for error conditions associated with a type or content of a reconfiguration message. For example, an RRC reconfiguration may have an indication / identifier that the WTRU uses for determining whether to perform error checking following the application of the configuration. For example, the WTRU may be configured with different checking conditions and / or different checking configuration parameters associated with a (e.g., single) condition, and the RRC reconfiguration message may indicate (e.g., explicitly) the condition to be checked (e.g., using an index).

[0224] The WTRU may monitor for an error condition associated with one or more of: a conditions related to cell measurements (e.g., of neighbor cells or the serving cell); conditions related to channel quality measurements (e.g., channel quality indicator (CQI)) or similar physical layer measurements; conditions related to RLF monitoring; conditions related to hybrid automatic repeat request (HARQ) feedback; conditions related to transmit power; conditions related to data rate, latency, or performance of data transmission / reception; conditions related to beam failures; conditions related to unlicensed access; conditions related to time; conditions related to WTRU capability; conditions related to the trigger of WTRU assistance information (e.g., for suggested DRX, overheating, or other triggers for WTRU assistance); conditions related to QoS / QoE; a combination thereof; and / or the like.

[0225] The WTRU may monitor for an error condition associated with conditions related to cell measurements (e.g., of neighbor cells or the serving cell). For example, the WTRU may be configured with a condition associated with the quality of the serving cell measurement or the change in the quality of the serving cell measurement (e.g., the quality changes by at least a threshold amount within the configured time period).

[0226] For example, the WTRU may be configured with a condition associated with the quality of one or more neighbor cell measurements, such as a change in quality, a number of measured neighbor cells that may be above a threshold condition, a combination thereof, and / or the like.

[0227] A change in quality may be a change in the quality of one or more neighbor cell measurements by at least an amount within the configured time period. The number of measured neighbor cells that are above a threshold condition may be a number of measured neighbor cells that are above a threshold change by at least a threshold number within the configured time period.

[0228] The WTRU may monitor for an error condition associated with conditions related to channel quality measurements (e.g., CQI) or similar physical layer measurements. For example, the measured CQI decreases by at least a threshold amount within the configured time period. For example, the measured CQI becomes below a threshold within the configured time period.

[0229] The WTRU may monitor for an error condition associated with conditions related to RLF monitoring. For example, the WTRU detects one or a configured number of out of sync (OOS) indications from the lower layers, where the configured number may be different than the value associated with RLF. In examples, the WTRU may be configured with a number (N) of consecutive OOS indications. Following a successfully applied reconfiguration, if the WTRU detects N consecutive OOS indications from lower layers, the WTRU may trigger an error procedure.

[0230] The WTRU may monitor for an error condition associated with conditions related to HARQ feedback. For example, the WTRU receives one or a configured consecutive number of HARQ NACK / HARQ DTX associated with its data transmissions following successful application of a configuration. For example, the WTRU transmits one or a configured consecutive number of HARQ NACK associated with received data.

[0231] The WTRU may monitor for an error condition associated with conditions related to transmit power. For example, the WTRU’s calculated transmit power may exceed a configured threshold. For example, the WTRU’s calculated headroom may reach a configured value. For example, the WTRU may be forced to increase / decrease its transmit power by / beyond a configured amount as a result of other procedures for determining transmit power.

[0232] The WTRU may monitor for an error condition associated with conditions related to data rate, latency, or performance of data transmission / reception. For example, the WTRU’s buffer occupancy may increase by / beyond a configured amount. For example, the WTRU may determine that one or more configured PDUs are unable to meet a configured latency parameter (e.g., requirement). For example, the WTRU may drop one or a configured number of PDU requested (e.g., required) latency associated with the PDU set.

[0233] The WTRU may monitor for an error condition associated with conditions related to beam failures. For example, the WTRU may trigger one or a configured number of beam failures. The WTRU may trigger beam failure detection / recovery procedures, one or a configured number of times.

[0234] The WTRU may monitor for an error condition associated with conditions related to unlicensed access. For example, the WTRU may trigger one or a configured number of listen-before-talk (LBT) failures when operating on an unlicensed spectrum. For example, the WTRU may trigger one or a configured number of consistent LBT failures when operating on an unlicensed spectrum.

[0235] The WTRU may monitor for an error condition associated with conditions related to time. For example, one or more (e.g., any) of the conditions herein may be considered for a period of time following the reception of the handover / reconfiguration, where the aforementioned time may be further configured by the network. In examples, the WTRU may trigger an error procedure if a configured condition occurs within a configured time following the successful application by the WTRU of a received reconfiguration. In examples, the WTRU may trigger an error procedure if a condition may be satisfied for a period of time following the successful application by the WTRU of a received reconfiguration.

[0236] The WTRU may monitor for an error condition associated with conditions related to WTRU capability. For example, if the application of the received configuration results in the WTRU exceeding its capabilities (e.g., possibly after some time operating with the configuration), the WTRU may trigger an error procedure.

[0237] The WTRU may monitor for an error condition associated with conditions related to the trigger of WTRU assistance information (e.g., for suggested DRX, overheating, or other triggers for WTRU assistance). For example, the WTRU may trigger overheating following successful application of the received configuration. For example, the WTRU may trigger a suggested DRX following successful application of the received configuration. For example, the WTRU may trigger a change in the periodicity / rate associated with configured uplink resources following the application of the configuration.

[0238] The WTRU may monitor for an error condition associated with conditions related to quality of service / quality of experience (QoS / QoE). For example, the WTRU may measure a metric, such as quality of experience. If the metric is below an acceptable amount, the WTRU may trigger an error procedure.

[0239] A WTRU, upon one or more (e.g., any) of the error conditions described herein being met, may trigger an error procedure. An error procedure may comprise one or more of suspending SRB transmissions (e.g., possibly to one of the nodes); suspending DRB transmission; reverting to another configuration; performing a recovery procedure; performing limited operational behavior as described herein; performing RRC message transmission; a combination thereof; and / or the like.

[0240] An error procedure may comprise suspending SRB transmissions (e.g., possibly to one of the nodes). Upon satisfying an error condition, the WTRU may suspend transmission on SRB. The WTRU may suspend transmission on SRB (e.g., to CU or DU (e.g., only). In examples, which SRB may be suspended may depend on the error condition itself, and / or where the applied configuration that triggered the error wasreceived from. In examples, if the WTRU receives and applies a configuration from the DU that results in an error condition, the WTRU may suspend one or more (e.g., all) SRB transmissions to the DU.

[0241] An error procedure may comprise suspending DRB transmission. Upon satisfying an error condition, the WTRU may suspend one or more DRB transmissions. For example, the WTRU may suspend transmissions of (e.g., some) DRBs based on configuration or based on the condition that caused the failure.

[0242] An error procedure may comprise reverting to another configuration. The WTRU may apply another configuration upon triggering an error procedure. The configuration may comprise one or more of a default configuration, a previous configuration, a WTRU determined configuration, a combination thereof, and / or the like.

[0243] The configuration may be a default configuration. For example, the WTRU may be configured with, or specifications may define, a default configuration. The WTRU may apply the default configuration following the triggering of an error condition. The default configuration may apply to one or more parts of the Uu RRC configuration. For example, the WTRU may apply parts of the default configuration associated with aspects of its configuration, where the aspects of its configuration to be applied may be determined by the nature of the failure. For example, the WTRU may determine the part of the default configuration to apply based on the specific error. For example, the WTRU may be provided (e.g., in the configuration of the error condition) with the specific part of the default configuration to apply in the case of an error. For example, the WTRU may determine the part of the default configuration to apply based on the layer or aspect of the WTRU's RRC configuration that triggered the failure (e.g., a PHY-related failure / error may cause the WTRU to apply the PHY related default configuration).

[0244] The configuration may be a previous configuration. For example, the WTRU may revert to an RRC configuration which it had previously applied successfully. The previous configuration may comprise one or more of: an RRC configuration that was provided by a node; an RRC configuration that was provided with or without full configuration or a delta configuration; an RRC configuration that was successfully applied in the past and that did not trigger an error procedure; a combination thereof; and / or the like.

[0245] In examples, the previous configuration may be an RRC configuration that was provided by a specific node. For example, the WTRU may revert to the RRC configuration that was previously provided by the CU. For example, the WTRU may revert to the RRC configuration that was previously provided by the DU. For example, the WTRU may revert to the RRC configuration that was previously provided by the node which may be the same or different than the node that provided the RRC configuration which led to the triggering of the error.

[0246] In examples, the previous configuration may be an RRC configuration that was provided with / without full configuration or delta configuration. For example, the WTRU may revert to the last RRC configuration provided to it using full configuration.

[0247] In examples, the previous configuration may be an RRC configuration that was successfully applied in the past, and which did not trigger any error procedures. For example, the WTRU may select (e.g., any) an RRC configuration that it applied in the past. The WTRU may indicate to the network the applied RRC configuration as part of the error procedure. For example, the WTRU may be configured with a time period (e.g., a minimum time since, a maximum time since, or both) prior to the reception of the configuration or triggering of the error for which it may use the RRC configuration that was applied at the WTRU at that time period.

[0248] The configuration may be a WTRU-determined (e.g., and indicated) configuration. For example, the WTRU may select or determine a configuration for operation and inform the network of the selected or determined configuration, either directly (e.g., by signaling the determined parameters) or indirectly (e.g., by providing the index to a configured or agreed upon set of parameters associated with a configuration).

[0249] For example, the WTRU may operate with its own selected configuration. A configuration may further be selected from a list of provided configurations or previous configurations. The WTRU may inform the network of the configuration in RRC signaling performed as part of the error procedure. For example, the WTRU may provide an index to a set of numbered configurations, where the network assigns an index to the corresponding configuration. For example, the index may be provided in the RRC reconfiguration message when the WTRU received a configuration over the past.

[0250] For example, the WTRU may select one of its past configurations based on a metric measured at the WTRU (e.g., QoS, QoE, etc.). The WTRU may select a configuration that has at least a configured level of QoE.

[0251] For example, the WTRU may select a configuration based on prediction of the configuration that results in the maximization of a metric which may be QoS / QoE related, or measurement related. For example, the WTRU may predict (based on measurements of the channel, measurements of HARQ feedback sequences, measurement of transmission / reception delay, etc.) the RRC configuration which may result in minimization of delay, maximization of reliability, minimization on decoding error, maximization in QoE, etc. Based on such prediction, the WTRU may apply a configuration. For example, the WTRU may select from a list of provided configurations to choose the configuration which most closely reflects the predicted configuration.

[0252] An error procedure may comprise performing a recovery procedure. For example, the WTRU may trigger a recovery procedure such as re-establishment, MCG / SCG failure, conditional handover, or similar legacy procedures for recovery.

[0253] An error procedure may comprise performing an operational behavior or action (e.g., a limited operational behavior) as described herein.

[0254] An error procedure may comprise performing RRC message transmission. In examples, a WTRU may perform RRC message transmission to the CU and / or DU. The RRC message transmission may occur at the application of the received configuration and / or following triggering of an error condition. RRC message transmission occurring after the triggering of an error condition may further refer to the previous message transmission, the applied configuration, and / or the error condition that was triggered.

[0255] Following the triggering of an error condition caused by a DU configuration, the WTRU may transmit separate error messages to both the CU and the DU. These may be the same error message or may be different error messages. For example, the WTRU may transmit a reconfig uration Fail ure message to the DU and a UEAssistancelnformation message to the CU.

[0256] For example, the WTRU may include a failure message to the CU and / or the DU. The message may include a (e.g., new) cause value indicating the failure (e.g., “error triggered as a result of DU reconfiguration”). The message may include an indication of the specific error condition (e.g., an index to an error condition in a configuration message) that triggered the error procedure. The message may include an elapsed time since the error condition was triggered. The message may include an index or indication of the configuration that was used while the error was triggered. The message may include an index or indication of the configuration selected by the WTRU and / or applied as a result of the condition being triggered. The message may include an index or indication of the model or computation used by the WTRU to determine its own configuration.

[0257] The RRC message transmission by the WTRU may occur both at application of the configuration and triggering of the error condition. For example, the WTRU may transmit a first message to the DU (e.g., ConfigurationComplete) when it applies the configuration, and may transmit a second message to the DU (e.g., reconfigurationFailure) and a third message to the CU (UEAssistancelnformation) when the trigger of the error condition occurs. For example, the first message transmitted (e.g., to the DU) (e.g., ConfigurationComplete) may further indicate whether the WTRU performs monitoring of the error condition or not.

[0258] WTRU may determine whether monitoring of an error condition may be performed following application of a reconfiguration.

[0259] A WTRU may be configured with one or more error conditions to monitor the reception / application of an RRC configuration / HO (e.g., received from the DU). The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on one or more factors. The one or more factors may comprise one or more of an availability of data for transmission; a type of data available for transmission; a radio quality; reception of and / or time between reception of reconfigurations, possibly from CU and / or DU; a nature of the reconfiguration (e.g., reconfiguration with sync, etc.); parameters modified in the reconfiguration; usage of WTRU capabilities; a combination thereof; and / or the like.

[0260] The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on an availability of data for transmission. For example, if the WTRU may have at least a configured amount of data available for transmission, the WTRU may perform monitoring of one or more possible error conditions.

[0261] The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on a type of data available for transmission. For example, if the WTRU haves data available for transmission, has one or more properties (e.g., latency, reliability, or other QoS property meets some criteria), the WTRU may perform monitoring of one or more possible error conditions.

[0262] The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on a radio quality. For example, the WTRU may be configured with a condition on the radio quality of a cell (e.g., serving cell, target cell of the HO, etc.) in which monitoring of the error condition may be performed. The error condition may be, for example, RSRP below a threshold, CQI below a threshold, beam measurement(s) below a threshold, etc.

[0263] The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on a reception of and / or time between reception of reconfigurations, possibly from CU and / or DU. For example, the WTRU may be configured with a condition on the timing between reception of reconfiguration messages from the CU and / or the DU that determines whether monitoring of the error condition has been requested. For example, if the DU reconfiguration is received within a configured period of time before / after a CU reconfiguration, the WTRU may not perform monitoring for the error condition. For example, if a CU configuration may be received within a duration of time after receiving a DU configuration, the WTRU may stop performing error condition monitoring. For example, if the WTRU receives a dependent CU configuration to the received DU configuration (e.g., as per description of dependent configurations herein) the WTRU may not perform monitoring of an error condition.

[0264] The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on the nature of the reconfiguration (e.g., reconfiguration with sync, etc.). For example, the WTRU may perform monitoring of an error condition for specific types of reconfigurations, such as upon reception of reconfiguration with sync (e.g., compared to reconfiguration without sync), reception of full reconfiguration (e.g., as opposed to a delta reconfiguration), and / or the like.

[0265] The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on one or more parameters modified in the reconfiguration. For example, the WTRU may perform monitoring of an error condition (e.g., only) when the reconfiguration modifies predefined or configured parameters. For example, monitoring may be performed when the DU changes specific parameters which are also configurable by the CU, or which normally are to be configured by the CU. The motivation for such is that a reconfiguration performed autonomously by the DU may not affect the CU (e.g., as long as the reconfiguration may be limited to some parameters).

[0266] The WTRU may determine whether to apply the monitoring of the error condition or not, or potentially the error conditions to be checked, based on a usage of WTRU capabilities. For example, the WTRU may perform monitoring if the WTRU is using at least a specific percentage of its capabilities (e.g., in terms of carriers, band usage, etc.).

[0267] WTRU determination of a dependent configuration may be provided. A WTRU may (e.g., opportunistically) determine or change a configuration at the CU following a configuration change at the DU, which may cause inconsistency in the full WTRU configuration. The WTRU may receive a first RRC message that includes a CU configuration and applies the received configuration. The WTRU may receive a set of allowable or unallowable CU configurations for a cell from the CU through SRB1 , which may be stored.

[0268] The WTRU may receive a second RRC message (e.g., on SRBx from the DU) that includes a DU configuration. If applying the DU configuration, along with the current first CU configuration, results in a reconfiguration failure due to exceeding WTRU capabilities, the WTRU may choose to select and apply one of the allowable CU configurations that results in a successful RRC reconfiguration (e.g., when both the CU and DU configurations are applied). The WTRU may apply the DU configuration from the second RRC message and transmit an identity that indicates the chosen CU configuration to the CU (e.g., through SRB1).

[0269] In examples, if applying the DU configuration does not lead to a reconfiguration failure, the WTRU may apply the DU configuration from the first RRC message. The WTRU may send an RRCreconfiguration complete message to the DU (e.g., on SRBx), indicating the completion of the reconfiguration process.

[0270] A WTRU may apply a dependent configuration with respect to one node (e.g., DU / CU) upon failure to apply a configuration provided by the other node (e.g., CU / DU).

[0271] In examples, a WTRU may apply a defined and / or dependent configuration with respect to one node when the WTRU fails to apply a reconfiguration received from another node. In examples, it may be assumed that the WTRU receives a reconfiguration from the DU and determines a dependent CU configuration. The examples may apply equal to the reverse case (e.g., a CU configuration is received, and the WTRU determines a dependent DU configuration).

[0272] A WTRU may be configured with a set of allowable CU / DU configurations and / or a dependency relation.

[0273] In examples, a WTRU may determine a set of partial RRC configurations (e.g., a CU configuration or a DU configuration). A partial CU RRC configuration may comprise of an RRC configuration associated with PDCP layer and above. For example, a partial CU RRC configuration may comprise of a subset of the RRC configuration (e.g., a subset of the RRC parameters that may be configured (e.g., possibly only) by the CU). The parameters associated with a partial RRC configuration may be defined in the specification, for example.

[0274] A WTRU may receive a set of partial CU RRC configurations directly from the network (e.g., the CU) in dedicated RRC signaling. For example, the WTRU may obtain a set of partial CU RRC configurations in SIB.

[0275] In examples, the WTRU may further be configured (e.g., in dedicated RRC signaling or SIB) with an association or dependency between the set of allowable partial CU configurations and one or more DU configurations. The WTRU may determine one or more allowable partial CU configuration for a DU configuration (e.g., determine the allowable association) using one or more of: a WTRU may receive an index / identifier / type with a CU configuration and a DU configuration; a WTRU may receive an index / identifier / type with a CU configuration and a DU configuration; methods for indicating / configuring the dependency by the network; a combination thereof; and / or the like.

[0276] The WTRU may determine one or more allowable partial CU configurations for a DU configuration (e.g., determine the allowable association) using an index / identifier / type with a CU configuration and a DU configuration. The WTRU may determine that a CU configuration is an allowable CU configuration for a DU configuration if they have the same index / identifier.

[0277] The WTRU may determine one or more allowable partial CU configuration for a DU configuration(e.g., determine the allowable association) using an index / identifier / type with a CU configuration and a DUconfi guration . The WTRU may further receive a table of CU index / identifiers that may be used for a DU index / identifier.

[0278] The WTRU may determine one or more allowable partial CU configurations for a DU configuration (e.g., determine the allowable association) using methods for indicating or configuring the dependency by the network.

[0279] In examples, a WTRU may determine one or more partial CU RRC configurations and the dependency relationship, based on a previous configuration, a default CU configuration, a combination thereof, and / or the like.

[0280] A WTRU may determine one or more partial CU RRC configurations and the dependency relationship based on a previous configuration provided by the DU and CU. For example, a WTRU that was successfully configured with a CU configuration for a given DU configuration in the past may consider the CU configuration to be an allowable CU configuration for that DU configuration. For example, a WTRU that was successfully configured with a CU configuration for a DU configuration in the past may consider a CU configuration (e.g., which may have a change in the configuration parameters compared to the past CU configuration), to be an allowable CU configuration for that DU configuration.

[0281] A WTRU may determine one or more partial CU RRC configurations and the dependency relationship based on a default CU configuration. For example, a WTRU may be provided with a default CU configuration that may be assumed allowable for any DU configuration.

[0282] A WTRU may apply an allowable CU configuration. A WTRU may autonomously apply (e.g., without the explicit reconfiguration message received by the network) a CU configuration upon reception of a DU configuration, whereby applying such DU configuration may result in a failure at the WTRU (e.g., reconfiguration failure). In examples, a WTRU may receive a DU configuration which, when applied, may lead to reconfiguration failure (e.g., exceeding of capabilities). In examples, the WTRU may apply the DU configuration as well as autonomously apply a dependent / allowed CU configuration. The WTRU may determine the dependent / allowed CU configuration based on mechanisms discussed herein. In examples, the WTRU may perform such action if the WTRU is able to determine a CU configuration which results in successful reconfiguration when the received DU configuration is applied with the determined CU configuration. For example, if the WTRU is unable to find an allowable CU configuration which, when applied with the received DU configuration, does not result in reconfiguration failure, the WTRU may trigger a recovery procedure (e.g., re-establishment).

[0283] The WTRU may be configured with one or more conditions when the WTRU autonomously applies the CU configuration. A decision to apply the CU configuration (e.g., a condition) may be based on one or more of an availability of data for transmission, a type of data available for transmission, a radioquality, a nature of the reconfiguration (e.g., reconfiguration with sync, etc.), one or more parameters modified in the reconfiguration, one or more conditions related to WTRU mobility, a combination thereof, and / or the like.

[0284] A decision to apply the CU configuration (e.g., a condition) may be based on the availability of data for transmission. For example, if the WTRU may have at least a configured amount of data available for transmission, the WTRU may autonomously apply an allowable CU configuration rather than trigger reestablishment.

[0285] A decision to apply the CU configuration (e.g., a condition) may be based on a type of data available for transmission. For example, if the WTRU has data available for transmission, which may have one or more properties (e.g., latency, reliability, or other QoS property meets some criteria), the WTRU may autonomously apply an allowable CU configuration rather than trigger reestablishment.

[0286] A decision to apply the CU configuration (e.g., a condition) may be based on radio quality. For example, the WTRU may be configured with a condition on the radio quality of a cell (e.g., serving cell, target cell of the HO, etc.) in which autonomous CU configuration is be performed. Such may be, for example, RSRP below a threshold, CQI below a threshold, beam measurement(s) below a threshold, etc.

[0287] A decision to apply the CU configuration (e.g., a condition) may be based on the nature of the reconfiguration (e.g., reconfiguration with sync, etc.). For example, the WTRU may autonomously apply an allowable CU configuration rather than trigger reestablishment for specific types of reconfigurations from the DU such as upon reception of reconfiguration with sync (e.g., compared to reconfiguration without sync), reception of full reconfiguration (e.g., as opposed to a delta reconfiguration), etc.

[0288] A decision to apply the CU configuration (e.g., a condition) may be based on parameters modified in the reconfiguration. For example, the WTRU may autonomously apply an allowable CU configuration rather than trigger re-establishment when the reconfiguration modifies predefined or configured parameters. For example, this may occur when the DU changes specific parameters which are also configurable by the CU, or which (e.g., normally) are to be configured by the CU.

[0289] A decision to apply the CU configuration (e.g., a condition) may be based on one or more conditions related to WTRU mobility. For example, if the WTRU speed is at least a value (e.g., satisfies a threshold), the WTRU may autonomously apply an allowable CU configuration rather than trigger reestablishment.

[0290] A WTRU informs the network after it may apply an allowable CU configuration. A WTRU may inform the network after it applies a CU configuration. The WTRU may transmit an RRC message to the network (e.g., to the CU) using the CU SRB. The WTRU may send a first RRC message (e.g., reconfigurationComplete) to the DU upon successfully applying the DU reconfiguration, and may send asecond RRC message (e.g., UEAssistancelnformation) to the CU. The message to the CU may indicate a cause value (e.g., autonomous CU configuration). The RRC message to the CU may further provide an indication of the CU configuration selected (e.g., an index, a type, etc.).

[0291] In examples, the WTRU may further indicate in the reconfigurationComplete message to the DU, a request to change the CU configuration in order to avoid re-establishment at the WTRU.

[0292] A WTRU may be provided for determining a node for transmitting one or more measurements. Whether a WTRU reports a measurement via a first or second SRB may depend on the neighbor cell that triggered the measurement. The WTRU may receive a measurement configuration from the CU and / or DU of a serving cell, which may include a measurement event triggered when the neighbor cell becomes better than the serving cell. The WTRU may be configured, possibly by the CU, with at least a first set of cells and a measurement event configuration. If the neighbor cell that belongs to the first set of cells satisfies the condition of the measurement event, the WTRU may report the measurement to the DU of the serving cell (e.g., on SRBx). If the neighbor cell does not fulfill the condition of the measurement event, the WTRU may report the measurement to the CU of the serving cell (e.g., on SRB1).

[0293] A WTRU may receive a HO / reconfiguration command from either CU or DU. When a reconfiguration is received from the CU, the WTRU may respond with a complete message to the CU. When a reconfiguration is received from the DU, the WTRU may respond with a message to the DU. For example, the WTRU may determine whether to transmit the message to the CU or the DU based on conditions similar to the conditions associated with selecting the node to which to trigger measurement reports. Reporting to the CU or the DU may be performed with the examples described herein (e.g., different SRB / LCH).

[0294] Properties of a triggered measurement event may be used to determine the node to which to report the measurement. In examples, a WTRU may determine the node to which a measurement report is transmitted based on properties / parameters of the measurement event itself. The WTRU may determine the node(s) to which a measurement report is transmitted based on one or more of the cell (s) that trigger the measurement event; the type of measurement event that is triggered; the mobility of the WTRU (e.g., possibly when the event may be triggered); the number of cells / measurements (e.g., possibly meeting a one or more conditions); a rule associated with the time to trigger (TTT); the (e.g., reported) measurement value(s) themselves, or the speed at which they change; the occurrence of successive measurement events (e.g., of the same or different types); The occurrence, or time since recent HO commands received; a combination thereof; and / or the like.

[0295] The WTRU may determine the node(s) to which a measurement report is transmitted based on the cell (s) that trigger the measurement event. For example, the WTRU may be configured with a list ofcells. If the event that triggers the measurement event (e.g., neighbor cell becomes better than serving cell), is associated with a cell that may be in the configured list (e.g., a list of neighbor cells), the WTRU may report the measurement report to a (e.g., one) node (e.g., the DU). In examples, the WTRU may report the measurement report to another node (e.g., the CU).

[0296] For example, the WTRU may be configured with a list of cells for reporting to CU and a list of cells for reporting to DU. The WTRU may report to the CU or DU depending on which list the cell that triggered the event belongs to.

[0297] For example, the WTRU may receive an indication from the target cell itself (e.g., in SIB, as part of SSB transmission, etc.). For example, the WTRU may be configured with a condition associated with reception of a signal or information (e.g., in a reference signal, SIB, etc.) which determines whether the WTRU reports a measurement to the CU or DU upon triggering an event associated with that cell, and / or when reporting a measurement associated with that cell.

[0298] The WTRU may determine the node(s) to which a measurement report is transmitted based on the type of measurement event that may be triggered. For example, the WTRU may be (pre)configured or have some predefined mapping between event type and reporting node. For example, one or more events (e.g., “A” events) may be reported to the DU and one or more events (e.g., “B” events) may be reported to the CU. For example, Ax, Ay, events may be reported to the CU and Ax events may be reported to the DU. For example, the WTRU may receive (e.g., in the measurement configuration), an indication of the node (CU or DU) to which the measurement report may be sent.

[0299] The WTRU may determine the node(s) to which a measurement report is transmitted based on the mobility of the WTRU (e.g., possibly when the event is triggered). For example, the WTRU may report the measurement reports to the CU in the case high mobility is detected by the WTRU, and the WTRU may report the measurement reports to the DU in the case low mobility is detected by the WTRU. Low or high mobility may be detected by the WTRU based on the WTRU speed (e.g., above / below a threshold), the number of mobility events (e.g., how many handovers over a recent period of time), or similar metrics that may represent how quickly.

[0300] The WTRU may determine the node(s) to which a measurement report is transmitted based on the number of cells / measurements (e.g., possibly meeting a condition). For example, if at least N (e.g., a configured quantity) cells are measured above a threshold quantity at the time the event may be triggered, the WTRU may report the measurement event to the CU. In examples, the WTRU may report the measurement event to the DU.

[0301] The WTRU may determine the node(s) to which a measurement report is transmitted based on a rule associated with the TTT. For example, the WTRU may report measurements to the CU or the DUdepending on a condition associated with the TTT associated with a measurement event. For example, the WTRU may be configured with two different TTTs. If the measurement event is triggered based on the first TTT, the WTRU may report to the DU / CU, and if the measurement event is triggered based on the second TTT, the WTRU may report to the CU / DU.

[0302] The WTRU may determine the node(s) to which a measurement report is transmitted based on the (reported) measurement value(s) themselves, or the speed at which they change. For example, the WTRU may report the measurements to the CU or the DU depending on a condition associated with the measurement(s) of the neighbor and / or serving cells. For example, if the serving cell is below a threshold (e.g., possibly at the trigger of an event), the WTRU may report the measurement to the CU / DU. In examples, the WTRU may report to the DU / CU. For example, if the neighbor cell is above a threshold (e.g., possibly at the trigger of an event), the WTRU may report the measurement to the DU / CU. In examples, the WTRU may report to the CU / DU.

[0303] The WTRU may determine the node(s) to which a measurement report is transmitted based on the occurrence of successive measurement events (of the same or different types). For example, the WTRU may transmit measurement reports to one node (e.g., the DU) upon trigger of the measurement event. If a HO is not received within a duration of time from the initiation of measurement report transmission, the WTRU may transmit measurement reports to the other node (e.g., the CU, possibly in addition to the first node, e.g., the DU). The WTRU may maintain such behavior and associated time for a (e.g., each) configured event. For example, the WTRU may maintain a (e.g., single) configured time for a (e.g., each) measurement event.

[0304] For example, the WTRU may transmit measurement reports to one node following a first event being satisfied. Following the first event being satisfied, if a second event is satisfied (e.g., possibly within a configured time of the first event), the WTRU may report the measurements to the second node (e.g., possibly in addition to the first node). In examples, the first event and the second event may be the same configured event, or different configured events. Events may be, for example, Ax events, Bx events, etc. configured for measurements.

[0305] The WTRU may determine the node(s) to which a measurement report is transmitted based on the occurrence, or time since recent HO commands received. For example, the WTRU may receive a HO command to move the WTRU to a cell (e.g., new cell). From the moment of the completion of the HO command, the WTRU may send measurement reports to a first node (e.g., CU). Following a period of time after the HO, the WTRU may send measurement reports to the second node (e.g., DU, possibly in addition to the first node). The WTRU may be configured with conditions on the cell itself (e.g., the cell is within a listof cells) in which the behavior as described herein is followed and / or which of the CU / DU to report measurements to first.

[0306] If a first condition is satisfied, the WTRU may report the measurement to the DU. In examples, the WTRU may report the measurement to the CU. For example, if a first condition is satisfied, the WTRU may report the measurement to both the CU and the DU. In examples, the WTRU may report the measurement to the DU / CU (e.g., only).

[0307] A WTRU may be configured with a condition (e.g., an event) that changes the reporting node.

[0308] In examples, a WTRU may be configured with a condition (e.g., possibly associated to measurements), which causes the WTRU to determine / change the node to which subsequent measurement reports are sent. The configured condition may be one or more of an explicit NW signaling, a cell level measurement, a WTRU location, a WTRU speed, a channel measurement, connection type, a time condition, a combination thereof, and / or the like.

[0309] The configured condition may be explicit NW signaling. For example, a WTRU may receive signaling (e.g., RRC message, SIB, MAC CE, downlink control information (DCI), etc.) that changes the reporting node, or explicitly indicates which reporting node to send measurement reports to.

[0310] The configured condition may be a cell level measurement. For example, a WTRU may be configured with conditions on one or more cells (serving cell and / or neighbor cells), which determines which node to send measurement reports to. Such conditions may be provided in the form of a measurement event (e.g., Ax or Bx events).

[0311] For example, a WTRU may be configured with a condition based on cell measurements, the number of cells satisfying a cell measurement, or the specific cells satisfying a cell measurement.

[0312] The condition based on cell measurements may comprise: one or more number of cells (neighbor and / or serving) are above / below a threshold; one or more neighbor cells are at least an amount better / worse than a threshold; one or more neighbor and / or serving cells with measurements above a threshold is greater / less than N (where N may be configured); one or more neighbor cells with measurement that are at least an amount above / below the serving cell measurement may be greater / less than N (e.g., where N may be configured); one or more neighbor cells that are above / below a threshold and / or above / below the serving cell by a configured amount; a combination thereof; and / or the like.

[0313] The configured condition may be based on a WTRU location. For example, the WTRU may be configured with a location, set of locations, area, etc., whereby the WTRU reports measurements to a first node (e.g., DU), otherwise, the WTRU may report measurements to a second node (e.g., CU, possibly in addition to the first node).

[0314] The configured condition may be based on a WTRU speed. For example, the WTRU may report to a first node when its speed is above a threshold and may report to a second node when its speed is below a threshold.

[0315] The configured condition may be based on a channel measurement. For example, the WTRU may be configured with conditions on channel measurements (e.g., CQI, L1 RSRP, etc.) whereby it reports to the first or the second node.

[0316] The configured condition may be based on a connection type. For example, the WTRU may be configured with conditions related to connection type for determining the node for transmitting the measurement report. Connection type may be based on whether the WTRU is connected to the network via a relay WTRU or via Uu. Connection type may comprise of whether the WTRU is connected via DC or not. Connection type may comprise of whether or not the WTRU is in power savings mode (e.g., DRX). Other types of connections may be used.

[0317] The configured condition may be based on a time condition. For example, the WTRU may be configured with a period of time for reporting to one node (e.g., possibly following the occurrence of another condition). For example, the WTRU may be configured with a period of time over which another condition may be met before the WTRU reports to one node or another node.

[0318] In examples, if one or more condition(s) described herein is met, the WTRU may report to one node (e.g., DU); otherwise, the WTRU may report to the other node (e.g., possibly in addition to the first node).

[0319] In examples, following an event, the WTRU may report to one node (e.g., CU). Upon the occurrence of one or more condition(s) above, the WTRU may then report to the second node (e.g., the DU), possibly in addition to reporting to the first node.

[0320] In examples, the WTRU may report to one node (e.g., DU). Upon the occurrence of one or more condition(s) above, the WTRU may then report to the other node (e.g., the CU, possibly in addition to the first node), for a configured period of time before returning to reporting to the first node.

[0321] Measurement report contents may depend on the node to which measurements are reported. For example, the WTRU may determine the contents of measurement reports to a node (e.g., a node) based on one or more of the cells that are reported, the reported quantities, a reporting of beam measurements, an identification of a cell being reported, a combination thereof, and / or the like.

[0322] The WTRU may determine the contents of measurement reports to a node (e.g., a node) based on the cells that are reported. For example, the WTRU may report the measurements of (e.g., some) cells to a first (e.g., one) node and (e.g., other) cells to another node. For example, there may be a rule (e.g., predefined or configured) for whether to report a serving cell to the CU and / or DU. For example,measurements of (e.g., specific) cells (e.g., configured) may be reported to CU / DU (e.g., only). For example, the WTRU may report a cell to the DU or CU based on a property of the cell or its measurement described herein. For example, the WTRU may report a cell to the DU or CU based on information obtained from reference signal (e.g., SSB) of the cell or SIB of that cell. For example, the WTRU may report cells to the DU which have a first UL timing condition, and cells to the CU that have a second UL timing condition. For example, the WTRU may report cells to the DU which have a first DL timing condition and may report cells to the DU that have a second UL timing condition.

[0323] The WTRU may determine the contents of measurement reports to a node based on the reported quantities. For example, the measurement quantities (e.g., RSRP, received signal strength indicator, SINR, etc.) may depend on the node to which the measurement report may be sent.

[0324] The WTRU may determine the contents of measurement reports to a node based on the reporting of beam measurements. For example, the WTRU may report beam measurements to one node (e.g., the DU) but not the other node(s).

[0325] The WTRU may determine the contents of measurement reports to a node (e.g., each node) based on an identification of the cells being reported. For example, the WTRU may report a different identifier for the cell to (e.g., each of) the nodes. For example, the WTRU may report additional identification (e.g., a DU ID) to the measurement reports provided to a (e.g., one) node (e.g., the CU).

[0326] Examples described herein may apply for a (e.g., any) RRC message. Examples described herein may refer to determining the node to which measurement reports (e.g., or measurements of specific cells) are sent by the WTRU. Similar examples may be used to determine the node to which to send any RRC message by the WTRU (e.g., such as UEAssistancelnformation, complete messages, etc.).

[0327] Examples described herein may apply for measurements of WTRUs. Examples described herein may refer to reporting of measurements of cells but may apply equally to reporting of measurements of WTRUs (e.g., such as relay WTRU measurements).

[0328] A WTRU may perform a two-stage / node re-establishment procedure. A WTRU may perform a reestablishment procedure towards the DU based on the problem that initiated the re-establishment. If the procedure is not successful, the WTRU may conduct a legacy re-establishment towards the CU.

[0329] In examples, the WTRU may be configured with conditions to perform re-establishment with the DU (e.g., instead of the CU). These conditions may be based on RLF cause or if the re-establishment is triggered by DU RRC reconfiguration failure, among other examples. Upon determining that the conditions for performing re-establishment to the DU are met, the WTRU may suspend the radio bearers associated with the DU (e.g., excluding SRBOx if configured). Cell reselection may be performed.

[0330] A re-establishment request message may be transmitted to the DU. This message may be sent via SRBOx or SRBO, and may include an indication that the message is intended for the DU. If the WTRU receives a re-establishment message from the DU, the security context of the DU may be updated according to the received message. One or more suspended DU radio bearers (e.g., such as SRBx), may be resumed. An indication about the DU re-establishment may be sent to the CU.

[0331] In examples, if the WTRU receives a re-establishment message from the CU, an RRC reestablishment (e.g., a legacy RRC re-establishment) may be performed according to the received reestablishment message from the CU. If the WTRU receives a re-establishment failure message from the DU or a configured time duration elapses without receiving an RRC message in response to the reestablishment request, an RRC re-establishment (e.g., a legacy RRC re-establishment) with the CU may be triggered. An RRC re-establishment may involve sending an RRCReestablishmentRequest via SRBO.

[0332] A WTRU may be configured to re-establish the connection to the DU based on conditions. In examples, the WTRU that is connected to the network that is employing the split RRC architecture may be configured to trigger an RRC re-reestablishment procedure (e.g., where the procedure is targeted to reestablish the RRC connection between the WTRU and DU). The re-establishment procedure may be transparent or partially transparent to the CU.

[0333] In examples, the WTRU may perform the re-establishment procedure to the DU depending on the reason why the re-establishment may be being triggered.

[0334] In examples, the WTRU may perform the re-establishment procedure to the DU if the cause of re-establishment was an RRC reconfiguration failure. In examples, the WTRU may perform the reestablishment procedure to the DU if the reconfiguration failure was due to an RRC message received from the DU. In examples, the WTRU may perform the reestablishment to the DU if the failure was due to an RRC received message received from the DU and another (e.g., configurable) criteria is met. For example, the WTRU may be configured to perform a re-establishment to the DU if the reconfiguration failure was due to (e.g., some) information elements that are included or not included in the reconfiguration message that caused the failure (e.g., for example, if the reconfiguration message included measurement configuration update or addition, if the reconfiguration message included security related information for SRBx, if the reconfiguration message included information related to PHY layer configurations, if the configuration message included information related to the MAC layer, etc.).

[0335] In examples, the WTRU may perform the re-establishment to the DU, even if the reconfiguration failure was due to an RRC message received from the CU.

[0336] In examples, the WTRU may perform the re-establishment procedure to the DU if the cause of re-establishment was a handover failure. In examples, the WTRU may perform the re-establishment to theDU if the handover failure was due to a handover triggered by the DU (e.g., an LTM cell switch, which may have been triggered by a MAC CE from the DU, or a DU RRC message). In examples, the WTRU may perform the re-establishment to the DU if the handover failure was performed between two cells of the same DU. For example, the WTRU may be configured with information about a group of cells (e.g., list of identities of the cells that belong to the same DU), and if the handover failure occurred while the WTRU was trying to handover to a target cell that belongs to the same group that the source cell belongs to, it performs a reestablishment to the DU, and otherwise perform the legacy reestablishment to the CU.

[0337] In examples, the WTRU may perform the re-establishment to the DU if the cell that it has reselected before sending the RRCReestablishmentRequest message belongs to a cell that belongs to the same DU as the source cell where the problem that led to the re-establishment was detected. Similar to the handover failure case discussed above, the WTRU may be configured with information about a group of cells (e.g., list of identities of the cells that belong to the same DU). If the cell that the WTRU has reselected before sending the RRCReestablishmentRequest message belongs to a cell that does not belong to the same DU, the WTRU may perform the legacy re-establishment to the CU.

[0338] In examples, the WTRU may perform the re-establishment procedure to the DU if the cause of re-establishment was a RLF. In examples, the WTRU behaves this way for one or more types of RLF. In examples, the WTRU may be configured to trigger the re-establishment to the DU depending on the particular RLF cause.

[0339] For example, the WTRU may be configured to perform the re-establishment to the DU if the RLF was caused due to a Random Access (RA) failure but trigger the legacy re-establishment to the CU if the RLF cause was not an RA failure.

[0340] For example, the WTRU may be configured to perform the re-establishment to the DU if the RLF was caused due to beam failure recovery failure. For example, the WTRU may be configured to perform the re-establishment to the DU if the RLF was caused due to a maximum limit of RLC retransmissions being reached for a bearer (e.g., SRB, DRB, or both).

[0341] In examples, the WTRU may be configured to perform the re-establishment to the DU if the RLF was caused due to the expiry of the T310 timer that is used for RLM (Radio link monitoring). In examples, T310 may be started by the WTRU up on detecting physical layer problems for the SpCell, (e.g., PCell or the PSCell), or upon receiving (e.g., N310) consecutive out-of-sync indications from lower layers), and it may be stopped (e.g., link assumed to be in sync) upon receiving (e.g., N311) consecutive in-sync indications from lower layers for the SpCell or a upon receiving a HO command.

[0342] In examples, the WTRU may be configured to perform the re-establishment to the DU if the RLF was caused due to the expiry of the T312 timer. T312 may be started upon the triggering of a measurementreport for a measurement identity for which T312 has been configured and use T312 has been set to true (e.g., while T310 in PCell / PSCell is running). In examples, the stopping conditions for T312 may be similar to T310. In examples, the re-establishment to the DU is triggered due to T312 expiry if the T312 was started due a measurement report that is destined to the DU. In examples, the re-establishment to the DU is triggered due to T312 expiry even if the T312 was started due a measurement report that may be destined to the CU.

[0343] The re-establishment may be communicated to the DU. In examples, the WTRU may use SRBO for re-establishment towards the DU (e.g., according to any of the solutions above), but includes an indication that this is intended for the DU and not the CU). For example, an information element may be included (e.g., a Boolean field) in the RRCReestablishmentRequest message. When the DU receives an RRCReestablishmentRequest message that includes this flag, it may know that the message is intended for it and not forward it to the CU on behalf of the WTRU (e.g., if this IE is not included, the DU may pass the message to the CU). In examples, a value of 0 or false may indicate the re-establishment request is intended for the CU and a value of 1 or true may indicate that the request is intended for the DU, or vice versa. In examples, the absence of the indication may implicitly indicate the re-establishment is to be performed to the DU. In examples, the absence of the indication may implicitly indicate the reestablishment is to be performed to the CU. In examples, the presence of the indication may implicitly indicate the re-establishment is to be performed to the DU. In examples, the presence of the indication may implicitly indicate the re-establishment may be to be performed to the CU.

[0344] In examples, an SRB (e.g., a new), e.g., SRBOx, that is associated with an LCID value different from 0 (e.g., different from SRBO), and the reception of an RRCReestablishmentRequest message may implicitly indicate that the message was intended to the DU.

[0345] In examples, the WTRU may generate the ReestabUE-ldentity the same way as in legacy, e.g., C-RNTI+ source PCI + ShortMAC-l). In examples, the ShortMAC-l included in the reestablishment request message to the DU may be derived using the DU RRC security context (e.g., security keys associated with DU RRC). In examples, instead of the C-RNTI, the WTRU may be configured with an identity (e.g., a DU level RNTI, DU-RNTI), and it includes this message in the reestablishment request message. In examples, the WTRU may be configured to use the same DU-RNTI with the group of cells that belong to the same DU.

[0346] In examples, the WTRU may include two ReestabUE-ldentity lEs in the RRCReestablishmentRequest message, the first IE may be a legacy IE (e.g., intended for the CU, including the C-RNTI, PCI, and shortMAC-l derived using the security context associated with the CU), the second IE may indicate a (e.g., new) identity (e.g., intended for the DU, including the C-RNTI or a DU-RNTI, the PCI, and shortMAC-l derived using the security context associated with the DU). In examples, the WTRU may include the PCI and C-RNTI in the RRCReestablishmentRequest message (e.g., as they are common to both identities) and may have two shortMAC-ls, a first (e.g., one) intended for the CU and the other for the DU, for example, for signaling optimization.

[0347] If the DU is not able to perform / accept the re-establishment (e.g., the WTRU is trying to reestablish at a different DU than that was serving the source cell where the problem that led to the reestablishment was detected), it may pass the RRCReestablishmentRequest message to the CU. If two reestablishment identities were included, the DU may include the ID that may be associated with the CU in this re-establishment request message.

[0348] WTRU behavior and / or actions may be based on determining to re-establish the DU RRC. In legacy RRC re-establishment (e.g., to the CU / gNB), the WTRU suspends one or more (e.g., all) radio bearers (e.g., except SRBO, as that may be used for sending the re-establishment command) and releases the carrier aggregation (CA) / DC configuration.

[0349] In examples, if the WTRU has detected the re-establishment is to be performed to the DU according to examples described herein, it may suspend (e.g., only) the radio bearers associated with the DU (e.g., SRBx), while the operation of (e.g., all) DRBs and SRBs that are associated with the CU (e.g., SRBO, SRB1 , SRB2, etc., and all DRBs) may continue. The CU level cyclic prefix / uplink (CP / UP) operation may continue as may be while the WTRU is trying to re-establish the DU RRC.

[0350] In examples, if the WTRU has detected that the re-reestablishment is to be performed to the DU according to example(s) described herein, it may maintain one or more of the CU RRC configurations (e.g., measurement configurations, etc.). The CU level CP operation may continue as may be while the WTRU is trying to re-establish the DU RRC.

[0351] In examples, if the WTRU has detected the re-reestablishment is to be performed to the DU according to example(s) described herein, it may suspend the SRBs associated with the CU (e.g., SRBO, SRB1 , SRB2, etc.). The WTRU may be configured to suspend (e.g., only some of) the SRBs (e.g., only SRB1). For example, suspending SRBs may be used to prevent the WTRU from receiving conflicting RRC messages from the CU while it is re-establishing the DU RRC.

[0352] In examples, if the WTRU has detected the re-reestablishment is to be performed to the DU according to example(s) described herein, it may suspend one or more (e.g., all) of the DRBs associated with the CU. The WTRU may be configured to suspend (e.g., only some of the) DRBs (e.g., bearers of a type, explicitly indicated list of bearers, etc.).

[0353] Actions / behavior may be determined upon / after the sending of the RRCReestablishmentRequest message. In examples, the WTRU may start a timer (e.g., T3xx) upon sending theRRCReestablishmentRequest message to the DU, and if it does not receive a positive response from the DU (e.g., an RRCReestablishment message) if / when the timer expires, it may start the legacy reestablishment to the CU.

[0354] In examples, if the WTRU receives a failure message from the DU (e.g., a new RRC message, e.g., an RRCReestablishmentFailure message) in response to the re-establishment request that it may have sent to the DU, it may start the legacy re-establishment to the CU.

[0355] In examples, an indication (e.g., a new IE) is included in the RRCReestablishment message that the WTRU receives in response to the request it may have sent to the WTRU, where the indication may indicate whether the re-establishment is to be performed to the CU or the DU. As an example, a value of 0 or false may indicate the re-establishment is to be performed to the CU, and a value of 1 or true may indicate that the re-establishment is to be performed to the DU, or vice versa. In examples, the absence of the indication may implicitly indicate the re-establishment is to be performed to the DU. In examples, the absence of the indication may implicitly indicate the re-establishment is to be performed to the CU. In examples, the presence of the indication may implicitly indicate the re-establishment is to be performed to the DU. In examples, the presence of the indication may implicitly indicate the re-establishment may be to be performed to the CU.

[0356] In examples, in response to the RRCReestablishmentRequest that it may have sent to the DU (e.g., according to any of the example(s) described herein), the WTRU receives an indication to reestablish the RRC to the DU with an RRCReestablishment message (e.g., via SRBx).

[0357] In examples, in response to the RRCReestablishmentRequest that it may have sent to the DU (e.g., according to any of the example(s) described herein), the WTRU receives an indication to reestablish the RRC connection to the CU with an RRCReestablishment message (e.g., via SRB1 as in legacy). For example, where the DU is not able to handle the DU RRC re-establishment or an (e.g., any other) implementation-based decision by the network, the WTRU may behave like the legacy RRC reestablishment procedure.

[0358] In examples, if the WTRU receives an RRCReestablishment message from the DU (e.g., as detected by the WTRU based on examples described herein), it may resume the suspended bearers (e.g., if any) according to examples described herein.

[0359] In examples, the WTRU may receive a counter (e.g., similar to the nextHopChainingCount used in legacy RRCReestablishment message), and it uses this counter to derive the DU RRC security context (e.g., DU RRC integrity protection and encryption keys).

[0360] In examples, the WTRU may be configured to reuse the (e.g., old) keys that it used before theDU re-establishment was triggered. This may be an implicit indication (e.g., the absence of a counter valuein the received RRCReestablishment message from the DU) or it may be explicitly indicated (e.g., with a new flag / IE in the RRC message).

[0361] In examples, the WTRU sends an RRCReestablishment message to the DU, indicating that the re-establishment with the DU was executed / completed successfully.

[0362] In examples, the WTRU receives a subsequent RRCReconfiguration message from the DU (e.g., which may be a full or delta configuration), which may be used after the reestablishment (e.g., reconfiguring some aspects that are different between the source and target cells).

[0363] In examples the RRCReestablishmentRequest and RRCReestablishment messages may be used (e.g., with some enhancements) for the case of DU RRC re-establishment. One or more messages (e.g., new messages) may be defined for the purposes of re-establishment to the DU (E.g., DURRCReestablishment, DURRCReestablishmentRequest, DUReestablishment, DUReestablishmentRequest, RRCReestabllishmentRequestl , RRCReestablishmentl , etc.).

[0364] In examples, the WTRU may receive an RRCSetup message in response to a reestablishment request to the DU (e.g., WTRU context was not found in the target DU or target CU and may not be fetched from the source DU or / and CU).

[0365] In examples, the WTRU may indicate to the CU that a re-establishment to the DU may have been performed. For example, this may be a part of the RLF report, or the HO failure report the WTRU may be sending to the CU (e.g., if the DU re-establishment was triggered due RLF or HO failure). In examples, this may be a new RRC message. The indication may include information such as the source cell, the target cell, the cause of the DU re-establishment, measurement taken before / after the re-establishment, etc. The indication may be sent by the WTRU (e.g., immediately) after the re-establishment to the DU, or it may be sent any other time (e.g., based on a request by the CU). The WTRU may indicate it may have detailed information about DU re-establishments and CU may request it. The WTRU may collect information about several DU re-establishments and send an aggregate information regarding these re-establishments at once to the CU.

[0366] In examples, the WTRU may be configured with a timer or counter that prevents re-establishment to the DU. For example, the WTRU may be configured to start a timer when a re-establishment to the DU is performed, and it may not start a re-establishment to the DU before that timer expires. If the WTRU has determined that the conditions for triggering a re-establishment to the DU (e.g., according to examples described herein, were fulfilled), it may perform the re-establishment to the CU as in legacy. In examples, the WTRU may be configured with a counter value (e.g., n=3), which indicates that after performing DU reestablishment to the same DU (e.g., assuming the cells of the DU may have been indicated to the DU, e.g.,in a list of cells), the DU may refrain from performing DU re-establishments and perform legacy RRC reestablishments.

[0367] Systems, methods, and devices may be used to perform a fallback procedure following a reconfiguration failure. For example, a WTRU may be provided to perform a fallback procedure following a reconfiguration failure. The WTRU may include a processor. A fallback data unit configuration may be received from a CU or the DU using either a first SRB or a second SRB. A failure condition for performing a recovery procedure may be determined. The failure condition may indicate a reconfiguration failure, an integrity verification failure, or a handover failure. A reconfiguration message may be received from the DU using the second SRB.

[0368] In examples, the recovery procedure may be performed when the failure condition is satisfied. The recovery procedure may include releasing the DU RRC or sending a request to release the DU RRC. The recovery procedure may also be performed when a confirmation may be received.

[0369] In examples, the fallback configuration may be applied when the DU RRC is released. The WTRU may be configured in a single RRC entity mode. A message may be sent to a network entity by the processor. The message may indicate that the DU RRC has been released and may indicate a release cause value.

[0370] A WTRU may be configured to release the DU RRC based on a condition. In examples, the WTRU may be configured to release the RRC (e.g., association) with the DU when it encounters an RRC reconfiguration failure while executing / compiling an RRC message received from the DU. In examples, the WTRU may release the DU RRC if the failure was due to an RRC received message received from the DU and another (e.g., configurable) criterion is met. For example, the WTRU may be configured to release the DU RRC if the reconfiguration failure was due to (e.g., some) information elements that are included or not included in the reconfiguration message that caused the failure (for example, if the reconfiguration message includes measurement configuration update or addition, if the reconfiguration message includes security related information for SRBx, if the reconfiguration message includes Information related to PHY layer configurations, if the configuration message includes information related to the MAC layer, etc.).

[0371] In examples, the WTRU may be configured to release the RRC (e.g., association) with the DU when it detects an integrity verification failure of an RRC message received from the DU.

[0372] In examples, the WTRU may be configured to release the RRC (e.g., association) with the DU when it detects a handover failure, if the handover was triggered by the DU (e.g., LTM, either triggered by a MAC CE a, or LTM triggered via a DU RRC message).

[0373] Behavior may be determined upon release of the DU RRC. In examples, the WTRU may release the SRBx and (e.g., any) other signaling radio bearers (e.g., SRBOx, if configured), associated with the DU upon releasing the DU RRC according to example(s) described herein.

[0374] In examples, the WTRU may release the packet data convergence protocol (PDCP) entities associated with (e.g., any of) the signaling radio bearers associated with the DU upon releasing the DU RRC according to example(s) described herein.

[0375] In examples, the WTRU releases the RLC entities associated with a (e.g.,, any of) the signaling radio bearers associated with the DU upon releasing the DU RRC according to example(s) described herein.

[0376] In examples, the WTRU may release / stop (e.g., any) timers that may be running that are related to the DU RRC operation based on releasing the DU RRC according to example(s) described herein.

[0377] In examples, the WTRU may apply a default / alternative DU configuration (e.g., cell group level configuration) that modifies the lower layer configurations towards the DU (e.g., MAC, PHY, etc.) upon releasing the DU RRC according to examples described herein.

[0378] Fallback to previous / default DU RRC configuration may be described. In examples, the WTRU may fallback to the DU configuration that was being used before the DU RRC reconfiguration received that caused the reconfiguration failure and subsequent release of the DU RRC. For example, the WTRU may apply the configurations that are associated with UP operation (e.g., no configuration related to SRBx, measurements, etc. is applied).

[0379] In examples, the WTRU may refrain from releasing the RRC with the DU and instead reject the DU RRC reconfiguration received that caused the reconfiguration failure and revert the DU configuration to the configuration that was being used before the reception of the DU RRC message. In one example, the rejection may be allowed (e.g., only) for some types of configurations (e.g., configurations that are not related to handover or cell switching, configurations that do not affect PHY operation, configuration that do not affect MAC operation, configurations that do not affect measurement operation, configurations that were causing the error due to exceeding WTRU capabilities, etc.).

[0380] Indicating to the DU / CU about DU RRC release or RRC Reconfiguration rejection may be provided. In examples, the WTRU informs the DU about the release of the DU RRC (association), according to examples described herein, by sending an indication to the DU. In one example, the WTRU sends an RRC message (e.g., a new RRC message) to the DU (e.g., via SRBx, SRBOx). In examples, the WTRU sends a MAC CE to the DU.

[0381] In examples, the WTRU informs the DU about the rejection of the DU RRC reconfiguration message (e.g., according to examples described herein, by sending an indication to the DU). In examples,the WTRU sends an RRC message (e.g., a new RRC message) to the DU (e.g., via SRBx, SRBOx). In examples, the WTRU sends a MAC CE to the DU.

[0382] In examples, the WTRU may include a release cause value in the DU RRC release indication (e.g., reconfiguration failure, integrity verification failure, handover failure, capability exceeded, etc.).

[0383] In examples, the WTRU may include a reject cause value in the DU RRC reconfiguration rejection indication (e.g., reconfiguration failure, integrity verification failure, handover failure, capability exceeded, etc.).

[0384] In examples, the WTRU informs the CU about the rejection of the DU RRC reconfiguration message, according to examples described herein, by sending an indication to the CU. In examples, the WTRU sends an RRC message (e.g., a new RRC message) to the CU (e.g., via SRB1). In examples, the WTRU uses an existing RRC message with new information elements (e.g., WTRU assistance information, WTRU information response, etc.,).

[0385] In examples, the WTRU may be configured to send an indication to the DU that the WTRU may have released the DU RRC (e.g., in a last RRC message to the DU before releasing the SRBx and associated lower layer entities).

[0386] In examples, the WTRU may be configured to send an indication to the CU that the WTRU may have released the DU RRC (e.g., in a new RRC message, in an existing RRC message such as WTRU assistance information or WTRU information response, in a MAC CE, etc.,).

[0387] In examples, the WTRU may be configured to send a request to the network to release the DU RRC, instead of autonomously releasing it by itself according to examples described herein. The WTRU then releases the DU RRC a (e.g., only) on receiving confirmation from the network.

[0388] In examples, the WTRU may be configured to autonomously release the DU RRC under one or more conditions while sending a request to release the DU RRC under other conditions. For example, there may be a verification failure regarding a DU RRC message, but a request to release the DU RRC if the error was a reconfiguration failure.

[0389] In examples, the WTRU may be configured to autonomously release the DU RRC if an error occurs a (e.g., some) number of times (e.g., consecutively, within a time duration, etc.). Otherwise, the WTRU may send a request to release the DU RRC.

[0390] In examples, the WTRU may send the DU RRC release request message to the DU.

[0391] In examples, the WTRU may send the DU RRC release request message to the CU.

[0392] In examples, the WTRU may be configured to apply a default / reference DU configuration if it does not get a positive response regarding to the request to release the DU RRC. In examples, the WTRUmay have previously been configured with multiple DU configurations that it may have stored, and in the response from the network informing the WTRU not to release the DU RRC, the network may include an indication which of these configurations to be applied (e.g., by including an index / identity of the stored DU configuration to be applied). In examples, the network may explicitly include a full / delta configuration to be applied by the WTRU (e.g., as an alternative to the configuration that caused the problem).

[0393] Although features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements.

[0394] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0395] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMSWhat is Claimed:

1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: receive a first radio resource control (RRC) message from a distributed unit (DU) RRC entity, wherein the first RRC message indicates first configuration information and a first interdependency characteristic; in response to receiving the first RRC message, set an interdependence RRC message timer based on an interdependence RRC message reception time duration; receive a second RRC message from a control unit (CU) RRC entity, wherein the second RRC message indicates second configuration information and a second interdependency characteristic; determine that a first condition and a second condition are satisfied, wherein the first condition is determined to be satisfied based on the second RRC message being received before expiry of the interdependence RRC message timer, and wherein the second condition is determined to be satisfied based on the first interdependency characteristic and the second interdependency characteristic; and update, based on the determination that the first condition and the second condition are satisfied, a parameter associated with the WTRU using the first configuration information or the second configuration information.

2. The WTRU of claim 1 , wherein the interdependence RRC message reception time duration is preconfigured or is received from the DU RRC entity.

3. The WTRU of claim 1 or 2, wherein the determination that the second condition is satisfied comprises a determination that the first interdependency characteristic and the second interdependency characteristic indicate a same value.

4. The WTRU of claim 1 or 2, wherein the determination that the second condition is satisfied comprises a determination that the first interdependency characteristic and the second interdependency characteristic indicate that the first RRC message and the second RRC message are interdependent.

5. The WTRU of any of claims 1 to 4, wherein the processor is further configured to: send a first reconfiguration message to the DU RRC entity and a second reconfiguration message to the CU RRC entity, wherein the first reconfiguration message or the second reconfiguration message comprises an indication that the parameter is updated.

6. The WTRU of any of claims 1 to 4, wherein the parameter comprises a first parameter and a second parameter, and wherein the processor is further configured to: update, based on the determination that the first condition and the second condition are satisfied, the first parameter using the first configuration information and the second parameter using the second configuration information.

7. The WTRU of any of claims 1 to 4, wherein the processor is further configured to: determine that a third condition is satisfied, wherein the third condition is determined to be satisfied based on a WTRU speed satisfying a threshold; and update, based on the determination that the first condition, the second condition, and the third condition are satisfied, the parameter associated with the WTRU using the second configuration information.

8. The WTRU of any of claims 1 to 4, wherein the processor is further configured to: update, based on the determination that the first condition and the second condition are satisfied, the parameter associated with the WTRU using the first configuration information; and send a first reconfiguration message to the DU RRC entity and a second reconfiguration message to the CU RRC entity, wherein the first reconfiguration message comprises an indication that the parameter is updated based on the first configuration information, and the second reconfiguration message comprises an indication that the parameter is not updated based on the second configuration information.

9. The WTRU of any of claims 1 to 4, wherein the processor is further configured to: update, based on the determination that the first condition and the second condition are satisfied, the parameter associated with the WTRU using the second configuration information; and determine that one or more error conditions have occurred within a duration of time associated with an error checking time value, wherein the duration of time began at the time the parameter was updated using the second configuration information.

10. The WTRU of any of claims 1 to 4, wherein the processor is further configured to: receive a set of configuration information from the CU RRC entity;determine that the update of the parameter associated with the WTRU using the first configuration information or the second configuration information results in a reconfiguration failure, wherein the update of the parameter is a first update; determine a third configuration information from the set of configuration information, wherein the third configuration information is compatible with the first configuration information; and perform a second update of the parameter associated with the WTRU using the first configuration or the third configuration.

11. A method comprising: receiving a first radio resource control (RRC) message from a distributed unit (DU) RRC entity, wherein the first RRC message indicates first configuration information and a first interdependency characteristic; in response to receiving the first RRC message, setting an interdependence RRC message timer based on an interdependence RRC message reception time duration; receiving a second RRC message from a control unit (CU) RRC entity, wherein the second RRC message indicates second configuration information and a second interdependency characteristic; determining that a first condition and a second condition are satisfied, wherein the first condition is determined to be satisfied based on the second RRC message being received before expiry of the interdependence RRC message timer, and wherein the second condition is determined to be satisfied based on the first interdependency characteristic and the second interdependency characteristic; and updating, based on determining that the first condition and the second condition are satisfied, a parameter associated with the WTRU using the first configuration information or the second configuration information.

12. The method of claim 11 , wherein the interdependence RRC message reception time duration is preconfigured or is received from the DU RRC entity.

13. The method of claim 11 or 12, wherein determining that the second condition is satisfied comprises a determination that the first interdependency characteristic and the second interdependency characteristic indicate a same value.

14. The method of claim 11 or 12, wherein determining that the second condition is satisfied comprises a determination that the first interdependency characteristic and the second interdependency characteristic indicate that the first RRC message and the second RRC message are interdependent.

15. The method of any of claims 11 to 14, wherein the method further comprises: sending a first reconfiguration message to the DU RRC entity and a second reconfiguration message to the CU RRC entity, wherein the first reconfiguration message or the second reconfiguration message comprises an indication that the parameter is updated.

16. The method of any of claims 11 to 14, wherein the parameter comprises a first parameter and a second parameter, and wherein the method further comprises: updating, based on the determination that the first condition and the second condition are satisfied, the first parameter using the first configuration information and the second parameter using the second configuration information.

17. The method of any of claims 11 to 14, wherein the method further comprises: determining that a third condition is satisfied, wherein the third condition is determined to be satisfied based on a WTRU speed satisfying a threshold; and updating, based on the determination that the first condition, the second condition, and the third condition are satisfied, the parameter associated with the WTRU using the second configuration information.

18. The method of any of claims 11 to 14, wherein the method further comprises: updating, based on the determination that the first condition and the second condition are satisfied, the parameter associated with the WTRU using the first configuration information; and sending a first reconfiguration message to the DU RRC entity and a second reconfiguration message to the CU RRC entity, wherein the first reconfiguration message comprises an indication that the parameter is updated based on the first configuration information, and the second reconfiguration message comprises an indication that the parameter is not updated based on the second configuration information.

19. The method of any of claims 11 to 14, wherein the method further comprises: updating, based on determining that the first condition and the second condition are satisfied, the parameter associated with the WTRU using the second configuration information; and determining that one or more error conditions have occurred within a duration of time associated with an error checking time value, wherein the duration of time began at the time the parameter was updated using the second configuration information.

20. The method of any of claims 11 to 14, wherein the method further comprises: receiving a fallback configuration from the DU RRC entity or the CU RRC entity;determining that a failure condition for performing a recovery procedure is satisfied, wherein the failure condition indicates at least one of a reconfiguration failure, an integrity verification failure, or a handover failure; receiving a reconfiguration message from the DU RRC entity; and performing another update of the parameter based on the fallback configuration.

Images