Method, architecture, apparatus and system for cell handover

Abstract

Procedures, methods, architectures, apparatuses, systems, devices, and computer program products for cell handover of a wireless transmit / receive unit (WTRU), and radio resource control (RRC) configuration overhead and / or data retransmissions are reduced. The RRC reconfiguration data structure is made modular by separating the data structure into configuration parts, e.g., a CU-specific part, a DU-specific part, and a cell-specific part. One configuration per CU, one configuration per DU, and one configuration per cell may be provided. According to one embodiment, one candidate cell group configuration is provided for each potential SCG and each potential MCG. Any part of the above configuration may be provided with an ID. By using common building blocks and IDs, the WTRU can determine what the differential configuration is based on the IDs of the source and target cell configurations and apply any required configurations and associated actions.

Description

[Technical Field]

[0001] The present disclosure is generally directed to the fields of communications, software and encoding, and includes, for example, methods, architectures, apparatus, and systems relating to handover of a wireless transmit / receive unit from a source cell to a target cell. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of (i) U.S. Provisional Patent Application No. 63 / 410,777, filed September 28, 2022, (ii) U.S. Provisional Patent Application No. 63 / 420,306, filed October 28, 2022, and (iii) U.S. Provisional Patent Application No. 63 / 456,262, filed March 31, 2023, each of which is incorporated herein by reference.

[0003] In a traditional L3 handover, or conditional one, a wireless transmit / receive unit (WTRU) will typically first send a measurement report using radio resource control (RRC) signaling. In response, the network can provide further measurement configuration and potentially conditional handover (CHO) configuration. In a traditional handover, the network provides configuration for the target cell after the WTRU reports using RRC signaling that the cell meets the configured radio quality criteria. In a conditional handover, to reduce handover failure rates due to delays in sending measurement reports and then receiving RRC reconfiguration, the network provides target cell configuration in advance, as well as metrics that determine when the WTRU should trigger CHO configuration. However, both of these L3 methods incur some amount of delay due to sending measurement reports and receiving the target configuration, especially for traditional (non-conditional) handover. There is a need to reduce handover latency. Summary of the Invention [Means for solving the problem]

[0004] According to one aspect of the present disclosure, there is provided a method performed by a WTRU according to the described embodiments and the appended claims.

[0005] According to further aspects of the present disclosure, embodiments of a WTRU are described and claimed in the accompanying claims. [Brief explanation of the drawings]

[0006] A more detailed understanding can be had from the following detailed description, given by way of example in conjunction with the drawings attached hereto. The figures in such drawings, like the detailed description, are examples only. Therefore, the figures and detailed description should not be considered limiting, as other equally valid examples are possible and possible. Moreover, like reference numerals in the figures indicate like elements.

[0007] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system. [Figure 1B] 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) used within the communication system shown in FIG. 1A. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN for use within the communication system shown in FIG. 1A. [Figure 2] FIG. 1 is a sequence diagram showing the basic handover procedure of New Radio (NR). [Figure 3] FIG. 1 illustrates an Abstract Syntax Notation One (ASN.1) representation of an excerpt of a Radio Resource Control (RRC) reconfiguration message. [Figure 4A] 4 shows an ASN.1 representation of other relevant information elements (IEs) of the RRC reconfiguration message of FIG. 3. [Figure 4B] 4 shows an ASN.1 representation of other relevant information elements (IEs) of the RRC reconfiguration message of FIG. 3. [Figure 4C] 4 shows an ASN.1 representation of other relevant information elements (IEs) of the RRC reconfiguration message of FIG. 3. [Figure 4D] 4 shows an ASN.1 representation of other relevant information elements (IEs) of the RRC reconfiguration message of FIG. 3. [Figure 5] FIG. 1 is a diagram of a cell group and a cell. [Figure 6] FIG. 1 illustrates an example physical layer (L1) / radio link control (L2) inter-cell mobility using carrier aggregation (CA). [Figure 7] 1 is a flowchart of one embodiment of a method for handover using a modular RRC configuration for pre-configured cells that properly allows for multiple primary cell changes while minimizing RRC configuration overhead and ensuring no unnecessary data retransmissions or data loss. [Figure 8] FIG. 1 is a diagram summarizing the existing RRC reconfiguration ASN.1 structure. [Figure 9] FIG. 1 illustrates one embodiment of a rearranged modular RRC reconfiguration ASN.1 structure. [Figure 10] FIG. 10 illustrates an embodiment of an alternative encoding of modular parts and relationships. [Figure 11] FIG. 10 illustrates an embodiment of a further alternative encoding of modular parts and relationships. [Figure 12] 11, which is a diagram related to steps 704 and 705a-b of FIG. 7, with reference to a further alternative embodiment. [Figure 13] 1 is a flowchart of a method for cell handover of one embodiment. [Figure 14] 10 is a flowchart of a method for cell handover of a further embodiment; [Figure 15]10 is a flowchart of a method for cell handover performed by a WTRU according to a further embodiment; DETAILED DESCRIPTION OF THE INVENTION

[0008] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. It will be understood, however, that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively, "provided") herein. Although various embodiments are described and / or claimed herein in which apparatuses, systems, devices, etc., and / or any elements thereof, perform operations, processes, algorithms, functions, etc., and / or any portions thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc., and / or any elements thereof, are configured to perform any operation, process, algorithm, function, etc., and / or any portion thereof.

[0009] Exemplary Communication System

[0010] The methods, apparatus, and systems provided herein are suitable for communication involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to Figures 1A-1D, where various elements of the network may utilize, implement, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatus, and systems provided herein.

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

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

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

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

[0015] 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).

[0016] More particularly, as mentioned above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 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 Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

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

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

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

[0020] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0021] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one 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 either a small cell, a picocell, or a femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0022] 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, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error resilience, reliability, data throughput, mobility, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid 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 understood that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

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

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

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

[0026] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be incorporated together, for example, in an electronic package or chip.

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

[0028] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. For 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.

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

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

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

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

[0033] The processor 118 may further be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the elements / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The element / peripheral 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0034] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the uplink (e.g., for transmission) and the downlink (e.g., for reception) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and or substantially eliminating self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio that is for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the uplink (e.g., for transmission) or the downlink (e.g., for reception)).

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

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

[0037] Each of the eNodeBs 160a, 160b, and 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 uplink (UL) and / or downlink (DL), etc. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0039] The MME 162 may be connected to each of the eNodeBs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. 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.

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

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

[0042] The CN 106 may facilitate communication 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 communication between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

[0045] 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 access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic during and / or from the BSS. Traffic to the STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within the BSS may be sent through the AP, e.g., where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA via a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

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

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

[0048] A very high throughput (VHT) STA can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz channel and / or an 80 MHz channel can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be passed through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to a medium access control (MAC) layer, entity, etc.

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

[0050] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA, from among all STAs operating in the BSS, that supports the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if a STA (that only supports 1 MHz operating mode) transmits to an AP such that the primary channel is busy, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and available for use.

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

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

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

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

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

[0056] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another via an Xn interface.

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

[0058] 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 act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c, for example, based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on Ultra-Reliable Low Latency (URLLC) access, services relying on enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc. The AMFs 182a, 182b 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 Wi-Fi.

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

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

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

[0062] 1A-1D and the corresponding description thereof, one or more, or all, of the functions described herein with respect to any of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other element / device(s) described herein may be performed by one or more emulation elements / 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 functionality.

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

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

[0065] Below is a list of abbreviations used herein: ACK Acknowledgment AS Application Server BLER Block Error Rate BWP Bandwidth Part CA Carrier Aggregation CC Component Carrier CCE Control Channel Element CHO Conditional Handover CE Control Element CG A configured grant or cell group CP Cyclic Prefix CPA conditional PSCell addition CPC Conditional PSCell Change CQI Channel Quality Indicator C-RNTI Cell Radio Network Temporary Identifier CSI Channel State Information CSI-RS CSI reference signal CU Central Unit DC Dual Connectivity DCI Downlink Control Information DG Dynamic Grant DL Downlink DM-RS Demodulation Reference Signal DRB Data Radio Bearer DRX Discontinuous reception DU Distributed Unit FR1 / 2 Frequency range 1 / 2 HARQ Hybrid Automatic Repeat Request HO Handover ID Identifier L1 5G NR physical layer L2 5G NR MAC RLC and PDCP layers L3 5G NR RRC layer LTE Long-term evolution from e.g. 3GPP LTE R8 and above NACK Negative ACK MAC Media Access Control MAC CE MAC Control Element MCG Master Cell Group MCS Modulation and Coding Scheme MIMO Multiple Input Multiple Output NR New Radio OFDM Orthogonal Frequency Division Multiplexing PCell Primary Cell PDCP Packet Data Convergence Protocol PDCCH Physical Downlink Control Channel PDSCH Physical Downlink Shared Channel PHY Physical Layer (L1) PO Paging Occasion PRACH Physical Random Access Channel PSCell Primary SCG cell PSS Primary Synchronization Signal RA Random Access (or Procedure) RACH Random Access Channel RAR Random Access Response RLC Radio Link Control RLC-AM RLC acknowledged mode RLF Radio Link Failure RLM Radio Link Monitoring RNTI Radio Network Identifier RO RACH occasion RRC Radio Resource Control RRM Radio Resource Management RS Reference Signal RSRP reference signal received power RSSI Received Signal Strength Indicator SCell Secondary Cell SCG Secondary Cell Group SCH Shared Channel SDAP Service Data Adaptation Protocol SDU Service Data Unit SMTC SSB-based measurement timing configuration SpCell Special Cell* SRS Sounding Reference Signal SS Sync Signal SSS Secondary Synchronization Signal SWG Switching gap (in self-contained subframes) SPS Semi-persistent scheduling SUL Supplemental Uplink TA Timing advance TAG Timing Advance Group TB Transport Block TBS Transport Block Size TCI Transmission Configuration Indication TRP sending and receiving point TSC Time-sensitive communication TSN Time-sensitive networking UL Uplink *The term SpCell refers to either a PCell of an MCG or a PSCell of an SCG, depending on whether the MAC entity is associated with an MCG or an SCG.

[0066] Handover - Procedure Overview

[0067] Figure 2 shows a basic handover procedure in NR. The entities shown, from top left to top right, are WTRU 260, source gNB 261, target gNB 262, AMF 263, and UPF 264. From top right to bottom right, the different phases of handover are shown, with handover preparation phase 230, handover execution phase 240, and handover completion phase 250.

[0068] At 200, the WTRU context in the source gNB includes information regarding roaming and access restrictions provided either at connection establishment or at the last TA (Timing Advance) update.

[0069] At 201, the source gNB configures a WTRU measurement procedure, and the WTRU reports according to the measurement configuration.

[0070] At 202, the source gNB determines to hand over the WTRU based on the received measurements.

[0071] At 203, the source gNB issues a handover request message to the target gNB, passing a transparent RRC container with necessary information to prepare the handover at the target side, including at least the target cell ID, KgNB* (KgNB* is an intermediate security key derived when performing horizontal or vertical key derivation), the C-RNTI of the WTRU at the source gNB, RRM configuration including WTRU inactivity time, basic AS configuration including antenna info and DL carrier frequency, current QoS flow-to-DRB mapping rule applied to the WTRU, system information block 1 (SIB1) from the source gNB, WTRU capabilities for different RATs, PDU session-related information, and, if available, WTRU-reported measurement information including beam-related information.

[0072] At 204, admission control may be performed by the target gNB.

[0073] At 205, if the WTRU can be admitted, the target gNB prepares the handover via L1 / L2 and sends a HANDOVER REQUEST ACKNOWLEDGE to the source gNB, including a transparent container (a container that does not need to be decoded by the source gNB) to be sent to the WTRU as an RRC message to perform the handover.

[0074] At 206, the source gNB triggers the Uu handover by sending an RRCReconfiguration message to the WTRU, which includes information needed to access the target cell, i.e., at least the target cell ID, the new C-RNTI, the target gNB security algorithm identifier for the selected security algorithm, which may also include a set of dedicated RACH resources, an association between the RACH resources and synchronization signal block (SSB(s)), an association between the RACH resources and the WTRU-specific CSI-RS configuration(s), common RACH resources, and system information of the target cell, etc.

[0075] At 207, the source gNB sends an SN STATUS TRANSFER message (SN represents sequence number) to the target gNB to convey the uplink PDCP SN receiver status and downlink PDCP SN transmitter status of the DRB for which PDCP status preservation applies (i.e., for RLC AM).

[0076] At 208, the WTRU synchronizes to the target cell and completes the RRC handover procedure by sending an RRCReconfigurationComplete message to the target gNB.

[0077] At 209, the target gNB sends a PATH SWITCH REQUEST message to the AMF to trigger the 5GC to switch the DL data path towards the target gNB and establish an NG-C interface instance towards the target gNB.

[0078] At 210, the 5GC switches the DL data path towards the target gNB. The UPF sends one or more "end marker" packets on the old path to the source gNB per PDU session / tunnel and can then release any U-plane / TNL resources towards the source gNB.

[0079] At 211, the AMF acknowledges the PATH SWITCH REQUEST message with a PATH SWITCH REQUEST ACKNOWLEDGE message.

[0080] At 212, upon receipt of the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB sends a UE CONTEXT RELEASE to inform the source gNB about the successful handover. The source gNB can then release radio and C-plane related resources associated with the WTRU context. Ongoing data forwarding can continue.

[0081] Handover - Configuration Details

[0082] The HO command is essentially an RRCReconfiguration message containing a reconfigurationWithSync. An excerpt of the RRC reconfiguration message and other associated information elements (IEs) is shown in Figures 3A-3C.

[0083] The RRCReconfiguration message 300 (see FIG. 3) contains the cell group configuration 302 (master cell group and possibly secondary cell group if dual connectivity DC is configured).

[0084] The cell group configuration (element 302 in Figures 3 and 4A-4D) contains the configuration of all cells that belong to the cell group (i.e., cells operating in carrier aggregation (CA)). These cells, collectively known as serving cells, are divided into primary and secondary cells.

[0085] The primary cell is the cell operating on the primary frequency on which the WTRU either performs the initial connection establishment procedure or initiates the connection re-establishment procedure, or the cell indicated as the primary cell in a handover procedure. The primary cell for the master cell group is called the PCell, and the primary cell for the secondary cell group (if DC is configured) is called the PSCell (Primary Secondary Cell). The term SpCell (special cell) is used to refer to the PCell and the PSCell.

[0086] A secondary cell (SCell) is a cell that provides other carriers used during carrier aggregation for the corresponding cell group.

[0087] A diagram of cell groups and cells is shown in Figure 5. Many operations, such as radio link monitoring (RLM) and associated radio link failure (RLF) detection and recovery, pertain only to the primary cell.

[0088] Each serving cell is identified by a servCellIndex (serving cell index), which can take on values ​​from 0 to 31. A PCell is always assigned a servCellIndex value of 0.

[0089] Inter-cell L1 / 2 mobility

[0090] 3GPP TSG RAN R17 supports inter-cell L1 / 2 mobility for managing beams in case of CA, but cell change / add is not supported.

[0091] In 3GPP TSG RAN R18, one of the goals of the work item "Further NR Mobility Enhancements" is to specify mechanisms and procedures for L1 / L2-based inter-cell mobility for mobility latency reduction, including: Configuration and maintenance of multiple candidate cells to enable fast application of configurations for candidate cells [RAN2, RAN3]; Dynamic switching mechanisms between candidate serving cells (including SpCell and SCell) for potential applicable scenarios based on L1 / L2 signaling [RAN2, RAN1], L1 extensions for inter-cell beam management, including L1 measurements and reporting, and beam indication [RAN1, RAN2]; Note 1: Early RAN2 involvement is needed, including the possibility of further clarifying the interaction between this bullet and the previous one. Timing advance management [RAN1, RAN2], CU-DU interface signaling to support L1 / L2 mobility, if required [RAN3], NOTE 2: FR2-specific extensions, if any, are not excluded. NOTE 3: The L1 / L2 based inter-cell mobility procedure is applicable to the following scenarios: In the case of standalone, CA and NR-DC, where the serving cell changes within one CG, Intra-DU and intra-CU inter-DU cases (applicable to standalone and CA, no new RAN interfaces expected), both within and between frequencies, Both FR1 and FR2, The source and target cells may be synchronous or asynchronous. This does not include between CUs.

[0092] L1 / L2-based mobility was initially launched in R17, and inter-cell beam management in R17 addresses intra-DU and intra-frequency scenarios. In this case, the serving cell remains unchanged (i.e., there is no possibility to change the serving cell using L1 / L2-based mobility). In FR2 deployments, CA is typically used to aggregate multiple CCs, for example, in one band, to utilize the available bandwidth. These CCs are typically transmitted on the same analog beam pair (gNB beam and WTRU beam). The WTRU is configured with TCI states (which can have a fairly large number, e.g., 64) for reception of PDCCH and PDSCH. Each TCI state includes an RS or SSB that the WTRU references to set its beam. In R17, an SSB can be associated with a non-serving PCI. MAC signaling ("TCI State Indication for WTRU-Specific PDCCH MAC CE") activates the TCI state for Coreset / PDCCH. Reception of PDCCH from non-serving cells is supported by the MAC CE indicating the TCI state associated with the non-serving PCI. MAC signaling ("TCI state activation / deactivation for WTRU-specific PDSCH") activates a subset of (at most) eight TCI states for PDSCH reception. The DCI indicates one of the eight TCI states. R17 also supports "combined TCI state" with a different update mechanism (DCI-based) but without multi-TRP. R18 will support combined TCI state with multi-TRP.

[0093] The overall goal of L1 / 2 inter-cell mobility is to improve handover latency, and in traditional or conditional L3 handover, the WTRU would typically first send a measurement report using RRC signaling. In response, the network can provide further measurement configuration and potentially a conditional handover configuration. In traditional handover, the network provides configuration for the target cell after the WTRU reports using RRC signaling that the cell meets the configured radio quality criteria. In conditional handover, to reduce handover failure rates due to delays in sending measurement reports and then receiving RRC reconfiguration, the network provides the target cell configuration in advance, as well as metrics that determine when the WTRU should trigger CHO configuration. However, both of these L3 methods incur some amount of delay due to sending measurement reports and receiving the target configuration, especially for traditional (non-conditional) handover.

[0094] In particular, the aim of L1 / 2-based inter-cell mobility is to enable fast application of configurations for candidate cells, including dynamic switching between SCells and PCell switching (e.g., switching roles between SCell and PCell) without RRC signaling. The inter-CU case requires PDCP anchor relocation and is not included in the R18 work, as it has already been excluded from the work item. Therefore, an improvement is needed, and according to an embodiment, an RRC-based approach to support at least inter-CU handover is disclosed. One of the aims of L1 / 2 should also be to enable CA operation to be enabled instantly upon serving cell change.

[0095] 6 shows an example of L1 / 2 inter-cell mobility operation using CA, where candidate cell groups are configured by RRC and dynamic switching between PCells and SCells is achieved using L1 / 2 signaling. When a WTRU 604 moves through the coverage of multiple cells, e.g., here through the coverage of cell 1 (603), cell 2 (600), cell 3 (601), and cell 4 (602), in cell 1, the RRC first configures cells 1-4 as candidates and activates cell 1 as a PCell (PCell1) and cell 2 as an SCell (SCell2). Then, when the WTRU moves to the next location, dynamic SCell switching is operated between cells 2 and 3 such that cell 2 is deactivated and cell 3 is activated as an SCell. At the next location, dynamic SCell switching is operated between cells 2 and 3 such that cell 3 is deactivated and cell 2 is once again activated as an SCell. At the next location, dynamic and simultaneous PCell and SCell switching is operated such that cell 2, which was previously the SCell, becomes the new PCell and cell 4 becomes the new SCell, while cell 1 is deactivated.

[0096] Reduced RRC configuration overhead

[0097] For L1 / 2 mobility and also for CHO / CPC / CPA with multiple "hops", the RRC configuration overhead is large because multiple candidate target cells must be pre-configured before a handover is triggered, which results in signaling overhead (i.e., over the air) and WTRU storage overhead.

[0098] This has already been recognized, and 3GPP RAN2 agreed in RAN2 WG meeting #119 that "RAN2 should consider the provision of target cell configurations that allow dynamic switching without requiring full configuration."

[0099] In conventional handovers using RRC reconfiguration messages, it is possible for the network to signal a "delta" configuration, i.e., signal only the difference between the current (source) cell configuration and the new (target) cell configuration, to reduce overhead. To support delta configurations after multiple "hops" (i.e., cell handovers across multiple pre-configured cells), the delta configuration for the target should also depend on the source's delta configuration. One possibility is for every target cell to be configured with a delta configuration based on the original cell (the cell providing the pre-configuration). For example, a WTRU may be configured with baseline_config when the PCell is cell1, configured with configA, a delta configuration from baseline_config, for candidate cellA, and configured with configB, a delta configuration also from baseline_config, for cellB. When the PCell is changed to cellA, the WTRU applies configA. However, if the WTRU then has to change the PCell to cellB, it cannot directly apply configB. Therefore, the WTRU must revert to the baseline_configuration (ie, the full configuration), followed by the differential configuration configB.

[0100] When the WTRU performs a full configuration, it releases all current dedicated radio configuration except for the MCG C-RNTI, AS security configuration and radio bearers (signaling and data), and logged measurements (TS38.331, section 5.3.3.11). This has some undesirable effects, such as the loss of any buffered data (waiting for initial transmission or retransmission) at the RLC / MAC level, which will cause data transmission interruptions, and may also lead to data loss (e.g., if a discard timer expires for a packet at the PDCP level). This is one of the reasons why full configuration is rarely used (in addition to having the drawback of incurring signaling overhead) and is mostly only used during RRC re-establishment, where the WTRU has to restart the connection from scratch after a failure such as a Radio Link Failure (RLF), or during connection resumption from INACTIVE state in scenarios where the target node / cell to which the WTRU is resuming the connection has some incompatibility with the source node / cell that sent the WTRU to INACTIVE state.

[0101] Furthermore, it was agreed at RAN2 WG Meeting #119 that "R2 assumes that L2 continues whenever possible (e.g., within the DU) without reset, with the goal of avoiding data loss and additional delays in data recovery." This means that, at least in the intra-DU case, RLC / PDCP and MAC reset may not be necessary. In the intra-DU case, since the MAC resides in the DU part of the network, there is no reason to reset the MAC (as is done in conventional L3 handover to cover all cases) if the MAC configuration is identical for both cells. RLC and PDCP reside in the CU, and therefore, in the case of L1 / 2 mobility, it may be possible to leave RLC and PDCP unchanged and avoid re-establishing them. In other cases, such as CHO, handover may cross the CU, and therefore RLC / PDCP may need to be re-established.

[0102] The goal of the proposed method according to the embodiment is to correctly enable multiple primary cell changes while minimizing the RRC configuration overhead and ensuring there are no unnecessary data retransmissions or data losses.

[0103] Handover using modular RRC architecture

[0104] FIG. 7 is a method 700 for handover using modular RRC configuration for pre-configured cells, according to one embodiment.

[0105] At 701, a WTRU may receive a configuration to be used for multiple cells, consisting of multiple configuration parts and an ID for each configuration part.

[0106] At 702, the WTRU may also receive (e.g., as part of the configuration) an indication of how to build a full configuration for each of the cells, referencing the corresponding ID of each part for use in the cell configuration.

[0107] At 703, the WTRU may receive a handover trigger (eg, an L1 / 2 mobility command).

[0108] At 704, for each configuration part, the WTRU may compare the source cell ID and the target cell ID, and for configuration parts that are different, the WTRU may apply the change and any associated procedures associated with the change at step 705b, and for parts that are not different, the WTRU may leave the existing configuration as is at step 705a and may not perform the associated procedures.

[0109] Handover using modular RRC architecture: RRC reconfiguration architecture

[0110] Figure 8 summarizes the existing RRC reconfiguration ASN.1 structure. Not all parts of the configuration are shown, but some of the parts of the configuration have been selected to help illustrate the concept. As can be seen, the different parts of the hierarchical structure of the radio bearer reconfiguration can be summarized as follows:

[0111] CU-specific information (shown as solid rectangles) typically resides in the top level of the RRC reconfiguration message (e.g., radio bearer configuration, including PDCP and SDAP configuration, which would reside in the CU in an NR CU / DU split architecture). Other information elements at this level (not shown in this figure) include measurement configuration, security configuration, and other configurations (related to other aspects such as delay budget reporting, overheating assistance information reporting, etc.).

[0112] DU-specific information (shown as short dashed rectangles) is typically present in the cell group configuration part of the message. The RRC reconfiguration message may contain cell group configuration for only the MCG (in the case of standalone NR without DC), only the SCG (in the case of EN-DC), or both the MCG and SCG (in the case of NR-DC). The cell group specific information includes the RLC bearer configuration, MAC cell group configuration, and physical cell group configuration. These parts are typically present in the DU part of the network in the case of a CU / DU split architecture.

[0113] Cell-specific information (shown as long dashed rectangles for SpCells and long dash-dotted rectangles for SCells). Typically, this is physical layer related information that may differ for individual cells.

[0114] Handover using modular RRC configuration: Modular RRC configuration

[0115] According to embodiments, by utilizing a network architecture where different parts of the configuration are associated with different parts of the network, the network can use a common configuration for some parts of the cell configuration. For example, according to one embodiment, if two candidate cells belong to the same DU, the MAC configuration may be identical or nearly identical, and the configuration itself may be shared, such that there is no need to perform a MAC reset when reconfiguring between the two cells. To support this, the ASN.1 structure may be rearranged according to one exemplary embodiment shown in FIG. 9.

[0116] As can be seen from this figure, the RRC configuration may be separated into parts, for example, a CU-specific part, a DU-specific part, and a cell-specific part. In that case, one configuration may be provided per CU, one configuration may be provided per DU, and one configuration may be provided per cell. In an alternative embodiment, one RRC reconfiguration may be provided for the SCG and another for the MCG. In yet another alternative embodiment, one candidate cell group configuration may be provided for potential SCGs and for potential MCGs. For example, one may be provided for each potential SCG and each potential MCG.

[0117] Furthermore, according to one embodiment, an ID may be provided or derived for each CU configuration, DU configuration, and cell configuration (e.g., a radio bearer configuration ID, a candidate cell group configuration ID, and a candidate cell configuration ID). Each candidate cell (with a candidate cell ID) may be provided with both an SpCell configuration and an SCell configuration, or alternatively, the SpCell configuration and the SCell configuration may be provided with separate IDs (e.g., treated as separate cell configurations). Parts of the configuration may be the same for different CUs, DUs, and cells. For example, a network may be provided with the same uplink configuration in every cell. In this case, the uplink configuration may be assigned an ID, and each cell configuration may reference its uplink configuration ID. Similarly, any part of a configuration may be provided with an ID, such that any common configuration is provided with an ID once, which can be referenced on the overall configuration. In general, a configuration may be separated into many smaller blocks, each of which is provided with an ID that can be referenced when building the overall configuration. By doing this, configuration overhead can be minimized by utilizing common parts even when configuring many cells belonging to several DUs or CUs.

[0118] A second advantage is that by using this type of structure with common building blocks and IDs, the WTRU can determine what the “delta” configuration is based on the IDs of the source and target cell configurations, without needing to refer to the original cell from which the configuration was received, or the “baseline” configuration. The WTRU can calculate the “delta” directly based on the current (source) and target cell configurations. Furthermore, the WTRU can determine which procedures it must perform; for example, if the source and target radio bearer configuration IDs are the same, PDCP (and possibly RLC as well) may not need to be re-established; if the IDs are different, the WTRU may need to perform RLC and PDCP re-establishment. By assigning this behavior to the radio bearer configuration, this also avoids the network having to expose its actual architecture beyond a traditional RRC reconfiguration (i.e., the WTRU just follows the radio bearer configuration, and the CU ID is not explicitly indicated). Similarly, if the source and target cell group configuration IDs are the same, the MAC may not need to be reset and the configuration may not need to be changed, but if the source and target cell group configuration IDs are different, the WTRU may perform a MAC reset. Similar checks may be performed for any configuration part ID to determine whether the configuration should be updated and what procedure (action) to take. For example, the WTRU may determine whether the cells are synchronized (same ID) or unsynchronized (different ID) based on comparing the IDs provided for each cell. Or the WTRU may determine whether the cells are on the same physical site and therefore can use the same timing advance.This can be used, for example, when reconfiguring from one cell to another, to decide whether to use a RACH procedure (e.g., if the TA needs to be obtained using the RACH procedure) or a RACH-less procedure (e.g., if the TA can be assumed to be the same in the source and target cells).

[0119] Exemplary procedures to be performed when performing a cell change may include, but are not limited to:

[0120] MAC reset,

[0121] PDCP re-establishment,

[0122] RLC re-establishment,

[0123] Security Refresh,

[0124] Physical layer synchronization,

[0125] Random access,

[0126] System information collection,

[0127] Measurement configuration or conditional reconfiguration updates,

[0128] neighbor cell relationship updates,

[0129] Tracking area update / registration,

[0130] C-RNTI change,

[0131] SCG activation / deactivation,

[0132] SCell activation / deactivation,

[0133] RACH procedure (sending PRACH in RAR and receiving TA),

[0134] RACH-less procedure (when TA is known in advance).

[0135] According to one embodiment, the handover trigger (e.g., an L1 / 2 mobility command or a CHO trigger) may reference only a candidate cell ID. From this candidate cell ID and pre-configured association to other parts of the configuration, the WTRU can determine the cell group configuration ID and radio bearer configuration ID. According to other embodiments, the handover trigger may explicitly specify the cell group ID, cell group type (e.g., MCG, SCG), and the SpCells and SCells to be included in the cell group. In some embodiments, a NULL pointer may be used in the handover trigger or pre-configured cell to indicate no changes to the previous configuration. For example, if the network knows that the cell change is within a DU, it may indicate a "NULL" cell group and a new candidate cell ID.

[0136] In addition to the configuration parts described above, measurement configurations and neighbor cell relationships may be determined in a similar manner. For example, by indicating that cells 1, 2, and 3 are neighbors, the WTRU knows that, for example, when on cell 1, its neighbors are cells 2 and 3, and that the measurement configuration (e.g., SMTC) to use is the one corresponding to cells 2 and 3.

[0137] According to embodiments, it is also possible to configure the IDs implicitly, for example, one cell group configuration may be provided for each candidate SpCell, together with the complete configuration of SpCells and SCells, as in, for example, Figure 10, an exemplary alternative embodiment of encoding of modular parts and relationships.

[0138] In the example of this figure, four candidate cells are configured, each with a corresponding cell group configuration and SCell configuration. Because each candidate cell belongs to the same DU, the cell group configuration is the same and, therefore, can be provided only once, along with the first candidate cell. Subsequent candidate cells include a NULL pointer indicating that the cell group configuration is the same as the previous one in the list (i.e., the one with candidate cell configuration ID 0). In this way, when a handover trigger is received to change between any two of these cells, the same cell group configuration (e.g., implicitly with ID 0) is referenced. If a fifth cell (e.g., ID 4) is configured in this list with an explicit cell group configuration, further subsequent cells may be configured with a NULL pointer indicating that the cell group configuration is the same as the configuration with ID 4. In this way, there is a cell associated with a cell group configuration with index 0 and a cell associated with a cell group configuration with index 5. A change in cell group configuration index may imply a change of DU and therefore a MAC reset.

[0139] According to an embodiment, SCells may be configured with explicit serving cell IDs. Since the PCell always has a serving cell ID of 0, in the case of an SCG, one potential encoding may follow Figure 10, where a first candidate cell configuration may be provided with an explicit configuration with SCells with serving cell identities 2, 3, and 4. A second candidate cell configuration provides an explicit configuration for an SCell with serving cell identity 1, and SCells with serving cell identities 3 and 4 are referenced from the first candidate cell configuration. In a third candidate cell configuration, SCells with serving cell identities 1, 3, and 4 are referenced from the first two candidate cell configurations, and a fourth serving cell configuration references SCells with serving cell identities 1, 2, and 3 from the first two candidate serving cell configurations. In an SCG, an SpCell may have any serving cell identity. In this case, the candidate cell configuration may provide an explicit serving cell identity for each SCell as well as the SpCell, but the configuration itself may be referenced in the same way, i.e., an explicit identity and a NULL pointer (if referencing another serving cell configuration), or an explicit configuration (if different from the previously configured serving cell) is provided for each serving cell in the configuration. Thus, serving cells may be provided with either an explicit or implicit serving cell identity, either based on their position in the list or based on the serving cell type (PCell or other).

[0140] Regardless of whether explicit (e.g., signaled) or implicit (e.g., position-in-list-dependent) IDs are used to identify cell groups, cells, or individual configuration parts, the WTRU may be able to distinguish which parts are different and therefore which parts should be updated and which associated procedures must be performed to perform a handover or cell reconfiguration based on comparing the source (current) and target (new) configurations.

[0141] In an alternative exemplary embodiment, the network provides a reference (full) configuration, which is either the current cell configuration or a reference (not yet applied) configuration. Each of the candidate cells may be provided with a differential configuration (from the reference full configuration). This is shown in Figure 11, which represents an alternative exemplary embodiment of the coding of module parts and relationships.

[0142] In the exemplary embodiment in this figure, a reference configuration may be provided. Each candidate cell configuration may be provided as a difference compared to the reference configuration. Candidate cell ID 0 may include difference configuration IE A.1 (which, for illustration, is IE type A, content version 1) and difference configuration B.1. Candidate cell 1 has difference configuration IE B.1 (the same IE, B, and content as this IE in cell 0) and C.1 (a different IE, C, that is unmodified in cell 0). Candidate cell 2 has difference configuration IE A.2 (the same IE as in cell 0, but different content) and C.1 (the same IE and content as in cell 1).

[0143] Assuming that the WTRU has applied a reference configuration for the current cell, when a handover to candidate cell 0 is triggered, the WTRU may apply a delta configuration consisting of IEs A.1 and B.1 and take the associated actions.

[0144] If a subsequent handover occurs between cell 0 and cell 1, the WTRU may compare the differential configuration of cell 0 with the differential configuration of cell 1. Since IE A.1 has not been modified in cell 1 compared to the reference configuration, the WTRU may revert the configuration of IE A to that provided in the reference configuration and may take associated actions (e.g., release measurements, reset MAC, etc., as enumerated earlier in this disclosure). Differential configuration B is the same in both cell 0 and cell 1, and therefore no action is taken. Differential configuration C is implemented on top of the reference configuration because it was not modified when the reconfiguration for cell 0 was performed.

[0145] If a subsequent handover occurs between cell 0 and cell 2, the WTRU can compare the differential configuration of cell 0 with the differential configuration of cell 2. IE A is modified in both of these configurations, but using different content. In one exemplary embodiment, the WTRU first reverts IE A to the original configuration and then applies configuration A.2. In an alternative example, IE applies only the difference between A.1 and A.2. Configuration B is reverted to the reference configuration, and configuration C.1 is applied as the difference compared to the reference configuration. In this exemplary embodiment, each candidate cell may be provided as a differential configuration that is compared to the reference configuration; this allows for a closer similarity to the legacy RRC reconfiguration message content, but it avoids the need to apply the reference (full) configuration every time a handover occurs; the WTRU may simply compare the differential parts between the source and target cells, revert any parts of the configuration that do not differ from the reference configuration, and apply any (differential) changes that differ between the source and target.

[0146] Handovers using modular RRC configurations: Reconfiguration of reference and / or candidate configurations

[0147] Once the WTRU is configured with a reference configuration and a set of one or more candidate configurations (e.g., based on differential or modular configurations as described above), the WTRU may be triggered via L1 / 2 signaling (e.g., MAC CE) to perform a reconfiguration and apply a target configuration as described above.

[0148] In conventional networks, when a WTRU receives an RRC reconfiguration message, it applies it directly and, in the case of a differential configuration, applies this differential configuration to the currently used configuration (i.e., the configuration that was in use when the RRC reconfiguration was received and before applying it). According to one embodiment, the network may perform an explicit RRC reconfiguration by sending an RRC reconfiguration message to the WTRU, and when the WTRU is pre-configured with a reference configuration, the WTRU may receive an indication in the RRC reconfiguration to specify whether the RRC reconfiguration (e.g., including the differential configuration) should be applied to the reference configuration, the current cell configuration, or both.

[0149] According to one embodiment, the WTRU is pre-configured with a reference configuration (e.g., the same as the cell 1 configuration) and differential configurations for cells 2 and 3 based on the reference configuration while on cell 1. After performing an L1 / 2 triggered mobility procedure from cell 1 to cell 2, the WTRU applies the differential configuration corresponding to cell 2.

[0150] According to one embodiment, when an RRC reconfiguration is received by the WTRU while on cell 2, this RRC reconfiguration may indicate that the WTRU should not update the currently used configuration, but only the reference configuration. When the WTRU performs a subsequent L1 / 2 triggered mobility, for example, from cell 2 to cell 3, the WTRU may need to apply the cell 3 differential configuration using the updated reference configuration. The updated reference configuration may be provided in a manner similar to any of the previous embodiments and examples. For example, using the example provided in FIG. 11, the updated reference configuration itself includes a differential configuration that may have an ID. In any subsequent L1 / 2 triggered cell change, the WTRU may compare the previously configured target cell configuration with the updated reference configuration and apply the necessary changes and procedures to the different parts.

[0151] In another embodiment, when an RRC reconfiguration is received by the WTRU while on cell 2, the RRC reconfiguration may indicate that the WTRU should update both the currently used configuration and the reference configuration. A further indication may be received to indicate whether the stored differential configuration for this cell should also be updated. If both the reference configuration and the current configuration are indicated as being updated, then if the differential configuration should also be updated, the parts of the new differential configuration that correspond to the reconfigured parameters will be the same as the reference configuration. For example, if the reference configuration is updated with a new RLC configuration, the stored differential configuration for this cell will be "NULL" (e.g., same as reference). If the differential configuration is not indicated to be updated, the WTRU modifies the currently used configuration and the stored reference configuration, but does not make any changes to the stored differential configuration for this cell. If the differential configuration for the current cell should not be updated, the WTRU may calculate a new difference compared to the updated reference configuration. Thus, the delta is the original part of the updated original reference configuration (i.e., before the update) compared to the updated reference configuration (i.e., after the update), and therefore the WTRU can store the original parameters from the reference configuration, calculated as the delta from the updated reference configuration, as part of the current cell differential configuration.

[0152] In another embodiment, when an RRC reconfiguration is received by the WTRU while on cell 2, this RRC reconfiguration may indicate that the WTRU should update both currently used configurations but not the reference configuration. An additional indication may be received to indicate whether the stored differential configuration for this cell should also be updated. In this case, the WTRU may simply update the current configuration, and when a subsequent L1 / 2 triggered cell change occurs, the WTRU may revert to the (e.g., original) reference configuration before applying the differential configuration for the new cell as before. The WTRU may or may not update the stored reference configuration for the cell from which the RRC reconfiguration was received (e.g., based on the indication). Because the reference configuration was not updated in this example, the WTRU stores the updated differential configuration for this cell as a differential compared to the original reference configuration.

[0153] Explicit configuration per source cell with configuration of whether the protocol layer should be reset when switching to the target

[0154] According to one embodiment, the WTRU may alternatively or additionally be configured with an explicit indication of whether to perform a protocol layer reset / reestablishment following L1 / L2 mobility. The WTRU may be further configured with such an indication per source and target cell pair; in particular, the WTRU may receive an indication of whether L1 / L2 mobility from a particular source cell to a particular target cell should trigger a protocol layer reset (e.g., MAC reset or partial reset, RLC reset / reestablishment, PDCP reestablishment). In particular, such an indication may be per cell pair (source and target). During L1 / L2 mobility from a source cell to a target cell, the WTRU may decide whether to perform a MAC reset, RLC reset, PDCP reestablishment, etc. based on the received indication associated with the source / target cell in question. The WTRU may receive such an indication for each source / target cell pair in RRC signaling, for example, for all source / target cell pairs in the area, or for all candidate L1 / L2 mobility targets upon RRC reconfiguration, or for all candidate L1 / L2 mobility targets sharing the same MAC or RLC or PDCP configuration ID.

[0155] In a similar manner, according to one embodiment, the WTRU may be configured with an indication for each source and target cell pair of whether to perform RACH-less mobility or RACH-based mobility.

[0156] Indication or determination of whether a delta configuration should be applied on top of the reference configuration or source cell configuration

[0157] According to embodiments, the WTRU may be configured with one or more L1 / 2 triggered mobility (LTM) candidate configurations, which are differential configurations (e.g., partial configurations that include only the difference between the current configuration or the reference configuration). In some embodiments, the configuration (e.g., LTM candidate configuration) may include an indication of whether the delta configuration should be applied to the source cell configuration (e.g., similar to a conventional RRC reconfiguration that includes a differential configuration) or whether it should be applied on top of the reference configuration (e.g., whether the WTRU applies the reference configuration first and then the differential configuration, or whether the WTRU builds a full configuration to be applied based on the reference configuration + the differential configuration). In some embodiments, a MAC CE (e.g., a MAC CE used to trigger an LTM cell switch) that includes a candidate configuration index may provide an indication of whether to apply the candidate differential configuration on top of the source cell configuration or the reference configuration.

[0158] In some embodiments, candidate configurations may be provided for cells belonging to one or more DUs. When a WTRU is triggered (e.g., using a MAC CE) to perform a cell switch to a target cell belonging to the same DU as the source cell, an indication may be provided to apply a differential configuration on top of the source cell (e.g., current) configuration. When a WTRU is triggered to perform a cell switch to a target cell belonging to a different DU, an indication may be provided to apply a differential configuration on top of a reference configuration. In this embodiment, it is possible to provide several candidate configurations that use differentials compared to the source cell, corresponding to cells on the same DU as the source cell, and several candidate configurations with differentials compared to a reference configuration, corresponding to a configuration for a DU different from the source cell. In this way, configuration overhead can be minimized by providing a reference configuration to be applied only if an LTM trigger indicates a change of DU; otherwise, a differential configuration is applied on top of the source cell configuration.

[0159] In some embodiments, the WTRU determines whether to apply a candidate delta configuration on top of a source cell configuration or a reference configuration. For example, in an initial LTM execution corresponding to a cell switch where the candidate configuration is on top of a particular reference configuration, the WTRU may first apply the reference configuration and then apply the delta configuration. In subsequent cell switches, the WTRU may determine that the reference configuration does not need to be applied, and the delta configuration may be directly applied to the source cell configuration since the source cell configuration already includes the reference configuration. In some embodiments, the WTRU may compare an identifier associated with a first cell and an identifier associated with a second cell to determine whether to apply the delta configuration associated with the second cell on top of the first cell configuration or on top of the reference configuration.

[0160] By applying the differential configuration on top of the source cell configuration, the amount of reconfiguration (e.g., the amount of WTRU processing) may be reduced compared to always applying the reference configuration before the differential configuration. Thus, the reference configuration may only need to be applied in some scenarios, e.g., the first LTM cell switch or the first LTM cell switch to a new DU, while subsequent LTM cell switches can apply the differential configuration using a procedure similar to a conventional handover.

[0161] In some embodiments, the WTRU may receive an indication with an identifier for one of the one or more reference configurations. The absence of such an indication may be interpreted by the WTRU as an indication to apply a candidate differential configuration on top of the source cell configuration. In some embodiments, the absence of a configuration of a reference configuration (e.g., when the WTRU is configured with one or more candidate differential configurations but is not provided with a reference configuration) may be interpreted by the WTRU as an indication to apply a candidate differential configuration on top of the source cell configuration, and the presence of a reference configuration is interpreted as an indication to apply a reference configuration. In some embodiments, the WTRU stores the reference configuration until the first LTM cell switch is triggered, and removes the reference configuration after applying that LTM cell switch (thus, at this point the WTRU applies any subsequent cell switches using a differential configuration on top of the source cell configuration, at which point it does not have a reference configuration and has already applied the removed reference configuration).

[0162] FIG. 12 relates to steps 704 and 705a-b of FIG. 7 with reference to a further alternative embodiment of FIG. 11. A 5G base transceiver station (BTS), designated gNB, may be divided into two physical entities designated CU (Central Unit) and DU (Distributed Unit). The CU provides support for the upper layers of the protocol stack, and the DU provides support for the lower layers of the protocol stack. The figure illustrates an exemplary intra-DU handover, e.g., from Cell1 to Cell2, an inter-DU handover, e.g., from Cell2 to Cell3, and an inter-CU handover, e.g., from Cell4 to Cell5. For example, a MAC reset may be performed in step 705b of FIG. 7 for an inter-DU handover from Cell2 to Cell3 (because the source and target have different MAC IDs), but a MAC reset is not performed in step 705a for an intra-DU handover from Cell1 to Cell2 (because the source and target have the same MAC ID).

[0163] FIG. 13 is a flow chart of a method 1300 for cell handover performed by a WTRU, according to one embodiment.

[0164] In 1301, the WTRU receives configuration information for at least one candidate cell for handover of the WTRU from a current cell to a target cell among at least one candidate cell for handover, the configuration information including, for each of the at least one candidate cell, configuration parts corresponding to a configuration different from a reference configuration.

[0165] At 1302, the WTRU receives a handover trigger for a handover of the WTRU from a current cell to a target cell.

[0166] At 1303, the WTRU compares the configuration information for the current cell with the configuration information for the target cell, and when the configuration information for the target cell differs from the configuration information for the current cell, applies the configuration information for the target cell and applies an action associated with the applied configuration information for the target cell.

[0167] According to one embodiment of the method, the configuration information is Radio Resource Control (RRC) information.

[0168] According to one embodiment of the method, the configuration parts are either central unit (CU) specific parts, distributed unit (DU) specific parts or cell specific parts.

[0169] According to one embodiment of the method, the configuration parts are either secondary cell group (SCG) specific parts or master cell group (MCG) specific parts.

[0170] According to one embodiment of the method, each configuration part of the configuration parts has an associated identifier, which corresponds to a radio bearer configuration identifier for the CU specific part, a candidate cell group configuration identifier for the DU specific part, and a candidate cell configuration identifier for the cell specific part.

[0171] According to one embodiment of the method, when the associated identifier corresponds to a radio bearer configuration identifier, the action includes one of a Packet Data Convergence Protocol (PDCP) re-establishment and a Radio Link Control (RLC) re-establishment.

[0172] According to one embodiment of the method, when the associated identifier corresponds to a candidate cell group configuration identifier, the action includes a medium access control (MAC) reset.

[0173] According to an embodiment, a WTRU is provided that includes at least one processor, the at least one processor configured to perform any of steps 1301-1303.

[0174] FIG. 14 is a flowchart of a method 1400 for cell handover performed by a WTRU, according to a further embodiment.

[0175] At 1401, the WTRU receives configuration information for at least one candidate cell for handover of the WTRU from a current cell to a target cell among at least one candidate cell for handover, the configuration information including, for each of the at least one candidate cell, configuration parts and an associated identifier for each configuration part.

[0176] At 1402, the WTRU receives a handover trigger for a handover of the WTRU from a current cell to a target cell.

[0177] At 1403, the WTRU determines a difference between the configuration for the current cell and the configuration for the target cell by comparing an identifier of a configuration part of the current cell with an identifier of a corresponding configuration part of the target cell.

[0178] At 1404, for each configuration part of the current cell that has an associated identifier different from the associated identifier of the corresponding configuration part of the target cell, the WTRU applies a configuration for the corresponding configuration part of the target cell to the WTRU and performs an action associated with the configuration for the corresponding configuration part of the target cell.

[0179] According to one embodiment of the method, the configuration information is Radio Resource Control (RRC) information.

[0180] According to one embodiment of the method, the configuration parts are either central unit (CU) specific parts, distributed unit (DU) specific parts or cell specific parts.

[0181] According to one embodiment of the method, the configuration parts are either secondary cell group (SCG) specific parts or master cell group (MCG) specific parts.

[0182] According to one embodiment of the method, each configuration part of the configuration parts has an associated identifier, which corresponds to a radio bearer configuration identifier for the CU specific part, a candidate cell group configuration identifier for the DU specific part, and a candidate cell configuration identifier for the cell specific part.

[0183] According to one embodiment of the method, when the associated identifier corresponds to a radio bearer configuration identifier, the action includes one of a Packet Data Convergence Protocol (PDCP) re-establishment and a Radio Link Control (RLC) re-establishment.

[0184] According to one embodiment of the method, when the associated identifier corresponds to a candidate cell group configuration identifier, the action includes a medium access control (MAC) reset.

[0185] According to an embodiment, a WTRU is provided that includes at least one processor, the at least one processor configured to perform any of steps 1401-1404.

[0186] FIG. 15 is a flowchart of a method 1500 for cell handover performed by a WTRU, according to one embodiment.

[0187] At 1501, the method includes receiving configuration information for a configuration of a WTRU for a plurality of candidate cells, the configuration information including, for each candidate cell among the plurality of candidate cells, at least one partial configuration part and a partial configuration part identifier for each partial configuration part among the at least one partial configuration part.

[0188] At 1502, the method includes receiving a handover trigger for a handover of the WTRU from a current cell to a target cell.

[0189] At 1503, the method includes performing configuration of the WTRU for the target cell based on the received configuration information by comparing partial configuration part identifiers for the current cell with partial configuration part identifiers for the target cell and by applying a partial configuration for the target cell that corresponds to a partial configuration part for the target cell having a different partial configuration part identifier than the partial configuration part identifier for the current cell, and performing at least one procedure associated with the applied partial configuration.

[0190] According to one embodiment, the method includes performing a MAC reset when partial configuration part identifiers associated with medium access control MAC configurations for the WTRU for the current cell and the target cell are not identical.

[0191] According to one embodiment, the method includes performing at least one of: a Radio Link Control (RLC) reset when partial configuration part identifiers associated with a Radio Link Control (RLC) configuration for the WTRU for the current cell and the target cell are not identical; a Packet Data Convergence Protocol (PDCP) reset when partial configuration part identifiers associated with a Packet Data Convergence Protocol (PDCP) configuration for the WTRU for the current cell and the target cell are not identical.

[0192] According to an embodiment of the method, the at least one partial configuration part is a central unit CU specific partial configuration part, a distributed unit DU specific partial configuration part or a cell specific partial configuration part.

[0193] According to an embodiment of the method, the at least one partial configuration part is one of a secondary cell group SCG specific partial configuration part and a master cell group MCG specific partial configuration part.

[0194] According to an embodiment of the method, the partial configuration part identifier corresponds to a radio bearer configuration identifier for the CU specific partial configuration part, a candidate cell group configuration identifier for the DU specific part, and a candidate cell configuration identifier for the cell specific partial configuration part. According to an embodiment of the method, when the partial configuration part identifier corresponds to a radio bearer configuration identifier, the procedures associated with the applied partial configuration include at least one of a Radio Link Control RLC re-establishment, a Packet Data Convergence Protocol PDCP re-establishment.

[0195] Also disclosed is a wireless transmit / receive unit (WTRU) device, the WTRU device comprising at least one processor, the at least one processor comprising: receiving configuration information for configuring the WTRU for a plurality of candidate cells, the configuration information including, for each candidate cell of the plurality of candidate cells, at least one partial configuration part and a partial configuration part identifier for each partial configuration part of the at least one partial configuration part; receiving a handover trigger for a handover of the WTRU from a current cell to a target cell; and performing (by / performing) a configuration of the WTRU for the target cell by comparing, based on the received configuration information, a partial configuration part identifier for the current cell with a partial configuration part identifier for the target cell, and by applying a partial configuration for the target cell that corresponds to a partial configuration part for the target cell having a different partial configuration part identifier than the partial configuration part identifier for the current cell, and performing at least one procedure associated with the applied partial configuration.

[0196] According to one embodiment, the at least one processor is configured to perform a MAC reset when partial configuration part identifiers associated with medium access control MAC configurations for the WTRU for the current cell and the target cell are not identical.

[0197] According to one embodiment, the at least one processor is configured to perform at least one of: a radio link control (RLC) reset when partial configuration part identifiers associated with a radio link control (RLC) configuration for the WTRU for the current cell and the target cell are not identical; a packet data convergence protocol (PDCP) reset when partial configuration part identifiers associated with a packet data convergence protocol (PDCP) configuration for the WTRU for the current cell and the target cell are not identical.

[0198] According to one embodiment, the at least one partial configuration part is a central unit CU specific partial configuration part, a distributed unit DU specific partial configuration part or a cell specific partial configuration part.

[0199] According to one embodiment, the at least one partial configuration part is one of a secondary cell group SCG specific partial configuration part and a master cell group MCG specific partial configuration part.

[0200] According to one embodiment, the partial configuration part identifier corresponds to a radio bearer configuration identifier for the CU specific partial configuration part, a candidate cell group configuration identifier for the DU specific part, and a candidate cell configuration identifier for the cell specific partial configuration part.

[0201] According to one embodiment, when the partial configuration part identifier corresponds to a radio bearer configuration identifier, the procedures associated with the applied partial configuration include at least one of a Radio Link Control RLC re-establishment, a Packet Data Convergence Protocol PDCP re-establishment.

[0202] While features and elements are provided above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure should not be limited in terms of the specific embodiments described in this application, which are intended as illustrations of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope thereof. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the above description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure should be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is understood that the present disclosure is not limited to a particular method or system.

[0203] The above embodiments are described, for simplicity, with reference to the terminology and structure of infrared-enabled devices, i.e., infrared emitters and receivers. However, the described embodiments are not limited to these systems and may be applied to other systems that use other forms of electromagnetic waves, or non-electromagnetic waves such as sound waves.

[0204] It should also be understood that the terminology used herein is for purposes of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or “image” may refer to either a snapshot, a single image, and / or multiple images displayed over a time base. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” “remote,” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of several embodiments of a WTRU, (iii) a wireless-enabled and / or wired-enabled (e.g., tetherable) device configured with, among other things, some or all of the structure and functionality of a WTRU, (iii) a wireless-enabled and / or wired-enabled device configured with less than all of the structure and functionality of a WTRU, or (iv) the like. Details of an example WTRU that may represent any WTRU enumerated herein are provided herein with respect to FIGS. 1A-1D . As another example, various disclosed embodiments hereinabove and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and that some or all of the present disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other devices include drones or other devices configured to stream information to provide an adapted reality experience.

[0205] Furthermore, the methods provided herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0206] Modifications to the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be taken as limiting the scope of the following claims. For example, the embodiments provided herein include handheld devices that may include or be utilized with any suitable voltage source, such as a battery, that provides any suitable voltage.

[0207] Furthermore, in the embodiments provided above, reference is made to processing platforms, computing systems, controllers, and other devices that include processors. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer-executed," or "CPU-executed."

[0208] Those skilled in the art will understand that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents the data bits, which cause the transformation or reduction of the resulting electrical signals and the maintenance of the data bits in memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU, as well as other processing of the signals. The memory locations where the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that embodiments are not limited to the above-mentioned platforms or CPUs, and that other platforms and CPUs can support the provided methods.

[0209] The data bits may also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium may include computer-readable media that reside exclusively on a processing system or that are distributed, cooperating, or interconnected among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that the embodiments are not limited to the memories described above, and that other platforms and memories may support the provided methods.

[0210] In an example embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium, which may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0211] Little distinction remains between hardware and software implementations of aspects of the system. The use of hardware or software is generally (but not always, in that in certain contexts, the choice between hardware and software can be important) a design choice representing a cost vs. efficiency trade-off. There may be various means (e.g., hardware, software, and / or firmware) by which the processes and / or systems and / or other techniques described herein may be achieved. The preferred means may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware means. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0212] The above detailed description sets forth various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. To the extent that such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be individually and / or collectively implemented by a wide range of hardware, software, firmware, or substantially any combination thereof. In one embodiment, portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may equivalently be implemented, in whole or in part, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as substantially any combination thereof, in integrated circuits, and that designing circuitry and / or writing code for software and / or firmware is well within the skill of one of ordinary skill in the art in light of this disclosure. Furthermore, those skilled in the art will understand that the subject matter mechanisms described herein may be distributed as program products in various forms, and that exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution.Examples of signal-bearing media include, but are not limited to, recordable-type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission-type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0213] Those skilled in the art will recognize that it is common within the art to describe devices and / or processes in the manner described herein and then integrate such described devices and / or processes into a data processing system using engineering practices. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can generally include one or more of the following: a system unit housing; a video display device; memory such as volatile and non-volatile memory; a processor such as a microprocessor and a digital signal processor; computational entities such as an operating system, drivers, a graphical user interface, and application programs; one or more interaction devices such as a touchpad or screen; and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communications and / or network computing / communications systems.

[0214] The subject matter described herein may depict different components contained within or connected with different other components. It should be understood that such depicted architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality may be achieved. Thus, any two components combined herein to achieve a particular functionality may be considered to be “associated” with each other such that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated may also be considered to be “operably connected” or “operably coupled” to each other to achieve the desired functionality. Any two components capable of being so associated may also be considered to be “operably coupleable” to each other to achieve the desired functionality. Specific examples of what is operably coupleable include, but are not limited to, physically matable and / or physically interacting components, wirelessly interacting and / or wirelessly interacting components, and / or logically interacting and / or logically interacting components.

[0215] With respect to the use of virtually any plural and / or singular term herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for clarity.

[0216] Those skilled in the art will understand that, in general, the terminology used herein, and particularly in the appended claims (e.g., the body of the appended claims), is generally intended as “open” terminology (e.g., the term “including” should be interpreted as “including, but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including, but not limited to,” etc.). Those skilled in the art will further understand that where a specific number of introduced claim recitations are intended, such intention will be expressly recited in the claim; in the absence of such recitation, no such intention exists. For example, where only one item is intended, the term “single” or similar language may be used. As an aid to understanding, the following appended claims and / or description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed as implying that introducing a claim recitation with the indefinite article "a" or "an" limits any particular claim containing such an introduced claim recitation to embodiments containing only one such recitation, even if the same claim also includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be construed to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Furthermore, those skilled in the art will recognize that even if a specific number of introduced claim recitations is explicitly recited, such recitation should be construed to mean at least the recited number (e.g., the mere recitation of "two recitations" without other modifiers means at least two recitations, or more than two recitations).Furthermore, in instances where a convention similar to "at least one of A, B, and C, etc." is used, such a configuration is generally intended in the sense that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In instances where a convention similar to "at least one of A, B, or C, etc." is used, such a configuration is generally intended in the sense that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further appreciate that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of those terms, either of those terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Furthermore, as used herein, the term "any of," followed by a listing of multiple items and / or multiple categories of items, is intended to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of" the items and / or categories of items, individually or in conjunction with other items and / or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. Also, as used herein, the term "multiple" is intended to be synonymous with "a plurality."

[0217] Furthermore, when features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will recognize that the present disclosure is also thereby described in terms of any individual members or subgroups of members of the Markush group.

[0218] As will be understood by those skilled in the art, for all purposes, including with respect to providing a specification, all ranges disclosed herein encompass any and all possible subranges and combinations of those subranges. Any recited range can be readily recognized as fully descriptive and allowing for that same range to be divided into at least two equal parts, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range described herein can be readily divided into a lower third, middle third, and upper third, etc. Also, as will be understood by those skilled in the art, all terms such as "at most," "at least," "greater than," and "less than" are inclusive of the recited number and refer to ranges that may be subsequently divided into subranges, as described above. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0219] Furthermore, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, the use of the term "means for" in any claim is intended to implement 35 U.S.C. § 112, paragraph 6 or means-plus-function claim format, and any claim without the term "means for" is not so intended.

Claims

1. 1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information for configuring the WTRU for a plurality of candidate cells, the configuration information including, for each candidate cell of the plurality of candidate cells, at least one partial configuration part and a partial configuration part identifier for each partial configuration part of the at least one partial configuration part; receiving a handover trigger for a handover of the WTRU from a current cell to a target cell; configuring the WTRU for the target cell based on the received configuration information by comparing a partial configuration part identifier for the current cell with a partial configuration part identifier for the target cell and by applying a partial configuration for the target cell that corresponds to a partial configuration part for the target cell having a partial configuration part identifier different from the partial configuration part identifier for the current cell, and performing at least one procedure associated with the applied partial configuration; A method for providing the above.

2. 10. The method of claim 1, comprising performing a MAC reset when partial configuration part identifiers associated with medium access control MAC configurations for the WTRU for the current cell and the target cell are not identical.

3. an RLC reset when partial configuration part identifiers associated with radio link control (RLC) configurations for the WTRU for the current cell and the target cell are not identical; a PDCP reset when partial configuration part identifiers associated with a Packet Data Convergence Protocol (PDCP) configuration for the WTRU for the current cell and the target cell are not identical; The method of claim 1 , comprising performing at least one of:

4. 2. The method of claim 1, wherein the at least one partial configuration part is one of a central unit CU-specific partial configuration part, a distributed unit DU-specific partial configuration part, and a cell-specific partial configuration part.

5. The method of claim 1 , wherein the at least one partial configuration part is one of a secondary cell group SCG partial configuration specific part and a master cell group MCG partial configuration specific part.

6. 5. The method of claim 4, wherein the partial configuration part identifier corresponds to a radio bearer configuration identifier for a CU-specific partial configuration part, a candidate cell group configuration identifier for a DU-specific part, and a candidate cell configuration identifier for a cell-specific partial configuration part.

7. When the partial configuration part identifier corresponds to a radio bearer configuration identifier, the procedure associated with the applied partial configuration comprises: Radio Link Control (RLC) re-establishment; Packet Data Convergence Protocol (PDCP) re-establishment 5. The method of claim 4, comprising at least one of:

8. 1. A wireless transmit / receive unit (WTRU) device comprising at least one processor, the at least one processor comprising: receiving configuration information for configuring the WTRU for a plurality of candidate cells, the configuration information including, for each candidate cell of the plurality of candidate cells, at least one partial configuration part and a partial configuration part identifier for each partial configuration part of the at least one partial configuration part; receiving a handover trigger for a handover of the WTRU from a current cell to a target cell; Based on the received configuration information, perform configuration of the WTRU for the target cell by comparing a partial configuration part identifier for the current cell with a partial configuration part identifier for the target cell, and by applying a partial configuration for the target cell that corresponds to a partial configuration part for the target cell having a partial configuration part identifier different from the partial configuration part identifier for the current cell, and perform at least one procedure associated with the applied partial configuration. A wireless transmit / receive unit (WTRU) device configured to:

9. 10. The WTRU of claim 8, wherein the WTRU device is configured to perform a MAC reset when partial configuration part identifiers associated with a medium access control MAC configuration for the WTRU for the current cell and the target cell are not identical.

10. The at least one processor an RLC reset when partial configuration part identifiers associated with radio link control (RLC) configurations for the WTRU for the current cell and the target cell are not identical; a PDCP reset when partial configuration part identifiers associated with a Packet Data Convergence Protocol (PDCP) configuration for the WTRU for the current cell and the target cell are not identical; 10. The WTRU of claim 8 configured to implement at least one of:

11. The WTRU of claim 8 , wherein the at least one partial configuration part is one of a central unit (CU) specific partial configuration part, a distributed unit (DU) specific partial configuration part, and a cell specific partial configuration part.

12. The WTRU of claim 8 , wherein the at least one partial configuration part is one of a secondary cell group SCG partial configuration specific part and a master cell group MCG partial configuration specific part.

13. The WTRU of claim 11, wherein the partial configuration part identifier corresponds to a radio bearer configuration identifier for a CU-specific partial configuration part, a candidate cell group configuration identifier for a DU-specific part, and a candidate cell configuration identifier for a cell-specific partial configuration part.

14. When the partial configuration part identifier corresponds to a radio bearer configuration identifier, the procedure associated with the applied partial configuration comprises: Radio Link Control (RLC) re-establishment; Packet Data Convergence Protocol (PDCP) re-establishment The WTRU of claim 11 , comprising at least one of:

Images