Wireless transmit-receive unit, method for executing same, and media access control entity

Abstract

A wireless transmit / receive unit (WTRU) includes a processor configured to: receive radio resource control (RRC) configuration information, the RRC configuration information including an indication of a plurality of candidate cells, a delta configuration for at least a subset of the plurality of candidate cells, and an anchor RRC configuration; receiving a medium access control (MAC) control element (CE) indicating that the WTRU should perform a handover to a candidate cell among the plurality of candidate cells, where the RRC configuration information includes an incremental configuration for the candidate cell; determining an RRC parameter of the candidate cell based on the anchor RRC configuration and the delta configuration for the candidate cell; performing a handover to the candidate cell based on the RRC parameter; and after the handover to the candidate cell is completed, maintaining the anchor RRC configuration and the delta configuration for at least a subset of the plurality of candidate cells.

Description

[0001] This application is a divisional application of the invention patent application with the application date of February 9, 2023, the application number of 202380023805.5, and the invention title of "Configuration and Management of Cells for L1 / L2 Mobility".

[0002] Cross - reference to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 309,231, filed on February 11, 2022, and U.S. Provisional Patent Application No. 63 / 394,778, filed on August 3, 2022, which are hereby incorporated by reference in their entireties. Background art

[0004] Users of mobile networks expect fast response times. For example, when a user enters a network, switches from one network to another, or opens an application, the user may expect the operation to occur quickly and / or transparently. The user may be less tolerant of network latency or dropped connections. In addition, the amount of data processed by the network continues to increase. Using traditional networks to handle the increased data throughput may result in latency and dropped connections. Summary of the invention

[0005] A wireless transmit / receive unit (WTRU) may be configured to implement layer 1 / layer 2 (L1 / L2) - based inter - cell mobility procedures with reduced latency during, for example, handover or other mobility operations. For example, the WTRU may be configured to implement an inter - cell mobility procedure that utilizes one or more mobility procedures designed to reduce latency during mobility events.

[0006] For example, the WTRU may be configured to maintain configurations for multiple candidate cells to allow for quick application of the configurations for candidate cells when a mobility procedure is initiated. The WTRU may use a dynamic handover mechanism between candidate serving cells (e.g., a primary cell (PCell, SpCell) and / or a secondary cell (SCell)) based on L1 (e.g., the physical layer) and / or L2 (e.g., media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and / or radio resource control (RRC)) signaling. The WTRU may implement physical - layer - based techniques for inter - cell beam management, including physical layer / layer 1 (PHY / L1) measurement reports and beam indication signaling. During or after a mobility event, the WTRU may implement a timing advance procedure that reduces the latency associated with obtaining timing synchronization. The WTRU and / or the network may utilize centralized unit (CU) - distributed unit (DU) interface signaling (e.g., at a gNodeB (gNB)) to support WTRU mobility.

[0007] A WTRU may receive configuration information associated with one or more candidate cells. The configuration information may be associated with one or more physical layer measurements for one or more candidate cells. For example, the WTRU may receive a set of RRC configurations for candidate cells for L1 / L2 mobility. The WTRU may perform beam measurements on a subset of the candidate cells. When the WTRU experiences a mobility event, the WTRU may indicate to the network the identities of the subset of candidate cells on which beam measurements are being performed.

[0008] To support lower layer (L1 / L2) mobility, the WTRU may receive a set of RRC configurations for a group of neighboring cell candidates for a given (e.g., current) serving cell. Each RRC configuration may apply to one or more of the neighboring cells in the neighboring cell group. The WTRU may be RRC-configured with measurement criteria for one or more (e.g., or each) of the candidate cells. For example, the measurement criteria may include a reference signal received power (RSRP) threshold associated with the candidate cell. The WTRU may be configured with a defined transition period, which may be configured for a group of neighboring cells or a particular neighboring cell.

[0009] The WTRU may apply the RRC configuration and activate adjacent beam management for a subset of the configured candidate cells. When applying the RRC configuration, the WTRU may perform an adjacent beam management process. The adjacent cell beam management process may include performing and / or reporting beam measurements associated with a subset of the neighboring cells without triggering a beam failure detection process.

[0010] The WTRU may determine a subset of candidate serving cells for adjacent cell beam management. In some scenarios, the WTRU may determine the subset of candidate cells (e.g., serving cells) based on the configured measurement criteria, WTRU capabilities, and / or the number of configured serving cells used by the WTRU. For example, the subset of candidate cells (e.g., neighboring cells) may be selected as all candidate cells determined to have an RSRP above a threshold, e.g., assuming the number of candidates meeting the criteria does not exceed the processing capabilities of the WTRU. In some examples, the criteria may include reference signal received power (RSRP). For example, the criteria may include an RSRP exceeding a threshold. The subset of the plurality of candidate cells may include all candidate cells above the RSRP threshold. The measurement criteria may include channel state information-reference signal received power (CSI-RSRP). In some examples, determining the subset of the plurality of candidate cells may be at least partially based on the number of configured candidate cells. For example, the number of configured candidate cells may be greater than a threshold.

[0011] The WTRU may be configured to report the identities of a subset of the candidate cells to the network. For example, upon a subset change (e.g., due to an RSRP change or a mobility event), the WTRU may report the new subset to the network. In one example, the reporting may be via a MAC CE or by triggering a beam measurement report indicating the subset. In some scenarios, the report may include a bitmap. The bitmap may be in the MAC-CE. An indication to perform a handover may be received in downlink control information (DCI). For example, the report may be transmitted to the base station. In some examples, the WTRU may report to the network when one or more of the candidate cells in the subset of the plurality of candidate cells change.

[0012] The WTRU may be configured to perform one or more physical layer measurements on a subset of the plurality of candidate cells. In some scenarios, the WTRU may be configured to perform one or more measurements on one or more of the candidate cells. In some examples, the physical layer measurements may be one or more of radio link monitoring measurements or beam measurements. The WTRU may be configured to receive an indication to perform a handover. In some examples, the handover may be a lower layer handover. For example, a handover may be performed to one or more of the candidate cells in the subset of the plurality of candidate cells. In some scenarios, a candidate cell may be maintained as a candidate cell in the plurality of candidate cells for a predetermined period of time. The predetermined period of time may be measured starting from the receipt of the indication to perform a handover. In some examples, a handover may be initiated after one or more of a beam failure or a beam failure recovery of a failed beam.

[0013] The WTRU may be configured to switch the beam(s) used for transmission and / or reception. When receiving and / or performing a beam switch of a beam from a first cell (e.g., the current serving cell) to a second cell (e.g., a non-serving cell), the WTRU may change the serving cell to the second cell associated with the new beam. For example, the WTRU may remove the second cell from the subset of the candidate cells. The WTRU may add the first cell (e.g., the old serving cell) to the subset of the candidate cells. For example, the WTRU may add the first cell to the subset of the candidate cells for at least the configured period of time associated with a configured transition timer. The WTRU may release the configuration of any candidate cell not in the subset. For example, the WTRU may release the configuration of any candidate cell not in the subset after performing a beam switch. In some scenarios, the WTRU may be configured to determine a target configuration. The target configuration may be based, for example, at least in part on one or more anchor cell identities. For example, the anchor cell identities may be used to apply candidate cell configurations.

[0014] Example methods for implementing L1 / L2 mobility may include configuring a WTRU with a set of radio resource control (RRC) configurations for each neighboring cell candidate in a group of neighboring cell candidates adjacent to a serving cell, where each configuration in the set includes a measurement criterion and a transition time period. The WTRU may apply the RRC configuration for each neighboring cell candidate in a subset of the group of neighboring cell candidates and activate neighbor beam management for each neighboring cell candidate in the subset of the group of neighboring cell candidates; report the subset of the group of neighboring cell candidates to the network; receive a beam switch on a cell indicating a beam of a non-serving cell; upon receiving the beam switch, change a current serving cell to a new serving cell, where the new serving cell is the non-serving cell on which the beam switch was received; remove the new serving cell from the subset of the group of neighboring cell candidates; add a previous current serving cell to the subset of the group of neighboring cell candidates; and release the RRC configuration of any candidate cell not in the subset of the group of neighboring cell candidates.

[0015] The WTRU may be configured to receive configuration information. The configuration information may be associated with a plurality of candidate cells. The configuration information may include configuration information associated with physical layer measurements. The physical layer measurements may be for each candidate cell. Additionally or alternatively, the configuration information may include one or more measurement criteria.

[0016] The WTRU may be configured to determine a subset of the plurality of candidate cells. For example, each candidate cell in the subset of the plurality of candidate cells may be determined based on the measurement criteria. The plurality of candidate cells may include all candidate cells above a reference signal received power (RSRP) threshold. Additionally or alternatively, the WTRU may be configured to transmit a report. The report may indicate the subset of the plurality of candidate cells. The report indicating the subset of the plurality of candidate cells may include a bitmap. The report may be transmitted via a media access control (MAC) control element (CE). The report may be transmitted to a base station.

[0017] The WTRU may be configured to perform physical layer measurements on the subset of the plurality of candidate cells. The WTRU may be configured to receive an indication. The indication may be to perform a lower layer handover. The lower layer handover may be to a candidate cell. The candidate cell may be the subset of the plurality of candidate cells. The indication may be received via MAC signaling. Additionally or alternatively, the indication may be received via downlink control information (DCI).

[0018] The physical layer measurements may include radio link monitoring (RLM) measurements. Additionally or alternatively, the physical layer measurements may include beam measurements. The measurement criteria may include reference signal received power. For example, the measurement criteria may include reference signal received power exceeding a threshold.

[0019] A wireless transmit / receive unit (WTRU) includes a processor configured to receive radio resource control (RRC) configuration information, where the RRC configuration information includes an indication of a plurality of candidate cells, an incremental configuration for at least one subset of the plurality of candidate cells, and an anchor RRC configuration; receive a media access control (MAC) control element (CE) that indicates that the WTRU should perform a handover to a candidate cell among the plurality of candidate cells, where the RRC configuration information includes an incremental configuration for the candidate cell; determine RRC parameters for the candidate cell based on the anchor RRC configuration and the incremental configuration for the candidate cell; perform a handover to the candidate cell based on the RRC parameters; and, after the handover to the candidate cell is complete, maintain the anchor RRC configuration and the incremental configuration for at least one subset of the plurality of candidate cells.

[0020] A method performed by a wireless transmit / receive unit (WTRU) includes: receiving radio resource control (RRC) configuration information, where the RRC configuration information includes an indication of a plurality of candidate cells, an incremental configuration for at least one subset of the plurality of candidate cells, and an anchor RRC configuration; receiving a media access control (MAC) control element (CE) that indicates that the WTRU should perform a handover to a candidate cell among the plurality of candidate cells, where the RRC configuration information includes an incremental configuration for the candidate cell; determining RRC parameters for the candidate cell based on the anchor RRC configuration and the incremental configuration for the candidate cell; performing a handover to the candidate cell based on the RRC parameters; and, after the handover to the candidate cell is complete, maintaining the anchor RRC configuration and the incremental configuration for at least one subset of the plurality of candidate cells.

[0021] A method performed by a wireless transmit / receive unit (WTRU) includes: receiving radio resource control (RRC) configuration information, where the RRC configuration information includes an indication of a plurality of candidate cells, an incremental configuration for at least one subset of the plurality of candidate cells, and an anchor RRC configuration; receiving a first media access control (MAC) control element (CE) that indicates that the WTRU should perform a handover to a first candidate cell among the plurality of candidate cells, where the RRC configuration information includes an incremental configuration for the first candidate cell; determining first RRC parameters for the first candidate cell based on the anchor RRC configuration and the incremental configuration for the first candidate cell; performing a handover to the first candidate cell based on the first RRC parameters and the incremental configuration for the first candidate cell; receiving a second MAC CE that indicates that the WTRU should perform a handover to a second candidate cell among the plurality of candidate cells; determining second RRC parameters for the second candidate cell based on the anchor RRC configuration; and performing a handover to the second candidate cell based on the second RRC parameters.

[0022] A Media Access Control (MAC) entity includes: a processor configured to: receive at least one Beam Failure Instance (BFI) indication; determine a count of BFIs based on the at least one BFI indication; determine a threshold number of BFIs; compare the count of BFIs with the threshold number of BFIs; and trigger a Beam Failure Request (BFR) when the count of BFIs exceeds the threshold number of BFIs. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1A is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented;

[0024] Figure 1B is an illustration of an example Wireless Transmit / Receive Unit (WTRU) that may be used within the Figure 1A illustrated communication system in accordance with an embodiment;

[0025] Figure 1C is an illustration of an example Radio Access Network (RAN) and an example Core Network (CN) that may be used within the Figure 1A illustrated communication system in accordance with an embodiment;

[0026] Figure 1D is an illustration of another example RAN and another example CN that may be used within the Figure 1A illustrated communication system in accordance with an embodiment;

[0027] Figure 2 is an illustration of an example associated with mobile speed and WTRU complexity. DETAILED DESCRIPTION

[0028] Figure 1A is a diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable the plurality of wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT-Spread OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0029] AsFigure 1A As shown in Figure 1A , the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include 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 computer, 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 device, 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., a robot and / or other wireless devices operating in an industrial and / or automated processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0031] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographical 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 base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in the desired spatial directions.

[0032] Base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) may be used to establish air interface 116.

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

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro to establish the air interface 116.

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

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

[0037] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., 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 Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0038] Figure 1AThe base station 114b therein may be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a commercial venue, 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 an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico base station or a femto base station. As Figure 1A shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

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

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

[0042] Figure 1B is a system diagram of an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, among others. It should be understood that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0043] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal decoding, 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 can be coupled to a transceiver 120, which can be coupled to a transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it should be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0050] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 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 earpiece, Modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographical location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0051] The WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139, which is used to reduce and / or substantially eliminate self-interference through signal processing via hardware (e.g., chokes) or 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, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0052] Figure 1C Is a system diagram illustrating the RAN 104 and CN 106 according to an embodiment. As noted above, the RAN 104 may communicate with the WTRU 102a, 102b, 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

[0053] The RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that the RAN 104 may include any number of evolved Node Bs while remaining consistent with the embodiment. Each of the evolved Node Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0054] Each of evolved Node Bs 160a, 160b, 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, etc. As Figure 1C shown, evolved Node Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0055] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] The MME 162 may be connected to each of the evolved Node Bs 162a, 162b, 162c in the RAN 104 via the 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 specific serving gateway during the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for exchange between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0057] The SGW 164 may be connected to each of the evolved Node Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between evolved Node Bs, 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.

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

[0059] CN 106 can facilitate communication with other networks. For example, CN 106 can provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 can include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and the PSTN 108 or can communicate with the IP gateway. Additionally, CN 106 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0061] In a representative embodiment, the other network 112 can be a WLAN.

[0062] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access to or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating outside the BSS and destined for an STA can reach the STA through the AP and can be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS can be delivered to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS can be delivered through the AP, e.g., where the source STA can deliver traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be delivered between a source STA and a destination STA (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs in the IBSS) can communicate directly with each other. The IBSS communication mode can sometimes be referred to as the "ad-hoc" communication mode in this document.

[0063] When operating in the 802.11ac infrastructure mode or a similar mode, the AP may send beacons on a fixed channel, such as the primary channel. The primary channel may be of 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 the STA to establish a connection with the AP. In some representative embodiments, for example, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented in an 802.11 system. For CSMA / CA, the STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0064] A High Throughput (HT) STA may communicate using a 40 MHz wide channel, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0066] 802.11af and 802.11ah support operation modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices can include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

[0067] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operation bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel can be set and / or restricted by an STA (which supports the minimum bandwidth operation mode) from all STAs operating in the BSS. In an example of 802.11ah, for an STA (e.g., an MTC type device) that supports (e.g., only supports) the 1 MHz mode, the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) setting can depend on the state of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operation mode) is transmitting to the AP, the entire available frequency band can be considered busy even if most of the frequency bands remain idle and may be available.

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

[0069] Figure 1D FIG. is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 can employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 can also communicate with CN 115.

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

[0071] WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a parameter set that can be scaled. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using various or scalable-length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or having an absolute time length that continuously varies).

[0072] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., such as evolved Node Bs 160a, 160b, 160c). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of the gNBs 180a, 180b, 180c as a mobility anchor point. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate / connect with gNBs 180a, 180b, 180c while also communicating / connecting with another RAN (such as evolved Node Bs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more of the gNBs 180a, 180b, 180c and one or more of the evolved Node Bs 160a, 160b, 160c substantially simultaneously. In the non-stand-alone configuration, the evolved Node Bs 160a, 160b, 160c can act as the mobility anchor for WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

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

[0074] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0077] UPF 184a and 184b can be connected to one or more gNBs among gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. The one or more gNBs can provide access to a packet switched network (such as the Internet 110) for WTRU 102a, 102b, and 102c to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0078] CN 115 can facilitate communication with other networks. For example, CN 115 can include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 115 and the PSTN 108 or can communicate with the IP gateway. In addition, CN 115 can provide access to other networks 112 for WTRU 102a, 102b, and 102c. The other networks can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and the local data network (DN) 185a and 185b.

[0079] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding descriptions, one or more or all of the functions described herein for one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a - 102d, base stations 114a - 114b, evolved Node Bs 160a - 160c, MME 162, SGW 164, PGW 166, gNBs 180a - 180c, AMF 182a - 182ab, UPF 184a - 184b, SMF 183a - 183b, DN 185a - 185b, and / or any one or more other devices described herein. The emulation devices can be one or more devices configured to mimic one or more or all of the functions described herein. For example, the emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0081] One or more simulation devices may perform one or more (including all) functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be used in a test laboratory and / or in a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network in order to implement tests of one or more components. One or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas) may be used by the simulation device to transmit and / or receive data.

[0082] A WTRU may transmit and / or receive physical channels and / or reference signals. The physical channels and / or reference signals may be transmitted and / or received according to at least one spatial domain filter. The term "beam" may be used to refer to a spatial domain filter. In this document, the terms spatial filter and tx beam may be used interchangeably.

[0083] A WTRU may use a spatial domain filter (e.g., the same spatial filter as that used for receiving a reference signal (RS)) to transmit a physical channel and / or a signal. For example, the RS may include a channel state information reference signal (CSI-RS) and / or a synchronization signal (SS) block. The WTRU transmission may be referred to as the "target". The received RS or SS block may be referred to as the "reference" or "source". In some scenarios, the WTRU may transmit a target physical channel or signal based on the spatial relationship with reference to such an RS or SS block.

[0084] A WTRU may transmit a first physical channel and / or a signal according to a spatial domain filter (the same spatial domain filter as that used for transmitting a second physical channel and / or a signal). The first transmission may be referred to as the "target" or "source". The second transmission may be referred to as the "reference". In some examples, it is alleged that the WTRU may transmit a first (e.g., target) physical channel and / or a signal based on the spatial relationship with reference to a second (e.g., reference) physical channel and / or a signal.

[0085] Spatial relationships can be implicit. The spatial relationships can be signaled by RRC configuration and / or by MAC CE and / or DCI. For example, a WTRU may implicitly transmit a Physical Uplink Shared Channel (PUSCH) and / or a Demodulation Reference Signal (DM-RS) for the PUSCH. For example, such transmission may be based on a spatial domain filter (e.g., the same spatial domain filter as the Sounding Reference Signal (SRS)). The SRS may be indicated by an SRS Resource Indicator (SRI) and / or indicated in DCI and / or configured by RRC. In another example, the spatial relationship may be configured by RRC for the SRI and / or signaled by MAC CE for the PUCCH. Such spatial relationships may also be referred to as "beam indication".

[0086] A WTRU may receive a first (e.g., target) downlink channel and / or signal. For example, a WTRU may receive the first downlink channel according to a spatial domain filter (e.g., the same spatial domain filter) and / or spatial reception parameters as a second (e.g., reference) downlink channel and / or signal. For example, there may be an association between a physical channel such as a PDCCH or PDSCH and / or the corresponding DM-RS. The first signal and the second signal may be reference signals. In some scenarios, when the WTRU is configured with a Quasi-Co-Location (QCL) assumption type D between corresponding antenna ports, the WTRU may receive the first (e.g., target) downlink channel and / or signal according to the same spatial domain filter and / or spatial reception parameters as the second (e.g., reference) downlink channel and / or signal. This association may be configured as a Transmission Configuration Indicator (TCI) state. The WTRU may be indicated by the association between a CSI-RS and / or an SS block and the DM-RS. Such an association may be based on an index, for example. The index may be a set of TCI states signaled by RRC configuration and / or by MAC CE. Such indication may also be referred to as "beam indication".

[0087] For example, in a beamforming system, a WTRU may be configured to maintain one or more beam pairs. In some scenarios, a WTRU may monitor a periodic CSI-RS (e.g., a specific periodic CSI-RS). The WTRU may monitor the periodic CSI-RS to evaluate its quality and / or calculate a corresponding quality metric. For example, the WTRU may monitor the periodic CSI-RS on a serving DL beam. The PHY entity of the WTRU may report a Beam Failure Instance (BFI). The beam failure instance may be reported to the MAC sublayer. For example, if the beam quality of one or more beams (e.g., all beams) in a maintained set is below a configured threshold within a given RS period, the PHY entity of the WTRU reports a BFI.

[0088] A WTRU may maintain a Beam Failure Detection (BFD) process. The BFD process may include periodic measurements of the maintained beam and / or a Beam Failure Recovery (BFR) request. The BFR request may be reported to the network when a beam failure is detected. For example, BFR may be configured for beam maintenance on a PCell and / or an SCell. In some examples, BFD measurements may be made when BFD and / or Discontinuous Reception (DRX) are configured. The BFD measurements may be made at the maximum of the DRX cycle and / or the CSI-RS cycle. The WTRU may maintain the BFD process to reconstruct a lost beam pair. The reconstruction of the lost beam pair may be faster than the RLM / RLF process.

[0089] A MAC entity may maintain a Beam Failure Instance (BFI) counter. The BFI counter may be used for beam failure detection. In some scenarios, the MAC entity may count the number of beam failure instances indicated. For example, the number of beam failure instances indicated may be received from a PHY entity. The BFI counter may exceed a certain maximum BFI number. A BFR request may be triggered to notify the serving gNB that a beam failure has been detected. The BFR request may be triggered when the BFI counter exceeds a certain maximum BFI number.

[0090] In some scenarios, the MAC entity may reset the BFI counter. The MAC entity may reset the BFI counter after a Beam Failure Detection timer (BFD timer) has expired. This may help provide some hysteresis, for example, when detecting a function. In some examples, the WTRU may reset the BFD timer each time a BFI is indicated. For example, if the BFD timer is configured for multiple (e.g., three) CSI-RS cycles, the MAC entity may reset the BFI counter after no BFI indication from the PHY has been observed for multiple (e.g., three) consecutive CSI-RS cycles.

[0091] In some scenarios, the WTRU may initiate a random access procedure for beam reconstruction. The WTRU may initiate a random access procedure, for example, to report a BFR request for a beam failure detected for the SpCell. The WTRU may select a suitable PRACH preamble and / or PRACH resource. This selection may be based on the best measured downlink beam (e.g., CSI-RS and / or DL synchronization signal block (SSB)). The WTRU may be configured to reconstruct a beam pair. The WTRU may be configured to reconstruct a beam pair when it determines that there is an association between the DL beam and / or UL preamble and / or PRACH occasion. The downlink beam selected by the WTRU may be tested by receiving a random access response (RAR). If the gNB configures a set of contention-free PRACH preambles / resources, the random access (RA) procedure for reconstruction may be performed more quickly. For example, the contention-free PRACH preambles / resources may be prioritized for the WTRU to select. The prioritization may be performed when initiating the RA procedure. In some scenarios, the WTRU may send a MAC CE indicating the cell on which a beam failure is detected. The WTRU may send a MAC CE to report a BFR request for a beam failure detected for the Scell.

[0092] In some scenarios, mechanisms and / or procedures for L1 / L2-based inter-cell mobility may reduce latency. For example, the configuration and / or maintenance for multiple candidate cells may allow for the rapid application of configurations for candidate cells (e.g., RAN2, RAN3). The dynamic handover mechanism between candidate serving cells (e.g., SpCell and / or SCell) may be applicable based on L1 / L2 signaling (e.g., Ran2, RAN1). In some scenarios, the L1 enhancements for inter-cell beam management may include one or more of L1 measurements and / or reports and beam indication (e.g., RAN1, RAN2). For example, RAN2 may be used for inter-cell beam management and / or beam indication. In some scenarios, there may be timing advance management (e.g., RAN1, RAN2). There may be centralized unit-distributed unit (CU-DU) interface signaling for L1 / L2 mobility support (e.g., RAN3). In some examples, beam switching techniques may be used for L1 / L2 mobility to change cells using the beam mobility techniques herein.

[0093] The WTRU may be configured to perform Layer 1 / PHY and / or Layer 2 / MAC / RLC / PDCP / RRC mobility procedures. Some handover commands may include cell configurations. For example, the cell configuration may include a target cell configuration, which may be indicated, for example, as an incremental configuration with respect to the source cell configuration. The L1 / L2 mobility described herein may refer to a WTRU configured to perform mobility (e.g., frequent mobility with no significant signaling overhead). The WTRU may be set with the cell configurations of one or more (e.g., multiple) cells available at the WTRU. For example, the configuration may not be provided to the WTRU in its entirety (e.g., acknowledgments may refer to cells as incremental configurations). The WTRU may store the radio resource control (RRC) configuration for each cell. The WTRU may apply the RRC configuration and / or indicate that a cell is in a deactivated state. For example, indicating that a cell is in a deactivated state may allow the WTRU to perform beam measurements on beams associated with non-serving cells, which may be used (e.g., by the network) to trigger L1 / L2 mobility. The WTRU may be configured to switch the beam(s) used for transmission and / or reception. For example, when receiving and / or performing a beam switch of a beam from a first cell (e.g., the current serving cell) to a second cell (e.g., a non-serving cell), the WTRU may change its serving cell to the second cell associated with the new beam. The WTRU may remove the second cell from a subset of candidate cells. The WTRU may add the first cell (e.g., the old serving cell) to the subset of candidate cells. For example, the WTRU may add the first cell to the subset of candidate cells for at least a configured period of time associated with a configured transition timer. The WTRU may release the configurations of any candidate cells not in the subset. For example, the WTRU may release the configurations of any candidate cells not in the subset after performing a beam switch. In some embodiments, the WTRU may be configured to determine a target configuration. The target configuration may be at least partially based on, for example, one or more anchor cell identifiers. For example, the anchor cell identifier(s) may be used to apply candidate cell configurations.

[0094] Figure 2 Examples associated with mobile speed and WTRU complexity are illustrated. Figure 2 The examples illustrated in may consider, for example, different modeling of cell configurations at a WTRU 202 in a New Radio (NR) network. The network may include a base station 214. In some scenarios, there may be multiple WTRUs 102 and / or multiple base stations 214, as described herein. As the complexity of the WTRU 202 and the number of network resources increase, the latency associated with L1 / L2 operations may decrease. For example, the dormant Scell configuration 244 (e.g., dormant behavior) has lower latency than both the deactivated Scell configuration 242 (e.g., carrier aggregation) and the stored cell configuration 240 (e.g., CHO). Figure 2It is also illustrated that the deactivated Scell configuration 242 (e.g., carrier aggregation) has a lower latency than the stored cell configuration 240 (e.g., CHO).

[0095] Figure 2 It is illustrated that the dormant Scell configuration 244 (e.g., dormant behavior) has a higher WTRU complexity and network resource utilization rate than both the deactivated Scell configuration 242 (e.g., carrier aggregation) and the stored cell configuration 240 (e.g., CHO). The deactivated Scell configuration 242 (e.g., carrier aggregation) also has a higher WTRU complexity and network resource utilization rate than the stored cell configuration 240 (e.g., CHO).

[0096] The WTRU can be configured to perform conditional handover (CHO) and conditional primary Scell (PSCell) addition / change CPA / CPC in an NR radio network. For example, the L1 / L2 mobility described herein can enable conditional handover and / or conditional PSCell addition / change. For example, in conditional handover (CHO), the WTRU can be configured (via an RRC reconfiguration message) with a HO target (e.g., a target cell configuration) and associated conditions (e.g., event A3 / A5 and corresponding cells) with respect to a cell measurement event. The WTRU can initiate monitoring of the associated conditions. For example, the WTRU can initiate monitoring of the associated conditions by receiving a CHO command after configuration. When the condition is met, the WTRU can trigger a HO (reconfiguration) to an associated cell with a given configuration. For conditional PSCell change (CPC) and / or conditional PSCell addition (CPA), the WTRU can trigger a PSCell change or PSCell addition associated with the stored PSCell configuration. For example, for conditional PSCell change (CPC) and / or conditional PSCell addition (CPA), the WTRU can trigger a PSCell change or PSCell addition associated with the stored PSCell configuration when triggering the associated conditions defined by a measurement event.

[0097] The wireless transmit / receive unit (WTRU) can be configured to achieve layer 1 / layer 2 (L1 / L2)-based inter-cell mobility procedures with reduced latency during, for example, handover or other mobility operations. For example, the WTRU can be configured to achieve inter-cell mobility procedures that utilize one or more mobility procedures designed to reduce latency during mobility events.

[0098] For example, the WTRU may be configured to maintain configurations for multiple candidate cells to allow for quick application of the configurations for the candidate cells when a mobility procedure is initiated. The WTRU may use a dynamic handover mechanism between candidate serving cells (e.g., a primary cell (PCell, SpCell) and / or a secondary cell (SCell)) based on L1 (e.g., physical layer) and / or L2 (e.g., Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and / or Radio Resource Control (RRC)) signaling. The WTRU may implement physical layer-based techniques for inter-cell beam management, including physical layer / layer 1 (PHY / L1) measurement reports and beam indication signaling. During or after a mobility event, the WTRU may implement a timing advance procedure that reduces the latency associated with obtaining timing synchronization. The WTRU and / or the network may utilize centralized unit (CU)-distributed unit (DU) interface signaling (e.g., at a gNodeB (gNB)) to support WTRU mobility.

[0099] The WTRU may receive configuration information associated with one or more candidate cells. The configuration information may be associated with one or more physical layer measurements for the one or more candidate cells. For example, the WTRU may receive a set of RRC configurations for candidate cells for L1 / L2 mobility. The WTRU may perform beam measurements on a subset of the candidate cells. When the WTRU experiences a mobility event, the WTRU may indicate to the network the identities of the subset of candidate cells on which beam measurements are being performed.

[0100] To support lower layer (L1 / L2) mobility, the WTRU may receive a set of RRC configurations for a group of neighboring cell candidates for a given (e.g., current) serving cell. Each RRC configuration may apply to one or more of the neighboring cells in the group of neighboring cells. The WTRU may be RRC-configured with measurement criteria for one or more (e.g., or each) of the candidate cells. For example, the measurement criteria may include a Reference Signal Received Power (RSRP) threshold associated with the candidate cell. The WTRU may be configured with a defined transition period that may be configured for a group of neighboring cells or a particular neighboring cell.

[0101] The WTRU may apply the RRC configuration and activate adjacent beam management for a subset of the configured candidate cells. When applying the RRC configuration, the WTRU may perform an adjacent beam management procedure. The adjacent cell beam management procedure may include performing and / or reporting beam measurements associated with a subset of the neighboring cells without triggering a beam failure detection procedure.

[0102] The WTRU may determine a subset of candidate serving cells for adjacent cell beam management. In some scenarios, the WTRU may determine a subset of candidate cells (e.g., serving cells) based on configured measurement criteria, WTRU capabilities, and / or the number of configured serving cells used by the WTRU. For example, the subset of candidate cells (e.g., adjacent cells) may be selected as all candidate cells determined to have an RSRP above a threshold, e.g., assuming the number of candidates meeting the criteria does not exceed the processing capabilities of the WTRU. In some examples, the criteria may include reference signal received power (RSRP). For example, the criteria may include the RSRP exceeding a threshold. The subset of the plurality of candidate cells may include all candidate cells above the RSRP threshold. The measurement criteria may include channel state information-reference signal received power (CSI-RSRP). In some examples, determining the subset of the plurality of candidate cells may be at least partially based on the number of configured candidate cells. For example, the number of configured candidate cells may be greater than a threshold.

[0103] The WTRU may be configured to report the identities of the subset of candidate cells to the network. For example, upon a subset change (e.g., due to an RSRP change or a mobility event), the WTRU may report the new subset to the network. In one example, the reporting may be via a MAC CE or by triggering a beam measurement report indicating the subset. In some scenarios, the report may include a bitmap. The bitmap may be in the MAC-CE. An indication to perform a handover may be received in downlink control information (DCI). For example, the report may be transmitted to a base station. In some examples, the WTRU may report to the network when one or more of the candidate cells in the subset of the plurality of candidate cells change.

[0104] The WTRU may be configured to perform one or more physical layer measurements on a subset of the plurality of candidate cells. In some scenarios, the WTRU may be configured to perform one or more measurements on one or more of the candidate cells. In some examples, the physical layer measurements may be one or more of radio link monitoring measurements or beam measurements. The WTRU may be configured to receive an indication to perform a handover. In some examples, the handover may be a lower layer handover. For example, a handover may be performed to one or more of the candidate cells in the subset of the plurality of candidate cells. In some scenarios, a candidate cell may be maintained as a candidate cell in the plurality of candidate cells for a predetermined period. The predetermined period may be measured starting from the receipt of the indication to perform a handover. In some examples, a handover may be initiated after one or more of a beam failure or a beam failure recovery.

[0105] The WTRU may be configured to switch beams for transmission and / or reception. When receiving and / or performing a beam switch from a beam in a first cell (e.g., the current serving cell) to a beam in a second cell (e.g., a non-serving cell), the WTRU may change the serving cell to the second cell associated with the new beam. For example, the WTRU may remove the second cell from a subset of the candidate cells. The WTRU may add the first cell (e.g., the old serving cell) to the subset of the candidate cells. For example, the WTRU may add the first cell to the subset of the candidate cells for at least a configured period of time associated with a configured transition timer. The WTRU may release the configuration of any candidate cell not in the subset. For example, the WTRU may release the configuration of any candidate cell not in the subset after performing a beam switch. In some scenarios, the WTRU may be configured to determine a target configuration. The target configuration may be at least partially based on, for example, one or more anchor cell identities. For example, the anchor cell identity may be used to apply candidate cell configurations.

[0106] Example methods for implementing L1 / L2 mobility may include configuring a WTRU with a set of radio resource control (RRC) configurations for each of a group of neighboring cell candidates adjacent to a serving cell, where each configuration in the set includes measurement criteria and a transition period. The WTRU may apply the RRC configurations for each of the subset of the group of neighboring cell candidates and activate neighbor beam management for each of the subset of the group of neighboring cell candidates; report the subset of the group of neighboring cell candidates to the network; receive a beam switch on a cell indicating a beam of a non-serving cell; upon receiving the beam switch, change the current serving cell to a new serving cell, where the new serving cell is the non-serving cell that received the beam switch; remove the new serving cell from the subset of the group of neighboring cell candidates; add the previous current serving cell to the subset of the group of neighboring cell candidates; and release the RRC configuration of any candidate cell not in the subset of the group of neighboring cell candidates.

[0107] The WTRU may be configured to receive configuration information. The configuration information may be associated with a plurality of candidate cells. The configuration information may include configuration information associated with physical layer measurements. The physical layer measurements may be for each candidate cell. Additionally or alternatively, the configuration information may include one or more measurement criteria.

[0108] The WTRU may be configured to determine a subset of the plurality of candidate cells. For example, each candidate cell in the subset of the plurality of candidate cells may be determined based on the measurement criteria. The plurality of candidate cells may include all candidate cells above a reference signal received power (RSRP) threshold. Additionally or alternatively, the WTRU may be configured to transmit a report. The report may indicate the subset of the plurality of candidate cells. The report indicating the subset of the plurality of candidate cells may include a bitmap. The report may be transmitted via a media access control (MAC) control element (CE). The report may be transmitted to the base station.

[0109] The WTRU may be configured to perform physical layer measurements on the subset of the plurality of candidate cells. The WTRU may be configured to receive an indication. The indication may be to perform a lower layer handover. The lower layer handover may be to a candidate cell. The candidate cell may be the subset of the plurality of candidate cells. The indication may be received via MAC signaling. Additionally or alternatively, the indication may be received via downlink control information (DCI).

[0110] The physical layer measurements may include radio link monitoring (RLM) measurements. Additionally or alternatively, the physical layer measurements may include beam measurements. The measurement criteria may include reference signal received power. For example, the measurement criteria may include reference signal received power exceeding a threshold.

[0111] The WTRU may be configured to implement MAC and / or RRC layer procedures to support L1 / L2 mobility.

[0112] As described herein, the term SCell may refer to a serving cell, which may include a primary cell (PCell), a primary cell of a secondary cell (PSCell), and / or a secondary cell (sCell) (e.g., in carrier aggregation). The architecture for L1 / L2 mobility may include a WTRU configured with a stored configuration associated with one or more cells (e.g., candidate cells). For example, the stored cell configuration may be specific to (e.g., one) PSCell and / or (e.g., one) SCell (e.g., or associated therewith). In some scenarios, a common set of candidate cells may be associated with multiple cells (e.g., may include SpCellI). The candidate cells may be configured using an association (e.g., reference) with a subset of SCell (e.g., may include SpCell). The SCell may also be configured with or alternatively configured with an association (e.g., reference) with a subset of candidate cells. For example, multiple SCells may have an association with the same candidate cell.

[0113] The WTRU may identify or determine a subset of cells within a set of candidate cells as potential L1 / L2 mobility target (PLMT) cells (e.g., a PLMT cell list). The PLMT cell list may also be referred to herein as a PLMT cell set. For example, the PLMT cell list for a given set of candidate cells may be configured by the network. The WTRU may update (e.g., add and / or remove) cells in the PLMT cell list. For example, the WTRU may add a candidate cell to the PLMT cell list based on rules defined herein. In some scenarios, a PLMT cell may be removed from the PLMT cell list. The removed PLMT cell may remain a candidate cell. The WTRU may receive configuration information associated with one or more candidate cells. The configuration information may be associated with one or more physical layer measurements (e.g., RLM, beam measurements, SSB, and / or CSI-RS) of one or more candidate cells.

[0114] L1 / L2 mobility may be performed by receiving signaling (e.g., beam change, transmission configuration indicator (TCI) state change, etc.) via L1 / L2 signaling. For example, L1 / L2 mobility signaling may be performed via downlink control information (DCI) or medium access control (MAC) control element (CE). L1 / L2 mobility signaling may be used, for example, to update the current serving cell to a PLMT cell. For example, the network may signal a beam switch to a beam associated with a non-serving PLMT cell. Upon receiving such signaling, the WTRU may perform a serving cell change from the serving cell to the PLMT cell, where the WTRU has applied and verified the RRC configuration for the PLMT cell.

[0115] As described herein, the term SCell may be used to refer to a serving cell, which may be a PCell, a PSCell, or an SCell (e.g., a secondary cell in carrier aggregation).

[0116] The WTRU may be configured to implement specific behaviors for deactivated SCell and dormant SCell, e.g., to facilitate improved L1 / L2 mobility.

[0117] The WTRU may be served by a serving cell (e.g., cell A). The WTRU may be configured with RRC configuration, for example, via the serving cell. For example, the RRC configuration may be associated with one or more candidate cells B, C, D, etc. The candidate cells and their configurations may be associated with the serving cell A. Alternatively or additionally, the candidate cells may be common to multiple serving cells (e.g., cells C and D may be candidate cells when served by cell A and cell B).

[0118] A WTRU may receive one or more candidate cell configurations (e.g., via a System Information Block (SIB) and / or RRC signaling (e.g., dedicated RRC signaling)). For example, the WTRU may receive RRC signaling from a serving cell. In some scenarios, e.g., the WTRU may store the candidate cell configurations without applying (e.g., not immediately applying) these configurations. For example, the WTRU may store the candidate cells and wait for a period of time before applying these configurations. The period of time may be based on a threshold. Alternatively or additionally, the WTRU may receive an indication to apply (e.g., immediately apply) the candidate cell configurations. For example, an indication to apply the candidate cell configurations may be received from the network.

[0119] A WTRU applying a stored candidate cell configuration may behave similarly to a WTRU adding a secondary cell (e.g., in carrier aggregation). In some examples, the WTRU may consider such a secondary cell as a dormant SCell. For example, after applying the configuration, the WTRU may consider the secondary cell as a dormant cell. In some examples, the WTRU may not perform physical downlink control channel (PDCCH) decoding and / or physical uplink control channel (PUCCH) transmission on the secondary cell. The WTRU may alternatively or additionally perform beam management (e.g., on the secondary cell). In some scenarios, the beam management process performed on a candidate cell may be different from, for example, the beam management process performed on a secondary cell (e.g., in carrier aggregation (CA)). Performing beam management on a candidate cell may allow the WTRU to report beam measurement results. The beam measurement report may be sent to the network (e.g., associated with L1 / L2 mobility). The WTRU may start the beam measurement report based on a TCI state configuration. The TCI state configuration may be associated with a cell provided in the RRC configuration from the serving cell. In some examples, the WTRU may start the beam measurement report after applying the stored configuration for the candidate cell and / or adding the cell as a PLMT cell. The WTRU may remove the cell from the PLMT cell. The WTRU may stop the beam measurement report. For example, the WTRU may stop the beam measurement report for the cell removed from the PLMT cell. The WTRU may additionally or alternatively release the RRC configuration for the cell (e.g., the cell removed from the PLMT cell). In some examples, for example, if the cell removed from the PLMT cell remains as a candidate cell, the WTRU may store (e.g., continue to store) the RRC configuration of the cell. Additionally or alternatively, the WTRU may perform radio link monitoring / radio link failure (RLM / RLF) differently for a cell that is a PLMT cell. For example, the WTRU may use a different configuration associated with RLM / RLF. Additionally or alternatively, the WTRU may monitor one or more reference symbols (e.g., different reference symbols), use one or more RLF timers (e.g., different RLF timers), use Qin values (e.g., different Qin values), and / or use Qout values (e.g., different Qout values).

[0120] In some examples, the WTRU may consider a cell as a deactivated SCell. For example, the WTRU may consider a cell as a deactivated cell after applying a configuration to deactivate the cell. In some examples, the WTRU may apply RRC configuration for a candidate cell, and / or may not perform beam management and / or RLM / RLF for the cell. The WTRU may initiate beam management and / or RLM / RLF for a cell. For example, the WTRU may initiate beam management and / or RLM / RLF for a cell based on signaling received from the network (e.g., via a MAC CE, such as an activate / deactivate MAC CE). If the WTRU initiates beam management and / or RLM / RLF for a cell based on signaling received from the network (e.g., a MAC CE), the WTRU may consider the cell as a dormant SCell (e.g., also referred to herein as a PLMT cell) as described herein. For example, the WTRU may receive a MAC CE that activates or deactivates beam measurement / reporting and / or RLM / RLF for the WTRU (e.g., without initiating any PDCCH monitoring) until the WTRU receives an L1 / L2 mobility trigger. Additionally or alternatively, the WTRU may add (e.g., autonomously add) a cell to the PLMT cell based on any of the techniques described herein. In some examples (e.g., in the case where the WTRU autonomously adds a cell to the PLMT cell list), the WTRU may initiate beam management and measurement reporting to the network.

[0121] The WTRU may be configured to implement a beam management process for a PLMT cell.

[0122] The WTRU may receive an indication associated with a TCI state configuration. For example, the TCI state configuration may be used to control beam management for a set of CSI configurations. One or more of the following may be applied.

[0123] The WTRU may receive a TCI state configuration. For example, the TCI state configuration may be used by the WTRU to control beam management for a set of CSI configurations. The TCI state configuration may be configured by the serving cell (e.g., via RRC). In some scenarios, the TCI state configuration received from the serving cell may be applied to CSI configurations that will be applied to neighboring cells (e.g., PLMT cells). Such configurations may be different from the CSI configurations applied to neighboring cells after L1 / L2 mobility. For example, the WTRU may switch from a first TCI state configuration to a second TCI state configuration (e.g., associated with L1 / L2 mobility).

[0124] The WTRU may receive signaling (e.g., MAC CE) that selects a subset of TCI states (e.g., configured by RRC) for a PLMT cell and / or for controlling beam measurements. For example, such signaling may be received from the serving cell. For example, the WTRU may receive signaling (e.g., via DCI) to change the beam measured on the PLMT cell list for beam reporting.

[0125] The WTRU may deactivate or stop beam measurements for a PLMT cell, for example, based on receiving a deactivation command. For example, the deactivation command received by the WTRU may be similar to or include a deactivation MAC CE. For example, after activation, the WTRU may re-initiate beam management, for example, using the previously (e.g., last) TCI state selected for the PLMT cell.

[0126] The WTRU may be configured to implement a procedure for managing candidate cell configurations. One or more of the following may be applied.

[0127] The WTRU may be configured with a set of candidate cells, for example, via RRC configuration (e.g., of PHY, MAC, etc.). For example, the RRC configuration may indicate parameters to be used by the WTRU when operating on the set of candidate cells. The candidate cells or candidate cell list may be associated with one or more SCell (e.g., SCell that may be activated at the WTRU). However, in some scenarios, the candidate cells may not be active SCell / deactivated SCell at the WTRU.

[0128] A WTRU may have candidate cells. For example, the WTRU may store candidate cell configurations without applying the candidate cell configurations. The WTRU may be configured with rules / events to trigger the application of candidate cell configurations. Additionally or alternatively, the WTRU may be configured with rules / events for when to initiate L1 measurements (e.g., beam measurements) on a candidate cell (e.g., a candidate cell whose configuration has been applied at the WTRU). A similar (e.g., the same) set of rules may be used, for example, for applying candidate cell RRC configurations at the WTRU and / or for initiating L1 measurements. For example, if the configured rules / events trigger the WTRU to apply the RRC configuration, the WTRU may initiate L1 measurements on the cell (e.g., according to the L1 configuration). Additionally or alternatively, the WTRU may be configured with a first rule / event to apply the RRC configuration and may be configured with a second rule / event to initiate L1 measurements. The first rule / event and / or the second rule / event may be based on L3 measurements (e.g., L3 measurements performed by the WTRU on the candidate cell). The WTRU may be configured with L3 measurements to perform on the candidate cell. The WTRU may perform L3 measurements. In some scenarios, the WTRU may perform L3 measurements and may not report the L3 measurements. The WTRU may use such measurements, for example, as part of the criteria for applying cell configurations and / or initiating L1 measurements. For example, the WTRU may be configured with an event based on a first L3 measurement to trigger the application of a candidate cell, and / or may be configured with a second L3 measurement event to initiate L1 measurements. Alternatively or additionally, the WTRU may be configured with an event based on L3 measurements to trigger the application of a candidate cell and be configured with another trigger (e.g., network signaling, positioning triggers, etc. as described herein) to initiate L1 measurements.

[0129] In some scenarios, some RRC parameters / configurations / information elements (IEs) may not be affected by L1 / L2 mobility. For example, the WTRU may maintain previously configured parameters / IEs. Additionally or alternatively, the WTRU may apply non-maintained RRC parameters. In some examples, the WTRU may maintain previously configured parameters during L1 / L2 mobility and / or may apply non-maintained RRC parameters during L1 / L2 mobility. The RRC configuration for the target L1 / L2 mobility may be associated with a stored (e.g., kept in storage) set of parameters / IEs. For example, the set of parameters / IEs may be stored for a PLMT cell and / or may be stored under L1 / L2 mobility. These parameters / IEs may not be applied in some scenarios. These parameters / IEs may be stored and / or applied by the WTRU when adding a cell to the PLMT cell list and / or applying a configuration. For example, the WTRU may apply the RRC configuration when, for example, applying a cell configuration or adding a cell as a PLMT cell. In addition to one or more IEs, the WTRU may additionally or alternatively apply the RRC configuration. For example, one or more non-applied IEs may remain stored but not applied. In some examples, the WTRU may apply the RRC configuration when applying a cell configuration and / or adding a cell as a PLMT cell. The IEs may be applied at a later time, such as, for example, during an L3 reconfiguration (e.g., L3 mobility and / or L3 reconfiguration) and / or a cell change (e.g., a network-controlled anchor cell change). In some examples, during the addition of a cell as a PLMT cell, the WTRU may not apply one or more of the following: a candidate cell list; events / conditions associated with the candidate cell list; a specific cell that will (e.g., always) be considered a PLMT cell for a given anchor or serving cell; and / or any configuration parameters associated with the maintenance of the candidate cell or PLMT cell. The WTRU may be provisioned with an RLM / RLF configuration that, in some scenarios, will remain unchanged. For example, the RLM / RLF configuration may remain unchanged under L1 / L2 mobility. Additionally or alternatively, the RLM / RLF configuration may change (e.g., may only) during an L3 handover. The WTRU may receive conditions (e.g., triggers) for performing RLM / RLF on a PLMT cell and / or may apply the RLM / RLF configuration during an L3 handover procedure. Thus, these parameters may remain unchanged due to L1 / L2 mobility. In some examples, the stored parameters for a cell may be different from the parameters applied to the target cell. For example, the stored parameters for a cell may be different from the parameters applied to the target cell after L1 / L2 mobility.

[0130] Certain RRC parameters may be applied based on adding a cell to the PLMT list under L1 / L2 mobility. The RRC configuration for a candidate cell may be divided into one or more (e.g., two) parts. These parts may include a first part and a second part. For example, when the WTRU adds a candidate cell to the PLMT list and / or applies the configuration, the WTRU may apply the first part. The second part may be applied, for example, under L1 / L2 mobility. The WTRU may use a candidate cell list. For example, when the WTRU is served by cell B, the candidate cell list may be configured by cell A. The WTRU served by cell A may apply the configuration of cell B (e.g., if cell B is added to the PLMT list). In some scenarios, the WTRU may, for example, not apply the candidate cell list until L1 / L2 mobility is triggered. For example, the WTRU may apply the beam measurement and / or reporting configuration of the PLMT cell. The WTRU may apply the beam measurement and / or reporting configuration of the PLMT cell. For example, the WTRU may apply the beam measurement and / or reporting configuration when adding the PLMT. The WTRU may apply one or more of the PDCCH configuration, PUCCH configuration, data decoding and transmission configuration, etc. For example, the WTRU may apply one or more of the PDCCH configuration, PUCCH configuration, data decoding and transmission configuration, etc. during an L1 / L2 handover. In some examples, the WTRU may maintain the beam measurement and / or reporting configuration. For example, when a cell is added to the PLMT list, the WTRU may maintain the beam measurement and / or reporting configuration. The WTRU may apply certain parameters to the target cell. For example, the WTRU may apply certain parameters to the target cell before L1 / L2 mobility (e.g., this may avoid RRC reconfiguration latency). The WTRU may ensure that some configurations (e.g., the candidate cell list and / or the parameters controlling the addition of candidates to the PLMT cell list) are (e.g., can be) applied to one or more cells (e.g., the serving cell and / or candidate cells).

[0131] A WTRU may request the RRC configuration of a cell (e.g., a candidate cell) from the network (e.g., using an RRC message such as dedicatedSIBRequest, etc.). For example, the WTRU may request the RRC configuration in order to avoid storing a large number of cell configurations at the WTRU for mobility, and / or in order to reduce the signaling overhead generated by providing a large number of candidate cell configurations for each WTRU at each cell. The RRC configuration of the candidate cell to be used in the cell may be stored in a separate System Information Block (SIB). For example, if the RRC configuration associated with the candidate cell is stored in a separate SIB, the WTRU may use dedicatedSIBRequest and / or SI request to obtain the System Information (SI) (e.g., if the WTRU cannot receive the SI from broadcast at a given time). Alternatively or additionally, the WTRU may request the RRC configuration of one or more candidate cells. For example, the WTRU may use an RRC message and / or a modified version of dedicatedSIBRequest to request (e.g., individually request) the RRC configuration of one or more candidate cells. In some examples, the WTRU may request the candidate cell configuration of a subset of candidate cells. The WTRU may request the candidate cell configuration of a subset of candidate cell requests based on one or more conditions. For example, the WTRU may request the candidate cell configuration of a subset of candidate cells based on adding the candidate cell as a PLMN cell. In some examples, the WTRU may trigger a request to obtain the candidate cell configuration based on one or more of the following: the measured cell quality is higher than a threshold; the location of the WTRU is within a specified distance of the cell; and / or when one or more triggers for adding the candidate cell as a PLMN cell also trigger the WTRU to request the configuration of the candidate cell.

[0132] In some scenarios, candidate cell configuration failures may occur. For example, when a WTRU applies a candidate cell RRC configuration, a configuration failure may occur. The WTRU may report the candidate cell configuration failure to the network. The configuration failure report may be transmitted immediately (e.g., at the time of the configuration failure), upon the triggering of a subsequent event, and / or based on a condition. For example, the condition that triggers the WTRU to transmit the configuration failure report may be after the configuration failure has occurred. In some examples, the WTRU may transmit / report the candidate cell configuration failure at one or more of the following times: immediately at the time of the configuration failure; when the number of configuration failures is greater than a specific threshold; during a successful / failed L3 mobility procedure; during a successful / failed L1 mobility procedure; when a beam failure is detected on an SCell and / or a candidate cell; when the number of candidate cells for which L1 measurements are valid is below a threshold; when the number of candidate cells for which L1 measurements are invalid is below a threshold; when the number of candidate cells with the applied RRC configuration is below a threshold; when the number of candidate cells with the applied RRC configuration but without valid L1 measurements is below a threshold; when the total number of candidate cells without a pending reconfiguration failure (e.g., to be reported) is below a threshold; when the configured number of RRC configuration failures occurs; and / or when an alternative candidate cell that meets the criteria for adding a candidate cell cannot be found. In some examples, the alternative candidate cell may not result in a configuration failure. Alternatively or additionally, when the configured number of RRC configuration failures occurs, the WTRU may report the configuration failure.

[0133] The WTRU may apply a candidate cell configuration. In some examples, the candidate cell application may fail. At the time of a configuration failure of the candidate cell configuration (e.g., when attempting to apply the configuration), the WTRU may perform one or more of the following: the WTRU may report the failure; the WTRU may release the configuration; the WTRU may retain the configuration; the WTRU may retain the configuration until the WTRU receives a subsequent RRC reconfiguration from the network; the WTRU may decide whether to retain or release the configuration based on any one of these conditions; the WTRU may release the candidate cell configuration; the WTRU may release the candidate cell configuration for application under L3 mobility and / or L1 / L2 mobility; the WTRU may be configured with rules regarding whether to release the candidate cell RRC configuration in the case of an application configuration failure. Additionally or alternatively, the WTRU may release the configuration at the time of the failure (e.g., as long as the candidate cell is not the identified anchor cell). The reporting of the failure may be immediate, and / or upon the triggering of a subsequent event, and / or when a condition is met (e.g., as described herein).

[0134] The WTRU may attempt to add another candidate cell to the PLMT list and / or attempt to apply another cell configuration. For example, if the WTRU finds another candidate cell, the WTRU may attempt to add another cell configuration. For example, the other candidate cell may meet the criteria to be added as a PLMT cell. In some examples, the WTRU may avoid and / or delay reporting a failure. For example, if the application of the configuration is successful, the WTRU may avoid and / or delay reporting a failure. Alternatively or additionally, for example, in the case where the WTRU cannot find another configuration that meets the criteria and / or all subsequently selected candidate cells also result in a configuration error, the WTRU may report a failure.

[0135] The WTRU may report a candidate cell RRC reconfiguration failure. For example, the candidate cell RRC reconfiguration failure may be reported via an RRC message (e.g., UEAssistanceInformation) sent by the WTRU. The RRC reconfiguration failure report may include one or more of the following information (e.g., it may be associated with each of one or more candidate cells for which the RRC reconfiguration failure is reported): the cell identity (e.g., cell ID) of each candidate cell; the index assigned to the candidate cell RRC reconfiguration (e.g., when the index is provided to the WTRU); the identity (e.g., cell ID) of the cell from which the WTRU initially received the configuration of the candidate cell; the identity (e.g., cell ID) of the cell acting as the anchor cell for the SCell (e.g., as described herein); and / or the RRM measurement results for one or more other candidate cells and / or the candidate cell with the failed reconfiguration.

[0136] The WTRU may maintain the identity of the anchor cell. For example, the identity of the anchor cell may be maintained for use in applying candidate cell configurations and / or L3 mobility. The WTRU may maintain the identity of the anchor cell. For example, the WTRU may maintain the identity of the anchor cell for each SCell. In some examples, the WTRU may maintain the identity of the anchor cell in order to apply different stored cell configurations at the WTRU during L1 / L2 mobility. The anchor cell may be configured via incremental RRC configuration. The candidate cells may have incremental configurations. For example, the WTRU may receive one or more candidate cell configurations in the form of incremental configurations. The WTRU may determine the complete cell configuration. The WTRU may determine the complete cell configuration by applying the incremental configuration to the existing configuration. Additionally or alternatively, the WTRU may apply the incremental configuration to the existing configuration on the anchor cell. For example, the WTRU may determine the complete cell configuration by applying the cell configuration (e.g., obtained using incremental signaling) to the anchor cell configuration associated with the SCell. In some examples, the WTRU may apply the RRC configuration for the target cell to the anchor cell upon HO / CHO / conditional PSCell addition or change (CPAC). For example, during HO / CHO / CPAC from an SCell to a target cell, the WTRU may apply the RRC configuration for the target cell to the anchor cell at HO / CHO / CPAC, and / or not apply it to the SCell configuration that is the source of the mobility. The WTRU may change the SCell from a source cell to a target cell (e.g., where the target cell is one of the candidate cells for L1 / L2 mobility). For example, the WTRU may change the SCell from a source cell to a target cell without changing the anchor cell. In some examples, the WTRU may change the SCell from a source cell to a target cell during L1 / L2 mobility.

[0137] The network may control / initiate an anchor cell change. In some examples, the anchor cell change may be performed by the network via RRC signaling. For example, the WTRU may receive an RRC message regarding the serving cell. The RRC message may indicate that the WTRU is to change the anchor cell of the serving cell. The RRC message may contain the cell ID of the cell that is to become the new anchor cell. The WTRU may receive a cell index associated with the candidate cell to identify the new anchor cell.

[0138] The WTRU may vary the reference cell configuration for one or more (e.g., all) future mobility commands and / or the configuration of new candidate cells. In some examples, the WTRU may vary the reference cell configuration for one or more (e.g., all) future mobility commands and / or the configuration of new candidate cells based on a network-controlled anchor cell change. For example, upon receiving an L3 mobility (HO / CHO / CPAC), the WTRU may apply one or more incremental configurations. Additionally or alternatively, the WTRU may apply one or more incremental configurations upon receiving a new candidate cell and a network-controlled anchor cell change or after a network-controlled anchor cell change. The one or more incremental configurations may be applied on top of the configuration of the new anchor cell (e.g., as may be indicated in the anchor cell change).

[0139] The WTRU may receive a candidate cell configuration and / or a conditional handover command. For example, the WTRU may receive a candidate cell configuration and / or a conditional handover command and a network-controlled anchor cell change. In some examples, the WTRU may determine a target cell configuration for the candidate cell and / or CHO candidate. For example, the WTRU may determine a target cell configuration for the candidate cell and / or CHO candidate based on the new anchor cell in the anchor cell change.

[0140] In certain scenarios, the anchor cell change of the WTRU may fail. For example, the anchor cell change of the WTRU may fail due to one or more of the following: the WTRU attempts to apply the configuration of the anchor cell and the configuration fails; the cell ID and / or index indicated in the anchor cell change is not a serving cell or a stored / configured candidate cell; and / or the WTRU is required to add a candidate cell as a PLMT cell in the anchor cell change and the configuration fails.

[0141] The WTRU may maintain the current anchor cell, maintain the operation of the current serving cell change, and / or ignore any CHO candidates and / or candidate cells included in the anchor cell change. For example, upon failure during an anchor cell change, the WTRU may maintain the current anchor cell, maintain the operation of the current serving cell change, and / or ignore any CHO candidates and / or candidate cells included in the anchor cell change.

[0142] When the anchor cell change is successful, the WTRU may perform one or more of the following: release one or more (e.g., all) candidate cells stored upon receipt of the anchor cell change; release one or more (e.g., all) candidate cells that are not currently PLMT cells stored upon receipt of the anchor cell change; release one or more (e.g., all) candidate cells stored upon receipt of the anchor cell change and / or upon the last anchor cell change, the configurations of which have not been applied and / or which are not (e.g., never have been) PLMT cells (e.g., since the last L3 mobility); and / or report specific information associated with the candidate cells (e.g., in a confirm RRC message). For example, the information associated with the candidate cells reported by the WTRU may include one or more of the following: candidate cells released by the WTRU, candidate cells maintained by the WTRU, candidate cells as PLMT cells and / or as cells with the applied configuration that have been released and / or maintained, or L3 measurements of any candidate cell. Alternatively or additionally, the WTRU may release one or more candidate cells. As described herein, the information associated with the candidate cells may be reported by the WTRU via a bitmap.

[0143] The WTRU may be configured to perform a conditional anchor cell change. For example, the WTRU may trigger an anchor cell change and / or notify the network of such. The WTRU may cause the trigger of the anchor cell change to be based on the occurrence of one or more conditions. The WTRU may be configured with one or more measurement events (e.g., similar to CHO, to perform a conditional anchor cell change). The one or more measurement events may be associated with the current anchor cell, the current serving cell, and / or any candidate serving cell. The WTRU may be configured with a new set of events / updated set of events for conditional anchor cell change. For example, the new set of events / updated set of events may be based on any of the events described for adding a PLMT cell.

[0144] The WTRU may be configured to maintain a PLMT list and / or utilize the PLMT list to facilitate L1 / L2 mobility procedures. For example, the WTRU may be configured with one or more events / triggers for adding / removing candidate cells from the PLMT cell list. The WTRU may be configured with one or more conditions for applying the stored candidate cell configurations and / or adding the stored / configured candidate cells as PLMT cells. For example, the one or more conditions for applying the stored candidate cell configurations and / or adding the stored / configured candidate cells as PLMT cells may be based on one or more measurement events. For example, for each candidate cell, the WTRU may be configured with conditions for applying the candidate cell configuration and / or adding the candidate cell as a PLMT cell. In some scenarios, the conditions for applying the stored candidate cell configurations and / or adding the stored / configured candidate cells as PLMT cells may be associated with L3 measurements of the candidate cell. For example, the conditions may be associated with measurements relative to the serving cell. Alternatively or additionally, the conditions for applying the stored candidate cell configurations and / or adding the stored / configured candidate cells as PLMT cells may be one of the conditions described herein.

[0145] The WTRU may be configured with conditions (e.g., a single condition) for the serving cell and / or conditions (e.g., a single condition) for one or more (e.g., a set or all) candidate cells associated with the serving cell. For example (e.g., when configured with a set of candidate cells), the WTRU may receive conditions for adding one or more of the candidate cells to the candidate cell list. In some examples, one or more candidate cell configurations may be applied and / or added as a PLMT. The events may be based on one or more legacy L3 measurement events. For example, one or more L3 events may be related to the serving cell and / or the candidate cell list. In some examples, the events may include one or more of the following: the serving cell quality drops below a threshold; the candidate cell quality exceeds the serving cell quality threshold; the candidate cell quality exceeds a threshold; or any combination thereof.

[0146] The WTRU may be configured with conditions for removing candidate cells that are PLMT cells on a per-candidate, per-serving cell, and / or per-candidate set (e.g., all candidates) basis.

[0147] In certain scenarios, the conditions for removing candidate cells that are PLMT cells on a per-candidate, per-serving cell, and / or per-candidate set (e.g., all candidates) basis may be related to one or more L3 measurements. For example, the conditions may include one or more of the following: the serving cell exceeds a threshold; the candidate cell quality does not exceed a threshold; the candidate cell quality does not exceed the serving cell quality threshold; or any combination thereof.

[0148] The WTRU may apply L3 measurement events. For example, the WTRU may apply L3 measurement events by comparing one or more candidate non-PLMT cells with one or more candidate PLMT cells. In another scenario, the WTRU may apply L3 measurement events by comparing one or more candidate PLMT cells. In another example, the WTRU may apply L3 measurement events by comparing one or more candidate non-PLMT cells. In some examples, the event may be a new event type. For example, an event may be defined for RRM measurements between one or more (e.g., multiple) cells.

[0149] An A3 event may involve multiple cells. An A3 event may compare a neighboring cell with a serving cell. Alternatively or additionally, an A3 event may trigger when a neighboring cell exceeds a threshold and / or exceeds a value associated with the serving cell. For example, the WTRU may add a candidate cell to the PLMT cell list. In some examples, the WTRU may add a candidate cell to the PLMT cell list if the candidate cell exceeds a certain threshold compared to all current PLMT cells. In some examples, the WTRU may add the candidate cell as a PLMT cell if the candidate cell exceeds a certain threshold compared to the current best PLMT cell. For example, the WTRU may add the candidate cell as a PLMT cell if the candidate cell exceeds a certain threshold compared to at least X (e.g., the configured number of) current PLMT cells. For example, the WTRU may add the candidate cell as a PLMT cell if the candidate cell exceeds a certain threshold compared to the average of the current PLMT cells. In some examples, the A3 event herein may be defined as the removal of a current PLMT cell.

[0150] An A5 event may involve multiple cells. An A5 event may compare a neighboring cell with a threshold. Additionally or alternatively, an A5 event may compare a serving cell with a threshold (e.g., a different threshold). For example, the WTRU may replace a PLMT cell with a candidate non-PLMT cell. In some examples, the WTRU may replace a PLMT cell with a candidate non-PLMT cell if, for example, the PLMT cell does not exceed a threshold and / or the non-PLMT cell exceeds a threshold. For example, the WTRU may replace a PLMT cell with a candidate non-PLMT cell if at least X (e.g., the configured number of) PLMT cells do not exceed a threshold and / or at least Y (e.g., the configured number of) non-PLMT candidate cells exceed a threshold. In some examples, X and Y may be configured and / or predefined with the event. The A5 event herein may be defined as the removal of a current PLMT cell.

[0151] In some scenarios, a WTRU may be configured with events and / or conditions for adding candidate cells to a PLMT cell list and / or removing candidate cells from the PLMT cell list.

[0152] The WTRU may consider various conditions to determine the number of PLMT cells for a serving cell. For example, the WTRU may be configured with a maximum / minimum number of PLMT cells. In some scenarios, the WTRU may (e.g., based on other conditions) ensure that the number of PLMT cells does not exceed the maximum value and / or is not less than the minimum value. In some scenarios, the WTRU may determine the number of PLMT cells based on the WTRU capabilities. For example, the total number of PLMT cells (e.g., over a cell group, per serving cell, etc.) should not exceed the WTRU capabilities. In another example, the total number of configured cells (e.g., potentially over a cell group, frequency, frequency band, etc.) should not exceed the WTRU capabilities. For example, the total number of serving cells and PLMT cells (e.g., over a cell group, frequency, frequency band, etc.) should not exceed the WTRU capabilities. In some scenarios, the WTRU may be configured per serving cell.

[0153] In certain scenarios, the WTRU may determine the number of PLMT cells. For example, the WTRU may determine the number of PLMT cells for a serving cell based on the data rate. In some scenarios, the number of PLMT cells maintained by the WTRU may be a function of the data rate (e.g., calculated over all bearers) at the WTRU and / or a function of the buffer occupancy at the WTRU.

[0154] The WTRU may determine, for example, the number of PLMT cells for a serving cell based on mobility criteria. For example, the number of PLMT cells maintained by the WTRU may be a function of the speed of the WTRU. In some scenarios, the number of PLMT cells maintained by the WTRU may be a function of the number of mobility events (e.g., L3 mobility and / or L1 / L2 mobility) performed at the WTRU over a period of time. For example, the period of time may be a recent period of time.

[0155] The WTRU may determine, for example, the number of PLMT cells for a serving cell based on a frequency range / frequency band. In some scenarios, the WTRU may be configured with multiple PLMT cells to maintain a specific frequency / frequency band. For example, the specific frequency / frequency band may be associated with the serving cell.

[0156] In some scenarios, a WTRU may determine, e.g., the number of PLMT cells for a serving cell, based on beam characteristics. For example, the WTRU may be configured with multiple PLMT cells to maintain. The number of PLMT cells to maintain may be related to the beamwidth, the number of beams. Additionally or alternatively, the number of PLMT cells to maintain may be related to any characteristic of the beam associated with the serving cell, the PLMT cell, and / or a combination thereof.

[0157] A WTRU may determine, e.g., the number of PLMT cells for a serving cell, based on a set of parameters. In some scenarios, the WTRU may be configured with multiple PLMT cells to maintain, based on a set of parameters configured for the serving cell, the PLMT cell, the candidate cell, and / or a combination thereof.

[0158] In some scenarios, a WTRU may determine, e.g., the number of PLMT cells for a serving cell, based on L1 / L2 and / or L3 measurements. In some examples, the WTRU may be configured with multiple PLMT cells determined based on L3 measurements of the serving cell and / or L3 measurements of the candidate and / or PLMT cells. In some scenarios, the WTRU may be configured to maintain a cell as long as the PLMT cell meets some L3 measurement criteria.

[0159] A WTRU may determine, e.g., the number of PLMT cells for a serving cell, based on the number of candidate cells configured for the serving cell. In some examples, the WTRU may be configured with a set of one or more candidate cells for each serving cell. In certain scenarios, the number of PLMT cells maintained when served by a serving cell may be a function (e.g., ratio) of the number of candidate cells configured for the serving cell.

[0160] In certain scenarios, a WTRU may determine, e.g., the number of PLMT cells for a serving cell, based on conditions / triggers for beam failure detection / recovery. For example, when the WTRU detects a beam failure on a beam, the WTRU may remove a PLMT cell / replace the PLMT cell with another candidate cell. In some scenarios, the beam may be the best beam and / or a configured number of beams associated with the cell. The WTRU may perform the removal / replacement immediately and / or after a configured period of time. For example, if the WTRU performs a successful beam failure recovery on a beam belonging to a candidate cell, the WTRU may add the candidate cell as a PLMT cell.

[0161] The WTRU may be configured to add a candidate cell as a PLMT cell and / or remove a candidate cell as a PLMT cell based on time-related conditions / triggers. For example, if any of the conditions herein are met for a PLMT cell for at least a configured period of time, the WTRU may add a candidate cell as a PLMT cell and / or remove a cell as a PLMT cell.

[0162] The WTRU may be configured to add a candidate cell as a PLMT cell and / or remove a candidate cell as a PLMT cell based on location-related conditions / triggers. For example, the WTRU may be configured with location to associate with each cell (e.g., in a candidate cell configuration). In some scenarios, if the location of the WTRU is within X (e.g., a configured amount of) meters of the location configured for a cell, the WTRU may add the candidate cell as a PLMT cell. In some examples, if the location of the WTRU is Y (e.g., a configured amount of) meters farther from the configured location for a cell, the WTRU may remove the PLMT cell.

[0163] The WTRU may be configured to add a candidate cell as a PLMT cell and / or remove a candidate cell as a PLMT cell based on conditions / triggers related to a change in cell quality. For example, if the cell quality degrades by more than a certain amount (e.g., a configured amount) within a configured period of time, the WTRU may remove the PLMT cell.

[0164] The WTRU may be configured to add a candidate cell as a PLMT cell and / or remove a candidate cell as a PLMT cell based on conditions / triggers. For example, the conditions / triggers may be based on L1 / L2 mobility and / or L3 mobility / reconfiguration. In some scenarios, due to the reconfiguration of a candidate cell, the WTRU may determine a new set of the PLMT cell list. For example, the WTRU may determine a new set of the PLMT cell list after L1 mobility. In some examples, if a PLMT cell is removed due to the removal of one or more candidate cells in the stored candidate cell configuration of the WTRU, the WTRU may select a new PLMT cell to replace the removed cell.

[0165] The WTRU may be configured to add a candidate cell as a PLMT cell and / or remove a candidate cell as a PLMT cell based on conditions / triggers (based on, for example, cell activation / deactivation and / or hibernation). For example, the WTRU may add / remove a PLMT cell associated with a serving cell (e.g., to meet WTRU capabilities) based on one or more of the following: serving cell addition / removal, cell activation / deactivation, cell entry / exit from hibernation, and / or any combination thereof.

[0166] In some scenarios, based on the triggers / conditions described herein, multiple (e.g., a large number) of cells may meet the specific criteria allowed for addition / removal. For example, the number of cells allowed to be added / removed may be based on other criteria that can be configured (e.g., a maximum number). The WTRU may select one or more cells to add / remove. For example, in scenarios where the maximum number is exceeded, the WTRU may use other conditions described herein to determine the specific cells to add / remove. For example, the WTRU may select the cells with the best / worst RRM measurement results and / or positioning to add / remove.

[0167] The WTRU may initiate L1 / L2 mobility upon receiving network signaling (e.g., DCI on the serving cell). In some scenarios, the signaling may include an explicit indication to perform cell mobility (e.g., implicitly / explicitly including the identity of the cell). The WTRU may select the best beam on the target cell to perform communication after receiving the DCI. Alternatively or additionally, the signaling may be DCI indicating a change in the beam / TCI state. For example, the beam / TCI state may indicate the beam and / or TCI state configuration associated with an adjacent cell. In some scenarios, the WTRU may determine whether the beam indicated in the DCI is associated with one of the serving cell and / or a PLMT cell. For example, upon receiving the DCI, the WTRU may determine whether the beam indicated in the DCI is associated with one of the serving cell and / or a PLMT cell. In some examples, the WTRU may initiate an action associated with L1 / L2 mobility. For example, if associated with a PLMT cell, the WTRU may initiate any action associated with L1 / L2 mobility herein. Alternatively or additionally, the WTRU may receive a MAC CE triggering L1 / L2 mobility. For example, the WTRU may receive a MAC CE activating one or more TCI states associated with different cells. The WTRU may implicitly and / or explicitly determine L1 / L2 mobility based on the content of the MAC CE (e.g., the identity of the cell or the identity of the TCI state configuration). In some scenarios, if the MAC CE indicates the activation of a TCI state associated with a different cell, the WTRU may trigger L1 / L2 mobility. Additionally, the combinations described above may also trigger L1 / L2 mobility.

[0168] In some scenarios, such as when triggering L1 / L2 mobility, the WTRU may perform one or more of the following actions in any order. The WTRU may transmit an acknowledgement to the source cell before or after successfully completing L1 / L2 mobility. For example, the WTRU may transmit an acknowledgement to the source cell (e.g., in response to a trigger that may be from a DL allocation). The WTRU may transmit an acknowledgement after successfully receiving and / or transmitting on the target cell. The WTRU may stop monitoring the PDCCH of the source cell. For example, the WTRU may stop monitoring the PDCCH of the source cell when triggering L1 / L2 mobility. The WTRU may initiate a RACH to the target cell or a UL transmission to the target cell. For example, the WTRU may initiate a RACH to the target cell or a UL transmission to the target cell when triggering L1 / L2 mobility. In some scenarios, the WTRU may perform a two-step RACH or a four-step RACH procedure. For example, the WTRU may perform a two-step or four-step RACH procedure based on whether the target cell is UL synchronized with the source cell, whether the L1 / L2 mobility is triggered by DCI or by a MAC CE from the source cell, and / or whether the WTRU has a pending UL grant when L1 / L2 mobility is triggered and / or any combination of the above.

[0169] The WTRU may apply any one or more unapplied portions of the target cell RRC configuration (e.g., as described above). For example, the WTRU may apply any unapplied portions when triggering L1 / L2 mobility. For example, after the WTRU has successfully performed transmission / reception to the target cell, the WTRU may apply the RRC configuration. In some scenarios, in the case of L1 / L2 mobility failure, the WTRU may revert to the source cell configuration and / or trigger a RACH transmission to the source cell. For example, when triggering L1 / L2 mobility, in the case of L1 / L2 mobility failure, the WTRU may revert to the source cell configuration and / or trigger a RACH transmission to the source cell. For example, if the WTRU detects a beam failure before any successful DL / UL transmission with the target cell, and / or the WTRU fails to receive a DL transmission from the target cell after a period of time and / or multiple attempts (e.g., RACH procedure), the WTRU may not be able to achieve L1 / L2 mobility.

[0170] In some scenarios, the WTRU may add the source cell as a PLMT cell, e.g., for at least a period of time. When L1 / L2 mobility is successful, the WTRU may add the source cell as a PLMT cell. In some embodiments, the WTRU may be configured with a period of time during which the source cell should be a PLMT cell, and / or may maintain the source cell as a PLMT cell for at least that period of time. For example, for the source cell, the WTRU may perform beam management as described herein (e.g., after mobility) for at least that period of time. The WTRU may perform one or more of the following: remove the new serving cell from the set of configured candidate cells; apply the stored RRC configuration (e.g., and L1 / L2 mobility parameters) for the candidate cell associated with the new serving cell; determine a new set of the PLMT cell list from the new / updated candidate cells and associated L1 / L2 mobility parameters; and release the configuration of any cell removed from the PLMT cell list; or any combination of the above. For example, when L1 / L2 mobility is successful, the WTRU may perform one or more of the following: remove the new serving cell from the set of configured candidate cells; apply the stored RRC configuration (e.g., and L1 / L2 mobility parameters) for the candidate cell associated with the new serving cell; determine a new set of the PLMT cell list from the new / updated candidate cells and associated L1 / L2 mobility parameters; and release the configuration of any cell removed from the PLMT cell list; or any combination of the above.

[0171] The WTRU may be configured to perform beam management on one or more PLMT cells. In some scenarios, the WTRU may be configured to perform a modified form of beam management on the PLMT cell. For example, the modified beam management may include one or more of the following: perform beam measurements on the PLMT cell; report beam measurements made on the serving cell; perform / report beam measurements at a reduced or different period; perform / report beam measurements without triggering beam failure detection and / or recovery; perform beam failure detection / reporting without any recovery action; perform the modified beam failure detection process described herein; or any combination of the above.

[0172] For certain PLMT cells (e.g., for RLM / RLF), the WTRU may perform beam failure detection and / or trigger an indication of beam failure to the network. For example, the WTRU may use the same / similar conditions as for performing RLM to perform beam failure detection. In some scenarios, the WTRU may use the same conditions as for reporting RLF to report beam failure.

[0173] In some scenarios, a WTRU may perform beam failure and / or triggering indication for one or more cells. For example, the WTRU may be configured with conditions based on whether beam failure is detected / reported for a PLMT cell. For example, the WTRU may report beam failure for a cell having an RSRP above a threshold. For example, the WTRU may report beam failure for a cell whose indicated location is at a specific distance from the WTRU's location. For example, the WTRU may report beam failure only for a subset of candidate cells for a given serving cell, as configured by the network. In some scenarios, the WTRU may determine a subset of candidate serving cells based on configured measurement criteria, WTRU capabilities, and / or the number of configured serving cells used by the WTRU. For example, a subset of neighboring cells may be selected as all candidate cells determined to have an RSRP above a threshold (e.g., assuming the number of candidates meeting the criteria does not exceed the WTRU's processing capabilities). In some examples, the criteria may include reference signal received power (RSRP) and / or an RSRP threshold. For example, if the criteria include an RSRP threshold, the subset of the plurality of candidate cells may include candidate cells associated with RSRP measurements above the RSRP threshold (e.g., all candidate cells). The measurement criteria may include channel state information-reference signal received power (CSI-RSRP). Alternatively or additionally, the measurement criteria may include synchronization signal block-reference signal received power (SSB-RSRP). In some scenarios, determining the subset of the plurality of candidate cells may be at least partially based on the number of configured candidate cells. For example, the number of configured candidate cells may be greater than a threshold.

[0174] In some scenarios, a beam failure indication (e.g., MAC CE) may be reported to a serving cell. For example, the WTRU may report one or more cells on which beam failure is detected together with the beam failure report. The MAC CE may contain one or more cell IDs and / or indices for which beam failure is triggered (e.g., associated with a PLMT cell). In some examples, the report may include a bitmap. The bitmap may be included in the MAC-CE. An indication to perform a handover may be received in downlink control information (DCI). In some examples, a report may be transmitted to the base station and / or received from the base station. In some scenarios, the WTRU may report to the network when one or more of the candidate cells in a subset of the plurality of candidate cells change.

[0175] A WTRU may be configured to receive and / or transmit configuration information. For example, the configuration information may be associated with one or more candidate cells. In some examples, the configuration information may include one or more of physical layer measurements and measurement criteria. For example, the measurement criteria may include an RSRP exceeding a threshold. In some scenarios, the WTRU may be configured to perform one or more physical layer measurements on a subset of multiple candidate cells. For example, one or more physical layer measurements may be associated with the configuration information. In some embodiments, one or more physical layer measurements may include one or more of radio link monitoring and beam measurements. In some examples, the WTRU may be configured to perform one or more measurements on one or more of the candidate cells. The subset of the one or more candidate cells may include one or more candidate cells having an RSRP above the threshold.

[0176] A WTRU may be configured to determine a subset of one or more candidate cells. For example, the WTRU may determine one or more of the candidate cells in the subset based on measurement criteria. In some examples, the WTRU may be configured to transmit and / or receive a report indicating the subset of one or more candidate cells. For example, the report may include a bitmap. In some scenarios, the report may be transmitted and / or received via a MAC CE.

[0177] The WTRU may be configured to receive an indication to perform a handover. For example, the handover may be a lower layer handover (e.g., L1 / L2 mobility). For example, the lower layer handover may be associated with a lower latency (e.g., compared to other handover techniques). The WTRU may be configured with an RRC configuration. The RRC configuration may be synchronized to a target cell (e.g., for a lower layer handover). A lower layer handover may be performed to one or more of the candidate cells in a subset of multiple candidate cells. In some scenarios, a candidate cell may be maintained as a candidate cell in the multiple candidate cells for a predetermined period of time. The predetermined period of time may be measured starting from the receipt of the indication to perform the handover. In some embodiments, the handover may be initiated after one or more of a beam failure or a beam failure recovery. In some examples, the indication may be received and / or transmitted via one or more of a MAC CE and a DCI. The WTRU may be configured to maintain one or more candidate cell configurations after receiving the indication to perform the handover.

[0178] The WTRU may be configured with conditions for whether and / or when to perform beam failure reporting to the network. For example, the WTRU may use these conditions to determine whether and / or when to perform beam failure reporting to the network after beam failure detection. In some scenarios, the conditions for whether and / or when to perform beam failure reporting to the network may be similar to those associated with adding a cell as a PLMN cell. For example, the WTRU may delay reporting a beam failure detected on a PLMN cell until a later time when specific conditions described herein are met. For example, the WTRU may delay reporting a beam failure detected on a PLMN cell until the number of PLMN cells with / without a beam failure reaches a threshold. Alternatively or additionally, the WTRU may delay beam failure recovery until L1 / L2 mobility is triggered to a cell. For example, when a beam failure is detected on a PLMN cell, the WTRU may keep the beam failure pending for the PLMN cell. If the WTRU triggers L1 / L2 mobility to the cell and the beam failure is still pending, the WTRU may initiate a beam failure recovery-like procedure (e.g., RACH to a different beam) at the time of L1 / L2 mobility. For example, if the beam failure occurs on a PLMN cell outside the target cell of the mobility, the WTRU may report the pending beam failure to the target cell at the time of L1 / L2 mobility.

[0179] In some scenarios, the WTRU may maintain a detected beam failure as pending for a specific period of time. For example, the WTRU may detect a beam failure but not report the beam failure within that period of time. In some scenarios, when the period of time expires and the conditions for reporting the beam failure have not been met, the WTRU may cancel the pending beam failure reporting associated with one or more PLMN cells.

[0180] In an example implementation, as a result of a beam failure on a serving cell, the WTRU may trigger L1 / L2 mobility. In one example, after beam failure detection on the serving cell, if the WTRU determines that the beam on the PLMN cell is better than any beam associated with the serving cell, e.g., by more than a threshold amount, the WTRU may trigger L1 / L2 mobility to that cell. In another example, if the WTRU triggers beam failure recovery on the serving cell and the beam failure recovery is unsuccessful, the WTRU may initiate L1 / L2 mobility to a PLMN cell. In some scenarios, if it is found that a PLMN cell meets any of the conditions herein, the WTRU may initiate L1 / L2 mobility.

[0181] In some scenarios, a WTRU that triggers L1 / L2 mobility due to a failed beam failure recovery may initiate a reconstruction (e.g., instead of performing any of the recovery actions described herein for L1 / L2 mobility failures). For example, after a failed L1 / L2 mobility, a WTRU that triggers L1 / L2 mobility due to a failed beam failure recovery may initiate a reconstruction. In some scenarios, a WTRU that triggers L1 / L2 mobility due to a beam failure on the serving cell may report the beam failure (e.g., using a MAC CE) to the target of the L1 / L2 mobility. For example, the WTRU may trigger L1 / L2 mobility to a PLMT cell that does not have a pending beam failure and / or whose BFI counter meets a specific criterion.

[0182] The WTRU may maintain the beam failure context (e.g., BFI counter, BFR timer) for the PLMT cell. For example, when the WTRU performs L1 / L2 mobility to a PLMT cell, the WTRU may maintain the beam failure context for that cell. Alternatively or additionally, the WTRU may only maintain some parts of the context (e.g., the WTRU may reset the timer but not the counter). Alternatively or additionally, the WTRU may reset the entire context for the cell. Alternatively or additionally, the WTRU may modify the context, such as, for example, subtract a configured value from the counter / timer.

[0183] In some embodiments, the WTRU may maintain a single beam failure context (e.g., BFI, counter, etc.) for the configured PLMT cells (e.g., all configured PLMT cells). For example, if the WTRU receives a beam failure indication from the PHY layer associated with any PLMT cell in the PLMT cell list, the WTRU may increment a counter (e.g., a single BFI). Alternatively or additionally, the WTRU may increment the BFI counter. For example, if the WTRU receives beam failure indications from at least N (e.g., the configured number of) PLMT cells in the PLMT cell list, the WTRU may increment the BFI counter.

[0184] The processes described herein can be implemented in a computer program, software, and / or firmware that is incorporated in a computer-readable medium for execution by a computer and / or a processor. Examples of computer-readable media include, but are not limited to, electronic signals (e.g., sent via a wired or wireless connection) and / or 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, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as CD-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: receive radio resource control (RRC) configuration information, wherein the RRC configuration information includes an indication of a plurality of candidate cells, an incremental configuration for at least one subset of the plurality of candidate cells, and an anchor RRC configuration; receive a media access control (MAC) control element (CE) that indicates that the WTRU should perform a handover to a candidate cell among the plurality of candidate cells, wherein the RRC configuration information includes an incremental configuration for the candidate cell; determine RRC parameters for the candidate cell based on the anchor RRC configuration and the incremental configuration for the candidate cell; perform a handover to the candidate cell based on the RRC parameters; and maintain the anchor RRC configuration and the incremental configuration for at least one subset of the plurality of candidate cells after the handover to the candidate cell is completed.

2. The WTRU according to claim 1, wherein the RRC configuration information and the MAC CE are received from a serving cell, and wherein the processor is further configured to: release RRC parameters for the serving cell of the WTRU before performing the handover to the candidate cell.

3. The WTRU according to claim 1, wherein the RRC configuration information and the MAC CE are received from a serving cell, and wherein the determined RRC parameters are not the RRC parameters used with the serving cell.

4. The WTRU according to claim 1, wherein, The processor is configured to: apply the incremental configuration for the candidate cell to the anchor RRC configuration to determine the RRC parameters for the candidate cell.

5. The WTRU according to claim 4, wherein The handover to the candidate cell is further based on a condition that the incremental configuration for the candidate cell is applied to the anchor RRC configuration.

6. The WTRU according to claim 1, wherein The processor is configured to: perform measurements for each candidate cell among the plurality of candidate cells; and transmit one or more reports indicating the measurements for each candidate cell among the plurality of candidate cells.

7. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving radio resource control (RRC) configuration information, wherein the RRC configuration information includes an indication of a plurality of candidate cells, an incremental configuration for at least one subset of the plurality of candidate cells, and an anchor RRC configuration; receiving a media access control (MAC) control element (CE) that indicates that the WTRU should perform a handover to a candidate cell among the plurality of candidate cells, wherein the RRC configuration information includes an incremental configuration for the candidate cell; determining RRC parameters for the candidate cell based on the anchor RRC configuration and the incremental configuration for the candidate cell; performing a handover to the candidate cell based on the RRC parameters; and maintaining the anchor RRC configuration and the incremental configuration for at least one subset of the plurality of candidate cells after the handover to the candidate cell is completed.

8. The method according to claim 7, wherein the RRC configuration information and the MAC CE are received from a serving cell, and wherein the method further comprises: Releasing RRC parameters of the serving cell for the WTRU before performing a handover to the candidate cell.

9. The method according to claim 7, wherein the RRC configuration information and the MAC CE are received from a serving cell, and wherein the determined RRC parameters are not the RRC parameters used with the serving cell.

10. The method according to claim 7 further comprises: Applying the incremental configuration for the candidate cell to the anchor RRC configuration to determine RRC parameters for the candidate cell.

11. The method according to claim 10, wherein the handover to the candidate cell is further based on a condition that the incremental configuration for the candidate cell is applied to the anchor RRC configuration.

12. The method according to claim 7, further comprising: Performing measurements for each of the plurality of candidate cells; And Transmitting one or more reports indicating the measurements for each of the plurality of candidate cells.

13. A method performed by a wireless transmit / receive unit WTRU, the method comprising: Receiving radio resource control RRC configuration information, wherein the RRC configuration information includes an indication of a plurality of candidate cells, an incremental configuration for at least one subset of the plurality of candidate cells, and an anchor RRC configuration; Receiving a first medium access control MAC control element CE, the MAC CE indicating that the WTRU should perform a handover to a first candidate cell among the plurality of candidate cells, wherein the RRC configuration information includes an incremental configuration for the first candidate cell; Determining first RRC parameters for the first candidate cell based on the anchor RRC configuration and the incremental configuration for the first candidate cell; Performing a handover to the first candidate cell based on the first RRC parameters and the incremental configuration for the first candidate cell; Receiving a second MAC CE, the second MAC CE indicating that the WTRU should perform a handover to a second candidate cell among the plurality of candidate cells; Determining second RRC parameters for the second candidate cell based on the anchor RRC configuration; And Performing a handover to the second candidate cell based on the second RRC parameters.

14. The method according to claim 13, further comprising: Maintaining the anchor RRC configuration and the incremental configuration for at least one subset of the plurality of candidate cells after the handover to the first candidate cell is completed.

15. The method according to claim 14 further comprises: Maintaining the anchor RRC configuration and the incremental configuration for at least one subset of the plurality of candidate cells after the handover to the second candidate cell is completed.

16. The method according to claim 13, wherein the RRC configuration information and the MAC CE are received from a serving cell, and wherein the method further comprises: Releasing RRC parameters of the serving cell for the WTRU before performing a handover to the first candidate cell.

17. The method according to claim 13, wherein the RRC configuration information and the MAC CE are received from a serving cell, and wherein the determined first RRC parameter and second RRC parameter are not RRC parameters used with the serving cell.

18. The method according to claim 13, further comprising: Apply the incremental configuration for the first candidate cell to the anchor RRC configuration to determine the first RRC parameter for the first candidate cell.

19. The method according to claim 18, wherein the handover to the first candidate cell is further based on a condition that the incremental configuration for the first candidate cell is applied to the anchor RRC configuration.

20. The method according to claim 13, wherein the RRC configuration information does not include an incremental configuration for the second candidate cell.

21. A Medium Access Control (MAC) entity, comprising: a processor configured to: receive at least one Beam Failure Instance (BFI) indication; determine a count of BFIs based on the at least one BFI indication; determine a threshold number of BFIs; compare the count of BFIs with the threshold number of BFIs; and when the count of BFIs exceeds the threshold number of BFIs, trigger a Beam Failure Request (BFR).

22. The MAC entity according to claim 21, wherein the processor is configured to receive the at least one BFI indication from a Physical (PHY) entity.

23. The MAC entity according to claim 21, wherein the processor is configured to: determine a BFD timer; determine that the BFD timer has expired; and set the count of BFIs to zero based on the expiration of the BFD timer.

Images