Wireless transmit / receive unit and method for performing same

Abstract

A wireless transmit / receive unit (WTRU) and a method performed by the same. The method comprises: receiving configuration information from a network, wherein the configuration information comprises at least one of the following items: information included in first broadcast information from a first cell; and information included in the second broadcast information from the second cell, wherein the information comprises at least one of a frequency layer of one or more adjacent cells and a PCI range of the one or more adjacent cells; determining that at least one of the first cell and the adjacent cell belongs to one or more mobile IAB nodes based on the configuration information; and modifying a measurement procedure for performing measurements on at least one of the first cell or the one or more neighboring cells.

Description

[0001] This divisional application is a divisional application with the application date of August 3, 2022, application number 202280066625.0, and invention name “New Radio (NR) in Integrated Access and Backhaul (IAB)—Measurement-related Enhancements for Mobile Cells”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 63 / 228,902, filed on August 3, 2021, the contents of which are incorporated herein by reference. Background Art

[0004] Integrated access and backhaul (IAB), where a portion of the wireless spectrum is used for backhaul connections to base stations instead of optical fiber, allows for more flexible and cheaper deployment of dense networks compared to deployments where there are dedicated optical fiber links to the base stations. A mature multi-hop IAB solution based on a split architecture, i.e., a centralized unit (CU) and distributed unit (DU) architecture, has been specified for New Radio (NR). Summary of the invention

[0005] A method performed by a wireless transmit / receive unit (WTRU) may include: receiving configuration information including neighbor cell and serving cell measurement behavior information, wherein the configuration information depends on the mobility state of the neighbor cell and the serving cell; and performing measurements based on the neighbor cell and serving cell measurement behavior information, wherein performing measurements based on the neighbor cell and serving cell measurement behavior corresponding to the mobility state of the neighbor cell and the serving cell includes at least one of the following: starting or stopping performing neighbor cell measurements or serving cell measurements; starting or stopping sending neighbor cell measurement reports or serving neighbor cell measurement reports; performing the measurements in a relaxed manner; or applying different parameters for measurement evaluation.

[0006] Performing the measurement in a relaxed manner may include at least one of applying a longer measurement period and reducing the number of measurement samples taken. Applying different parameters for the measurement values ​​may include applying at least one of a different time to trigger (TTT) value and a different hysteresis value.

[0007] The start of performing neighbor cell measurements may occur after the mobility state of the serving cell changes from mobile to static. The stop of performing neighbor cell measurements may occur after the mobility state of the serving cell changes from static to mobile. The start of performing neighbor cell measurements may occur after the mobility state of the neighbor cell changes from mobile to static. The stop of performing neighbor cell measurements may occur after the mobility state of the neighbor cell changes from static to mobile. The start or stop of performing neighbor cell measurements may be based on the location of the WTRU. Performing measurements in a relaxed manner may occur in a progressive manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

[0009] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0010] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the communication system shown;

[0011] Figure 1C It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the illustrated communication system;

[0012] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown;

[0013] Figure 2 is a diagram of an integrated access and backhaul (IAB) user plane according to one embodiment;

[0014] Figure 3 is a diagram of an IAB control plane according to one embodiment;

[0015] Figure 4A and Figure 4B is a diagram of inter-cu IAB topology adaptation according to one implementation;

[0016] Figure 5 is a diagram illustrating an exemplary process performed between a serving cell, a neighboring cell, and a WTRU according to one embodiment. DETAILED DESCRIPTION

[0017] Figure 1A 1 is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0018] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but 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 (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 smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0019] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is 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, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an evolved Node B (eNB), a Home Node B, a Home evolved Node B, a next generation Node B such as a gNode B (gNB), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0022] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 and the 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 the air interface 116. 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 ​​Uplink (UL) Packet Access (HSUPA).

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

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

[0025] 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 sent to / from multiple types of base stations (e.g., eNBs and gNBs).

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

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

[0028] The RAN 104 may be in communication with the CN 106, 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, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the specification, the CN 106 may be 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. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0032] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

[0039] The processor 118 may also be coupled to other peripherals 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 peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geographic location sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0040] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

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

[0042] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the 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.

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

[0044] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are 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.

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

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

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

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

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

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

[0051] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and leading to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent by the AP, for example, wherein the source STA may send traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0052] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may transmit a beacon on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a 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. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0053] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0054] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be transmitted by transmitting STA. At the receiver of the receiving STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

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

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

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

[0058] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0059] The RAN 104 may include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the 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 an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0060] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmit spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

[0061] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while also not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or connect with the gNBs 180a, 180b, 180c while also communicating or connecting with other RANs, such as the evolved Node-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the evolved Node-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0062] Each of the gNBs 180a, 180b, 180c 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, support of network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0063] Figure 1DThe illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the aforementioned elements are 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.

[0064] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 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.

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

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

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

[0068] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0069] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more 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 perform testing using over-the-air wireless communications.

[0070] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which may include one or more antennas) may be used by the simulation device to transmit and / or receive data.

[0071] As described above, Integrated Access and Backhaul (IAB), where a portion of the wireless spectrum is used for backhaul connections to base stations instead of optical fiber, allows for more flexible and cheaper deployment of dense networks compared to deployments where there are dedicated optical fiber links to the base stations. A mature multi-hop IAB solution based on a split architecture, i.e., a centralized unit (CU) and distributed unit (DU) architecture, has been specified for New Radio (NR).

[0072] Figure 2 An IAB user plane (UP) protocol architecture 200 is shown according to one embodiment.

[0073] Figure 3An IAB control plane (CP) protocol architecture 300 is shown according to one embodiment. The UP architecture 200 and the CP architecture 300 may include a mobile termination (MT) portion 211 that may be used to communicate with a parent node, and a DU portion 209 that may be used to communicate with a child node or a normal WTRU (e.g., WTRU 201). Both the UP and CP architectures may employ a routing / forwarding approach inspired by IP networks, where each IAB node is assigned an IP address (and associated L2 address) that is routable from a donor base station, and intermediate IAB nodes transparently forward packets based on a routing identifier / destination address. The IAB node may terminate the DU functionality. A base station that may be referred to as an IAB-donor 207 may terminate the CU functionality 215. Thus, the IAB node and the donor CU 215 may form one logical base station unit employing a CU / DU split architecture, regardless of how many hops the IAB node and the donor CU are physically apart from each other. An IAB node serving a WTRU (e.g., serving a Figure 2 The IAB node 203 of the WTRU 201 in the embodiment may be referred to as an access IAB node, and a node between the IAB donor DU and the access IAB node (eg, Figure 2 The IAB node 205 in the WTRU may be referred to as an intermediate IAB node. In some embodiments, the IAB node plays the role of an access IAB node (for WTRUs directly connected to it) and an intermediate IAB node (for WTRUs served by its descendant IAB nodes).

[0074] Instead of using end-to-end (E2E) RLC between the donor DU 213 and the WTRU 201, hop-by-hop (H2H) RLC may be used between IAB nodes. An adaptation layer called the Backhaul Adaptation Protocol (BAP) may be used to achieve efficient multi-hop forwarding. The IAB-donor 207 may assign a unique L2 address (BAP address) to each IAB node it controls (e.g., IAB node 203 and IAB node 205). In the case of multiple paths, multiple routing IDs may be associated with each BAP address. The BAPs of the source nodes (IAB-donor DUs for DL ​​traffic and access IAB nodes for UL) may add BAP headers to packets that they may be transmitting, which may contain BAP routing IDs (e.g., the BAP address of the destination / source IAB node, and the path ID). If a packet arrives with a BAP Routing ID that contains a BAP address equal to the BAP address of the IAB node, the packet may be destined for it and the packet may be passed to higher layers for processing (i.e., an F1-C / U message destined for the DU of the IAB node, an F1-C message containing SRB data for a WTRU directly connected to the IAB node, or an F1-U message containing DRB data for a WTRU directly connected to the IAB node). Otherwise, the IAB node may employ a routing / mapping table to determine where to forward the data. Each IAB node may have a routing table (configured by the IAB donor CU) that contains the next hop identifier for each BAP Routing ID. Separate routing tables are maintained for the DL and UL directions, with the DL table used by the DU portion of the IAB node, while the MT portion of the IAB node uses the UL table.

[0075] The backhaul (BH) RLC channel is used to transport packets between IAB nodes (or between an IAB-donor DU and an IAB node). The BH RLC channel configuration contains the associated RLC and logical channel configurations. Many-to-one (N:1) or one-to-one (1:1) mapping can be performed between WTRU radio bearers and BH RLC channels. N:1 mapping multiplexes several WTRU radio bearers into a single BH RLC channel based on specified parameters (such as the QoS profile of the bearer) and is suitable for bearers that do not have very strict requirements, such as best-effort bearers. On the other hand, 1:1 mapping maps each WTRU radio bearer to a separate BH RLC channel and is designed to ensure finer QoS granularity at the WTRU radio bearer level. 1:1 mapping is suitable for bearers with strict throughput or / and delay requirements, such as guaranteed bit rate (GBR) bearers or VoIP bearers.

[0076] When an IAB node detects a BH radio link failure (RLF), the IAB node may send a BH RLF indication (which is a BAP control PDU) to its descendant nodes. Upon receiving such an indication from a parent node, the IAB node may initiate a specific process including reestablishment to another parent node, or suspend transmission / reception with the relevant parent node.

[0077] In a multi-hop IAB network, data congestion may occur at intermediate IAB nodes. If not resolved, this congestion may result in dropped packets. Although higher layer protocols such as TCP may be used to ensure reliability, TCP congestion avoidance and slow start mechanisms may be very costly for overall end-to-end performance (e.g., throughput degradation). Therefore, the IAB network employs flow control. For DL, both E2E and H2H flow control mechanisms are available.

[0078] DL E2E flow control is based on the DL Data Delivery Status (DDDS) specified for the CU / DU split architecture. In DDDS, the DU (in the context of the IAB network, the DU portion that accesses the IAB node) reports information such as the expected buffer size per DRB, the expected data rate per DRB, the highest successfully delivered PDCP SN, lost packets (i.e., DUs not acknowledged at the RLC level), etc. to the CU (in the context of the IAB network, the donor CU, specifically, the CU-UP). In some embodiments, only the access IAB node performs DDDS (i.e., the IAB only reports information about the DRBs of the WTRUs they directly serve), and does not provide information about the BHRLC channels.

[0079] For DL ​​H2H flow control, an IAB node generates a flow control message (which is also a BAP control PDU) when its buffer load exceeds a certain level or when it receives a flow control poll message from a peer BAP entity (e.g., a child node). In some embodiments, the H2H flow control information indicates the available buffer size and may be at the granularity of a BH RLC channel (e.g., for BH RLC channel #1, available buffers = value_1, available buffers = value_2, or per BH RLC channel #2, etc.) or a destination routing ID (e.g., for destination routing ID = address 1, available buffers = value_1, for destination routing ID = address 2, available buffers = value 2, etc.). A node receiving a flow control message may use this information to control the flow of traffic towards the sender (e.g., throttling or pausing services associated with a particular BH RLC channel or / and destination if the flow control message indicates a low available buffer for the associated traffic, increasing the traffic flow if the flow control indicates a high available buffer value, etc.). The exact actions taken on flow control as well as the configuration / values ​​of the thresholds and other parameters that trigger the flow control messages (e.g., buffer thresholds, polling timers, etc.) are not specified and are left to the IAB / network implementation.

[0080] A preemptive buffer status report (BSR) has been specified, where an IAB node can trigger a BSR to the parent node of the IAB node even before new data has arrived in its UL buffer, based on a BSR that the IAB node has received from its child nodes or WTRUs or based on a scheduling grant (i.e., an indication of expected data) that the IAB node has provided to its child nodes or WTRUs. Conventional NR mechanisms are applied, where the IAB node controls the UL data flow from its child nodes and WTRUs by providing them with appropriate UL scheduling grants based on the BSRs received from them. In some embodiments, the IAB node is a static node. However, switching of the IAB node from one donor to another (also called migration or relocation) is supported for load balancing and for handling radio link failures (RLFs) due to congestion, such as due to moving objects such as vehicles, seasonal changes (foliage), or infrastructure changes (new buildings). Inter-donor CU switching is supported (i.e., the target and source parent DUs of the IAB node are controlled by the same donor CU), and it is desired to specify inter-donor CU switching.

[0081] IAB connectivity via MR-DC is supported. For example, an IAB node can be connected to the network via EN-DC, where the primary node is an LTE node and the secondary node is an NR node.

[0082] In some embodiments, from the WTRU's perspective, the IAB node appears as a normal base station).

[0083] Migration / relocation of IAB nodes from one parent node to another (which may involve changes in donor DU or even donor CU) is specified for load balancing or backhaul RLF handling. Such migration of IAB nodes may also be referred to as topology adaptation.

[0084] Figure 4A and Figure 4B 400A, 400B are shown according to one embodiment of inter-CU topology adaptation. In some embodiments, topology adaptation may include establishing new routes / resources via new parent CUs / paths. For example, in Figure 4A In the embodiment shown, an adaptation route A411 is established between the IAB-node 405, the IAN-node 403, the IAB-node 401 and the IAB-donor DU 406. Figure 4B As shown, during topology adaptation, a new adaptation route B 421 may be established between the IAB-node 405 , the IAB-node 404 , the IAB-node 402 , and the IAB-donor DU 408 .

[0085] In some embodiments, topology adaptation may also include redirecting the F1-U tunnel and F1--AP to a new route. Figure 4A In the illustrated embodiment, a tunnel connection for F1 412 is established between the IAB-donor DU 406 and the IAB-donor CU 407; an F1-C 413 is established between the DU of the IAB-node 405 and the CU-CP of the IAB-donor CU 407; and an F1-U1 614 is established between the DU of the IAB-node 405 and the CU-UP of the IAB-donor CU 407, as shown in FIG. Figure 4A The tunnel connection for F1 412 may be redirected to the tunnel connection for F1 415 between IAB-donor DU 408 and IAB-donor 409. Similarly, F1-C 413 and F1-U1 414 may be redirected to F1-C 416 and F1-C 417, as shown. Figure 4B shown.

[0086] In some embodiments, topology adaptation may also include the release of old routes / resources. Figure 4B In the illustrated embodiment, the following routes / resources are released: Adaptation route A 411 for tunnel connections of F1 412 , F1 -C 413 , and F1 -U1 414 .

[0087] In RRC_CONNECTED mode, the WTRU may measure multiple beams of a cell and the measurements (i.e., power values) may be averaged to derive the cell quality. The WTRU may be configured to consider a subset of the detected beams. Filtering may be done at two different layers: (1) deriving beam quality at the physical layer and (2) deriving cell quality from multiple beams at the RRC layer. Cell quality from beam measurements may be derived in the same way for serving and non-serving cells. The measurement report may contain measurements of the X best beams if the WTRU is configured to do so by the gNB.

[0088] The measurement report configuration may be event-triggered or periodic. If the measurement report is periodic, the WTRU may send a measurement report at every reporting interval. For example, the range may be between 120 ms and 30 minutes.

[0089] For event triggered measurements, the WTRU may send a measurement report when the conditions associated with the event are met. The WTRU may continue to measure the serving cell and neighbor cell reporting quantities and validate the reporting quantities using the thresholds or offsets defined in the reporting configuration. The reporting quantities for the triggering event may be RSRP, RSRQ or SINR.

[0090] The following intra-RAT measurement events may be defined for NR: (1) event A1; (2) event A2; (3) event A3; (4) event A4; (5) event A5; and (6) event A6.

[0091] In event A1, the serving cell becomes better than a threshold. Event A1 may be used to cancel an ongoing handover procedure. This may be desired if the WTRU moves towards a cell edge and triggers a mobility procedure, but then moves back into good coverage before the mobility procedure has completed.

[0092] In event A2, the serving cell becomes worse than a threshold. Since event A2 does not involve any neighbor cell measurements, event A2 is usually used to trigger blind mobility procedures, or the network may configure the WTRU for neighbor cell measurements when it receives a measurement report triggered due to event A2 in order to save the WTRU battery (i.e., not performing neighbor cell measurements when the serving cell quality is good enough).

[0093] In event A3, the neighboring cell becomes better offset than the special cell (SpCell). Event A3 can be used for handover process. Note that SpCell is the primary serving cell (i.e. PCell) of the master cell group (MCG) or the primary serving cell (i.e. PSCell) of the secondary cell group (SCG). Therefore, in DC operation, the secondary node (SN) can be configured with the A3 event for SN-triggered PSCell change.

[0094] In event A4, the neighbor cell becomes better than a threshold. Event A4 may be used for handover procedures that do not rely on the coverage of the serving cell (eg, load balancing, where the WTRU is handed over to a good neighbor cell even if the serving cell condition is excellent).

[0095] In event A5, SpCell becomes worse than threshold-1, and the neighboring cell becomes better than threshold-2. Similar to event A3, event A5 is generally used for handover, but unlike event A3, it provides a handover trigger mechanism based on absolute measurements of the serving and neighboring cells, while event A3 uses relative comparisons. Thus, it is suitable for time-critical handovers when the serving cell becomes weak and it is necessary to change towards another cell that may not meet the criteria for event A3 handover.

[0096] In event A6, the neighbor cell becomes better offset than the SCell. Event A1 is for SCell addition / release.

[0097] Event B1 and Event B2 are defined for inter-RAT measurements in NR. In event B1, the inter-RAT neighbor cell becomes better than a threshold. Event B1 is equivalent to event A4, but for the case of inter-RAT handover. In event B2, the PCell becomes worse than a threshold -1, and the inter-RAT neighbor cell becomes better than a threshold -2. Event B1 is equivalent to A5, except for the case of inter-RAT handover.

[0098] The WTRU's measurement configuration may contain an s-MeasurementConfig that specifies a threshold for NR SpCell RSRP measurement control when the WTRU is required to perform measurements on non-serving cells. This value may be a threshold corresponding to the RSRP of the PCell or the RSRP of the PSCell. If the measured PCell RSRP is above the s-MeasurementThreshold, the WTRU will not perform measurements on non-serving cells, which improves WTRU power consumption (i.e., if the WTRU has very good radio conditions towards the serving cell, it does not perform unnecessary measurements).

[0099] Although the rel-17 work on IAB enhancements is specifying signaling enhancements to optimize the migration of IAB nodes from one donor to another, this is all done under the assumption that the migration of IAB nodes is being performed for load balancing or handling undesired RLF, not mobility. A problem arises if the IAB nodes support full mobility (e.g., deployed on a fast-moving vehicle).

[0100] One problem is ping-pong switching of bystander WTRUs outside the vehicle. For example, a WTRU near a bus / train station connects to a mobile IAB node on the bus / train and immediately becomes disconnected.

[0101] The second problem is ping-pong handover of WTRUs within a vehicle. For example, when a train passes another train or stops temporarily at a station, the WTRU temporarily connects to a cell outside the mobile IAB node.

[0102] A third problem is that a mobile or stationary IAB node may temporarily connect to a mobile IAB node and then immediately switch to another parent node.

[0103] Many of the embodiments described below are described for a WTRU or an IAB node. However, these embodiments are equally applicable to other types of nodes or devices, such as a conventional WTRU, or a sidelink WTRU acting as a WTRU-to-WTRU relay or a WTRU-to-NW relay (e.g., via a sidelink). Unless otherwise stated, embodiments described for a WTRU may also be applicable to an IAB node served by another IAB node.

[0104] A direct descendant or child node of a particular node may be an IAB node / WTRU that is directly connected to the IAB node (e.g., a mobile terminal or node served by the IAB node). In a multi-hop scenario, a given IAB node may indirectly serve a node / WTRU if the node / WTRU is not directly connected to the IAB node but the UL / DL traffic of the node / WTRU must traverse the given IAB node before reaching the node / WTRU (in the UL direction) or the donor node (in the DL direction). The general term "descendants" may be used to refer to all nodes / WTRUs served by an IAB node, directly or indirectly.

[0105] In the following description, the term "mobile cell" may be used to describe a cell belonging to a mobile IAB node (i.e., an IAB node containing both MT and DU parts) capable of mobility or any network node (e.g., a full gNB, a DU part of a gNB operating under a CU-DU split architecture, a relay node, etc.). In some conditions, the implementation may even be applicable to non-mobile network nodes if similar behavior is desired. One such condition may be a scenario where the WTRU is stationary for a long duration.

[0106] An IAB node may be configured to indicate whether it supports mobility. An IAB node may indicate whether mobility is supported to the WTRU and other IAB nodes it is serving in one or more of the following methods as described below.

[0107] An IAB node may indicate whether it supports mobility by using a new information element (IE) broadcasted in the system information about the DU of the IAB node. For example, "0" may indicate a static IAB node and "1" may indicate a mobile IAB node (or vice versa). For another example, the absence of a flag in the SI may indicate a static IAB node, and the presence of a flag may indicate a mobile IAB node (or vice versa).

[0108] The IAB node may indicate whether it supports mobility from one IAB node to another IAB node. For example, the IAB node may send a WTRU information request to another IAB node that it is currently serving to request its mobility support. For another example, the IAB node may send a WTRU assistance information message including the mobility support of the IAB node to the parent IAB node.

[0109] A node may indicate whether it supports mobility by broadcasting a new SIB specifically associated with the system information for mobile IAB nodes. For example, a static IAB node may not broadcast / support a specific SIB (e.g., SIBx), while a mobile IAB node may broadcast / support such a SIB.

[0110] The WTRU or IAB node may be configured with respect to mobility support of the IAB node. In one embodiment, the WTRU or IAB may provide an implicit indication. For example, the WTRU or IAB node may be configured with a physical cell ID (PCI) or cell global identifier (CGI) that falls within a given range (e.g., PCI x to y corresponds to a mobile cell, or PCI a to d belongs to a static cell, etc.). As another example, the WTRU or IAB node may be configured with a given range of operating frequencies (e.g., a mobile cell is configured to operate on a frequency range of x to y).

[0111] In one embodiment, there may be an on-demand request from the WTRU or IAB node. For example, the WTRU or IAB node may send a request (e.g., a mobility support capability request) to the IAB node, and the IAB node may send a response to the WTRU regarding whether it supports mobility.

[0112] The mobility support indication may be more granular than a "yes / no" indication. For example, "0" may indicate a static IAB node, "1" may indicate an IAB node that can move at a low speed, "2" may indicate a node that can move at a medium speed, and "3" may indicate a node that can move at a high speed. Additional values ​​may provide additional indications.

[0113] The IAB node may also be configured to indicate its current mobility state (ie, currently static or mobile).Any of the above mechanisms for indicating mobility support may also be used to indicate the current mobility state of the IAB node.

[0114] In one embodiment, the current mobility state indication may be more granular than merely an indication of whether the IAB node is currently static or mobile. For example, one or more of the following additional pieces of information may be included: (1) a more granular flag, where "0" indicates a static IAB node, "1" indicates a slow-moving node, "2" indicates a node moving at a moderate level, "3" indicates a high-speed IAB node, etc.; (2) direction of movement (e.g., south to north, east to west, final destination, etc.); (3) speed information (e.g., current speed, average speed, etc.); (4) next stop / station name or coordinates; (5) a list of upcoming stop names or coordinates (possibly including the duration of the stop time at each station); (6) time to arrive at the next stop / station (incremental or exact clock time) (or a detailed schedule of stations and arrival / departure times); and (7) expected time before mobility stops (if the current state is mobile) or resumes (if the current state is static). Additional values ​​may provide additional indications.

[0115] In one embodiment, the WTRU may be configured to avoid performing any neighbor cell measurements when being served by a cell belonging to a mobile IAB node (eg, as determined by the WTRU using any of the above embodiments for indicating mobility support or current mobility state).

[0116] In one embodiment, the WTRU may be configured to avoid performing any neighbor cell measurements when being served by a cell that is currently moving and / or moving fast (e.g., as determined by the WTRU using any of the above embodiments for indicating mobility state).

[0117] In one embodiment, a mobile cell may broadcast information about whether a WTRU or other IAB node connected to it should perform neighbor cell measurements. For example, a value of "1" or no broadcast indication may indicate that neighbor cells should be measured, while a value of "0" may indicate that neighbor cell measurements should not be performed.

[0118] In one embodiment, the WTRU may be configured to avoid performing any neighbor cell measurements from the time it is handed over to a mobile cell.

[0119] In one embodiment, the WTRU may be configured to perform neighbor cell measurements for a certain period of time after being handed over to a mobile cell and then stop measuring if it is still connected to the same mobile cell. The period of time may be configurable.

[0120] In one embodiment, the WTRU may be configured to perform neighbor cell measurements only after a certain period of time after handover to a mobile cell. This period of time may be configurable.

[0121] Combinations of the above embodiments are also possible. For example, the WTRU may be configured to have a first time (T1) and a second time (T2). Each time may correspond to the time to stop and start neighbor cell measurements. The WTRU may perform neighbor measurements for T1 seconds after being handed over to the mobile IAB cell, may stop performing measurements for T2 seconds, and may start performing measurements thereafter. The two thresholds may be absolute duration values, or they may be specified from the time the handover is completed.

[0122] For example, in the first case, if T1 is 5 seconds and T2 is 30 seconds, the WTRU may interpret this to mean that after handover to a mobile IAB cell, the WTRU should continue to perform measurements for 5 seconds, and after that time has passed, if it is still connected to the same cell, stop performing measurements for 30 seconds, and resume measurements after that (i.e., 35 seconds from the handover). In the latter case, the WTRU may stop performing measurements 30 seconds from the handover (i.e., the WTRU will not perform measurements for only 25 seconds).

[0123] In one embodiment, the WTRU may be configured with an absolute time value (eg, at 14:35:30) for when to stop and / or start measurements, rather than a time period value from being handed over to the mobile IAB node.

[0124] In one embodiment, the WTRU may be configured to apply similar behavior as described above when starting / stopping neighbor cell measurements based on a change in the mobility state of the current serving cell to which it is connected. For example, when the mobility state of the serving cell changes from mobile to static and / or from high speed to low speed, the WTRU may start performing neighbor cell measurements. For another example, when the mobility state of the serving cell changes from static to mobile and / or from low speed to high speed, the WTRU may stop performing neighbor cell measurements.

[0125] The time period-based control of stopping and / or starting neighbor cell measurements after switching to a mobile IAB cell described in the above embodiments may also be applied to situations where the mobility state of the WTRU changes when connected to a mobile cell. For example, the WTRU may be configured to continue performing neighbor cell measurements for T1 seconds after the mobility state of the serving cell changes from static to mobile, stop performing measurements for T2 seconds, and then resume measurements.

[0126] In one embodiment, the WTRU may be configured to start performing neighbor cell measurements when a radio link failure or handover failure is detected, or when being handed over to a non-mobile (fixed) cell (if it is currently connected to a mobile cell and not performing measurements).

[0127] In one embodiment, the WTRU may be provided with a schedule indicating when to start / stop performing neighbor cell measurements when connected to a mobile cell. For example, the schedule may be received from the network in a dedicated configuration, the stop / start schedule of the mobile cell may be read from the cell's system information broadcast, and / or provided from a higher layer or third party application such as a bus / train trip planner.

[0128] In one embodiment, the WTRU may be configured to start or stop performing neighbor cell measurements based on its current location when connected to a mobile cell. For example, the WTRU may be provided with coordinates or a range of coordinates at which to start / stop neighbor cell measurements. As another example, the WTRU may obtain information about the location of stops on the path of the vehicle (e.g., in a dedicated configuration, system information broadcast by a mobile cell, a third-party trip planning application, etc.), and may avoid measuring neighbor cells based on this information (e.g., at the location where the vehicle is moving, until a certain number of meters before reaching the next stop, a certain number of meters after leaving the current stop, a certain duration before the next stop, where the duration is calculated / estimated based on the current WTRU / vehicle speed, etc.). As another example, the WTRU may be configured with zones or areas defined based on coordinates, where the zone number may be determined by a modulo operation of the WTRU coordinates and one or more parameters configured by the network, and may be configured to perform neighbor cell measurements only in a subset of such zones.

[0129] In one embodiment, the WTRU may be configured to start / stop neighbor cell measurements based on the amount of change in the WTRU's serving cell measurements. For example, the WTRU may be configured with a first threshold change in the reference signal received power (RSRP) of the serving cell. If the measurement of the serving cell changes (increases or decreases) by an amount greater than the threshold, the WTRU may start neighbor cell measurements. The WTRU may be further configured to stop neighbor cell measurements based on the amount of change in the WTRU's serving cell measurements and a time period. For example, if the change in the serving cell measurement at the WTRU is below a threshold for at least a configured time T, the WTRU may stop neighbor cell measurements. The change in the serving cell measurement may be determined as the difference between two subsequent RSRP measurements, or as the difference between RSRP measurements separated by a configured time period.

[0130] In one embodiment, the WTRU may be configured to use different S-measurement values ​​when connected to a mobile cell. In one embodiment, the WTRU may be configured with an S-measurement threshold that is specifically used when the WTRU is connected to a cell belonging to a mobile IAB node. For example, the WTRU may be configured with an S-measurement threshold of 1 that is used when the WTRU is connected to a static cell (as in legacy LTE / NR) and another S-measurement threshold of 2 that is used when the WTRU is connected to a mobile cell.

[0131] In one embodiment, the WTRU may be configured with an S-measurement scaling factor for scaling the S-measurement value up / down when the WTRU is connected to a mobile cell.

[0132] In one embodiment, the WTRU may be configured with a list of S-measurement thresholds (or scaling factors) that are specific to a particular or a group of mobile cells. For example, the S-measurement value or scaling factor may be associated with a given mobile cell (e.g., based on the PCI or CGI). As another example, the S-measurement value or threshold may be associated with a group of mobile cells (e.g., cells belonging to the same gNB as can be determined from the CGI, cells operating within a given frequency or frequency range, cells moving at high speed, etc.).

[0133] In one embodiment, the S-measurement threshold used when connected to a mobile cell may be the same as the S-measurement threshold used for static cells, but an offset or scaling value may be used that will modify the L3 filter parameters / coefficients / times used for S-measurement related measurements and evaluations. The same offset or scaling value may be used for all mobile IAB cells, or it may be specific to a given or set of IAB nodes (e.g., an explicit list of cells, dependent on operating frequency, dependent on speed, etc.).

[0134] In one embodiment, the S-measurement threshold or scaling factor used when connected to a mobile cell may only apply for a certain configurable duration after the WTRU switches to the mobile cell (e.g., provided in the RRC reconfiguration message containing the handover command). After this duration has elapsed, the WTRU may start using the S-measurement value for the static cell (or stop applying the scaling factor if a mechanism is employed).

[0135] In one embodiment, the S-measurement threshold or scaling factor used when connected to a mobile cell may only apply for a certain configurable duration after the mobility state of the serving cell changes (e.g., the mobility state changes from static to mobile). After this duration has elapsed, the WTRU may start using the S-measurement value for static cells (or stop applying the scaling factor if a mechanism is employed).

[0136] In one embodiment, the S-measurement threshold or scaling factor used when connected to a mobile cell may depend on the current location of the WTRU. For example, the WTRU may be provided with coordinates or coordinate ranges at which to start / stop using the S-measurement threshold or scaling factor for the mobile cell. As another example, the WTRU may obtain information about the location of stops on the vehicle's path (e.g., in a dedicated configuration, system information broadcast by the mobile cell, a third-party trip planning application, etc.), and may use the mobile cell-related S-measurement threshold or scaling factor based on this information (e.g., at the location where the vehicle is moving, a certain number of meters until the next stop, a certain number of meters after leaving the current stop, a certain duration until the next stop, where the duration is calculated / estimated based on the current WTRU / vehicle speed, etc.).

[0137] In one embodiment, the WRTU may be configured to perform relaxed neighbor cell measurements when connected to a mobile cell. The above embodiments for starting / stopping neighbor cell measurements may be applied to embodiments where the WTRU will perform measurements in a relaxed manner instead of stopping neighbor cell measurements. For example, for a specific duration / location or based on a broadcast indication from the current serving cell, the WTRU may apply a longer measurement period, reducing the number of measurement samples to be taken, instead of stopping measurements completely.

[0138] In one embodiment, a gradual measurement stop may be performed. In a gradual measurement stop, the WTRU may first perform measurement relaxation and then stop measurement. For example, after switching to a mobile IAB cell, the WTRU may be configured to perform normal neighbor cell measurements during time period T1, perform relaxed neighbor cell measurements during time period T2, stop neighbor cell measurements during time period T3, start performing relaxed neighbor cell measurements during time period T4, then start performing normal neighbor cell measurements, etc.

[0139] In one embodiment, a mobile cell may broadcast information about whether a WTRU or other IAB node connected to it should perform relaxed neighbor cell measurements (e.g., a value of 1 or no broadcast indication indicates that neighbor cells should be measured in a normal manner, a value of 0 indicates that neighbor cell measurements should be performed in a relaxed manner).

[0140] In one embodiment, in addition to the S-measurement for the mobile cell, an additional S-measurement may be specified, such as a threshold. When the signal of the serving cell is above the threshold, the WTRU may perform neighbor cell measurements in a relaxed manner. When the signal of the serving cell drops below the threshold, the WTRU may start performing neighbor cell measurements normally.

[0141] It should be noted that all the above-mentioned implementations for starting / stopping measurements (location-based, absolute time-based, WTRU mobility state change-based, etc.) may be replaced or extended with implementations based on measurement relaxation.

[0142] In one embodiment, all of the above embodiments for starting / stopping / relaxing neighbor cell measurements are applied to measurements related to the current serving cell. For example, the WTRU may be configured to perform relaxed serving cell measurements based on one or more of the following: (1) information broadcast by the serving cell (e.g., a value of 1 or no broadcast indication indicates that the serving cell measurement will be performed normally, a value of 0 indicates that the serving cell measurement will be performed in a relaxed manner); (2) time information (the duration of starting and stopping the relaxed measurement after the cell's HO or mobility state changes, the absolute time of starting / stopping the relaxed measurement, etc.); (3) current location information; and (4) serving cell signal threshold (e.g., if the current serving cell signal strength / quality drops below a certain threshold for a given time, revert to normal serving cell measurement, if it is above a certain threshold for a given time, start performing relaxed serving cell measurement, etc.).

[0143] In one embodiment, instead of serving cell measurement relaxation, the WTRU may be configured to avoid performing measurements even on the serving cell based on any of time, location, mobility state information, etc. It should be noted that the serving cell measurements referred to here are only related to RRM measurements used for mobility, and thus L1 measurements used for radio link monitoring and scheduling are not affected.

[0144] All of the above embodiments for starting / stopping / relaxing neighbor or serving cell measurements may be applied to embodiments where the WTRU keeps performing measurements normally but will not send measurement reports. For example, the WTRU may avoid sending measurement reports for a specific duration / location or based on a broadcast indication from the current serving cell.

[0145] In one embodiment, the configuration of not sending measurement reports is applied to any measurement reports regardless of the way the measurement reports are triggered (eg, periodic measurement reports, event-triggered measurement reports based on absolute or relative thresholds).

[0146] In one embodiment, the configuration for not sending measurement reports may be specific to the manner in which the measurement reports are triggered (e.g., instead of sending periodic measurement reports, event-triggered measurement reports are sent, or vice versa, event-triggered measurement reports based on absolute thresholds are sent, while those based on relative thresholds are not sent, or vice versa, etc.).

[0147] The WTRU may be configured to perform and evaluate measurements on neighboring cells differently when connected to a mobile cell than when connected to other cells (eg, static cells).

[0148] In one embodiment, the WTRU is configured to adjust the trigger time (TTT) value used to determine the condition for measurement reporting configuration (e.g., A3 event) or conditional handover (CHO) configuration (e.g., conditional A3 event that triggers CHO) when connected to a cell that belongs to a mobile IAB (or / and they are currently mobile). For example, the WTRU may be configured with a TTT scaling factor greater than 1 to be applied when connected to a mobile cell. In this way, the WTRU will only report measurements on neighboring cells (or perform CHO towards them) when the radio conditions have been met for a considerable period of time, thereby preventing unnecessary ping-pong handovers (e.g., a WTRU in a train / bus is temporarily handed over to a cell that does not belong to an IAB node installed on the train / bus at a train / bus station).

[0149] In one embodiment, the WTRU may be configured to adjust the value of the offset, hysteresis or threshold used to determine the conditions for measurement reporting configuration (e.g., A3 event) or CHO configuration (e.g., conditional A3 event that triggers CHO) when connected to a cell belonging to a mobile IAB (or / and they are currently mobile). For example, the WTRU may be configured with a hysteresis scaling factor to be applied when connected to a mobile cell. In this way, the WTRU will only report measurements about neighboring cells (or perform CHO towards them) when the radio conditions towards the neighboring cells are significantly better than the current mobile serving cell, thereby preventing unnecessary ping-pong handovers (e.g., a WTRU in a train / bus is temporarily switched to a cell that does not belong to an IAB node installed on the train / bus at a train / bus station). Different scaling factors may be configured for / applied to hysteresis, offsets and thresholds.

[0150] In one embodiment, instead of a scaling factor for TTT or offset / hysteresis / threshold, a delta value to be added / subtracted may be specified.

[0151] In one embodiment, the WTRU may apply the same scaling factor or increment value when connected to any mobile cell.

[0152] In one embodiment, the scaling factor or delta value applied by the WTRU is specific to the cell of a particular mobile IAB node.

[0153] In one embodiment, the scaling factor or increment value may be specific to cells belonging to a particular set of mobile cells that meet a given criterion. For example, a scaling factor may be applied when served by a cell of a slow-moving IAB node compared to a cell of a fast-moving IAB node.

[0154] In one embodiment, similar to the above embodiments for starting / stopping / relaxing neighbor cell measurements or reporting measurements, the adjustment of the scaling factor or delta value (for TTT, offset, threshold, etc.) to be applied may depend on several factors, such as the current time, the current location of the WTRU, the trajectory of the WTRU compared to the serving mobile cell (e.g., speed, direction, etc.). In one embodiment, the scaling factor or delta value may be the same for all WTRUs in a cell / network (e.g., broadcasted in system information).

[0155] In one embodiment, the scaling factor or delta value may be specific to a given WTRU (eg, provided via dedicated signaling).

[0156] In one embodiment, the WTRU may be configured to avoid performing measurements of mobile neighboring cells (eg, as determined by the WTRU using any of the above embodiments for indicating mobility support or current mobility state).

[0157] In one embodiment, the WTRU is configured to avoid performing measurements on mobile neighbor cells that are currently moving (or / and how fast they are moving) (eg, as determined by the WTRU using any of the above embodiments for indicating mobility state).

[0158] In one embodiment, the behavior of the WTRU to avoid performing measurements on a mobile cell or / and that it is currently moving may depend on the current mobility state of the WTRU or / and the mobile cell. For example, the WTRU may be configured to avoid measuring mobile neighboring cells when the WTRU is stationary. As another example, the WTRU may be configured to avoid measuring mobile neighboring cells that are not moving in the same direction as the WTRU. As another example, the WTRU may be configured to avoid measuring mobile neighboring cells that move at speeds higher or lower than a certain threshold compared to the speed of the WTRU. As another example, the WTRU may be configured with timing information about when it should or should not measure mobile neighboring cells (e.g., a timetable specifying the time period during which the WTRU should or should not measure mobile neighboring cells). As another example, the WTRU may be configured with location information about where it should or should not measure mobile neighboring cells (e.g., a location table specifying where the WTRU should or should not measure mobile neighboring cells). As another example, the WTRU may be configured with a serving cell signal strength / quality threshold, and when the signal strength of the serving cell is above the threshold, the WTRU avoids measuring mobile neighboring cells. As another example, the IAB node may be configured to avoid measuring mobile neighboring cells. As another example, the IAB node may be configured to avoid measuring mobile neighboring cells if the IAB node itself is mobile (eg, when two trains with installed IAB nodes pass each other).

[0159] In one embodiment, the WTRU is configured to start performing mobile neighbor cell measurements (if it is not already performing measurements) upon detecting a radio link failure or a handover failure.

[0160] In one embodiment, the WTRU is configured to measure or not measure mobile neighbor cells via dedicated signaling regarding the behavior.

[0161] In one embodiment, the WTRU is configured with broadcast signaling from the current serving cell regarding the behavior of measuring or not measuring mobile neighbor cells.

[0162] All of the above embodiments for starting / stopping mobile neighbor cell measurements may be applied to embodiments where the WTRU will perform measurements in a relaxed manner instead of stopping mobile neighbor cell measurements. For example, for a specific duration / location or based on a broadcast indication from the current serving cell, the WTRU may apply a longer measurement period and / or reduce the number of measurement samples to be taken, instead of stopping measurements completely.

[0163] The above-described implementations for starting / stopping measurements of mobile neighbor cells (based on location, based on absolute time, based on WTRU mobility state change, etc.) may be replaced or extended with implementations based on measurement relaxation.

[0164] The above embodiments for starting / stopping / relaxing moving neighbor cells may be applied to embodiments where the WTRU continues to perform measurements normally but will not send measurement reports. For example, for a specific duration / location or based on a broadcast indication from the current serving cell, the WTRU may avoid sending measurement reports triggered by moving neighbor cells.

[0165] In one embodiment, the configuration to stop sending measurement reports related to mobile neighbor cells is applied regardless of how the measurement reports are triggered (e.g., periodic measurement reports related to mobile neighbor cells, measurement reports triggered by events based on absolute or relative thresholds regarding mobile neighbor cells).

[0166] In one embodiment, the configuration for stopping sending measurement reports related to mobile neighbor cells may be specific to the manner in which measurement reports are triggered (e.g., instead of sending periodic measurement reports, time-triggered measurement reports are sent, or vice versa; measurement reports triggered by events related to mobile cells and based on absolute thresholds (e.g., A4) are sent, but measurement reports triggered by those events based on relative thresholds (e.g., A3 / A5 / A6) are not sent, or vice versa, etc.).

[0167] The WTRU may be configured to perform and evaluate measurements on mobile neighbor cells differently than on other (static) neighbor cells.

[0168] In one embodiment, the WTRU is configured to adjust the TTT value used to determine the conditions for measurement reporting configuration (e.g., A3 events) or CHO configuration (e.g., conditional A3 events that trigger CHO) for cells that belong to mobile neighbor cells (or / and they are currently mobile). For example, the WTRU may be configured with a TTT scaling factor greater than 1 to be applied to all mobile neighbor cells. In this way, the WTRU will only report measurements on mobile neighbor cells (perform CHO towards them) when the radio conditions have been met for a considerable period of time, thereby preventing unnecessary ping-pong handovers (e.g., a bystander WTRU at a train / bus station connected to an IAB node installed at the train / bus).

[0169] In one embodiment, the WTRU is configured to adjust the value of an offset, hysteresis or threshold for determining a condition for a measurement reporting configuration (e.g., an A3 event) or a CHO configuration (e.g., a conditional A3 event that triggers CHO) for mobile neighbor cells (or / and they are currently mobile). For example, the WTRU may be configured with a hysteresis scaling factor to be applied to all mobile neighbor cells. In this way, the WTRU will only report measurements about a mobile neighbor cell (or perform a CHO towards it) when the radio conditions towards the mobile neighbor cell are significantly better than those of a static cell. Different scaling factors may be configured / applied for hysteresis, offsets and thresholds.

[0170] In one embodiment, instead of a scaling factor for TTT or offset / hysteresis / threshold, a delta value to be added / subtracted may be specified.

[0171] In one embodiment, the WTRU applies the same scaling factor or delta value to all mobile neighbor cell measurements.

[0172] In one embodiment, the scaling factor or delta value to be applied is cell specific for a particular mobile cell.

[0173] In one embodiment, the scaling factor or increment value may be specific to cells belonging to a specific set of mobile cells that meet a given criterion. For example, one scaling factor may be applied to cells moving at a lower speed than to cells moving at a higher speed.

[0174] In one embodiment, similar to the above-described embodiments for starting / stopping / relaxing mobile neighbor cell measurements or reporting measurements, the adjustment of the scaling factor or incremental value (for TTT, offset, threshold, etc.) to be applied may depend on several factors, such as the current time, the current location of the WTRU, the trajectory of the WTRU compared to the mobile neighbor cells (e.g., speed, direction, etc.).

[0175] In one embodiment, the scaling factor or delta value may be the same for all WTRUs in a cell / network (eg, broadcast in system information).

[0176] In one embodiment, the scaling factor or delta value may be specific to a given WTRU (eg, provided via dedicated signaling).

[0177] In one embodiment, the above-described embodiments regarding neighbor and serving cell measurements when connected to a mobile cell or mobile neighbor cell measurements (e.g., no measurement, relaxed measurements, using different parameters than used when connected to a non-mobile cell, using different parameters than used when measuring non-mobile neighbor cells, etc.) may be applied to all neighbor cells that the WTRU can detect / measure.

[0178] In one embodiment, the above embodiments may be specific to a particular neighboring cell or a set of neighboring cells. For example, the WTRU may be configured with an explicit list of neighboring cells to which the WTRU should apply modified measurement behavior (e.g., a list based on PCI or CGI) when connected to a mobile cell. As another example, the WTRU may be configured to apply modified measurement behavior to a set of neighboring cells based on criteria (e.g., cells belonging to the same gNB as can be determined from the CGI, cells operating within a given frequency or frequency range, inter-RAT cells, mobile neighboring cells, etc.).

[0179] Figure 5 is a flow chart illustrating an exemplary process performed between a serving cell, a neighboring cell, and a WTRU. Figure 5 As shown, the serving cell 502 and the neighboring cell 504 may transmit configuration information, including measurement behavior information. The configuration information may depend on the mobility state of the neighboring cell and the serving cell. Based on the received configuration information, the WTRU may perform measurements according to the neighboring cell and the serving cell measurement behavior information. The WTRU may perform measurements according to the neighboring cell and the serving cell measurement behavior corresponding to the mobility state of the neighboring cell and the serving cell. The measurement may include at least one of the following: (1) starting or stopping performing neighboring cell measurements or serving cell measurements; (2) starting or stopping sending neighboring cell measurement reports or serving neighboring cell measurement reports; (3) performing the measurement in a relaxed manner; and (4) applying different parameters for measurement evaluation.

[0180] Relaxing the measurement may include (1) applying a longer measurement period and / or (2) reducing the number of measurement samples taken. Relaxing the measurement may occur in a gradual manner. Additionally, application of different parameters for the measurement values ​​may include (1) different time to trigger (TTT) values ​​and / or (2) different hysteresis values.

[0181] The start or stop of performing neighbor cell measurements may be based on the location of the WTRU. The start of performing neighbor cell measurements may occur after the mobility state of the serving cell changes from mobile to static. The stop of performing neighbor cell measurements may occur after the mobility state of the serving cell changes from static to mobile. The start of performing neighbor cell measurements may occur after the mobility state of the neighbor cell changes from mobile to static. The stop of performing neighbor cell measurements may occur after the mobility state of the neighbor cell changes from static to mobile.

[0182] The above-mentioned embodiments propose the behavior of the WTRU in connected mode, mainly focusing on the measurement of neighboring cells and serving cells when connected to a mobile cell or the measurement of mobile neighboring cells (for example, no measurement, relaxed measurement, using parameters different from those used when connected to a non-mobile cell, using parameters different from those used when measuring non-mobile neighboring cells, etc.).

[0183] All embodiments are equally applicable to WTRUs in idle mode that are simply camped on a mobile cell. For example, the WTRU may modify the behavior of performing neighbor cell measurements when camped on a mobile cell, or may modify the behavior of performing measurements on a mobile neighbor cell, where the modification of the behavior may be to start / stop performing measurements or perform measurements in a relaxed manner for a configurable time period based on location, based on a change in signal strength / quality or relative signal strength / quality of a serving cell, etc.

[0184] Although the features and elements are described above in particular combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information from the network, wherein the configuration information includes at least one of the following: information included in the first broadcast information from the first cell; and The information included in the second broadcast information from the second cell includes at least one of a frequency layer of one or more neighboring cells and a PCI range of the one or more neighboring cells; Based on the configuration information, determining that at least one of the first cell and the neighboring cell belongs to one or more mobile IAB nodes; as well as A measurement procedure for performing measurements on the first cell or at least one of the one or more neighboring cells is modified.

2. The method according to claim 1, wherein: The first broadcast information is received in a system information broadcast (SIB).

3. The method according to claim 1, wherein: Modifying the measurement process includes at least one of: Start or stop performing neighbor cell measurement or serving cell measurement; Start or stop sending neighbor cell measurement reports or serving neighbor cell measurement reports; performing said measurements in a relaxed manner; or Different parameters were applied for the measurement evaluation.

4. The method according to claim 3, wherein: Performing the measuring in a relaxed manner includes at least one of: Applying longer measurement cycles; and Reduce the number of measurement samples taken.

5. The method according to claim 3, wherein: Applying different parameters to the measurements includes applying at least one of: Different Time To Trigger (TTT) values; and Different hysteresis values.

6. The method according to claim 3, wherein: The starting of performing neighbor cell measurements occurs after a mobility state of the first cell changes from mobile to static.

7. The method according to claim 3, wherein: The stopping of performing neighbor cell measurements occurs after a mobility state of the first cell changes from static to mobile.

8. The method according to claim 3, wherein: The initiation of performing neighbor cell measurements occurs after the mobility state of the one or more neighbor cells changes from mobile to static.

9. The method according to claim 3, wherein: The cessation of performing neighbor cell measurements occurs after the mobility state of the one or more neighbor cells changes from static to mobile.

10. The method according to claim 3, wherein: The starting or stopping of performing neighbor cell measurements is based on the location of the WTRU.

11. A wireless transmit / receive unit (WTRU), the WTRU comprising: Transceiver; as well as processor; The transceiver and the processor are configured to: Receive configuration information from the network, wherein the configuration information includes at least one of the following: information included in the first broadcast information from the first cell; and The information included in the second broadcast information from the second cell includes at least one of a frequency layer of one or more neighboring cells and a PCI range of the one or more neighboring cells; Based on the configuration information, determining that at least one of the first cell and the neighboring cell belongs to one or more mobile IAB nodes; as well as A measurement procedure for performing measurements on the first cell or at least one of the one or more neighboring cells is modified.

12. The WTRU of claim 11 wherein: The first broadcast information is received in a system information broadcast (SIB).

13. The WTRU of claim 11 , wherein: Modifying the measurement process includes at least one of: Start or stop performing neighbor cell measurement or serving cell measurement; Start or stop sending neighbor cell measurement reports or serving neighbor cell measurement reports; performing said measurements in a relaxed manner; or Different parameters were applied for the measurement evaluation.

14. The WTRU of claim 13 wherein: Performing the measuring in a relaxed manner includes at least one of: Applying longer measurement cycles; and Reduce the number of measurement samples taken.

15. The WTRU of claim 13 wherein: Applying different parameters to the measurements includes applying at least one of: Different Time To Trigger (TTT) values; and Different hysteresis values.

16. The WTRU of claim 13 wherein: The starting of performing neighbor cell measurements occurs after a mobility state of the first cell changes from mobile to static.

17. The WTRU of claim 13 wherein: The stopping of performing neighbor cell measurements occurs after a mobility state of the first cell changes from static to mobile.

18. The WTRU of claim 13 wherein: The initiation of performing neighbor cell measurements occurs after the mobility state of the one or more neighbor cells changes from mobile to static.

19. The WTRU of claim 13 wherein: The cessation of performing neighbor cell measurements occurs after the mobility state of the one or more neighbor cells changes from static to mobile.

20. The WTRU of claim 13 wherein: The starting or stopping of performing neighbor cell measurements is based on the location of the WTRU.

Images