WO2025034771A1

WO2025034771A1 - Methods and apparatus for coverage-based relay selection for multi-hop and multi-path communications

Info

Publication number: WO2025034771A1
Application number: PCT/US2024/041160
Authority: WO
Inventors: Ananth KINI; Martino Freda; Oumer Teyeb; Tuong Hoang; Jongwoo HONG
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-08-07
Filing date: 2024-08-07
Publication date: 2025-02-13
Anticipated expiration: 2026-02-07

Abstract

A first UE communicates with a second UE via a direct UE-to-UE PC5 link. The first UE receives, from the network, configuration information including conditions to trigger a relay addition procedure. The first UE may monitor and evaluate the conditions of the direct link with the second UE. Based on the monitoring, the first UE detects a triggering condition for a relay addition. The first UE monitors discovery messages from candidate relays. The discovery messages include an indication of whether the candidate relay is in network coverage (IC) or out of network coverage (OOC). The first UE selects a relay based on the indication, selecting, from all candidate relays, a relay that in IC. The first UE establishes a direct link with the selected relay. The newly established link is used for the communication between the first UE and the second UE.

Description

METHODS AND APPARATUS FOR COVERAGE-BASED RELAY SELECTION FOR MULTI-HOP AND MULTI-PATH COMMUNICATIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/531 ,279, filed August 7, 2023, the contents of which are incorporated herein by reference.

BACKGROUND

[0002] A first device may be in network coverage. A second device may be out of network coverage. The first device may support relay operation, e.g., may be able to relay traffic to/from the second device from/to a network. Device-to-device direct communication, such as communication using the sidelink channel, may be used between the first device and the second device.

[0003] A UE may be configured as a UE-to-UE (U2U) relay or a UE-to-Network (U2N) relay. Before communicating with each other, UEs may need to discover other UEs in proximity. When the UE to be found is a UE supporting relay functionality, the process of finding the relay is referred to as relay discovery. There may be two models for relay discovery: Model A and Model B. Both discovery Models A and B are supported for U2N and U2U relay discovery.

[0004] In Model A, a relay UE may send announcement messages. The announcement messages may include the ID of the relay, the relay service code (RSC), and the ID of the UEs in their proximity. In Model B, the remote UE that wants to discover a relay UE, may broadcast a solicitation message. The solicitation messages may include the ID of the remote UE and a relay service request. When a candidate relay receives this solicitation message, it retransmits the same solicitation message. The remote UE monitors the channel for the transmission of its own solicitation message. Once the solicitation messages are received, the remote UE selects a relay UE and establishes a unicast link with it.

SUMMARY

[0005] The path between a source UE and a destination UE may be a single-hop path or a multi-hop path. In a “single-hop path” there is a single direct link between the source UE and the destination UE, i.e , a single hop with no U2U relay UEs in the path. A “multi-hop path” is a path with multiple hops between the source UE and the destination UE, i.e., there is at least one U2U relay UE in the path. If there are ‘N’ U2U relay UEs in the path, the path will have N+1 hops.

[0006] A multi-path case is a case where there are a plurality of paths established between the source UE and the destination UE. In one example, a multi-path case is used for duplication of data packets, with the objective of increasing the reliability of the communication. In another example, a multi-path case is used for aggregation of data traffic, with the objective of increasing the throughput between the source UE and the destination UE. [0007] A source UE may be communicating with a destination UE using a direct UE-to-UE link. The source UE or the destination UE (or both) may be configured with one or more conditions to trigger a relay addition in the direct link. The conditions may be, for example, the detection of a Radio Link Failure (RLF) in the direct link or the detection of a measured SL-RSRP (Sidelink Reference Signal Received Power) value of the direct link being below a threshold. The conditions and the associated parameters may be configured by the network, or negotiated between the source UE and the destination UE.

[0008] During the process of selecting a relay to add, the UE may take into consideration, e.g., the number of hops between a candidate relay and the destination UE, or the measured SL-RSRP value in the link with a candidate relay. The UE may also consider the candidate relay coverage characteristics, e.g., whether the candidate relay is in network coverage (IC) or out of network coverage (OOC). For the case of OOC, the UE may further consider other factors, such as the number of hops from the candidate relay to an in coverage relay, the distance the candidate relay travelled since last in coverage, the time elapsed since the candidate relay moved out of coverage, or the number of paths available to the destination UE. Once a relay is selected from all candidate relays, the UE establishes a direct link with the selected relay. The newly established link can then be used for the communication between the source UE and the destination UE.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0011] FIG. 1 B is a system diagram illustrating an example WTRU;

[0012] FIG. 1C is a system diagram illustrating the RAN and the CN according to an embodiment;

[0013] FIG. 1D is a system diagram illustrating the RAN and the CN according to an embodiment;

[0014] FIG. 2 illustrates an example of Model A relay discovery;

[0015] FIG. 3 illustrates an example of Model B relay discovery;

[0016] FIG. 4 depicts an example of control plane protocol stack for L2 UE-to-Network relay;

[0017] FIG. 5 depicts an example of user plane protocol stack for L2 UE-to-Network relay;

[0018] FIG. 6 depicts an example of protocol stack for relay discovery;

[0019] FIG. 7 illustrates an example of a multi-hop scenario with 3 UEs 701, 702, 703 and 2 hops 704,

705;

[0020] FIG. 8 illustrates a flow chart of an example of a relay selection based on relay UE coverage characteristics; [0021] FIG. 9 illustrates a diagram of an example of a multipath relay selection based on relay UE coverage characteristics;

[0022] FIG. 10 shows a flow chart of an example of triggering a relay addition; and

[0023] FIG. 11 shows a flow chart of an example of performing a relay addition.

DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0041] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116. [0042] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

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

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

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

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

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

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

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

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

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

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

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

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

[0055] The GN 106 may facilitate communications with other networks For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. [0056] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

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

[0058] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication. [0059] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0078] A first device may be in network coverage. A second device may be out of network coverage. The first device may support relay operation, e. g. , may be able to relay traffic to/from the second device from/to a network. Device-to-device direct communication, such as communication via a sidelink channel, may be used between the first device and the second device.

[0079] The first device may be referred to as sidelink relay. The second device may be referred to as remote device. Device-to-device communication, direct communication, PC5, or sidelink terminology may be used to refer to the device-to-device link The term sidelink relay is also referred to as UE-to-Network (U2N) relay, as it provides connectivity to the network for U2N remote devices.

[0080] Both Layer 2 (L2) and Layer 3 (L3) U2N relay architectures may be supported. The L3 U2N relay architecture is transparent to the serving RAN of the U2N relay device, except for controlling sidelink resources. [0081] A UE is used as a non-limiting example of a wireless transmit/receive unit (WTRU); the solutions described apply to other examples of WTRUs.

[0082] A U2N relay UE should be connected to the network (e.g., in RRCJDONNECTED mode) to perform relaying of unicast data. For a L2 U2N relay operation, both U2N relay UE and U2N remote UE should be in connected mode (e.g., RRCJDONNECTED). Optionally, a U2N relay UE may be in any mode (e.g., RRCJDLE, RRCJNACTIVE or RRCJCONNECTED) while a U2N remote UEs are not in connect mode (e.g., they are in RRCJNACTIVE or in RRCJDLE).

[0083] A UE may operate as a UE-to-UE relay.

[0084] Before communicating with each other, UEs may need to discover other UEs in proximity. When the UE to be found is a UE supporting relay functionality, the process of finding the relay is referred to as relay discovery. There may be two models for relay discovery: Model A and Model B Both discovery Models A and B are supported for U2N and U2U relay discovery.

[0085] FIG. 2 illustrates an example of Model A relay discovery.

[0086] In Model A, a relay UE which has discovered other UEs in its proximity 201 via either direct discovery or direct communication procedures may send/broadcast announcement messages 202. These announcement messages may include the type of discovery message, user info ID of the relay, relay service code (RSC), user info ID of the proximity UEs as well as potentially other information available to relay UE (e.g., relay load etc.) The remote UE then may use this information to select the relay.

[0087] FIG. 3 illustrates an example of Model B relay discovery.

[0088] In Model B, the remote UE that wants to communicate with a relay UE, may broadcast a solicitation message 301 , which may include: the type of discovery message, user information and/or ID of the remote UE, user information and/or ID of the target relay UE, and relay service request. When a candidate relay receives this solicitation message it may then retransmit by broadcasting the same solicitation message 302 303. The remote UE monitors the channel for the broadcast with its own solicitation message. Once the solicitation messages is received, the remote UE selects a relay UE 304 from the candidate relays based on, e g., signal strength of the received message. The remote UE replies to the selected relay UE 305, which then may forward the response to the remote UE 306 .

[0089] After successful discovery, a single unicast link is established between one L2 U2N relay UE and one L2 U2N a remote UE. The traffic of U2N remote UE to the network is realized via the U2N relay UE. The data traffic of the U2N relay UE to the network and the data traffic being relayed are sent over Uu interface and are preferably separated in different Uu RLC channels over the Uu interface.

[0090] The communication between a remote UE and a relay UE may be carried using one out of two different modes, referred to as Mode 1 and Mode 2. In Mode 1 , the resources used for such communication are allocated by the network (e.g., gNB). For Mode 1 to properly operate, the two UEs may have direct connectivity with the network (e.g. gNB). In this case, the Uu interface may be used for scheduling of the U2U communication resources. In Mode 2, a pool of resources may be available for the communication and configured in the remote, and a resource may be autonomously chosen by the UE, without any intervention of the gNB. The resource pool may be configured by, e.g., the gNB/eNB when the UE is in network coverage.

[0091] For L2 U2N relay, a L2 U2N remote UE (a UE that is communicating to the network via a L2 U2N relay) may be primarily configured to use resource allocation Mode 2 for data to be relayed

[0092] The protocol stack for a L2 U2N relay is separated in user plane and control plane protocol stacks. A Sidelink Relay Adaptation Protocol (SRAP) sublayer is introduced above the RLC sublayer for both CP and UP at both PC5 interface and Uu interface.

[0093] FIG. 4 depicts an example of control plane protocol stack for L2 UE-to-Network relay

[0094] The Packet Data Convergence Protocol (PDCP) 401 and Radio Resource Control (RRC) 402 are terminated between L2 U2N remote UE and gNB, while the Sidelink Relay Adaptation Protocol (SRAP) 403, Radio Link Control (RLC) 404, Medium Access Control (MAC) 405 and Physical layer (PHY) 406 are terminated in each hop i.e., the link between L2 U2N remote UE and L2 U2N relay UE 407 and the link between L2 U2N relay UE and the gNB 408.

[0095] FIG. 5 depicts an example of user plane protocol stack for L2 UE-to-Network relay

[0096] In the L2 U2N relay, for uplink (UL) communication, the Uu SRAP sublayer 501 supports UL bearer mapping between ingress PC5 relay RLC channels for relaying 502 and egress Uu relay RLC channels over the L2 U2N relay UE Uu interface 503. For uplink relaying traffic, the different end-to-end RBs (SRBs or DRBs) of the same remote UE and/or different remote UEs may be multiplexed over the same Uu relay RLC channel 503.

[0097] The Uu SRAP sublayer supports L2 U2N remote UE identification for the UL traffic. The identity information of L2 U2N remote UE Uu Radio Bearer and a local remote UE ID are included in the Uu SRAP header at UL in order for gNB to correlate the received packets for the specific PDCP entity associated with the right Uu Radio Bearer of a remote UE. The PC5 SRAP sublayer at the L2 U2N remote UE supports UL bearer mapping between remote UE Uu Radio Bearers and egress PC5 relay RLC channels.

[0098] In the L2 U2N relay, for DownLink (DL) communication, the Uu SRAP sublayer supports DL bearer mapping at gNB to map end-to-end Radio Bearer (SRB, DRB) of remote UE into Uu relay RLC channel over relay UE Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end Radio Bearers (SRBs or DRBs) of a L2 U2N remote UE and/or different L2 U2N remote UEs and one Uu relay RLC channel over the relay UE Uu interface;

[0099] The Uu SRAP sublayer supports remote UE identification for DL traffic. The identity information of remote UE Uu Radio Bearer and a local remote UE ID are included into the Uu SRAP header by the gNB at DL in order for relay UE to map the received packets from remote UE Uu Radio Bearer to its associated PC5 relay RLC channel.

[0100] The PC5 SRAP sublayer at the relay UE supports DL bearer mapping between ingress Uu relay RLC channels and egress PC5 relay RLC channels.

[0101] The PC5 SRAP sublayer at the remote UE correlates the received packets for the specific PDCP entity associated with the right Uu Radio Bearer of a remote UE based on the identity information included in the Uu SRAP header.

[0102] A local remote UE ID may be included in both PC5 SRAP header and Uu SRAP header. L2 U2N relay UE may be configured by the gNB with the local remote UE ID to be used in SRAP header. A remote UE may obtain the local remote ID from the gNB via Uu RRC messages including RRCSetup, RRCReconfiguration, RRCResume and RRCReestablishment. Uu DRB(s) and Uu SRB(s) may be mapped to different PC5 relay RLC channels and Uu relay RLC channels in both PC5 hop and Uu hop.

[0103] It is the gNB’s responsibility to avoid collision on the usage of local remote UE ID. The gNB may update the local remote UE ID by sending the updated local remote ID via a RRCReconfiguration message to the relay UE. The serving gNB may perform local remote UE ID update independent of the PC5 unicast link L2 ID update procedure.

[0104] A UE discovery is defined as the process that detects and identifies another UE in proximity. This detection may be performed using direct radio signals. This detection may be classified as open or restricted, e.g., open for the case where there is no requirements for an explicit permission from the UE being discovered, restricted for the case where such permission may be needed.

[0105] FIG. 6 depicts an example of protocol stack for relay discovery.

[0106] The discovery layer 601 in the U2N relay UE may transmit a relay Discovery message in the sidelink channel 602 to the remote UE. The network may broadcast a maximum Uu RSRP threshold, a minimum Uu RSRP threshold, or both, which may be used by the U2N relay UE to determine if it may transmit relay discovery messages to U2N remote UE(s). The U2N remote UE may monitor the sidelink channel for the relay discovery message. The discovery layer U2N remote UE 603 may transmit a relay discovery solicitation message in the sidelink channel The network may broadcast a threshold, which is used by the U2N remote UE to determine if it may transmit relay discovery solicitation messages to U2N relay UE(s).The U2N relay UE may monitor the sidelink channel for a relay discovery solicitation message

[0107] The resource pool(s) used for NR sidelink communication may be used for relay discovery, or the network may configure resource pool(s) dedicated for relay discovery. Resource pool(s) dedicated for relay discovery may be configured simultaneously with resource pool(s) for NR sidelink communication in system information, dedicated signaling and/or pre-configuration. Whether a dedicated resource pool(s) for relay discovery is configured may vary depending on network implementation As an example, it may be that if resource pool(s) dedicated for relay discovery are configured, then only those resource pool(s) dedicated for relay discovery would be used for relay discovery procedure. As an example, if only resource pool(s) for NR sidelink communication are configured, all the configured transmission resource pool(s) may be used for relay discovery and sidelink communication.

[0108] For U2N remote UE (including both in-coverage and out of coverage cases) that has been connected to the network via a U2N relay UE, only resource allocation mode 2 may be used for discovery message transmission.

[0109] The U2N remote UE may perform radio measurements at PC5 interface and use them for relay selection and reselection and/or higher layer criteria. The remote UE may use SL-RSRP (Sidelink Reference Signal Received Power) and/or SD-RSRP (Sidelink Discovery Reference Signal Received Power) measurements to assist with the selection. As an example, when there may be no unicast transmission between the U2N relay UE and the U2N remote UE, the U2N remote UE may use SD-RSRP measurements to evaluate whether PC5 link quality towards a U2N relay UE satisfies relay selection criterion. For relay reselection, for example, the U2N remote UE may use the SL-RSRP measurements towards the serving U2N relay UE for a relay reselection trigger evaluation criteria.

[0110] A U2N relay UE may be considered suitable by a U2N remote UE in terms of radio criteria if the PC5 link quality measured by U2N remote UE towards the U2N relay UE exceeds configured threshold (preconfigured or provided by gNB). The U2N remote UE may need to search for suitable U2N relay UE candidates that meet all access layer and higher layer criteria. Additional criteria may be e.g., the PLMN ID, the cell ID. If there are multiple suitable U2N relay UEs, the U2N remote UE may need to break the tie based on some implementation specific rules.

[0111] Examples of relay selection triggers include: when the direct Uu signal strength of current serving cell of the U2N remote UE may be below a configured signal strength threshold, or when the upper layers indicate to the lower layers to start selection. Examples of relay reselection triggers include: PC5 signal strength of U2N remote UE to current U2N relay UE may be below a (pre)configured signal strength threshold, U2N relay UE indicates to U2N remote UE via PC5-RRC signaling an event such as cell selection/reselection, handover or Uu Radio Link Failure (RLF), the U2N remote UE receives a PC5-S link release message from U2N relay UE, U2N remote UE detects PC5 RLF, or upper layer indication

[0112] For L2 U2N remote UEs in RRCJDLE/INACTIVE and L3 U2N remote UEs, the cell (re)selection procedure and relay (re)selection procedure may run independently. If both suitable cells and suitable U2N relay UEs are available, it may be a UE implementation decision to select either a cell or a U2N relay UE. A L3 U2N remote UE may select a cell and a U2N relay UE simultaneously

[0113] For both L2 and L3 U2N relay UEs in RRCJDLE/INACTIVE, the PC5-RRC message(s) are used to inform their connected remote UE(s) when U2N relay UEs select a new cell. The PC5-RRC message(s) are also used to inform their connected L2 or L3 U2N remote UE(s) when L2/L3 U2N relay UE performs handover or detects Uu RLF Upon reception of the PC5 RRC message for notification, it may be up to U2N remote UE whether to release or keep the unicast PC5 link. If U2N remote UE decides to release the unicast PC5 link, it may trigger the L2 release procedure followed by a relay reselection.

[0114] The term “network" refers to a Radio Access Network. The term network coverage refers to the coverage area of a given Base Station, e g., eNB, gNB. The UE is said to be in network coverage when the received signal in uplink (at the base station) and downlink (at the UE) is such that bidirectional communication between the UE and the network, using the Uu interface, is feasible. Otherwise, the UE is said to be out of network coverage.

[0115] The term “source UE” refers to a UE that is interested in communicating with another UE or with the network, using a U2U relay, a U2N relay, or both

[0116] The term “destination UE” refers to the last UE in the communication “path,” i.e., it is the UE that the “source UE” is trying to communicate with, in a UE-to-UE communication.

[0117] The term “hop” refers to a “direct” PC5 communication link (e.g., sidelink) between two UEs. Here, the term “direct’ refers to the case where the communication does not involve any U2U relays in the middle, i.e., a hop refers to a link between two UEs when the two UEs communicate directly, i.e., without any relays facilitating the UE-to-UE communication. Each UE may each be a source UE, a destination UE, U2U relay UE, or a U2N relay UE. Examples of hops are: a direct communication link between a source UE and a destination UE, a direct communication link between a source UE and a U2U relay UE, a direct communication link between a source UE and a U2N relay UE, a direct communication link between two U2U relay UEs, a direct communication link in between a U2U relay UE and a U2N relay UE.

[0118] The term “PC5 link” or a “sidelink” refers to one direct link between two UEs, without any relays in the middle. This is the equivalent to one hop. An end-to-end communication link between 2 UEs may include multiple PC5 links, i.e., may include multiple hops.

[0119] A “path” between a source UE and a destination UE is the representation of the communication link between the two UEs. There may be one or more U2U relay UEs in a path, resulting in a plurality of hops between the source UE and the destination UEs. In the last hop, the target UE is the destination UE. Each path may include one or more hops.

[0120] A “single-hop path” is a path with a single hop between the source UE and the destination UE, i.e., there are no U2U relay UEs in the path.

[0121] A “multi-hop path” is a path with multiple hops between the source UE and the destination UE, e.g., there is at least one U2U relay UE in the path. If there are N U2U relay UEs in the path, the path will have N+1 hops.

[0122] The term “multi-path” refers to the case where there may be a plurality of paths established between the source UE and the destination UE, and the paths are different from each other. A multi-path case may be used to e.g , duplication of packets (increase reliability) or aggregation of data (increase throughput). One of the paths may be a single-hop path. Two paths are considered to be different if at least one hop is different.

[0123] FIG. 7 illustrates an example of a multi-hop scenario with 3 UEs 701 , 702, 703 and 2 hops 704, 705. [0124] The multi-hop scenario may be a natural extension of the single hop case, where multiple paths may be used for duplication of packet with the objective to improve the reliability of the system. UE1 701 may be the source UE and it may be IC or OOC UE2 702 may be the relay UE, and it may be also IC or OOC. . UE1 cannot reach UE 3, so the intermediary relay may be needed, which may be UE2702operating as a U2U relay. UE2 702 functions as the intermediary relay, and it may be referred to as the target UE as it is the UE being targeted by UE1 , or first in the path. The multipath scenario is when the source remote UE 701 may create two separate paths to the destination (e.g., network). UE3703 is the destination UE, and it is in coverage, and it may operate as a U2N relay.

[0125] U2N relay UEs may have a very simple connectivity architecture and network coverage. The U2N source remote UE may be out of network coverage, while the U2N relay UE should be in coverage to be able to reach the network; the source remote UE may have a single unicast link with the U2U relay UE (e.g., sidelink). The U2U relay may have more variations of topology and coverage situations, such as one, two, or all the UEs either in coverage or out of coverage, and/or operating in Mode1/Mode2, resource pool configuration, as well as same or different relays serving a single source UE with multiple connections to different destinations or vice versa When in coverage, the U2U relay UE may be in RRCJDLE, RRCJNACTIVE or RRC_CONNECTED. Furthermore, any remote UE may initiate a relay discovery or (re)selection procedure.

[0126] New conditions for discovery and relay selection may be considered for multipath cases (to ensure QoS requirements). Additionally, given that multi-hop scenarios may lead to different coverage situations for both relays as well as remote UEs, various new criteria may be considered to ensure optimal relay and path selection and to reduce any potential unnecessary discovery message transmissions that may occur.

[0127] Remote UEs may be communicating, either directly (using a direct PC5 link/sidelink) or indirectly (via one or more UE-to-UE relays). A remote UE may also communicate with a gNB (via a combination of one or more UE-to-UE (U2U) and or U2N relays). Multi-hop and multi-path communication may apply for both U2U as well as U2N cases. The solutions described herein apply to both U2U and U2N relay scenarios, for both multi-hop and multipath scenarios.

[0128] A source UE communicating with a destination UE via an existing path may trigger procedure to add a new path. If source and destination UEs are communicating via an existing path, and a new potentially better path is discovered, the source UE or the destination UE may trigger a procedure to add the newly discovered path The UEs may utilize both paths, on a temporary basis, to evaluate whether the new path is in fact better than the existing one, before deciding to switch to this new path. The classification of being better may depend of several parameters.

[0129] The source or destination UE may monitor the different paths. To differentiate the paths, , a different source and/or destination UE ID may be used on each path. The source UE may then duplicate a certain number of packets and send the same packet, at the same time, over both paths using different IDs. Optionally, an additional flag may be included in the packet, e.g., PDCP header, e g., different path IDs for the first and second path. By comparing the arrival times of packets with the same Sequence Numbers (SN) over the two paths, the remote UE may determine which of the paths may be performing better in terms of latency or throughput. The source UE may then select the best path to use.

[0130] In one example, the path selection decision may be based on throughput. The source UE may send an equal number of packets over both links and the determination of the throughput may be performed at the destination UE (e.g., how long it took to receive all the packets over each link). Based on the throughput determination (i.e., lower latency in this case), either the first path may be kept or a switching may be made to a new path This may be triggered either by the destination UE or by the source UE, based on information provided by the destination.

[0131] In another example, the selection decision may be based on requirements, e g., on latency and/or total throughput and/or reliability the performance of each of the links may not be good enough for them to operate individually, as a single path. In one example, when adding a second path, the first path may be suitable for one bearer (e.g., low latency, low throughput bearer) while the second path may be suitable for another bearer (e.g , high latency, high throughput bearer). In such cases, keeping both paths may be the optimal decision. For example, both paths may be used for duplication (e.g., for bearers requiring high reliability); each path may be used for the bearers that require a QoS that matches the path’s latency/throughput; or a bearer may be sent over both paths, i.e., perform aggregation by sending some packets of a given bearer over a first path and other packets of the same bearer via the second path, to increase the throughput for that bearer. Other combinations are also possible.

[0132] Solutions for relay selection based on relay UEs coverage characteristics are described.

[0133] A source UE may perform relay addition or relay reselection based on the destination of interest, e.g., if it wants to communicate with another UE or with the network. During the selection process, the source UE may take into consideration the number of hops between the candidate relay UE and the destination UE. The source UE may also consider the candidate relay UEs coverage characteristics, i.e., in network coverage or out of network coverage. For the case of out of coverage, the source UE may further consider other factors such as the number of hops from the candidate relay UE to an in coverage UE, the distance the candidate relay UE moved since last in coverage, the time elapsed since the candidate relay UE moved out of coverage, or the number of paths available to the destination UE.

[0134] The conditions to trigger relay discovery and/or relay (re)selection may vary. For example, the trigger may be based on measured RSRP: when the RSRP measurement for direct (PC5) or indirect (relay - PC5 or Uu) link is below a threshold, reselection may be triggered

[0135] Another trigger example may be based on number of hops in a path: the availability or discovery of a new U2U relay with fewer number of hops (shorter path) to the network or to a destination UE, as compared to the current hop count to the network, or to the destination UE; or the availability or discovery of a new U2N relay reachable with fewer number of hops (shorter path) as compared to the current hop count to the network. [0136] In another example, the trigger may be based on the received path information, which may be included in a discovery message. For example, if there is a path with a relay that is currently operating as a U2U relay, but may potentially operate as a U2N relay (e.g., the relay may be in IDLE mode and may potentially move to RRC-CONNECTED) and enable a shorter path to the network, then that path may be preferred because it may potentially be enabled.

[0137] Another example of a trigger may be based on latency: a reselection triggered by the E2E latency exceeding some threshold value, optionally with a hysteresis parameter to avoid ping-pong effect. End-to-end latency may be based on a timestamp included by source which the destination remote UE may use to calculate end-to-end latency. This may then be provided as a measurement to the source UE.

[0138] Another trigger example may be conditional QoS of service - e.g., if the current service permits triggering of reselection, where it may tolerate some service interruption, as opposed to a QoS requirement where limited service interruption may be tolerated. In another example, the establishment of a new QoS flow, which may result in requirement for improved redundancy or for additional bandwidth, which may result in the need for a second path, may result in triggering selection of a second path (when an initial path already exists). The establishment of the new QoS flow may also result in the changing the requirements for improved latency, triggering relay reselection and/or path switching or path addition (e.g., to increase the throughput by traffic aggregation or to increase redundancy by packet duplication).

[0139] A remote (source and/or destination UE) UE may trigger relay reselection, possibly for any of the reasons above, or others, where reselection of two separate relay paths may be selected. In one example, when a second path is needed, the initially established path may be used to communicate information to facilitate the selection of a second path, for e.g., the two remote UEs may exchange information regarding existing paths/relays using the first path to facilitate the selection of the second path [0140] In another example, the initial trigger for relay selection may result in two paths being selected right at the onset. This may be based on QoS needs of the service and link quality of paths, e.g., if the link quality of one path is insufficient and two paths are required, e.g., to ensure that the reliability requirements (duplication) and/or bandwidth needs (aggregation) are met.

[0141] In an example, a change in remote UEs traffic characteristics may result in a U2U relay UE triggering an RRC connection establishment with the network to operate as a U2N relay. For example, a remote UE may be communicating with the network via multi-hop U2U relays, and a final U2N relay. A U2U relay along that path may be in coverage but may be in RRCJDLE state. The U2U relay UE may trigger an RRC connection establishment with the network as a possible means to reduce the number of hops in the multi-hop path between the remote UE and the network. In this case, the trigger to RRC_CONNECTED of the relay UE may be based on latency (e.g., current multi-hop path exceeding a configured threshold, which may be determined via measurements) or may be based on the remote UE initiating a new QoS flow requiring a shorter path to the network (e.g., based on exchange of QoS information at the establishment of the link) or based on some information shared among the UEs in the existing path.

[0142] Discovery transmission and relay reselection may be triggered by either an Access Stratum (AS) layer criteria (e.g., received PC5 signal strength, path information etc.) or by an indication from the upper layers (e g., application layer trigger) of the remote UE. The type of connection set up may determine how discovery may be triggered. For instance, a remote UE (e.g., source and/or destination UE) that has a multi-hop path with another remote UE may trigger a discovery at AS layer (as opposed to waiting for an upper layer trigger) as a means of maintaining an alternate path available, which can then be provided to upper layers e.g., when a path switch is needed, possibly reducing latency and/or minimizing data interruption or data loss. In another example, a remote UE (e.g., source and/or destination UE), which is configured with an end-to-end path that has a number of hops which is larger than a threshold, may trigger discovery at the AS layer to constantly search for a shorter path. As another example, a remote UE configured with an end-to-end path that has latency above a threshold may trigger discovery at the AS layer to constantly search for a shorter path while that condition may be true. That threshold may be below the latency requirement for the service in that path.

[0143] Once selection or reselection is triggered, the remote/source UE may need to select one or more U2U relay UEs from a set of candidate U2U relay UEs to communicate with a destination UE The remote UE may utilize the relay UEs coverage and/or mobility characteristics and path information when performing the U2U relay selection. For example, if the remote UE is aware (e g., via discovery) of the coverage status or other aspects of relay UE’s mobility information, it may use this information when performing U2U relay selection. For instance, a U2U relay UE may include, in discovery message, coverage status: In Coverage (IC), Out Of Coverage (OOC), multi hop or single hop, number of hops to IC, number of hops to network, mobility status (fast or slow moving), etc.

[0144] In a multi-hop case, a remote (e.g. , source) UE may choose, for example, the path that has the most in coverage (IC) U2U relay UEs. In this case, a remote UE may utilize other mobility information that may be available for relay selection. For e.g., OOC relay UEs may provide distance information (e.g., distance moved since falling out of coverage, time since relay UE went OOC, hop count to another in coverage relay UE, etc.). The remote UE may be configured with thresholds for each of these parameters, where the threshold depends on the type of service (e.g., QoS). Alternately, the remote UE may be able to implicitly derive appropriate (time/distance/hop count) thresholds for the relays in the path based on its QoS data (e.g., latency, bandwidth needs based on throughput etc.). This may then be used for relay selection purposes.

[0145] For example, a remote UE that performs U2U relay selection may select an initial path and decide on a set of U2U relay candidates for a second path. The UE may then select a relay UE from that set, or optionally may pre-select the path and then start a timer and/or wait for a trigger before establishing of the second path. The trigger may be based on notification from the destination that one path may be insufficient or inadequate. This could also be based on the source realizing the first/initial path may be insufficient (e g., if volume of buffered data may be increasing or rate of depletion may be insufficient, need for additional bandwidth due to a new QoS flow, etc.) The timer for the second path may be a timer that indicates when to select the second path (complete the selection process), or a timer that indicates the viability of this second path, meaning if the timer expires and the trigger condition for selection of this second path are not met, it drops it. If the selection of the second path is not successful for any given reason, the UE may need to start over the selection of the initial path.

[0146] In an example, a remote UE may select multiple paths (possibly via multiple relays) to the destination. This may be done for the purposes of redundancy, duplication, reliability, additional bandwidth needs etc. For example, the remote UE may be configured with a mapping between bearer configuration/QoS and the minimum number of paths required.

[0147] The selection of multiple paths may be done at the very onset (i e., multiple paths are initially selected, simultaneously), or alternatively, the remote UE may select an initial path and add a second path if the need arises (e g., need for additional bandwidth due to a new QoS flow/service) or even opportunistically as a backup in case the need arises later (e.g., increased in CBR, increase in number of hops, decrease in RSRP, etc.)

[0148] In one scenario, the source and destination may utilize the original/initial path to facilitate selection of a new (single) path or a second path For example, if the destination UE finds a new path to source, it may then indicate this to the source UE. In another scenario, if the source UE initiates a new QoS flow which requires a new path, it may indicate this to the destination UE, which may trigger the destination UE to send this new path information to the source

[0149] FIG. 8 illustrates a flow chart of an example of a relay selection based on relay UE coverage characteristics.

[0150] A source UE has a single hop, direct PC5 connection established with a destination UE 801. The source UE may be configured with a hop count threshold (hopCnt_{OOC_to_IC}), indicating number of hops to reach an in-coverage relay UE, and/or a time threshold t_{OOC} for determining time since a relay moved from in coverage to out of coverage 802. The source UE may receive discovery messages 803 from one or more U2U relay UEs 804 containing relay coverage status, e.g., IC/OOC indication; if OOC, a number of hops to the next relay UE that may be IC (hop_relay_IC); if OOC, a period of time since the relay UE was last IO (t_relay_IC).

[0151] The source UE may monitor PC5 connection link for potential selection trigger events 805, e.g , the source UE detects RLE in any hop along the path to the destination UE, or the source UE detects SL-RSRP falling below a predefined threshold in any hop along the path to the destination UE 806. Upon detection of SL- RLF with the destination UE, or SL-RSRP < threshold, if at least one U2U relay UE is IC, the source UE may select a relay UE among those IC relay UEs 807. If no potential relay is in coverage, the source UE shortlists a set of relay UE(s) based on time elapsed t < t_{OOC}, and/or hop count threshold hopCnt < (hopCnt_{OOC_to_IC}) and selects a relay from the shortlisted relay UEs 808.

[0152] FIG. 9 illustrates a diagram of an example of a multipath relay selection based on relay UE coverage characteristics.

[0153] The candidate relay UEs transmit a discovery message 901. The discovery messages may contain, among others, parameters such as: an indication if the UE may be IC or OOC (tagged IC and OOC); if OOC, the number of hops to a relay UE that is IC (Hop-Relay-IC); and if OOC, the time since the relay UE was IC (Time-Relay-IC) The source UE creates a candidate list based on the receive information 902. The source UE then selects a relay from the candidate list 903.

[0154] After the path is established with the selected relay UE 904, the source UE continues to monitor the sidelink connection link 905 for potential selection/reselection trigger events 906. Possible trigger events were described in previous paragraphs. The source UE continues to monitor and process the discovery messages received from the candidate relays. If a path addition is triggered, the source UE may select a relay from the candidate relays it is monitoring list. Otherwise, if all relays are OOC, then the source UE may check if the value of received in the Discover message for Hop-Relay-IC and Time-Relay-IC are less than their configured thresholds, and the source UE may select a relay from the list of candidate relays that satisfies that condition. [0155] The source UE may also classify and order the remaining relays in order of preference based on different criteria. The source UE may create a prioritized list of candidate relays. Optionally, after the first path is established, the source UE may monitor the status of its QoS flows, such as buffer size, latency, PER, etc., and compare with the requirements for each service. Based on such comparison, and/or other factors, the source UE may decide to establish a second path with a different relay UE. The source UE may use the prioritized candidate list of relays to establish the second path. The source UE may run a timer after which the candidate list may be obsolete and it needs to refresh it by processing the discovery messages from the nearby relay UEs. As another example, the new relay UE may signal some information to the source UE triggering the addition of another path. Based on the configured candidate relay classification 907, the source UE selects the best relay from the candidate list 908.

[0156] The examples discussed are not intended to be limiting, as the selection of a second path may not be required and/or the trigger for establishment of a second path may be different, or the source UE may not support multi-paths.

[0157] In the examples discussed, the source UE may be receiving discovery messages including In Coverage (IC) or Out of Coverage (OOC) information, and for the case of OOC, the number of hops to the next relay UE and/or the time elapsed since last IC from the destination UE (or candidate relay UE). However, this information may be instead sent by UEs that are already in the existing path, or even from the network.

[0158] In one embodiment, a relay UE may provide information about its coverage characteristics in a message (e.g , discovery message). The relay UE may provide additional information to the remote UE, e.g., in the Discovery message or a message specific to share relay capabilities. Some examples are the preferred mode of resource allocation (e.g., Mode 1 vs. Mode 2), support of carrier aggregation, including e.g., the number of carriers supported, the type of carrier, if licensed or unlicensed; support for HARQ feedback (e.g., PSFCH configuration in the resource pool); It may also provide its current state, e.g., the RRC state (e.g., RRC_CONNECTED vs. RRCJDLE vs RRCJNACTIVE); relevant measurements such as CSI report; current reachability to U2N relays; indication if it is IC or OOC, including the distance and/or time moved once OOC. This information may be dependent on the time elapsed and/or distance moved where if the time or distance moved exceeds some threshold it stops reporting this information.

[0159] In one solution, a U2U relay UE that is out of coverage may connect to the network/gNB/eNB via a U2N relay and may provide this information via its own discovery message. The U2U relay UE may know (e.g., via U2N discovery), that it may connect to the U2N relay UE. The U2U relay UE may then include this information in its discovery message. This information may then be obtained by a remote UE that may be looking to connect to the network. In one example, the remote UE may send a solicitation message, and the reception of this message by the U2U relay UE may trigger the U2U relay UE to announce its capabilities. The U2U relay UE may announce that it is not a U2N relay, but that it is able to connect to a U2N relay.

[0160] In one example, if the remote UE is only able to connect to the network via multiple U2U relay UEs that are out-of-coverage, the discovery message of the in-coverage U2N relay could be received by the U2U relay UEs and be forwarded to the remote UE.

[0161] In another example, the discovery message that announces the reachability of a U2U relay UE to a U2N relay UE may include a hop count, k, where a hop count of ‘0’ indicates that this relay itself is the U2N relay, whereas a hop count of ‘k>0’ indicates the number of hops to an in coverage U2N relay is ‘k’. Knowing whether the relay UE is directly connected to the gNB for U2N discovery may be useful from the remote UE’s perspective, as it then knows whether the relay UE is in coverage or is out of coverage and if it is relying on another U2N and/or U2U relay to communicate with the network. This may also be beneficial for the remote UE for relay selection purposes, since it may receive multiple discovery messages indicating several paths to an in coverage (e.g., U2N) relay, allowing the remote UE to utilize this hop count information for relay selection. Additionally, for multi-hop paths (e.g., for both U2N and U2U) having one or more (U2U and/or U2N) relays being in coverage and/or in RRC_CONNECTED may be useful from a latency and reliability perspective.

[0162] In an example, an OOC relay UE may determine whether to transmit/forward discovery messages from other relay UEs based on the RSRP of the received discovery message. For instance, if the RSRP of a received discovery message is larger than a threshold, and the received discovery message represents a relay with fewer hops to the network, the said relay UE may not transmit its own discovery message as it may infer that there is a relay UE with fewer hops in the vicinity which is already transmitting a discovery message with large power.

[0163] The relay UE may also provide the total number of available paths to a remote UE, including e.g., length in time or hop count of each path and/or path information. In an example, a relay UE that receives path information regarding reachability to a remote UE, may indicate complete path information (i.e., hop count for all available paths to the remote UE). There may be a limit such that the relay UE considers only paths with less than a certain hop count or distance or latency to the remote UE, e.g , based on a configured threshold, and then start to include only limited path information (e g., some subset of paths, shortest paths, etc.)

[0164] The relay UE may also include the number of paths with overlap information between paths, when applicable. For instance, if a relay UE may reach a UE ‘x’ via multiple paths, it may include information regarding how many paths have no overlap, and for those that do have some degree of overlap, the number of overlapping hops (e.g., as a percentage, ratio of overlapping hops to total hops etc.).

[0165] The relay UE may provide (any) of the above information based on the remote UE’s needs (e.g., indication requesting the information via solicitation). In one example, a remote UE may indicate the need for the above information (e.g., path, coverage status etc.), and may indicate this in its Solicitation message. In another example, the relay UE may provide just normal discovery (e g., legacy) with no added coverage characteristics, if it receives no indication from the remote UE.

[0166] The relay UE may also indicate the unicast link status of hops in the path. For instance, a relay UE may include information regarding whether any of the hops in the path have unicast link already setup; it may also provide information on the number of hops that have a unicast link setup, or alternatively a percentage relative to the number of total hops in the path. The remote UE may use this information for path selection. E.g., perform relay selection based on the fact that the QoS has some latency requirement, which may translate to some maximum number ‘y’ of unicast links that will require a setup procedure to create a path. Knowing how many hops in a path need a unicast link to be setup may allow the remote UE to eliminate some these (as the latency may not be able to be guaranteed).

[0167] In another example, the relay UE may be configured by the network to provide any of the above information. This may be done by providing two different configurations, where one indicates a basic discovery message transmission and the other results in an enhanced discovery message with some or all of the above information. The network may dynamically request the relay UE to change between the basic to the enhanced message or vice versa.

[0168] A relay UE may choose to provide an enhanced discovery message (with the above-mentioned information) (or a basic discovery message), only if it hears other relay UE’s announcement messages that also are providing this information in their announcement messages. This may be an indication that the other relays have been asked to provide this information and therefore it too should (or should not) do so.

[0169] When sending the information/parameters above, the relay UE may provide one or more parameters, i.e., any combination of the above parameters, for instance, a preconfigured subset of parameters may be configured by the network or the subset may be based on a request from the remote UE e.g., in a solicitation request message. Optionally, different triggers may be used to trigger the transmission of each specific parameter.

[0170] In one example, the relay may choose to provide information regarding multiple paths (and the number of hops for each path) to reach a given remote UE. In another example, the relay may choose to include information for just the best path to the given remote UE. The relay UE may monitor the paths, and if a better path is found, it may report the newly found path to the remote UE. The relay UE may choose to include only path information of paths that contain a given number of hops, or less. For instance, the solicitation message from a remote UE may indicate the maximum path length that remote UE is interested in discovering, and it may indicate all relay candidates or a particular relay candidate. E.g., “interested in relays that may access the destination UE in less than or equal to 3 hops”. The relay UE may use the discovery solicitation messages it hears from other relay UEs to determine the information regarding multiple paths. For instance, a first relay UE may know that there may be another second relay UE that may provide a connection to the network UE via another third relay UE. In addition there may be a case where first relay UE knows that there may be a shorter path through another relay UE which may be less than this one, and it may report this shorter path. There may be a minimum of ‘k’ hops of difference between paths in order to justify the triggering of the report of another path

[0171] In one solution, a relay UE may include only limited information in the discovery message, as described above, and may provide more detailed path information upon request by the remote UE (e.g., in a discovery solicitation message, or a follow-up message after the remote UE receives discovery message from other relay UEs).

[0172] In one example, a relay UE may include information related to only one path when multiple similar paths exist. The relay UE may select a representative path for which to include the path information. Path similarity may consist for example of paths with the same number of hops or paths having common relay UEs. [0173] A relay UE may transmit two different discovery messages with different periodicity/frequency. For instance, a relay UE may transmit a short discovery message more frequently, and a detailed discovery message less frequently, where the detailed discovery message may contain more details about the path information. The relay UE may further indicate, in the short discovery message, that it will transmit detailed discovery/path information, and potentially include a schedule or periodicity of the transmissions of future discovery messages, so that interested remote UEs can listen to the messages in the specified time intervals and/or frequencies.

[0174] The relay UE may transmit discovery information for multiple paths (e.g., shorter path and a longer path). This may be based e.g., on relay service requirements (e.g., QoS, bearer configuration etc.), link quality, or path information. In one example, a relay may include in its discovery message information for more than one path to a remote UE, where one path (e g., the shortest path) may be best for low latency, while a second path may have more hops may but may have a better link quality over each hop, which may be better from a reliability perspective.

[0175] Additionally, the relay UE’s geographic information may be used to determine whether to transmit a discovery announcement message. For example, if the first U2U relay UE knows that there is a shorter path to a remote UE (shorter by at least ‘k’ hops) via a second U2U relay UE, and that the second U2U relay that provides a shorter connection to the destination, but it may be in a different geographic area (as determined by zone ID, distance, coordinates, or other similar parameters), then the first U2U relay UE may decide to advertise this path information - as it may be useful for a different subset of remote UEs which are in that geographic area.

[0176] In one example, the type of discovery (e.g., U2U or U2N) and designation of UEs along the path may determine the relay UEs’ behavior in terms of deciding what information (e.g., path information) they may include in their messages (e.g , in their announcement messages). For instance, a UE that has more than one path to the network and it is a U2N relay may decide which paths to include in its own message (e.g. announcement message). In one example, the hop count of each of these paths may be considered and the relay UE may only include the shortest path in its announcement. If there are multiple paths with the same distance (e.g., number of hops), then the relay UE may include all of them. In another example, the relay UE may include the shortest ‘n’ paths or all paths that are less than some configured hop count ‘k’. In another example, the relay may include path information only for those paths that have no overlap or paths where the overlap may be below some threshold (e.g., y% of hops overlap of y% of U2U relays overlap) In another example, in addition to the overlapping hops, the relay may consider whether the overlap may be one contiguous overlap (several hops in a row) or non-contiguous overlap (just the U2U relays overlap). Additionally, the relay UE may consider the link quality of the paths by factoring the link quality of the overlapping hops relative to the link quality of the non-overlapping hops in the path. In one example, the relay UE may sometimes transmit discovery with only the shortest path information and may sometimes transmit discovery with information on all available paths.

[0177] A relay UE that receives multiple solicitation messages from a remote UE (e.g. , source remote UE), may choose to forward all solicitation messages received from other relays, or just a subset of the solicitation messages. In one example if a relay UE that receives more than one solicitation from a remote UE, it may decide to forward just one or both based on the number of hops from the source and/or the number of hops to the destination remote UE that this source may be trying to reach.

[0178] In an example, if the relay receives multiple solicitations from the same remote UE, it may only forward the one with the lowest hop count and/or based on relative the link quality of the hops along the paths if this information is available. In another example, the relay may choose whether to forward one or both received discovery messages based on the distance (e.g., number of hops) to the destination remote UE. This could also be based on factors such as the QoS of the data being served, whether the service requires just one path or more than one path (e.g., for duplication), or other factors herein.

[0179] In an embodiment, the remote UE triggers the relay selection if it finds a path that is “k” hops shorter than the original path. For instance, if two remote UEs are communicating via a multi-hop path, the discovery of a new shorter path and/or an issue with the current path may result in relay reselection being triggered. Path shortening may be triggered by any UE along the path (e.g., by remote UEs, relay UE) based on different triggers. A source remote UE may trigger path selection based on the source remote UE transmitting discovery periodically and receiving a discovery response that indicates a shorter path may be available In another example, the remote (e.g., source) UE may compare the length of the newly discovered path with the existing path and only trigger relay selection if the new path is at least some ‘k’ hops shorter than the original path. The value of ‘k’ may be pre-configured or signaled from the network while the UE was IC. The value may map to the type of service/ QoS of current data and/or any potential new data that may be served, as well as the length of the current path Different values may be configured for different types of service/QoS

[0180] In one example, ‘k’ may be implicitly derived from the current path length and the current links performance - for e.g., if the destination remote UE provides some feedback based on the End-to-End (E2E) of the current path (e.g., based on E2E latency exceeding some threshold), the source remote UE may use this to calculate the maximum length of a new path (e.g., new path needs to be at least ‘k’ hops less than current one to ensure latency threshold isn’t exceeded). This may then be used as a criterion for initiating path shortening procedure. In another example, ‘k’ may be configured based on Constant Bit Rate (CBR). For example, for higher CBR, the network may configure a smaller value of ‘k.’

[0181] The trigger of reselection for path shortening may be conditional on the QoS requirements for the remote UE, i.e., A remote UE may choose to trigger reselection for path shortening only if the QoS permits it. For instance, if the service may tolerate some data loss and/or service interruption (while switching paths), the remote UE may trigger a path shortening. However, if the service may tolerate no interruption, the remote UE may opt to wait. An end-to-end bearer configuration may include an indication of whether path shortening is allowed when the bearer is established. For example, an end-to-end bearer configuration may include a threshold buffer status below which path shortening is allowed If the buffer status for the bearer is above the threshold, the UE may not perform such path shortening. [0182] Link quality of new and current paths may be used for reselection trigger. In an example, if the source UE detects a shorter path, and the link quality of the new shorter path may be better than the link quality of the existing path, a path reselection may be triggered. This may be based on a comparison (e.g., min/max/average) over each hop for both paths, where for e.g., the link quality of the worst hop on the new path may be no worse than the best hop link quality of the original path. This would guarantee that the remote UE only switches if the new path may be shorter (ensuring lower latency) and the link quality may be at least as good as the link quality of the original path.

[0183] The destination UE may inform the source UE of the need for a shorter path based on some conditions at destination being met (e.g., destination measures end-to-end latency of current path based on conditions described herein), and then may inform the source UE if one or more of the parameters exceeds some threshold, and then the source UE may choose to trigger reselection for path shortening purposes.

[0184] In an example, a remote UE (e.g., source) may be configured with a prohibit timer between triggers of relay selection, i.e., based on a first reselection, the source UE may not trigger a second reselection for a period of time based on this prohibit timer. The UE may determine the value of the timer based on current path length, QoS characteristics of data, resource usage (e.g., CBR), relay coverage status of current path (e.g., how many relays in current path are IC), mobility information of OOC UEs in path - i.e., time/distance moved since being OOC, etc. The length of the current path may determine the length of the prohibit timer between path reselections. For instance, a path that may be several hops in length may need quicker action in terms of triggering reselection (to minimize delay). Accordingly, a shorter prohibit timer may be used for longer paths, whereas if the current path is short a larger value may be used for the timer In another example, the timer may be based on the current path length and the 'k' (where new path needs to be at least ‘k’ hops shorter than current path as mentioned previously). A longer timer may be used when ‘k’ is small vs. a larger ‘k’ value (since the larger ‘k’ is guaranteeing a significantly shorter path than the current one.)

[0185] The source UE may trigger discovery message transmission (e.g., model B solicitation) based on conditions that may indicate an issue along the current path. For example, if the source (remote) UE notices an increase in its current buffer status, arrival of new data with lower latency requirement, measurement data that may be available to the remote UE indicating an issue with the link quality for any of the hops along the current path.

[0186] Relay UE may trigger discovery message transmissions (e.g., model A announcements) based on information available at the relay UE. In an example, a change in the relay’s load conditions, which could be based on active connections and/or new connections since the original path was instantiated, and the relay realizing, through other relay discovery messages, that a new shorter path may be available, may result in the relay UE triggering a discovery message transmission which source remote UE may use as an indication for triggering a new path shortening or reselection. [0187] In one scenario, the source UE may need to be informed of any change in the current path to a destination UE. In an example, a relay UE communicating to a destination UE via one or more relay UEs may observe that a shorter and/or direct path may be available to this destination UE. If this relay is part of an existing multi-hop path to a destination UE currently being used by a source UE, this UE may benefit from this newly available shorter path. The relay UE may use RRC messages over sidelink channel to communicate this change to the source UE. Alternately, this change may be advertised via announcement messages, which may then be forwarded to the source UE, either directly or via other relays This information may then be used by the source UE to determine whether it should trigger a relay reselection.

[0188] For multipath scenarios, path selection may be performed to ensure redundancy for duplication. Path selection may ensure that only paths that have no overlap are selected by the remote UEs. For e.g., duplication may require that there is no common relay (hops) for the different path of the multipath to increase transmission reliability.

[0189] In an example, duplication may need separate paths where relay UEs along the path are different (no overlap), wherein even if the UEs are using the same channel (e.g., frequency/carrier), having the paths being different is sufficient from a duplication requirement.

[0190] In an example, The UE may be configured with a threshold RSRP and, having already a first path established, it may select a path that is above the threshold and that there is no overlap with the first path in any of the hops . If there are no paths without overlap that satisfy the threshold RSRP requirement, then the UE may select an overlapping path that is above an RSRP threshold.

[0191] In another example, the UE may select the path based on QoS of data being served. For example, the remote UE only selects non-overlapping paths if the bearer configuration requires it. In another example, bearers may allow a degree of overlapping - e.g., between some minimum and maximum degree of overlap (based on number/percentage of overlapping/common hops shared for the paths). The remote UE may then only select paths where the degree of overlap does not exceed these thresholds.

[0192] The overlapping in the paths may be permitted for duplication as long as there are other mechanisms to provide redundancy and improve reliability. For instance, carrier aggregation over the overlapped paths, enabling HARQ feedback (if it is not already enabled), change in transmission parameters such as MCS, transmit power etc The sidelink configuration information may be provided by the network (e.g., preconfigured by gNB). The relay UE knows which configuration to apply based on whether the path is overlapped or nonoverlapped. The relay UE may use two different carriers when it is part of an overlapped path. Alternately, the UE may choose to utilize a more conservative MCS when the paths are overlapped, vs. a less conservative and more aggressive (e.g., , higher MCS) when there is no overlap. The relay UE may utilize a lower transmit power for the non-overlapped case, and a higher transmit power when the paths overlap

[0193] In the presence of overlapped paths, where only certain data require high reliability (relay serves multiple connections, where only one subset requires high reliability), the relay may apply different configurations for each path. This may be based on LCP restriction, ingress-egress mapping for the logical channel. These changes may be performed via a pre-configuration or dynamically (for e.g., changing ingressegress mapping from say N:1 to N:M for the new logical channels).

[0194] In an example, a remote UE may maintain the identity of a set of relay UEs for a multi-hop path. This may be the case for ensuring no service interruption (e.g., based on QoS of service) The remote UE may do this by triggering a discovery procedure at the AS layer (e.g., based on current paths link quality). The remote UE may provide this information to upper layers, which may be used to facilitate a path switch while ensuring service continuity in case a path switch needs to be carried out. Additionally, the source UE may inform the relay of the appropriate configuration to apply (since it knows the end-to-end paths and whether the paths are overlapped).

[0195] A UE that has selected a path may provide the network with measurement reports for other relays (e g., relay UEs that it has discovered). This may be useful for the network when it is needs to configure duplication (for U2N), as discussed in above paragraphs. The network may have limited knowledge of paths to a UE, which may limit the usefulness of reports provided by the remote UE. In one scenario, a remote UE may provide the network with measurement reports on a relay that it may communicate with, but that it also is on a path that is common (overlaps) with the current path. This information may not be useful, for example, if the gNB is relying on this measurement report to configure duplication. For duplication, it is preferred to have non-overlapping paths to maximize diversity. Thus, providing measurement reports for overlapping paths would result in a waste of signaling with no benefit.

[0196] To address this, the gNB may configure a measurement event with a condition or a measurement report that provides the path information. For instance, the remote UE may be configured to report the path information (partial or complete) to the network, together with the measurements The remote UE may report path information of all reachable relay UEs (e.g., U2U relays) based on received discovery messages.

[0197] In one example, the remote UE may receive a discovery message with path information from a first relay UE and also from a second relay UE - and the first relay UE is able to reach the second relay UE. This allows the remote UE to know the path information for up to two hops away.

[0198] In another example, the path information may be passed hop by hop. For example, a relay UE that is second-closer to the gNB may get the path information from the closest relay UE to the gNB, the third-closer relay UE from the gNB may get the path information from the second- closer relay UE (i.e. , the path information between the 2nd relay UE and the gNB), and so on, until the remote UE gets the full path information to the gNB The remote UE may then provide this full path information to the network. This information may help the network make decisions regarding measurement configuration parameters, thresholds and event criteria.

[0199] In another example, the remote UE may only have complete path information for some limited number of hops from the source (e.g , two hops), and also a hop count indicating the total number of hops to the U2N relay and/or to the network. The remote UE may then report this information to the network (i.e., hop count, and path information for up to the hops where path information is available). The network may be able to utilize this information to infer whether there is overlap between two paths. Fore.g., if the remote UE provides complete path information for two hops and indicates that the gNB is ‘k’ hops away, the network may utilize the value of 'k to determine the measurement reports usability for initiating a second path. For example, if the source provides complete path information for 2 hops, but ‘k’ is » 2 (say 8), then the network may deem this report not particularly relevant when it comes to the determination of the overlap of this path with the current path On the other hand, if k is 4, then the network may be more confident that the chance of this path overlapping with current path is small.

[0200] The remote UE may be configured with a measurement event configuration that may have one or more triggering conditions. Triggering conditions could be, for instance a minimum RSRP/RSRQ of a path - e.g., minimum link quality of any hop on a path; an average/median RSRP/RSRQ of path - e.g., average of the link quality of all the hops on a path; a maximum overlap level for path - e.g , based on number or percentage of overlapping hops, etc.

[0201] The network may also configure multiple events based on whether it is targeting duplication, aggregation or path selection/reselection. It may select appropriate threshold values for each of the parameters

[0202] In one example, if the network is targeting a path for duplication, it may configure the minimum RSRP threshold for the path to be some ‘RSRPjnin’ value, while setting overlap factor ‘Overlap_pct’ to be 0. This would ensure that the path has some minimum acceptable link quality while ensuring no overlap between the reported and existing paths (for increased diversity). If, instead, the network is targeting a second path for the sake of getting an additional path (e.g., aggregation for more bandwidth/throughput) it may configure a different (e.g., higher) RSRP threshold than the one used for duplication, while the ‘Overlap_pct’ may be set to a non-zero value, since the focus here is on increased throughput and some degree of overlap between the paths is acceptable, as the same packet will not be duplicated.

[0203] In another example, the network may set the minimum RSRP/RSRQ of the new path relative to the minimum/maximum RSRP/RSRQ of the current path For example, the RSRP/RSRQ condition for triggering the measurement report could be a condition where all of the hops in the new path have an RSRP/RSRQ better than the lowest RSRP/RSRQ of all of the hops in the existing path. Another example may be a condition that new path has an RSRP/RSRQ that is better than the highest RSRP/RSRQ of all the hops in the existing path. Optionally, measurement report may be triggered if the average RSRP/RSRQ of all hops in the new path have an RSRP/RSRQ that is better than the average RSRP/RSRQ of all the hops in the existing path

[0204] In some cases, the network may configure measurement events even if there is already more than one path (e g., to add a third path or to replace one of the paths with a new path). In these cases, the network may associate the different paths with a path index/ID, and indicate in the measurement event configuration which path the UE must consider if the overlap factor threshold is fulfilled. [0205] FIG. 10 shows a flow chart of an example of triggering a relay addition.

[0206] A first UE is configured, by the network, with relay addition or relay reselection triggering events, including triggering parameters 1001 The first UE has a direct PC5 link established with a second UE 1002. The first UE monitors and evaluates the direct UE-to-UE channel for possible triggering events, wherein the triggering events are based on the previously configured triggering parameters 1003. Upon detection of a triggering event at the first UE, a relay addition procedure is initiated 1004.

[0207] The triggering conditions include Radio Link Failure (RLF) with the established direct UE-to-UE channel.

[0208] The triggering conditions include the RSRP value of the direct UE-to-UE direct channel is below a previously configured threshold.

[0209] FIG. 11 shows a flow chart of an example of performing a relay addition.

[0210] A first UE is communicating directly with a second UE 1101. A relay addition is triggered at the first UE 1102 The first UE monitors for discovery messages from candidate U2U relay UEs 1103. The first UE receives discovery messages from the candidate U2U relay UEs 1104 The discovery messages include at least information of in-coverage or out-of-coverage status, number of hops between the first UE and the candidate U2U relay UE, and the number of hops between the candidate U2U relay UE and the second UE. The first UE selects a U2U relay UE from the candidate U2U relay UEs based on the information included in the discovery message 1105. The first UE establishes a link with the selected U2U relay UE and continues communication with the second UE via the selected U2U relay UE 1106.

[0211] If the candidate UE is out-of-coverage, the out-of-coverage information may include the number of hops between the candidate U2U relay UE and the next relay UE that is in-coverage.

[0212] If the candidate UE is out-of-coverage the out-of-coverage information may include the period of time since the candidate U2U relay UE was in-coverage.

[0213] In one example, during the selection, the first UE may give preference to the candidate U2U relay UE that is in-coverage.

[0214] In one example, during the selection, if there are more than one candidate relay UEs in-coverage, the candidate relay UE with the highest RSRP is preferred.

[0215] In one example, during the selection, if there are no candidate relay UEs in-coverage, the candidate relay UE with the shortest time duration since it was last in-coverage is preferred.

[0216] In one example, during the selection, if there are no candidate relay UEs in-coverage, the candidate relay UE with the least number of hops to a relay UE in-coverage is preferred.

[0217] In one example, during the selection, the candidate U2U relay UE that is within the least number of hops from the first UE is preferred. [0218] In one example, during the selection, the candidate U2U relay UE that is within the least number of hops from the second UE is preferred.

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

Claims

CLAIMS What is Claimed:

1. A method performed by a first wireless transmit and receive unit (WTRU) in communication with a second WTRU via a first link that is a direct link, the method comprising: receiving, from a network, configuration information that includes a condition to initiate a relay addition in the first link; detecting, at the first WTRU, based on the configuration information, that the condition to initiate a relay addition in the first link is met; receiving, at the first WTRU, discovery messages from candidate relay WTRUs; selecting, at the first WTRU, based on the discovery messages received, a relay WTRU from the candidate relay WTRUs; and establishing, at the first WTRU, a second link with the second WTRU, wherein the second link is via the selected relay WTRU, and wherein the second link is used to send data traffic between the first WTRU and the second WTRU.

2. The method of claim 1 , wherein the candidate relay WTRUs are configured to operate as WTRU-to- WTRU relays.

3. The method of claim 1 or 2, wherein the first link is a 5G sidelink over a PC5 interface.

4. The method of any one of claims 1 to 3, wherein the condition to initiate a relay addition includes detection of a Radio Link Failure (RLF) in the first link.

5. The method of any one of claims 1 to 4, wherein the condition to initiate a relay addition is based on a measured SL-RSRP (Sidelink Reference Signal Received Power) value in the first link being below a threshold.

6. The method of any one of claims 1 to 5, wherein each discovery message includes a number of hops between the candidate relay WTRU and the second WTRU, and wherein the selection of a relay WTRU from the candidate relay WTRUs is based at least on the number of hops between the candidate relay WTRU and the second WTRU.

7. The method of any one of claims 1 to 6, wherein the selected relay WTRU is less than ‘N’ hops from the second WTRU, wherein ‘N’ is configured in the first WTRU.

8. The method of any one of claims 1 to 7, wherein each discovery message includes an indication of whether the candidate relay WTRU is in network coverage (IC) or out of network coverage (OOC), and the OOC indication includes a number of hops between the candidate relay WTRU and a relay WTRU that is IC

9. The method of claim 8, wherein the selection of a relay WTRU from the candidate relay WTRUs is based at least on one of: the IC or OOC indication, or the number of hops between the candidate relay WTRU and a relay WTRU that is IC.

10. The method of any one of claims 1 to 9, wherein the selected relay WTRU has the highest measured SL-RSRP value from all candidate relay WTRUs, wherein the SL-RSRP is measured at the first WTRU.

11. A first wireless transmit and receive unit (WTRU), configured to communicate with a second WTRU via a first link that is a direct link, and the first WTRU comprising: at least one processor; and a transceiver, wherein the at least one processor and transceiver are configured to: receive, from a network, configuration information that includes a condition to initiate a relay addition in the first link; detect, at the first WTRU, based on the configuration information, that the condition to initiate a relay addition in the first link is met; receive, at the first WTRU, discovery messages from candidate relay WTRUs; select, at the first WTRU, based at least on the discovery messages received, a relay WTRU from the candidate relay WTRUs; and establish, at the first WTRU, a second link with the second WTRU, wherein the second link is via the selected relay WTRU, and wherein the second link is used to send data traffic between the first WTRU and the second WTRU.

12. The WTRU of claim 11 , wherein the candidate relay WTRUs are configured to operate as WTRU-to- WTRU relays.

13. The WTRU of claim 11 or 12, wherein the first link is a 5G sidelink over a PC5 interface.

14. The WTRU of any one of claims 11 to 13, wherein the condition to initiate a relay addition includes detection of a Radio Link Failure (RLF) in the first link.

15. The WTRU of any one of claims 11 to 14, wherein the condition to initiate a relay addition is based on measured SL-RSRP (Sidelink Reference Signal Received Power) value in the first link being below a threshold

16. The WTRU of any one of claims 11 to 15, wherein each discovery message includes a number of hops between the candidate relay WTRU and the second WTRU, and wherein the selection of a relay WTRU from the candidate relay WTRUs is based at least on the number of hops between the candidate relay WTRU and the second WTRU.

17. The WTRU of any one of claims 11 to 16, wherein the selected relay WTRU is less than ‘N’ hops from the second WTRU, wherein ‘N’ is configured in the first WTRU.

18. The WTRU of any one of claims 11 to 17, wherein each discovery message includes an indication of whether the candidate relay WTRU is in network coverage (IC) or out of network coverage (OOC), and the OOC indication includes a number of hops between the candidate relay WTRU and a relay WTRU that is IC

19. The WTRU of claim 18, wherein the selection of a relay WTRU from the candidate relay WTRUs is based at least on one of: the IC or OOC indication, or the number of hops between the candidate relay WTRU and a relay WTRU that is IC.

20. The WTRU of any one of claims 11 to 19, wherein the selected relay WTRU has the highest measured SL-RSRP value from all candidate relay WTRUs, wherein the SL-RSRP is measured at the first WTRU.