Side link relay cell reselection or handover and measurement

Abstract

A relay radio transmit / receive unit (WTRU) may be configured to receive information indicative of characteristic(s) associated with a remote WTRU. The relay WTRU may receive configuration information associated with the relay WTRU. The relay WTRU may determine whether the remote WTRU is supported by a neighboring cell. The determination may be based on whether the characteristic(s) associated with the remote WTRU are supported by the neighboring cell. The relay WTRU may determine a behavior of the relay WTRU based at least on the configuration information and a percentage of the remote WTRU(s) supported by the neighboring cell. The determined behavior may be associated with the neighboring cell. In an example, the determined behavior of the relay WTRU may be based on a percentage of the remote WTRU(s) supported by the neighboring cell being above or below a threshold.

Description

Technical Field

[0001] (Cross-Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 228,851 filed on August 3, 2021, the disclosure of which is incorporated herein by reference in its entirety.

Background Art

[0002] Mobile communications using wireless communication continue to evolve. The fifth generation of mobile communication radio access technology (RAT) may be referred to as 5G New Radio (NR). Previous (conventional) generations of mobile communication RAT may be, for example, fourth generation (4G) Long Term Evolution (LTE).

Summary of the Invention

[0003] Systems, methods, and means for sidelink (SL) relay cell reselection and measurement are described herein.

[0004] A relay wireless transmit / receive unit (WTRU) may receive information indicating characteristic(s) (e.g., respective characteristic(s)) associated with a remote WTRU (e.g., respective characteristic(s) of each respective remote WTRU(s)). The characteristic(s) associated with the remote WTRU may include at least one of a supported public land mobile network (PLMN), a configured radio access network (RAN) area, or a remote capability. The remote capability may include at least one of a supported frequency or a supported bandwidth.

[0005] A relay WTRU can receive configuration information associated with it. A relay WTRU can determine whether a remote WTRU (e.g., each of several WTRUs) is supported by an adjacent cell. This determination may be based on whether the characteristics (e.g., each of several WTRUs) associated with the remote WTRU (e.g., supported PLMN, configured RAN area, and / or remote capability) are supported by the adjacent cell. For example, a relay WTRU can determine that a first remote WTRU is supported by an adjacent cell if the PLMN associated with the first remote WTRU is supported by the adjacent cell. Similarly, a WTRU can determine that a second remote WTRU is supported by an adjacent cell if the capabilities of the second remote WTRU and the configured RAN area associated with the second WTRU are supported by the adjacent cell.

[0006] A relay WTRU can determine its behavior based at least on configuration information and the number / percentage of remote WTRUs supported by the neighboring cell. The determined behavior may be related to the neighboring cell. The determined behavior may be related to cell reselection or handover. For example, in cases where the neighboring cell does not support remote WTRUs associated with the relay WTRU, threshold numbers / percentages of remote WTRUs associated with the relay WTRU, etc., the determined behavior may include at least one of the following: disabling cell reselection to the neighboring cell, disabling measurement to the neighboring cell, disabling sending measurement reports triggered by the neighboring cell, or lowering the priority of measurement to the neighboring cell. The relay WTRU can perform the determined behavior in relation to the neighboring cell.

[0007] The determined behavior of a relay WTRU may be based on whether the proportion of remote WTRUs supported by the neighboring cell is above or below a threshold. In the example, the first and second neighboring cells may be available. The relay WTRU may be connected to the first neighboring cell. If the proportion of remote WTRUs supported by the first neighboring cell is below a threshold, the determined behavior of the relay WTRU may be to perform cell reselection to the second neighboring cell. If the proportion of remote WTRUs supported by the first neighboring cell is above a threshold, the determined behavior of the relay WTRU may be to perform measurement on the first neighboring cell. In the example, the received configuration information may include the first and second behaviors. The determined behavior of the relay WTRU may be either the first or the second behavior. If the proportion of remote WTRUs supported by the neighboring cell is above a threshold, the determined behavior of the relay WTRU may be the first behavior. If the proportion of remote WTRUs supported by the first adjacent cell falls below a threshold, the determined behavior of the relay WTRU may be the second behavior. [Brief explanation of the drawing]

[0008] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D]This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This document presents an example of a user plane (UP) protocol stack for new radio (NR) from the perspective of WTRU and gNB. [Figure 3] This shows an example of a control plane protocol stack for NR from the perspective of WTRU and gNB. [Figure 4] This document provides an example of a connection setup procedure for the Radio Resource Control (RRC) CONNECTED state. [Figure 5] This shows an example of how WTRU transitions from the RRC INACTIVE state to the RRC CONNECTED state. [Figure 6] This shows an example of how WTRU transitions between the RRC IDLE state, the RRC INACTIVE state, and the RRC CONNECTED state. [Figure 7] This shows an example of a user plane stake for an NR L2 WTRU-to-Network relay. Figure 8 shows an example of a control plane protocol stack for an L2 WTRU-to-Network relay. [Figure 8] This shows an example of a control plane protocol stack for L2 WTRU inter-network relays. [Figure 9] This shows an example of a relay WTRU within conventional RRC coverage connected via a Uu. [Figure 10] This shows an example of an out-of-coverage relay WTRU with RRC state signaling / maintenance entirely via a relay path. [Figure 11] An example of a relay WTRU that determines behavior in relation to adjacent cells is shown. [Figure 12] This shows an example of a served WTRU and a relay WTRU that is serviced by a relay WTRU. [Modes for carrying out the invention]

[0009] Figure 1A illustrates 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, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), Zero-Tail Unique-Word DFT-Spread OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtering OFDM, and Filter Bank Multi Carrier (FBMC).

[0010] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial radio networks, etc. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

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

[0012] Base station 114a may be part of RAN 104 / 113, which may also include other base station and / or network elements (not shown), such as a Base Station Controller (BSC), Radio Network Controller (RNC), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectra, unlicensed spectra, or combinations of licensed and unlicensed spectra. Cells may provide coverage of radio services to a particular geographic area that may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, the base station 114a may use 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.

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

[0014] More specifically, as described 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, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0015] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies 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).

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

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

[0018] 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), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

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

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

[0021] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

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

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

[0024] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a Digital Signal Processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of Integrated Circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Figure 1B depicts the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

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

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

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

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

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

[0030] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

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

[0032] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., transmission) and downlink (e.g., reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with specific subframes for either uplink UL (e.g., transmission) or downlink (e.g., reception)).

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

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

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

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

[0037] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

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

[0040] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

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

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

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

[0045] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

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

[0048] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, a large portion of the frequency band may remain idle and could be considered busy, even if it were available.

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

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

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

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

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

[0054] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, etc. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

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

[0056] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c within RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may perform roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0058] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN113, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

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

[0061] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial radio communication.

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

[0063] Systems, methods, and means for reselecting and measuring side-link (SL) relay cells are described herein.

[0064] A relay radio transmitter / receiver unit (WTRU) can receive information relating to a remote WTRU and its associated characteristics (e.g., each characteristic(s)) (e.g., each characteristic(s) of each remote WTRU(s)). The characteristics relating to a remote WTRU may include at least one of the following: a supported public land mobile network (PLMN), a configured radio access network (RAN) area, or remote capability. Remote capability may include at least one of the following: a supported frequency or a supported bandwidth.

[0065] A relay WTRU can receive configuration information associated with the relay WTRU. The relay WTRU can determine whether a remote WTRU (e.g., each of several WTRUs) is supported by an adjacent cell. This determination may be based on whether the characteristics (e.g., each of several WTRUs) associated with the remote WTRU (e.g., each of several WTRUs) are supported by the adjacent cell. For example, the relay WTRU may determine that a first remote WTRU is supported by an adjacent cell if the PLMN associated with the first remote WTRU is supported by the adjacent cell. Similarly, the WTRU may determine that a second remote WTRU is supported by an adjacent cell if the capabilities of the second remote WTRU and the configured RAN area associated with the second WTRU are supported by the adjacent cell.

[0066] A relay WTRU can determine its behavior based at least on configuration information and the percentage of remote WTRUs supported by the neighboring cell. The determined behavior may be related to the neighboring cell. The determined behavior may be related to cell reselection or handover. For example, if the neighboring cell does not support the number of remote WTRUs associated with the relay WTRU, the threshold number / percentage of remote WTRUs associated with the relay WTRU, etc., the determined behavior may include at least one of the following: disabling cell reselection to the neighboring cell, disabling measurement to the neighboring cell, disabling sending measurement reports triggered by the neighboring cell, or lowering the priority of measurement to the neighboring cell. The relay WTRU can perform the determined behavior related to the neighboring cell.

[0067] The determined behavior of a relay WTRU may be based on whether the proportion of remote WTRUs supported by the neighboring cell is above or below a threshold. In the example, the first and second neighboring cells may be available. The relay WTRU may be connected to the first neighboring cell. If the proportion of remote WTRUs supported by the first neighboring cell is below a threshold, the determined behavior of the relay WTRU may be to perform cell reselection to the second neighboring cell. If the proportion of remote WTRUs supported by the first neighboring cell is above a threshold, the determined behavior of the relay WTRU may be to perform measurement on the first neighboring cell. In the example, the received configuration information may include the first and second behaviors. The determined behavior of the relay WTRU may be either the first or the second behavior. If the proportion of remote WTRUs supported by the neighboring cell is above a threshold, the determined behavior of the relay WTRU may be the first behavior. If the proportion of remote WTRUs supported by the first adjacent cell falls below a threshold, the determined behavior of the relay WTRU may be the second behavior.

[0068] A relay WTRU may be configured to receive information regarding PLMN support, RAN area configuration, and WTRU capability of served WTRUs (e.g., remote WTRUs or child relay WTRUs). A WTRU may be configured to transmit information regarding PLMN support, RAN area configuration, and WTRU capability to these serving relay WTRUs. A relay WTRU may be configured to consider PLMN support, RAN area configuration, WTRU capability, or a combination of these features in order to perform at least one of cell reselection, measurement, or measurement reporting. A relay WTRU may be configured not to perform measurement for cell reselection or handover on a given adjacent cell if the cell in question does not support a particular configuration ratio of directly or indirectly served / remote WTRUs. In the example, a cell may be considered supported by a given WTRU if the cell has a PLMN supported by the served / remote WTRU, if the cell is within the configured RAN area of ​​the served / remote WTRU, or if the cell matches the served / remote WTRU capability. A relay WTRU may be configured to modify the measurement for cell reselection or handover (e.g., scaling the signal level of the neighboring cell during comparison with an absolute threshold, applying a specific offset when comparing with the serving cell) depending on a configurable threshold associated with the level or percentage of the served / remote WTRU supported by the neighboring cell. A relay WTRU may be configured not to transmit measurement reports triggered by the achievement of measurement reporting conditions associated with a given neighboring cell. The achievement of measurement reporting conditions may depend on a configurable threshold associated with the level or percentage of the served WTRU(s) (e.g., remote WTRU(s)) supported by the neighboring cell. A relay WTRU may be configured to transmit RAN area (e.g., group RAN area) update information regarding a served WTRU(or more) (e.g., remote WTRU(or more)).A relay WTRU may be configured to delay individual RAN area update messages from a served WTRU (e.g., a remote WTRU) according to specified settings (e.g., until a certain number of individual RAN area updates are received or detected by the relay WTRU, until a certain amount of time has elapsed since the last group RAN update, or until the next periodic RAN area update of the relay WTRU itself).

[0069] A relay WTRU can receive information about the PLMN, RAN area, or WTRU capabilities of a served / remote WTRU (for example, directly) and forward that information to the parent relay WTRU. The relay WTRU can apply modified measurement and cell reselection behavior that takes into account the served WTRU capabilities / support / configuration and the characteristics / configuration of adjacent cells.

[0070] An SL relay WTRU may be configured to determine whether to perform measurements on adjacent cells for cell reselection or handover. An SL relay WTRU may be configured to change how measurements or measurement reports are performed (e.g., prioritizing / de-prioritizing certain cells, scaling up / down adjacent cell measurements during comparison with absolute or relative thresholds compared to the serving cell). The decision to perform measurements may be based on considerations of the capabilities (e.g., supported frequencies, bandwidth, etc.) and configuration (e.g., supported PLMN, RAN area configuration, etc.) of the served WTRU (e.g., remote WTRUs and relay WTRUs that may be serviced directly or indirectly by the relay WTRU), as well as the configuration or characteristics of the adjacent cells.

[0071] A relay WTRU can receive information about the served WTRU (e.g., from a remote WTRU, from a gNB, from a child relay WTRU providing services to the remote WTRU), supported PLMNs, RAN area-related information (e.g., INACTIVE, of the served WTRU or child relay WTRU), or one or more of the WTRU capabilities. The relay WTRU may be configured to forward information about the served WTRU (e.g., the information described above) to the parent relay WTRU. The relay WTRU can receive settings (e.g., from a gNB) regarding behaviors related to cell reselection, measurement, and measurement reporting. These behavioral settings may depend on the served WTRU's support for adjacent cells. The served WTRU may assume that an adjacent cell supports an adjacent cell if one or more of the following conditions are met: the adjacent cell supports a PLMN (or more) supported by the WTRU, the adjacent cell is within the WTRU's configured RAN area, or the WTRU can operate within the adjacent cell (e.g., supported frequency, bandwidth, etc.). Settings for behavior regarding cell reselection, measurement, and measurement reporting may include disabling measurement to adjacent cells for cell reselection, disabling cell reselection to adjacent cells, disabling performing measurements to adjacent cells for Radio Resource Management (RRM), or disabling sending measurement reports that may be triggered by the fulfillment of measurement reporting conditions associated with adjacent cells (e.g., if less than a specified percentage of served WTRU supports the adjacent cell in question); or lowering the priority of measurements for cell reselection or RRM to adjacent cells, which may include scaling up or down thresholds or offsets to the measured signal level or quality of adjacent cells based on the percentage of served WTRU that supports or does not support the cell in question; or considering an adjacent cell with more support from served WTRU as a preferred cell for cell reselection or handover, compared to another cell with better radio conditions than the first cell, unless the former is worse than the latter by a specified threshold.

[0072] A relay WTRU can perform cell reselection or receive a command from a gNB to perform a handover (HO) to a cell not supported by the served WTRU (e.g., a remote WTRU). An SL relay WTRU may be configured to notify the served WTRU about cell reselection or a handover to a cell not supported by a given served WTRU (e.g., a remote WTRU). A relay WTRU can receive information about one or more of the following: the served WTRU (e.g., from a remote WTRU, from a gNB, from a child relay WTRU serving the remote WTRU), supported PLMNs, RAN area-related information (of the served WTRU or child relay WTRU, inactive), or WTRU capabilities. A relay WTRU can perform a handover to a target cell or cell reselection. If a relay WTRU determines that the served WTRU does not support the target cell (for example, the target cell has a PLMN that the WTRU does not support), it can send instructions to the served WTRU (for example, a remote WTRU) to notify the served WTRU of the change.

[0073] A relay WTRU may perform RAN area updates on behalf of multiple served WTRUs (e.g., remote WTRUs). An SL relay WTRU may be configured to notify the network about RAN area changes of one or more served WTRUs. A relay WTRU may receive RAN area-related information for served WTRUs (e.g., a list of cells in the RAN area, a periodic RAN area update timer, etc.) from (e.g., from a remote WTRU, from a gNB, from a child relay WTRU providing services to a remote WTRU). A relay WTRU may determine that a served WTRU must perform a RAN area update, and this may be based on one or more of the following: receiving instructions from the served WTRU, a decision made in the relay WTRU based on a configured timer value for the served WTRU's periodic RAN area update, or the relay WTRU determining that a target cell is outside the served WTRU's configured RAN area when performing a handover or cell reselection.

[0074] A relay WTRU can send a group RAN area update to the network, which includes RAN area update instructions for one or more served WTRUs (e.g., remote WTRUs), which may include delaying the transmission of the group RAN area update depending on configured factors (e.g., the number of served WTRUs whose RAN areas must be updated, the time elapsed since the last group RAN update, the time until the next periodic RAN area update for the relay WTRU itself, the time until the served WTRU with the most frequent RAN area update timer expires, the time until the served WTRU with the least frequent RAN area update timer expires, etc.). The relay WTRU can receive response messages from the network regarding the RAN area update message. The relay WTRU can forward the response messages to the WTRUs involved.

[0075] Examples of Radio Resource Protocols (RRCs) and their states are provided herein. Figure 2 shows an example of a user plane (UP) protocol stack for a new radio (NR) from the perspective of a WTRU and gNB. Figure 3 shows an example of a control plane protocol stack for an NR from the perspective of a WTRU and gNB. The RRC protocol may be a protocol (e.g., the main protocol) that plays a role in controlling the WTRU's connection to the network. The RRC protocol may include one or more functions (e.g., key functions) such as broadcasting system information (e.g., to enable WTRU access to cells), paging to indicate the arrival of downlink (DL) data to WTRUs, establishing, maintaining, and releasing radio connections (e.g., including carrier aggregation (CA) and dual connectivity (DC)), security functions including establishing, configuring, maintaining, and releasing security keys for signaling radio bearers (SRB) and data radio bearers (DRB), mobility functions such as handover, context transfer, cell selection, and re-selection, control of WTRU measurement and reporting, or detection and recovery from radio link failures. A powered-on WTRU may be in one of the RRC states, which is IDLE, INACTIVE, or CONNECTED.

[0076] In the RRC IDLE state, when a WTRU is first powered on, the WTRU's RRC may be in the RRC IDLE state. In the RRC IDLE state, the WTRU can prepare to receive paging (for example, for incoming voice calls, DL data reception, etc.). In the RRC IDLE state, the WTRU may not be registered in a particular cell, and therefore may not have any other information received from the Access Stratum (AS) context and the network. In the RRC IDLE state, the WTRU can perform mobility procedures (which may include cell selection and cell re-selection, for example).

[0077] Cell selection may be a procedure that allows the WTRU to select a cell to camp on (e.g., the first cell to camp on) when it is powered on or transitions from the RRC CONNECTED state to the RRC IDLE state. The WTRU may be configured with a list of PLMN identifiers to which the WTRU is registered or can access (e.g., a list of operators and operator services). There may be priorities between PLMNs (e.g., PLMN1 has a higher priority than PLMN2), or a preferred PLMN may be manually selected by the user (e.g., via the WTRU's user interface). The WTRU may be configured with a list of frequencies and radio access technologies (RATs) that the WTRU supports. Frequencies and RATs may include priorities (e.g., 5G first priority, 4G second priority). A preferred RAT may be selected by the user.

[0078] The WTRU can explore the NR frequency band. For each carrier frequency detected by the WTRU, it can identify the strongest cell. The WTRU can read the cell system information broadcast to identify its PLMN. The WTRU may attempt to identify a suitable cell. If the WTRU cannot identify a suitable cell, it may attempt to identify an acceptable cell. A suitable cell may be one whose measured cell attributes meet the cell selection criteria, whose cell PLMN is a selected PLMN, registered PLMN, or equivalent PLMN, whose cell is not excluded or reserved, and whose cell is not part of a tracking area on the list of "forbidden tracking areas for roaming". An acceptable cell may be one whose measured cell attributes meet the cell selection criteria and whose cell is not excluded. A cell may be considered to meet the cell selection criteria if its signal level and / or quality is better than a certain set threshold. If a suitable cell is found, or if an acceptable cell is found (for example, only in this case), the WTRU can camp on to that cell (which may be known as a serving cell, for example) and initiate the cell reselection procedure.

[0079] Cell reselection may be a procedure that allows a WTRU in the RRC IDLE state to change the cell it camps on if it detects an adjacent cell with better radio conditions (for example, via broadcast information of the current serving cell, or according to some specific comparison thresholds that may be set on the WTRU). The WTRU may be configured not to perform measurements on adjacent cells for cell reselection unless the radio signal level / quality of the current serving cell falls below a certain threshold (and may be configured further, for example).

[0080] A WTRU in the RRC IDLE state can monitor paging messages from the network to receive incoming voice calls or incoming data. The WTRU may be configured with WTRU identification information (e.g., paging WTRU identification information). The WTRU can check whether a paging message broadcast by the network indicates the WTRU identification information. Since continuous monitoring and decoding of the paging channel can consume power, the WTRU may be configured for discontinuous reception (DRX). The WTRU may wake up periodically (e.g., only periodically) according to a configured DRX cycle to monitor paging messages directed to it. When the WTRU detects a paging message directed to it, it can initiate a connection establishment procedure and transition to the RRC CONNECTED state.

[0081] Figure 4 shows an example of a connection setup procedure for the RRC CONNECTED state. In the RRC CONNECTED state, if the WTRU is being paged (e.g., an incoming voice call, incoming downlink data, etc.) or if the WTRU wants to initiate an uplink (UL) transmission (e.g., an outgoing voice call, access to a data service initiated by the WTRU, etc.), the RRC IDLE WTRU can initiate the connection setup procedure. The connection setup procedure may be performed as described herein.

[0082] A Signaling Radio Bearer 1 (SRB1), which may be used for signaling (e.g., control plane), may be configured to communicate with the network. A WTRU may send an RRC Connection Setup Request message (RRCSetupRequest) to the current serving cell on which the WTRU is camped. The RRCSetupRequest message may include instructions for WTRU identification information (e.g., initial WTRU identification information) and the reason for establishment (e.g., cause) (e.g., mobile outgoing voice call, mobile outgoing data call, mobile terminated access by paging, emergency, etc.). The network may respond with an RRC Connection Setup (RRCSetup) message. The RRCSetup message may include configuration information for setting up SRB1 (e.g., SRB1 PDCP (bearer) configuration, RLC, and MAC level configuration for SRB1). The WTRU may respond by sending an RRCSetupComplete message.

[0083] Connection setup procedures may include setting up security. A WTRU can receive a SecurityModeCommand message from the network. The SecurityModeCommand message may indicate to the WTRU the encryption and integrity protection algorithms to be used for communication (e.g., from there onward). Encryption can ensure that only a WTRU with the correct encryption key (e.g., only that WTRU) can properly decrypt the message. Integrity protection can ensure that no intermediate entity has tampered with the message (e.g., the message is the same as when it was sent by the sender).

[0084] The WTRU can derive a key associated with the base station (known as the KgNB key). The KgNB key may be updated when the WTRU performs connection mode mobility to another cell / gNB (e.g., each time). The KgNB key derivation may use information (e.g., additional information) such as the frequency of the target cell or the physical cell identity (PCI) of the target cell. The WTRU can derive an integrity key for the RRC (KRRCint) using the KgNB and integrity assurance algorithm indicated in the received SecurityModeCommand message. The WTRU can check the integrity of the received SecurityModeCommand message. If integrity is verified, the WTRU can proceed to derive cryptographic keys for control plane messages and user plane messages (KRRCenc and KUPenc, respectively) and an integrity key for user plane messages (KUPint) (e.g., may be set optionally). The WTRU can send a SecurityModeCommandComplete message to indicate to the network that the security setup was successful. Control plane messages (e.g., RRC messages) (e.g., all control plane messages) can be encrypted and integrity-protected using the corresponding key. User plane messages can be encrypted and integrity-protected in both the UL and DL directions (e.g., integrity-protected) if configured. Security update procedures can be triggered by the network (e.g., at any time) through subsequent reconfiguration (e.g., by handover).

[0085] The connection setup procedure may include setting up a radio barrier. The network may transmit details of the radio bearer configured to enable the desired data service to the WTRU. UL and DL data may be transmitted or received by the WTRU in a secure manner (e.g., accordingly). The network may transmit an RRCReconfiguration message (e.g., at any time) to release, change, or add a radio bearer, or to hand over the WTRU to another cell / gNB. In the RRC CONNECTED state, the WTRU may be provided with connection mode WTRU identification information known as the Cell Radio Network Temporary Identifier (C-RNTI). The WTRU may monitor the PDCCH (e.g., constantly) to determine whether the PDCCH has DL data or whether the PDCCH has permission for pending UL transmissions (e.g., the PDCCH indicates DL data, and UL permission is for a given WTRU by associating the data transmitted within the PDCCH using the C-RNTI of the WTRU concerned).

[0086] A WTRU can transition from the RRC CONNECTED state to the RRC IDLE state. If there is no activity to or from the WTRU for a certain period of time, the network can instruct the WTRU to transition to the RRC IDLE state by sending an RRCRelease command, thereby reducing the WTRU's power consumption. The network can also put a WTRU into the RRC IDLE state at any time, even if the WTRU is actively sending or receiving data.

[0087] If a WTRU loses radio connectivity (e.g., going out of coverage for a certain duration, failure of control plane message integrity verification, etc.), the WTRU may transition from the RRC CONNECTED state to the RRC IDLE state. When a WTRU loses connectivity, this may be referred to as a Radio Link Failure (RLF) or Handover Failure (HoF), which can occur when connectivity is lost while performing a handover to another cell / gNB and the WTRU attempts to re-establish connectivity. If re-establishment fails, the WTRU may remain in the RRC IDLE state until the network pages or until a higher layer (e.g., an application on the WTRU) begins transmitting UL data (e.g., initiating a voice call, initiating a data service request, etc.).

[0088] A WTRU can be in the RRC INACTIVE state. As referred to herein, putting a WTRU into the RRC IDLE state can save the WTRU's battery because, if the WTRU has been inactive for a given period of time (e.g., no data has been sent or received), the WTRU does not need to continuously monitor the PDCCH. If the data on the WTRU is intermittent (e.g., a smartphone sends small amounts of data very frequently), round tripping the WTRU between the RRC CONNECTED and RRC IDLE states can cause control plane signaling (e.g., a lot of control plane signaling) in the network. Signaling to move a WTRU from the RRC IDLE state to the RRC CONNECTED state may involve the RAN (e.g., gNB) and (e.g., further) the core network (CN), as the network may not have a WTRU context for an RRC IDLE WTRU (e.g., any WTRU context) and may not know where the WTRU is (e.g., it may not know exactly where it is). In the example, if the transition to the RRC CONNECTED state is triggered by DL data or an incoming voice call, the WTRU may need to be paged across the geographic area in which the WTRU is registered (e.g., across the entire geographic area, e.g., across all gNBs / cells).

[0089] Transitions from RRC IDLE to RRC CONNECTED (e.g., frequent transitions from RRC IDLE to RRC CONNECTED) can incur signaling overhead. A WTRU may have bearers that transmit data infrequently but are sensitive to delay. Even if a WTRU is not frequently actively transmitting or receiving data, it may be undesirable to have it in the RRC IDLE state (e.g., accordingly). A WTRU may be in an intermediate state known as the RRC INACTIVE state. In the RRC INACTIVE state, a WTRU can have the power-saving benefits of the RRC IDLE state (e.g., not continuously monitoring the PDCCH) but can return to the RRC CONNECTED state (e.g., quickly). Returning to the RRC CONNECTED state can be achieved by releasing the WTRU connection but maintaining the WTRU's context in the RAN and WTRU without involving the CN (e.g., the CN can see the WTRU in the same way it does when it is in the RRC CONNECTED state).

[0090] Figure 5 shows an example of a WTRU transitioning from the RRC INACTIVE state to the RRC CONNECTED state. The network can put a WTRU into the INACTIVE state by sending an RRCRelease message to the WTRU that includes a suspension configuration (known as suspendConfig). suspendConfig may include a WTRU identifier used when resuming the connection, a RAN area configuration, security information used to secure the resumption procedure, and a paging configuration (e.g., for paging from RAN instead of CN compared to the IDLE state). The RAN area configuration may include a list of cells (e.g., PCI) or tracking area codes. The RAN area configuration may include a periodic RAN area time (e.g., via a timer configuration) (e.g., optional). The WTRU can perform cell reselection as a WTRU in the RRC IDLE state and can monitor the paging channel using the configured RAN paging information (e.g., may monitor).

[0091] The WTRU may initiate a connection reactivation procedure in at least one of the following cases: when the WTRU detects a paging request in a paging channel associated with WTRU reactivation identification information (e.g., an incoming voice call or data call); when the WTRU needs to send UL data transmissions (e.g., arrival of UL data from a higher layer, voice call initiation, etc.); when a cell reselection procedure leads to reselection to a cell outside the configured RAN area; or when a periodic RAN area update timer is set and a duration equal to the set timer value has elapsed since the last RAN area update (or since the WTRU was put into the RRC INACTIVE state).

[0092] A WTRU can initiate the reactivation procedure by sending an RRCResumeRequest message. The RRCResumeRequest message may contain WTRU reactivation identification information and information about the cause of the connection reactivation (e.g., mobile outgoing voice call, mobile outgoing video call, mobile incoming call indicated by paging, emergency, reselection outside the current RAN area, or RAN area update due to timer expiration).

[0093] In the case of a RAN area update, the network can return the WTRU to the INACTIVE state (e.g., immediately) by sending an RRCRelease message (which may include, for example, new WTRU restart identification information, RAN area settings, or security and paging settings). The network may respond with an RRCResume message that may indicate to the WTRU to restart radio connectivity, and UL / DL transmissions may then proceed (e.g., immediately). Restarting from the RRC INACTIVE state can save considerable signaling for the WTRU and the network, and can reduce (e.g., may reduce) the latency for restarting data transmission / reception to or from the WTRU (e.g., compared to signaling for setting up connectivity from the RRC IDLE state).

[0094] Figure 6 shows an example of how a WTRU transitions between the RRC IDLE, RRC INACTIVE, and RRC CONNECTED states. A WTRU can transition from the RRC INACTIVE state to the RRC IDLE state (for example, it may transition from RRC INACTIVE to RRC IDLE). In the example, a WTRU can transition from the RRC INACTIVE state to the RRC IDLE state if it requests to resume connectivity but the network does not have available resources to accommodate its user.

[0095] Examples of NR sidelink relays are provided herein. Both WTRU inter-network relays and PC5 (sidelink) based WTRU inter-relays can be provided. The NR sidelink version can focus on supporting V2X-related road safety services. This version can provide support for broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios. Sidelink-based relay functionality can provide sidelink / network coverage extension and improved power efficiency. Sidelink-based relay functionality can consider a wider range of applications and services. Examples of coverage extension for sidelink-based communications include WTRU inter-network coverage extension and WTRU-to-WTRU coverage extension. WTRU inter-network coverage extension can provide Uu coverage reachability, which can enable WTRUs to reach servers in the PDN network or corresponding WTRUs outside the immediate area. WTRU inter-network relay may not be applicable to NR-based systems (e.g., for both NG-RAN and NR-based sidelink communications) due to its limitation to EUTRA-based technology. WTRU inter-network coverage extensions may limit proximity reachability to single-hop sidelink links (e.g., via either EUTRA-based or NR-based sidelink technology). This limited proximity reachability may be insufficient in scenarios where Uu coverage is absent, given the limited single-hop sidelink coverage. Overall, sidelink connectivity may be extended within the NR framework to support enhanced QoS requirements.

[0096] Relay selection / reselection for ProSe (Proximity Service) WTRU inter-network relays may be performed based on a combination of AS layer quality measurement (RSRP) and higher layer criteria. The eNB may control whether a WTRU can function as a ProSe WTRU inter-network relay. ProSe WTRU inter-network relay operation may be supported in a cell if the eNB broadcasts information (e.g., arbitrary information) associated with ProSe WTRU inter-network relay operation. The eNB may provide at least one instruction(s) of the following: a transmit resource for ProSe WTRU inter-network relay discovery using broadcast signaling for the RRC_IDLE state and dedicated signaling for the RRC CONNECTED state; a receive resource for ProSe WTRU inter-network relay discovery using broadcast signaling; or the minimum and / or maximum Uu Link Quality (RSRP) threshold(s) that a ProSe WTRU inter-network relay may respect before initiating the WTRU inter-network relay discovery procedure. In RRC IDLE, if the eNB broadcasts the transmit resource pool, the WTRU can use a threshold(s) to autonomously start or stop the WTRU inter-network relay discovery procedure. In RRC CONNECTED, the WTRU can use a threshold(s) to determine whether it can instruct the eNB that it is a relay WTRU and wishes to start ProSe WTRU inter-network relay discovery. If the eNB does not broadcast the transmit resource pool for ProSe-WTRU inter-network relay discovery, the WTRU can initiate a request for ProSe-WTRU inter-network relay discovery resources by dedicated signaling (e.g., respecting these broadcasted thresholds(s)). If ProSe WTRU inter-network relay is initiated by broadcast signaling, ProSe WTRU inter-network relay discovery can be performed if the RRC IDLE state is active.If a ProSe WTRU network relay is initiated by dedicated signaling, relay discovery can be performed if the RRC CONNECTED state is active.

[0097] A ProSe WTRU inter-network relay that performs sidelink communication for ProSe WTRU inter-network relay operation may be in the RRC CONNECTED state. When a ProSe WTRU inter-network relay receives a Layer 2 link establishment request or a TMGI monitoring request (e.g., a higher layer message) from a served WTRU, the ProSe WTRU inter-network relay may indicate to the eNB that it is a ProSe WTRU inter-network relay and intend to perform ProSe WTRU inter-network relay sidelink communication. The eNB may provide resources for ProSe WTRU inter-network relay communication.

[0098] A Served WTRU can decide when to begin monitoring for ProSe WTRU inter-network relay discovery. Depending on the configuration of resources for ProSe WTRU inter-network relay discovery, a Served WTRU can send ProSe WTRU inter-network relay discovery request messages while in the RRC IDLE or RRC CONNECTED state. The eNB can broadcast a threshold that can be used by the Served WTRU to determine whether it can send a ProSe WTRU inter-network relay discovery request message to connect with or communicate with a ProSe WTRU inter-network relay WTRU. In the RRC CONNECTED state, a Served WTRU can use the broadcasted threshold to determine whether it can indicate to the eNB that it is a Served WTRU and wishes to participate in ProSe WTRU inter-network relay discovery or communication. The eNB can provide transmit resources for ProSe WTRU inter-network relay operation using broadcast or dedicated signaling, and provide receive resources using broadcast signaling. A served WTRU may cease using ProSe WTRU inter-network relay discovery and communication resources if the RSRP exceeds the broadcast threshold.

[0099] The Served WTRU can perform radio measurements on the PC5 interface and use these measurements, along with higher-layer criteria, for ProSe WTRU inter-network relay selection and reselection. A ProSe WTRU inter-network relay may be considered suitable with respect to the radio criteria if its PC5 link quality exceeds a set threshold (e.g., pre-configured or provided by the eNB). The Served WTRU can select a ProSe WTRU inter-network relay from among suitable (e.g., all suitable) ProSe WTRU inter-network relays that meets the higher-layer criteria and has the best PC5 link quality.

[0100] A Served WTRU may trigger a ProSe WTRU inter-network relay reselection if the current PC5 signal strength of the ProSe WTRU inter-network relay falls below a configured signal strength threshold, or if the Served WTRU receives a Layer 2 link release message (e.g., a higher layer message) from the ProSe WTRU inter-network relay.

[0101] Figure 7 shows an example of a user plane stake to an NR L2 WTRU inter-network relay. Figure 8 shows an example of a control plane protocol stack to an L2 WTRU inter-network relay. In the case of an L2 WTRU inter-network relay, the adaptation layer may be located on top of the RLC sublayer for both CP and UP at the Uu interface between the relay WTRU and the gNB. The Uu SDAP / PDCP and RRC may be terminated between the served WTRU and the gNB, and the RLC, MAC, and PHY may be terminated at each link (e.g., the link between the served WTRU and the WTRU inter-network relay WTRU, and the link between the WTRU inter-network relay WTRU and the gNB). In the example, the adaptation layer may be present at the PC5 interface between the served WTRU and the relay WTRU. In the example, the adaptation layer may not be present at the PC5 interface between the served WTRU and the relay WTRU.

[0102] In the case of UL for L2 WTRU inter-network relay, the Uu adaptation layer in the relay WTRU can support UL bearer mapping between the ingress PC5 RLC channel for the relay and the outgress Uu RLC channel via the relay WTRU Uu path. For uplink relay traffic, different end-to-end RBs (SRB, DRB) of the same or different Served WTRUs may be subject to N:1 mapping and data multiplexing via the Uu RLC channel. The Uu adaptation layer may be used to support the identification of Served WTRUs for UL traffic (e.g., multiplexing data coming from multiple Served WTRUs). Served WTRU Uu radio bearer and Served WTRU identification information may be included in the Uu adaptation layer in the UL so that the gNB correlates received data packets for a specific PDCP entity associated with the correct Served WTRU Uu radio bearer of the Served WTRU.

[0103] In the case of DL for L2 WTRU inter-network relay, the Uu adaptation layer can be used to support DL bearer mapping in the gNB, allowing the end-to-end radio bearers (SRBs, DRBs) of a served WTRU to be mapped to a Uu RLC channel via the relay WTRU Uu path. The Uu adaptation layer can be used to support DL N:1 bearer mapping and data multiplexing between a served WTRU or multiple end-to-end radio bearers (SRBs, DRBs) of different served WTRUs and a Uu RLC channel via the relay WTRU Uu path. The Uu adaptation layer can support the identification of the served WTRU for DL ​​traffic. The identification information of the served WTRU Uu radio bearer and the identification information of the served WTRU can be fed into the Uu adaptation layer by the gNB in ​​the DL so that the relay WTRU can map received data packets from the served WTRU Uu radio bearer to its associated PC5 RLC channel.

[0104] Examples of measurements in NR are provided herein. Examples of measurements in Uu are provided herein. In the RRC CONNECTED state, the WTRU can measure at least one beam (e.g., multiple beams) of a cell. The measurement results (e.g., power values) can be averaged to derive cell quality. When measuring, the WTRU can be configured to consider a subset of the detected beams. Filtering can be performed at different levels (e.g., two different levels), such as at the physical layer to derive beam quality and at the RRC level to derive cell quality from multiple beams. Cell quality from beam measurements may be derived in the same manner for serving cells and non-serving cells. The measurement report may include measurement results for the number of best beams if the WTRU is configured so by the gNB. The measurement reporting setting can be either event-triggered or periodic. If the measurement reporting setting is periodic, the WTRU may send measurement reports at reporting intervals (e.g., ranging from 120 milliseconds to 30 minutes). In event-triggered measurements, the WTRU may send a measurement report when the conditions associated with the event are met. The WTRU continuously measures the report quantity of the serving cell and neighbors and may validate this using thresholds or offsets defined in the reporting settings. The report quantity or trigger for the event may be an RSRP, RSRQ, or SINR.

[0105] The following measurement events may be defined for NR. RAT events may be defined as follows: Event A1 (e.g., serving cell is better than the threshold), Event A2 (e.g., serving cell is worse than the threshold), Event A3 (e.g., adjacent cell is better than SPCell by an offset value), Event A4 (e.g., adjacent cell is better than the threshold), Event A5 (SPCell is worse than threshold 1 and adjacent cell is better than threshold 2), and Event A6 (e.g., adjacent cell is better than SCell by an offset value).

[0106] Event A1 can be used to cancel an ongoing handover procedure. This can occur if a WTRU moves towards a cell edge and triggers a mobility procedure, but (for example, then) returns to good coverage before the mobility procedure is completed.

[0107] Event A2 may not involve any adjacent cell measurements. Event A2 may be used to trigger a blind mobility procedure. The network may not configure the WTRU for adjacent cell measurements until it receives a measurement report triggered by Event A2 (for example, to conserve WTRU battery power).

[0108] Event A3 may be used for handover procedures. A Spcell (e.g., a special cell) can be the primary serving cell of either a Master Cell Group (MCG) (e.g., a PCell) or a Secondary Cell Group (SCG) (e.g., a PSCell). In DC operation, a Secondary Node (SN) may set up an A3 event for a PSCell change triggered by the SN.

[0109] Event A4 may be used for a handover procedure. The handover procedure may not depend on the coverage of the serving cell (for example, load balancing where a handover to a neighboring cell with a good WTRU may occur even if the serving cell conditions are good).

[0110] Event A5 can be used for handover. Event A5 may provide a handover triggering mechanism based on absolute measurements of the serving cell and adjacent cells. Event A5 may be suitable for time-critical handovers when a serving cell weakens and is moved towards another cell that may not meet the criteria for handover in Event A3.

[0111] Event A6 can be used to add or release SCells.

[0112] Inter-RAT events can be defined as follows: Event B1 (e.g., an inter-RAT neighbor cell is better than the threshold) and Event B2 (e.g., a PCell is worse than threshold 1 and an inter-RAT neighbor cell is better than threshold 2). Event B1 may relate to A4 (e.g., equivalent) except in the case of an inter-RAT handover. Event B2 may relate to A5 (e.g., equivalent) except in the case of an inter-RAT handover.

[0113] The WTRU measurement configuration may include an s-measure configuration (s-MeasureConfig). The s-measure configuration can specify a threshold for NR SPCell RSRP measurements that controls whether the WTRU needs to perform measurements on non-serving cells. This value can be a threshold corresponding to ssb-RSRP (e.g., corresponding to cell RSRP based on SS / PBCH blocks) or a selection of csi-RSRP (e.g., corresponding to cell RSRP of CSI-RS). If the measured SPCell SSB or CSI RSRP exceeds the threshold, the WTRU does not need to perform measurements on non-serving cells, which can improve the WTRU's power consumption (e.g., the WTRU does not perform unnecessary measurements if it has very good radio conditions to the serving cell).

[0114] Measurements may be performed on the sidelink. The WTRU can be configured to perform NR sidelink measurements according to the NR sidelink measurement settings for unicast via the RRCReconfigurationSidelink message and report on the corresponding PC5-RRC connection, as per the relevant peer WTRU configuration.

[0115] The following measurement events may be defined for NR sidelinks: Event S1 (e.g., serving cell is better than the threshold) and Event S2 (e.g., serving cell is worse than the threshold). Measurements based on Event S1 and Event S2 (e.g., measurement reports) may be used by the receiving WTRU to adjust power levels when transmitting data. NR sidelink transmissions may have two resource allocation modes: Mode 1 (sidelink resources are scheduled by the gNB) and Mode 2 (the WTRU autonomously selects sidelink resources from a pre-configured sidelink resource pool(s) based on the channel sensing mechanism). For in-coverage WTRUs, the WTRU may be configured to operate in Mode 1 or Mode 2. Out-of-coverage WTRUs may operate in Mode 2 (e.g., Mode 2 only).

[0116] To improve the QoS of NR sidelink transmissions, congestion control can be implemented (e.g., especially in mode 2) to prevent the transmitting WTRU from occupying too many resources in sidelink transmissions. For this purpose, two metrics can be defined: the Channel Busy Ratio (CBR) and the Channel Occupation Ratio (CR). The CBR can be defined as the portion of subchannels where the RSSI exceeds a pre-set value over a certain duration. Given a particular slot n, the CR can be defined as (X+Y)M, where X is the number of subchannels occupied by the transmitting WTRU within [na, n-1], Y is the number of subchannels allowed within [n, n+b], and M is the total number of subchannels within [na, n+b].

[0117] In congestion control, the upper limit of CR indicated by CRlimit may be imposed on the transmitting WTRU, and CRlimit is a function of CBR and sidelink transmission priority. The amount of resources occupied by the transmitting WTRU may not exceed CRlimit. CBR reporting may be used by the gNB to determine the pool of resources allocated to sidelink communication (for example, increasing the resource pool if WTRUs involved in sidelink communication report a high CBR, and decreasing the resource pool if the reported CBR is low).

[0118] Peer WTRUs involved in sidelink operation can be configured with each other for measurements for in-coverage operation (e.g., either periodic or S1 / S2 events) (e.g., a served WTRU may be within the coverage of a gNB). A gNB can configure a served WTRU for CBR measurement, which can be either periodic or event-triggered (e.g., either). The following two measurement events can be configured for CBR measurement reporting: Event C1 (e.g., CBR of NR sidelink communication is better than the absolute threshold), and Event C2 (e.g., CBR of NR sidelink communication is worse than the absolute threshold).

[0119] Relay WTRUs and served WTRUs can support different PLMNs. A relay WTRU can support a set of PLMNs (e.g., a, b, c), while a served WTRU can only belong to PLMN a. Cell reselection may be supported for cells belonging to PLMN b (e.g., for intermediate relay WTRUs in the case of multihops), so if a relay WTRU is handed over or performs cell reselection (e.g., if the relay WTRU was in RRC INACTIVE or RRC IDLE mode), the served WTRU may no longer be serviced by the relay WTRU (e.g., even if the PC5 between them could be in good radio condition). This can happen even if there are other candidate cells belonging to a PLMN supported by the served WTRU that have radio condition that may not be significant when handing over the relay WTRU to the target cell, or that may be worse than the ultimately selected target cell (e.g., only slightly worse). This situation can be problematic if cell reselection occurs while the relay WTRU is in RRC IDLE / INACTIVE mode, because cell reselection may be performed based on signal levels by the relay WTRU, and the network may not intervene to prevent it from happening.

[0120] In RRC INACTIVE mode, while a served WTRU is connected to a relay WTRU, the relay WTRU can perform a HO or cell reselection to a cell outside the WTRU's RAN area configuration. If multiple such WTRUs exist (e.g., a multi-hop scenario), this can lead to a signaling storm as affected WTRUs (e.g., all affected WTRUs) perform a two-step restart procedure to perform a RAN area update procedure (e.g., all RAN area update procedure) one by one. This can occur even if the improvement in handing over the relay WTRU to the target cell is not significant, or if there is another candidate cell belonging to the RAN area supported by the served WTRU with radio conditions comparable to (e.g., slightly worse) the ultimately selected target cell. This situation can be problematic (e.g., even more problematic) if cell reselection occurs while the relay WTRU is in RRC IDLE / INACTIVE mode, because cell reselection may be based on signal levels by the relay WTRU and the network may not intervene to stop it from happening.

[0121] While a served WTRU is connected to a relay WTRU, the relay WTRU may perform a HO or cell reselection to a cell on which the served WTRU cannot operate. The relay WTRU may perform a HO or cell reselection to a cell with characteristics / configurations (e.g., frequency, bandwidth, BWP, etc.) that the served WTRU may not be able to support. A HO or cell reselection may trigger an implicit cell reselection (e.g., a large number of implicit cells) (e.g., for the served WTRU or child relay WTRU in RRC IDLE and RRC INACTIVE modes) or a HO (e.g., for the served WTRU or child relay WTRU in RRC CONNECTED mode). This may occur even if the improvement in handing over the relay WTRU to the target cell is not significant, or even if there were other candidate cells that could support (e.g., support most of) the relay WTRU that the served WTRU and the relay WTRU were directly or indirectly serving.

[0122] An example of connection establishment in a multi-hop WTRU-to-NW relay is provided herein. A relay WTRU acting as an intermediate WTRU in a multi-hop WTRU-to-NW relay link may itself be associated with a Uu RRC state.

[0123] Figure 9 shows an example of a relay WTRU in coverage by conventional RRC connected via a Uu. A relay WTRU can be in the RRC CONNECTED, RRC IDLE, or RRC INACTIVE state. A relay WTRU can be configured (for example, further configured) to perform a multi-hop WTRU to a NW relay for a served WTRU (for example, via a relayed path) in one or more RRC states (for example, or all of these RRC states). In the example, a relay WTRU can be in the RRC INACTIVE state but can serve an active remote WTRU in the RRC CONNECTED state, and a sidelink connection between the inactive relay WTRU and another relay WTRU can be used to forward communications of the served WTRU even if the intermediate relay WTRU is not in the RRC CONNECTED state.

[0124] Figure 10 shows an example of an out-of-coverage relay WTRU with signaling or maintenance of an RRC state entirely through a relay path. A relay WTRU can have an RRC state with respect to Uu. A relay WTRU can be in the RRC CONNECTED, RRC IDLE, or RRC INACTIVE state. A relay WTRU can be configured (for example, further configured) to perform a multi-hop WTRU to a NW relay for a served WTRU (for example, via a relayed path) in one or more RRC states (for example, or all of these RRC states). In the example, a relay WTRU can be in the RRC INACTIVE state but can serve an active served WTRU that is in the RRC CONNECTED state, and a sidelink connection between the inactive relay WTRU and another relay WTRU can be used to forward communications of the served WTRU even if the intermediate relay WTRU is not in the RRC CONNECTED state.

[0125] In the examples shown in Figures 9 and 10, the paths that RRC signaling can take are different. In the example shown in Figure 9, the relay WTRU may be scheduled for sidelink transmission (e.g., via Uu) using Mode 1 (e.g., NW scheduled) SL scheduling mode. The example shown in Figure 9 may allow RRC signaling / connection for intermediate relays to proceed either through a direct or indirect path.

[0126] An RRC connection or RRC state associated with an intermediate relay WTRU may be assumed to refer to one of the examples described herein. The examples described herein may equally apply to WTRU-to-network relays (e.g., where the source / destination may be a network node) and WTRU-to-WTRU relays (e.g., where the source / destination may be another WTRU). The term "parent relay" may be used to refer to a relay WTRU that transmits data upstream and services a given relay WTRU (e.g., a child relay) to receive data downstream (e.g., in the case of a U2N relay). In the case of a U2U relay, the terms upstream and downstream may be interchangeable depending on the direction of flow from one WTRU to another. In the case of a U2U relay, the terms parent and child may be interchangeable (e.g., they may be interchangeable). The term "intermediate relay WTRU" may be used to refer to a relay WTRU that services another WTRU or relay WTRU but may be serviced by another relay WTRU. The term "final relay WTRU" may be used to describe a relay WTRU that may be directly serviced by a gNB cell. The term "served WTRU" may be used to refer to a served WTRU, remote WTRU, or relay WTRU (e.g., in the case of multi-hop) that is serviced by a relay WTRU. The term "directly served WTRU" may be used to refer to a served WTRU that is directly connected to a relay WTRU. The term "indirectly served WTRU" may be used to refer to a served WTRU that is serviced by a relay WTRU that is directly serviced by a relay WTRU (e.g., one or more hops away from the relay WTRU). The terms "state" and "mode" may be used interchangeably (e.g., CONNECTED mode, CONNECTED state).

[0127] Figure 11 shows an example of a relay WTRU that determines the behavior of the relay WTRU to be performed (for example, this behavior may be related to the actions of the relay WTRU moving toward an adjacent cell). The determined behavior may be related to handover, cell reselection, and associated measurements. The determination of the behavior may take into account the characteristics(s) of the remote WTRU(s) (e.g., the respective characteristics(s) of each remote WTRU(s)) and / or the characteristics of the child WTRU(s). Examples of such characteristics(s) may include at least one of the supported PLMN, configured RAN area, or WTRU capability(s) of the remote WTRU(s) (e.g., each WTRU among several remote WTRU(s) may have its own characteristics). In the example, the relay WTRU may take into account the characteristics(s) of the child relay WTRU(s). A relay WTRU(or more) may be configured to know (receive information indicating) the characteristics(or characteristics) associated with (e.g., each of several remote WTRUs) (e.g., each of several remote WTRUs). For each remote WTRU(or more), a relay WTRU(or more) may be configured to know (receive information indicating) at least one of the following: each supported PLMN(or more), each configured RAN area, or each remote WTRU capability associated with (e.g., each of several remote WTRUs) (e.g., as shown in Figure 11). In the example, each remote WTRU capability may include at least one of the supported frequencies or supported bandwidths.

[0128] In the example, the relay WTRU may receive a first characteristic associated with the first remote WTRU (e.g., supported PLMN), a second characteristic associated with the second remote WTRU (e.g., configured RAN area), and a third characteristic associated with the third remote WTRU (e.g., remote capability). In the example, the relay WTRU may receive first and third characteristics associated with the first remote WTRU (e.g., supported PLMN and remote capability), first and second characteristics associated with the second remote WTRU (e.g., supported PLMN and configured RAN area), and second and third characteristics associated with the third remote WTRU (e.g., configured RAN area and remote capability).

[0129] For example, a relay WTRU(s) may be configured to know (e.g., receive) information about the supported PLMN(s) (e.g., each) RAN area-related information, or the WTRU capabilities (e.g., each) of these served WTRU(s) (e.g., remote WTRU(s)) that have an active PC5 link. This can be achieved in several ways, such as by one or more of the following: a served (e.g., remote) WTRU can provide the relay WTRU with relevant information (e.g., characteristics(s)) (e.g., during PC5 establishment); a served (e.g., remote) WTRU can provide relevant information (e.g., characteristics(s)) after PC5 establishment in a PC5-RRC message; or the relay WTRU can be configured by the network (e.g., via a Uu RRC message) with respect to the relevant information (e.g., characteristics(s)) of the served (e.g., remote) WTRU. A served (e.g., remote) WTRU that provides information (e.g., characteristics) relevant during PC5 establishment to a relay WTRU may be based on at least one of the following: network configuration to include that information in the PC5 setup, an autonomous decision by the served WTRU (e.g., remote WTRU), or a request by the relay WTRU during the PC5 setup procedure. A served WTRU (e.g., remote WTRU) that provides information (e.g., characteristics) relevant after PC5 establishment in a PC5-RRC message may be a push message without a request from the relay WTRU (e.g., based on an autonomous decision by the served WTRU, or based on network configuration to do so after PC5 establishment), or a response message to a request from the relay WTRU.

[0130] A relay WTRU configured by the network (e.g., via a Uu RRC message) regarding information related to a served (e.g., remote) WTRU may receive a push message from the gNB or a request from the relay WTRU concerning a specific service-receiving (e.g., remote) WTRU.

[0131] In the example, PC5 WTRUCapabilityEnquirySidelink and WTRUCapabilityInformationSidelink are extended to include non-sidelink related capabilities (for example, a flag is added to the inquiry message indicating to the remote WTRU to send non-sidelink related WTRU capabilities).

[0132] In the example, a subset of WTRU capabilities (e.g., only a subset) may be requested (e.g., a flag or set of flags indicating which capability information is required, or a flag or set of flags indicating which capability information is not required). Information communicated to the relay WTRU (in addition to RAN area configuration) may include other RRC inactive state information such as WTRU restart identification information (e.g., full I-RNTI, short I-RNTI), RAN paging cycle, periodic RAN area update timer, nextHopChainCount used for security key derivation, etc.).

[0133] If a relay WTRU selects or reselects a cell while in the RRC IDLE / INACTIVE state, or is handed over to a cell while in the RRC CONNECTED state and this cell does not support a particular served WTRU, the relay WTRU can communicate this information to the served (e.g., remote) WTRU. In the example, a WTRU may not monitor (e.g., continuously monitor) PLMN information broadcast by a cell because PLMN information is not typically expected to change when the WTRU is directly connected to or camped in a cell rather than via a sidelink relay. Notifying the WTRU to be aware of such PLMN changes can ensure that the WTRU does not remain camped or connected to a cell to which it does not have registration (e.g., this could cause failures during connection setup triggered by UL data arrival or scheduling requests to the network to send UL data while connected, after a period of inactivity (e.g., before the network detects data inactivity and decides to put the WTRU into the RRC IDLE or RRC INACTIVE state)).

[0134] Information communicated to the relay WTRU may include INACTIVE status information (e.g., in addition to RAN area-related information) such as WTRU restart identification information (e.g., full I-RNTI, short I-RNTI), RAN paging cycle, periodic RAN area update timer, and nextHopChainCount used for security key derivation. Examples of constraints on the Uu RRC state of a relay WTRU or served WTRU (e.g., remote WTRU) for communication of supported PLMNs, RAN areas, and WTRU capabilities are provided herein. A served WTRU (e.g., remote WTRU) may be configured to communicate its PLMNs, RAN area settings, and / or WTRU capabilities to the relay WTRU regardless of its Uu RRC state. A served WTRU (e.g., remote WTRU) may be configured to communicate its PLMNs, RAN area settings, and / or WTRU capabilities to the relay WTRU depending on its Uu RRC state (e.g., only while in RRC_IDLE). A served WTRU (e.g., a remote WTRU) may be configured to communicate its PLMN, RAN area configuration, and / or WTRU capabilities to a relay WTRU when transitioning from one Uu RRC state to another (e.g., when disconnecting from the RRC IDLE / INACTIVE state, or when reconnecting / setting up the connection).

[0135] A relay WTRU may be configured to request PLMN, RAN area configuration, and / or WTRU capabilities from a served WTRU (e.g., a remote WTRU) regardless of the relay WTRU's Uu RRC state. A relay WTRU may be configured to request PLMN, RAN area configuration, and / or WTRU capabilities from a served WTRU (e.g., a remote WTRU) depending on the relay WTRU's Uu RRC state (e.g., a relay WTRU requests information from a served / remote WTRU only when it is in the RRC CONNECTED state itself). A relay WTRU may be configured to request PLMN, RAN area configuration, and / or WTRU capabilities from a served WTRU (e.g., a remote WTRU) when transitioning from one Uu RRC state to another (e.g., a relay WTRU may request information from a served / remote WTRU during connection reactivation / setup). Requests from a relay WTRU (or push messages from a served WTRU) may depend on the Uu RRC state of the relay WTRU and the served / remote WTRU (for example, a relay WTRU may request information from the served WTRU when the relay WTRU transitions to the RRC INACTIVE state while the served / remote WTRU is in the RRC IDLE state). Different behavior may be configured for the processing of child served WTRUs (e.g., remote WTRUs) and child relay WTRUs (for example, the behavior for a child served WTRU may not depend on the RRC state of the relay WTRU, but the behavior for a child remote relay WTRU may depend on the RRC state of the relay WTRU).

[0136] A relay WTRU may be configured to forward information about supported PLMNs, configured RAN areas, or the WTRU capabilities of their served WTRUs (e.g., remote WTRUs). In multi-hop scenarios, a relay WTRU may be configured to forward information (e.g., characteristics) related to the served WTRU (e.g., remote WTRUs) upstream toward the parent relay WTRU (e.g., via PC5-RRC messages). This forwarding of information about the served (e.g., remote) WTRU may be triggered, for example, when the relay WTRU first becomes aware of the information (e.g., characteristics) related to the served WTRU, when the relay WTRU becomes aware that the information (e.g., characteristics) related to the served WTRU has changed, based on a request from the parent relay WTRU, or based on other configurations (e.g., periodic updates).

[0137] When PC5 is released to a served WTRU (e.g., a remote WTRU), the relay WTRU can update the relevant information (e.g., characteristics) and forward it to the parent relay WTRU. The information forwarded to the parent relay WTRU may include information about (e.g., all) served WTRUs (e.g., remote WTRUs) and relay WTRUs that are serviced by the relay WTRU (e.g., all transmitted at the same level of hierarchy). For example, consider the scenario shown in Figure 12.

[0138] Figure 12 shows an example of a served WTRU (e.g., a remote WTRU) and a relay WTRU serviced by a relay WTRU. Relay WTRU1 can send information such as [WTRUa, list of supported PLMNs] [WTRUb, list of supported PLMNs] [Relay WTRU1, list of supported PLMNs] to relay WTRU2. Relay WTRU2 can send information such as [WTRUa, list of supported PLMNs] [WTRUb, list of supported PLMNs] [Relay WTRU1, list of supported PLMNs] [Relay WTRU2, list of supported PLMNs] to relay WTRU3. Relay WTRU3 does not need to have hierarchical information and does not need to know whether WTRUa and WTRUb are directly connected to relay WTRU2 or are more than two hops away from WTRU2.

[0139] Hierarchical information may be included (for example, it may be included). For example, relay WTRU2 may transmit information such as {its own PLMN, {Level 1 PLMN including directly served WTRU identity information and supported PLMN}, {Level 2 PLMN including WTRU identity information and supported PLMN of WTRUs indirectly served by the relay WTRU and one hop away}, {Level 2 PLMN including WTRU identity information and supported PLMN of WTRUs indirectly served by the relay WTRU and two hops away}. Non-hierarchical or hierarchical information may include a representation of WTRU identity information (e.g., C-RNTI of served / remote WTRUs in the RRC CONNECTED state, resumeIdentity of WTRUs in the RRC INACTIVE state). Non-hierarchical or hierarchical information may include summarized information indicating the number of WTRUs to which the information relates. For example, in the non-hierarchical example considered above, the information may be something like {PLMN x: 2 WTRUs, PLMN y: 3 WTRUs, PLMN z: 10 WTRUs}.

[0140] Information about configured RAN areas forwarded to the parent relay WTRU may consider one or more of the following: the RAN area configured for the relay WTRU itself (e.g., if the relay WTRU is also in the RRC INACTIVE state), child relay WTRUs connected to the relay WTRU (e.g., directly connected), served WTRUs (e.g., remote WTRUs), and relay WTRUs connected to the relay WTRU (e.g., directly connected), served WTRUs (e.g., remote WTRUs) that are one hop away. Information about configured RAN areas forwarded to the parent relay WTRU may consider one or more of the following: the WTRU capability of the relay WTRU itself, the WTRU capability of child relay WTRUs directly connected to the relay WTRU, the WTRU capability of served WTRUs (e.g., remote WTRUs) and relay WTRUs directly connected to the relay WTRU, and the WTRU capability of served WTRUs (e.g., remote WTRUs) that are one hop away.

[0141] A relay WTRU(or more) can receive configuration information associated with the relay WTRU(or more). The received configuration information may include the behavior(s) of the relay WTRU(or more) in relation to neighboring cells, for example, behaviors performed based on a threshold of support by neighboring cells as described herein (for example, as shown in Figure 11). The configured behavior(s) of the relay WTRU(or more) may be related to cell reselection, handover measurement, or measurement reporting (for example, the relay WTRU may be configured to perform or not perform). The behavior may be determined by the relay WTRU based on a threshold of support by neighboring cells for each characteristic(s) of each remote WTRU, for example, this determination may take into account each PLMN(or more) supported by each served WTRU(e.g., remote WTRU) and / or child relay WTRUs supported by neighboring cells. A relay WTRU(or more) can determine whether a remote WTRU(e.g., each of several remote WTRU(or more)) is supported by a neighboring cell. Relay WTRUs may be configured to perform or not perform determined behaviors on neighboring cells (e.g., cell reselection or measurement for cell reselection (e.g., during the IDLE / INACTIVE state)) depending on the characteristics (e.g., each) of each WTRU (e.g., each supported PLMN, each supported RAN area, or each WTRU (e.g., each remote WTRU (e.g., each WTRU capability)) and the configuration or characteristics of neighboring cells, e.g., whether or to what extent neighboring cells support each characteristic (e.g., each characteristic). Served WTRUs may be served directly or indirectly by relay WTRUs.

[0142] A served WTRU (e.g., a remote WTRU) can be determined to support an adjacent cell (or the adjacent cell is determined to support a served / remote WTRU) if one or more of the following conditions are met: for example, the adjacent cell supports a PLMN supported by the WTRU, the adjacent cell is within the RAN area where the WTRU is configured, or the WTRU can operate within the adjacent cell (e.g., as shown in Figure 11) (e.g., supporting the adjacent cell's frequency, bandwidth, etc.). As one possible example, the characteristic of the first remote WTRU may be that the first remote WTRU is associated with a first PLMN, and the characteristic of the second remote WTRU may be that the second remote WTRU is associated with a second PLMN. An adjacent cell may support the first PLMN but not the second. In such a case, the relay WTRU can determine that the adjacent cell supports the first WTRU but not the second WTRU.

[0143] A relay WTRU can determine its behavior based on configuration information and the percentage of remote WTRUs supported by the neighboring cell. The determined behavior may be related to the neighboring cell. For example, if the neighboring cell does not support remote WTRUs associated with the relay WTRU, the number / percentage of remote WTRUs associated with the relay WTRU, etc., the determined behavior may include at least one of the following: disabling cell reselection to the neighboring cell, disabling measurement to the neighboring cell, disabling sending measurement reports triggered by the neighboring cell, or lowering the priority of measurement to the neighboring cell. The relay WTRU can perform the determined behavior related to the neighboring cell. For example, the relay WTRU may be configured to measure or perform cell reselection towards (for example, only towards) cells supported by at least a certain percentage threshold of directly and / or indirectly served WTRUs (e.g., remote WTRUs) (e.g., only towards cells). In the example, a 100% threshold means that a cell cannot be eligible for cell reselection or cell reselection measurement even if a served / remote WTRU (e.g., just one served / remote WTRU) does not support that cell, and a 50% threshold means that half of the served / remote WTRUs must be supported by the cell, and so on. Different percentage thresholds can be specified for served / remote WTRUs that are directly serviced by relay WTRUs and served / remote WTRUs that are indirectly serviced. Configurations can also be made to specify different percentage thresholds per hop (e.g., directly connected, one hop away, two hops away), and hop-level percentage thresholds can be specified per hop or based on some scaling (e.g., explicitly specified).

[0144] In the example, the determined behavior of the relay WTRU may be based on whether the proportion of remote WTRUs supported by the neighboring cell is above or below a threshold. The first and second neighboring cells may be available. The relay WTRU may be connected to the first neighboring cell. If the proportion of remote WTRUs supported by the first neighboring cell is below a threshold, the determined behavior of the relay WTRU may be to perform cell reselection to the second neighboring cell. If the proportion of remote WTRUs supported by the first neighboring cell is above a threshold, the determined behavior of the relay WTRU may be to perform measurement on the first neighboring cell. In the example, the received configuration information may include the first and second behaviors. The determined behavior of the relay WTRU may be either the first or the second behavior. If the proportion of remote WTRUs supported by the neighboring cell is above a threshold, the determined behavior of the relay WTRU may be the first behavior. If the proportion of remote WTRUs supported by the first adjacent cell falls below a threshold, the determined behavior of the relay WTRU may be the second behavior.

[0145] A relay WTRU may be configured to prioritize the cell supported by the most served WTRUs (e.g., remote WTRUs). This may be specified, for example, by a scaling factor or offset on the signal level directed to the cell being measured, which may depend on the percentage of served WTRUs (e.g., remote WTRUs) that support the cell in question; a descaling / penalty factor that depends on the percentage of WTRUs that may not support the cell in question; or a signal level threshold / window that specifies a cell supported by more served WTRUs (e.g., remote WTRUs) over another cell supported by a lower percentage of WTRUs (unless the signal from the former is worse than the signal from the latter by a set threshold).

[0146] Prioritizing or deprioritizing a cell by a relay WTRU based on support from a served WTRU (e.g., a remote WTRU) can be made hop-dependent by, for example, considering a remote (e.g., remote only) WTRU directly connected to a relay WTRU, considering a relay (e.g., relay only) WTRU directly connected to a relay WTRU, considering a served WTRU (e.g., all served WTRUs and relay WTRUs directly connected to a relay WTRU), or considering a remote WTRU one hop away (e.g., a remote WTRU as well).

[0147] A relay WTRU can update the priority of PLMNs set on the relay WTRU depending on the served WTRU and the PLMNs that the relay WTRU supports. PLMNs can serve served WTRUs (e.g., remote WTRUs) and relay WTRUs directly or indirectly. For example, a relay WTRU may support two PLMNs, a and b, where a is set as the high-priority PLMN. If the majority of served WTRUs support only PLMN b, the relay WTRU may consider b to be the high-priority PLMN. This may be based on which has more support, or it may depend on a comparison between different PLMNs. For example, the relay WTRU may use the original priority of the PLMN as long as the highest-priority PLMN does not support less than x% of the served WTRUs, or a PLMN supported by more than x% of served WTRUs (e.g., x set to 10%) compared to the original high-priority PLMN may be considered the new high-priority PLMN.

[0148] The cell reselection measurement examples described herein may apply to RRM measurements when the relay WTRU is in the RRC CONNECTED state. The relay WTRU may be configured to perform or not perform neighbor measurements for a handover to a specific neighboring cell (e.g., while in the RRC CONNECTED state). The relay WTRU may be configured not to transmit measurement reports triggered by a served WTRU (e.g., a remote WTRU) when a given neighboring cell satisfies several set thresholds (e.g., event A3 described above), depending on the level of support for the cell in question.

[0149] The examples described herein may be applied to RRM measurements in connected mode. In the examples, this is specified for adjacent cells considered for RRM measurement, with different minimum percentage thresholds for support by a served WTRU (e.g., remote WTRU) (e.g., measure if more than 75% of the served WTRU (e.g., remote WTRU) support the same PLMN as the cell concerned (e.g., only in that case), measure if more than 75% of the served WTRU (e.g., remote WTRU) have the cell concerned within their configured RAN area (e.g., only in that case), measure if more than 90% of the served WTRU (e.g., remote WTRU) support the same frequency as the cell concerned (e.g., only in that case)), and for the adjacent cell to trigger the measurement report, the served WTRU (e.g., remote WTRU) to the adjacent cell. This may include different minimum percentage thresholds for support by moat WTRUs (e.g., if the measurement is performed as usual, but the number of served WTRUs (e.g., remote WTRUs) supporting the PLMN(s) of the cell in question exceeds a set percentage (e.g., only in that case), or if the percentage of served WTRUs supporting the frequency of the cell in question exceeds a set percentage, or if the percentage of served WTRUs (e.g., remote WTRUs) having the cell in question in the RAN area exceeds a set percentage), and specified thresholds (or specified offsets) that scale cell measurements up / down applied to adjacent cell measurements depending on the level of support by served WTRUs (e.g., remote WTRUs).

[0150] The percentage level (or scaling / offset value) to be met may be hop-specific or may take into account directly or indirectly served WTRUs (e.g., remote WTRUs) (e.g., all). Different percentage levels (or scaling / offset values) may be related to the level of support for PLMN, RAN area, and WTRU capacity.

[0151] Relay WTRUs in RRC CONNECTED mode may be configured to perform RAN area update-related operations on behalf of the served WTRU and child relay WTRUs that they directly or indirectly service. When a connected relay WTRU performs a handover to a cell that does not belong to the served WTRU's RAN area (e.g., as shown in Figure 11), it can perform procedures such as RAN area updates on behalf of the served WTRU. In the example, this may include at least one of the following: a relay WTRU that sends information equivalent to the information contained in a restart request message that may be sent during a two-step restart request for a RAN area update, which may include WTRU restart identification information; a relay WTRU that receives response information equivalent to a release message that may be sent in response to a two-step restart request sent for a RAN area update (e.g., which may include a new RAN area configuration, new WTRU restart identification information for the served WTRU, a paging cycle, etc.); or a relay WTRU that can pass this response information to the served WTRU (e.g., via a PC5-RRC message).

[0152] Response information that may be forwarded to the served WTRU (e.g., RAN area, WTRU restart identification information, paging cycle, etc.) may be visible to the relay WTRU. Response information that may be forwarded to the served WTRU may be transparent to the relay WTRU (e.g., sent to the relay WTRU within a potentially encrypted transparent OCTET container that the served WTRU (e.g., only) can understand).

[0153] A relay WTRU can send RAN area update information for multiple served WTRUs to the network in a single message (e.g., including all WTRU reactivation identification information for served WTRUs that the relay WTRU directly or indirectly services). A relay WTRU can receive response information for multiple served WTRUs in a single message (e.g., including all new WTRU reactivation identification information, updated RAN area configuration, and old reactivation identification information for matching purposes).

[0154] In a multi-hop scenario, if a relay WTRU receives response information for a given served WTRU that is not connected to it (e.g., directly connected), the relay WTRU can pass the information to child relay WTRUs that are directly or indirectly serving the served WTRU. The information can be propagated hop by hop until it reaches the WTRUs involved. For example, consider a scenario where served WTRU1 and WTRU2 are connected to relay WTRUa, served WTRU3 and relay WTRUa are connected to relay WTRUb, which is further connected to relay WTRUc. Assuming the target gNB cell is outside the configured RAN area of ​​the WTRUs (e.g., all WTRUs), relay WTRUc can send a message to the target gNB to indicate the restart identification information for relay WTRUb, relay WTRUa, served WTRU1, WTRU2, and WTRU3. In response, relay WTRUc can obtain the updated restart identification information and RAN area for these WTRUs and pass the information for relay WTRUb. Relay WTRUb can obtain updated information for itself from this message and pass the information about WTRU3 to its connected WTRU (e.g., a directly connected WTRU), and the remaining information to WTRUa. From this message, WTRUa can obtain its updated information and pass the remaining information to the relevant WTRUs, WTRU1 and WTRU2.

[0155] A relay WTRU can send RAN area update-related information regarding a served WTRU to the gNB in ​​the HO completion message. After HO completion, the relay WTRU can send RAN area update-related information regarding a served WTRU in a separate message. The relay WTRU can send RAN area update-related information regarding a served WTRU to the gNB in ​​a measurement report that is expected to trigger a handover (e.g., the event A3 trigger measurement event described above). The relay WTRU can receive response information from the source gNB / cell in the HO command, including the updated RAN area and WTRU identification information for the relevant WTRU. After HO completion, the relay WTRU can receive response information from the target gNB / cell, including the updated RAN area and WTRU identification information for the relevant WTRU.

[0156] The involved WTRU(s) (e.g., each involved WTRU) can generate a restart request for a RAN area update due to a relay WTRU's HO to a cell not within the WTRU's configured RAN area. The relay WTRU can collect restart request messages (e.g., all restart requests) and send them to the network in one large message. This may be a list of restart request messages. The relay WTRU can collect response messages to the restart request messages for these WTRUs that are indirectly served and send them to the service-providing relay WTRU in one group message. The involved WTRU(s) (e.g., each involved WTRU) can generate restart requests for periodic RAN area updates (e.g., conventional, if configured). The relay WTRU can collect these periodic updates from different WTRUs for a specified duration and send them to the network in one large message. In the example, a relay WTRU may be configured not to send RAN area update-related information for its served WTRU up to once every 5 minutes, thereby delaying the RAN area update for a given WTRU by up to 5 minutes (for example, assuming it was received immediately after a previous RAN area update was sent by the relay WTRU), allowing the RAN area update to be aggregated with any other update messages sent by other WTRUs and sent all together.

[0157] A relay WTRU can recognize the configured periodic RAN area update timer value of its served WTRU. The relay WTRU can use this to attempt to determine how often the WTRU should forward periodic RAN area update messages. In the example, assuming (imaging) that served WTRU1 through WTRU are each configured with a timer value of 5 minutes, they were put into the RRC INACTIVE state at t1, t1+1, t1+2, t1+3, and t1+4 minutes, without any change in conventional behavior, RAN area updates could be sent to the network every minute (for example, from WTRU1 to t1+5, from WTRU2 to t1+6, from WTRU3 to t1+7, from WTRU4 to t1+8, from WTRU5 to t1+9, from WTRU0 to t1+10, etc.). The relay WTRU may delay the transmission of a first aggregate message at t1+9 containing updates from (e.g., all) WTRUs, a second aggregate message at t1+14, and so on (for example, accordingly).

[0158] Relay WTRUs in RRC INACTIVE mode may be configured to perform RAN area update-related operations on behalf of served WTRUs and child relay WTRUs that they directly or indirectly service. When a relay WTRU in RRC INACTIVE mode performs a RAN area update, this may include information related to its served WTRUs that do not have target cells within their configured RAN area. For example, this may include a relay WTRU sending a restart request message indicating a RAN area update, which may include the relay WTRU's own WTRU restart identification information, as well as other related WTRUs that may need to update their RAN area (e.g., may also need to), a relay WTRU receiving a release message which may include updated information (e.g., new WTRU identification information for the relay WTRU and all related WTRUs, RAN area configuration, etc.), or a relay WTRU passing the updated information to the served WTRU(s) (e.g., via a PC5-RRC message).

[0159] A resumption request containing multiple identifiers can implicitly or explicitly indicate which identifier belongs to the relay WTRU sending the message. Updated information forwarded to the served WTRU may be visible to the relay WTRU. The updated RAN area and WTRU identifiers forwarded to the served WTRU may be transparent to the relay WTRU (for example, sent to the relay WTRU within a potentially encrypted, transparent OCTET container that can be understood by the served WTRU (e.g., only this)).

[0160] In a multi-hop scenario, if a relay WTRU receives updated restart identification information and RAN area settings for a given served WTRU that is not directly connected to it, the relay WTRU can pass the information to child relay WTRUs that are directly or indirectly serving the served WTRU. The information can be propagated hop by hop until it reaches the WTRUs involved. For example, consider a scenario where served WTRU1 and WTRU2 are connected to relay WTRUa, served WTRU3 and relay WTRUa are connected to relay WTRUb, which is further connected to relay WTRUc. Assuming the target gNB cell is outside the configured RAN area of ​​(e.g., all) WTRUs and relay WTRUc itself, relay WTRUc can initiate a two-step restart procedure to show the target gNB its own restart identification information, as well as the identification information of relay WTRUb, relay WTRUa, served WTRU1, WTRU2, and WTRU3. In return, relay WTRUc can obtain updated restart identification information and RAN areas for itself and the other WTRUs. WTRUc can pass information about other WTRUs to relay WTRUb. Relay WTRUb can obtain updated information about itself from this message. Relay WTRUb can pass information about WTRU3 to its directly connected WTRU and the remaining information to WTRUa. From this message, WTRUa can obtain its updated information and pass the remaining information to the relevant WTRUs, WTRU1 and WTRU2.

[0161] A relay WTRU can initiate a restart procedure for a RAN area update on behalf of a served WTRU or relay WTRU that directly or indirectly provides the service, even if it does not need to perform the RAN area update itself. This can be triggered when the relay WTRU performs cell reselection for a cell that belongs to its own RAN area but not to the served WTRU's RAN area (e.g., as shown in Figure 11), or when a certain period expires (e.g., when a timer for a periodic timer-based RAN area update for the served WTRU expires, if one is set). The relay WTRU can implicitly or explicitly indicate that this information is for a child WTRU and not for the relay WTRU itself (e.g., in this case). In the example, the relay WTRU's restart identification information may include a flag (e.g., an additional flag) indicating that it does not update the RAN for the relay WTRU.

[0162] A relay WTRU may delay notifying the network of RAN area updates of its child WTRUs or relay WTRUs in order to reduce the number of RAN area update messages sent. For example, suppose served WTRU1 is configured to be in the RRC INACTIVE state at t1, served WTRU2 is inactive at t1+1 minutes, and both are configured to send periodic RAN area update information every 5 minutes. This could result in RAN area updates being sent to the gNB at t1+5, t1+5, t1+10, t1+10, etc. A relay WTRU (e.g., knowing the periodic timer settings of both WTRUs) could decide to synchronize the RAN area update procedures of the two WTRUs, so that the relay WTRU can instead send both updates in one message every 5 minutes. The relay WTRU can track time (e.g., via the periodic RAN area timer). During each update period, the WTRU can aggregate update information from its served WTRUs (e.g., all update information). Each time its own RAN area timer expires, the relay WTRU can forward this update information in a single group update message, which includes its own updates.

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

[0164] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and may be further applicable to other wireless systems.

[0165] The processes described above can be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media, magneto-optical media, and / or optical media such as Compact Disc (CD)-ROM discs and / or Digital Versatile Discs (DVDs), including but not limited to read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks. A processor associated with the software can be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs (Radio Network Controllers), and / or any host computer.

Claims

1. A relay wireless transmitter / receiver unit (WTRU), The processor comprises, Receiving information related to multiple remote WTRUs, wherein the information includes a first characteristic related to a first remote WTRU and a second characteristic related to a second remote WTRU. Receiving configuration information related to the aforementioned relay WTRU, The determination that the first remote WTRU and the second remote WTRU are supported by the cell, wherein the determination is based on the fact that the first and second characteristics are supported by the cell. The behavior of the relay WTRU is determined based at least on the configuration information and the first and second remote WTRUs supported by the cell, wherein the determined behavior of the relay WTRU is related to the cell. A relay WTRU is configured to perform the determined behavior associated with the aforementioned cell.

2. The relay WTRU according to claim 1, wherein the determination of the behavior of the relay WTRU is further based on the proportion of the plurality of remote WTRUs supported by the cell.

3. The relay WTRU according to claim 2, wherein the determined behavior is further based on the proportion of the plurality of remote WTRUs supported by the cell being above or below a threshold.

4. The aforementioned cell is the first cell, The relay WTRU is connected to the first cell, If the proportion of the aforementioned multiple remote WTRUs falls below the threshold, the determined behavior is cell reselection to the second cell. The relay WTRU according to claim 2, wherein if the proportion of the plurality of remote WTRUs exceeds the threshold, the determined behavior is a measurement of the first cell.

5. The setting information exhibits a first behavior when the ratio of the multiple remote WTRUs exceeds a threshold, and exhibits a second behavior when the ratio of the multiple remote WTRUs falls below the threshold. The relay WTRU according to claim 2, wherein the determined behavior is the first behavior or the second behavior.

6. The relay WTRU according to claim 1, wherein the determined behavior is related to cell reselection or handover.

7. The relay WTRU according to claim 6, wherein the determined behavior in relation to the cell reselection or the handover includes at least one of: disabling cell reselection to the cell, disabling measurement to the cell, disabling the transmission of measurement reports triggered by the cell, or lowering the priority of measurement to the cell.

8. The relay WTRU according to claim 1, wherein the first and second characteristics include at least one of a supported public land mobile network (PLMN), a configured radio access network (RAN) area, or remote WTRU capability.

9. A method implemented by a relay radio transmitter / receiver unit (WTRU), Receiving information related to multiple remote WTRUs, wherein the information includes a first characteristic related to a first remote WTRU and a second characteristic related to a second remote WTRU. Receiving configuration information related to the aforementioned relay WTRU, The determination that the first remote WTRU and the second remote WTRU are supported by the cell, wherein the determination is based on the fact that the first and second characteristics are supported by the cell. The behavior of the relay WTRU is determined based at least on the configuration information and the first and second remote WTRUs supported by the cell, wherein the determined behavior of the relay WTRU is related to the cell. A method comprising performing the determined behavior associated with the cell.

10. The method according to claim 9, wherein the determination of the behavior of the relay WTRU is further based on the proportion of the plurality of remote WTRUs supported by the cell.

11. The method according to claim 10, wherein the determined behavior is further based on the proportion of the plurality of remote WTRUs supported by the cell being above or below a threshold.

12. The aforementioned cell is the first cell, The relay WTRU is connected to the first cell, If the proportion of the aforementioned multiple remote WTRUs falls below the threshold, the determined behavior is cell reselection to the second cell. The method according to claim 10, wherein if the proportion of the plurality of remote WTRUs exceeds the threshold, the determined behavior is the measurement of the first cell.

13. The setting information exhibits a first behavior when the ratio of the multiple remote WTRUs exceeds a threshold, and exhibits a second behavior when the ratio of the multiple remote WTRUs falls below the threshold. The method according to claim 10, wherein the determined behavior is the first behavior or the second behavior.

14. The method according to claim 9, wherein the determined behavior is related to cell reselection or handover.

15. The method of claim 14, wherein the determined behavior in relation to the cell reselection or handover includes at least one of: disabling cell reselection to the cell, disabling measurement to the cell, disabling the transmission of measurement reports triggered by the cell, or lowering the priority of measurement to the cell.

16. The method according to claim 9, wherein the first and second characteristics include at least one of a supported public land mobile network (PLMN), a configured radio access network (RAN) area, or remote WTRU capability.

Images