Method and apparatus for coverage-based relay selection for multi-hop and multipath communications

Abstract

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

Description

[0001] Cross-references to related applications 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 Technology

[0002] The first device may be within network coverage. The second device may be outside network coverage. The first device may support relay operations, for example, it may be able to relay traffic to / from the second device to / from the network. Direct device-to-device communication, such as communication using a side link channel, may be used between the first and second devices.

[0003] A UE can be configured as a UE-to-UE (U2U) relay or a UE-to-network (U2N) relay. Before communicating with each other, a UE may need to discover other nearby UEs. When the UE to be discovered is a UE that supports relay functionality, the process of discovering a relay is called relay discovery. Relay discovery can have two models: Model A and Model B. Both U2N and U2U relay discovery support discovering both Model A and Model B.

[0004] In Model A, a relay UE can send an announcement message. The announcement message may include the relay's ID, relay service code (RSC), and the IDs of nearby UEs. In Model B, a remote UE wanting to discover a relay UE can broadcast a solicitation message. The solicitation message may include the remote UE's ID 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 to transmit its own solicitation message. Once it receives a solicitation message, the remote UE selects a relay UE and establishes a unicast link with it. Summary of the Invention

[0005] The path between the source UE and the destination UE can be a single-hop path or a multi-hop path. A "single-hop path" has a single direct link between the source UE and the destination UE, meaning there is no single hop with a U2U relay UE in the path. A "multi-hop path" has multiple hops between the source UE and the destination UE, meaning 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] Multipath propagation occurs when multiple paths are established between a source UE and a destination UE. In one example, multipath propagation is used for data packet replication to increase communication reliability. In another example, multipath propagation is used for data traffic aggregation to increase throughput between the source and destination UEs.

[0007] The source UE can communicate with the destination UE using a direct UE-to-UE link. The source UE or the destination UE (or both) can be configured with one or more conditions to trigger relay addition in the direct link. Conditions may include, for example, detecting a radio link failure (RLF) in the direct link, or detecting that the measured SL-RSRP (Side Link Reference Received Power) value of the direct link is below a threshold. Conditions and associated parameters can be configured by the network or negotiated between the source and destination UEs.

[0008] During the process of selecting a relay to add, the UE may consider, for example, the hop count between the candidate relay and the destination UE, or the SL-RSRP value measured in the link with the candidate relay. The UE may also consider the coverage characteristics of the candidate relay, such as whether the candidate relay is within network coverage (IC) or outside network coverage (OOC). In the case of OOC, the UE may further consider other factors, such as the hop count from the candidate relay to the in-coverage relay, the distance traveled by the candidate relay since it last entered 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 communication between the source UE and the destination UE. Attached Figure Description

[0009] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the figures indicate similar elements, and wherein: Figure 1A This is a diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B This is a system diagram illustrating an example WTRU; Figure 1C This is a system diagram illustrating the RAN and CN according to an embodiment; Figure 1D This is a system diagram illustrating the RAN and CN according to an embodiment; Figure 2 The illustration shows an example of relay discovery in Model A; Figure 3 The illustration shows an example of relay discovery in Model B; Figure 4 An example of a control plane protocol stack for L2 UE to network relay is depicted; Figure 5 An example of a user plane protocol stack for L2 UE-to-network relay is depicted; Figure 6 An example of a protocol stack used for relay discovery is depicted; Figure 7 The illustration shows an example of a multi-hop scenario with three UEs 701, 702, and 703 and two hops 704 and 705; Figure 8 The flowchart illustrates an example of trunk selection based on trunk UE coverage characteristics; Figure 9 The diagram illustrates an example of multipath relay selection based on relay UE coverage characteristics; Figure 10 A flowchart illustrating an example of triggering a relay addition is shown; and Figure 11 A flowchart illustrating an example of relay addition is shown. Detailed Implementation

[0010] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Spread Spectrum OFDM (ZT-UW-DTS-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and so on.

[0011] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will 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 can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, any of WTRUs 102a, 102b, 102c, and 102d can be referred to as a Station (STA), can be configured to transmit and / or receive wireless signals, and can include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and so on. Any of WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0012] Communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106, Internet 110, and / or other networks 112. By way of example, base stations 114a and 114b may be basic transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs such as gNodeBs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

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

[0015] More specifically, as noted above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and so on. For example, base station 114a in RAN 104 and WTRUs 102a, 102b, and 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an 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).

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

[0017] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0018] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use the dual connectivity (DC) principle to implement both LTE and NR radio access. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0019] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced GSM Evolution Data Rate (EDGE), GSM EDGE (GERAN), and so on.

[0020] Figure 1ABase station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, residence, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, it is not required that base station 114b access Internet 110 via CN 106.

[0021] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but will be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs, which may use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which may be using NR radio technology, CN 106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0022] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0024] Figure 1B The following diagram illustrates the system of example WTRU 102. Figure 1B As shown, among other things, 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 supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

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

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

[0028] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

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

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

[0031] 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) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may obtain location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information using any suitable location determination method, while remaining consistent with the embodiments.

[0032] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0033] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of both 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 hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of either UL (e.g., for transmission) or DL ​​(e.g., for reception) may be concurrent and / or simultaneous.

[0034] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0035] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

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

[0038] The MME 162 can connect to each eNode-B 162a, 162b, 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0039] The SGW 164 can connect to each eNode B 160a, 160b, or 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, or 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, or 102c, and managing and storing the context of WTRUs 102a, 102b, or 102c.

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

[0041] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRU 102a, 102b, 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0042] Despite WTRU in Figures 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0044] In an Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may access or have an interface to a Distributed System (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating outside the BSS and destined for a STA may arrive via the AP and be transmitted to the STA. Traffic originating from a STA and destined for a destination outside the BSS may be sent to the AP for transmission to the appropriate destination. For example, traffic between STAs within the BSS may be transmitted via the AP, where a source STA can send traffic to the AP, and the AP can transmit traffic to a destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0045] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or a dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0046] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0047] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, data can be passed through a segmented parser that splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0048] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support metering-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities to support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

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

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

[0051] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0052] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while maintaining consistency with the embodiment. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0053] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or a continuously varying length of absolute time).

[0054] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0055] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0056] Figure 1DThe CN 106 shown 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. Although the foregoing elements are all depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0057] AMF 182a and 182b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service type used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

[0058] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0059] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface. This interface provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0060] CN 106 can facilitate communication with other networks. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through their N3 interfaces and the N6 interface between UPF 184a and 184b and DN 185a and 185b.

[0061] Given Figures 1A-1D as well as Figures 1A-1D The functions described herein with respect to one or more of the following items can be performed by one or more emulation devices (not shown): WTRU 102a-102d, base station 114a-114b, eNode-B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0062] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. For testing purposes, simulation devices can be directly coupled to another device and / or use over-the-air wireless communication to perform tests.

[0063] One or more emulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios within test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices can be test rigs. Emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0064] The first device can be within network coverage. The second device can be outside network coverage. The first device can support relay operations, for example, it can be able to relay traffic to / from the second device to / from the network. Direct device-to-device communication, such as communication via a side link channel, can be used between the first and second devices.

[0065] The first device can be referred to as a sidelink relay. The second device can be referred to as a remote device. The terms device-to-device communication, direct communication, PC5, or sidelink can be used to refer to a device-to-device link. The term sidelink relay is also known as UE-to-network (U2N) relay because it provides a connection to the network for U2N remote devices.

[0066] It can support both Layer 2 (L2) and Layer 3 (L3) U2N trunk architectures. Except for control-side walkway resources, the L3 U2N trunk architecture is transparent to the RAN serving the U2N trunk equipment.

[0067] The UE is used as a non-limiting example of a wireless transmit / receive unit (WTRU); the described solution is applicable to other examples of WTRUs.

[0068] U2N relay UEs should be connected to the network (e.g., in RRC_CONNECTED mode) to perform unicast data relay. For L2 U2N relay operation, both the U2N relay UE and the U2N remote UE should be in connected mode (e.g., RRC_CONNECTED). Optionally, the U2N relay UE can be in any mode (e.g., RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED), while the U2N remote UEs are not in connected mode (e.g., they are in RRC_INACTIVE or RRC_IDLE).

[0069] The UE can operate as a UE-to-UE relay.

[0070] Before communicating with each other, UEs may need to discover other nearby UEs. When the UE to be discovered is a UE that supports relay functionality, the process of discovering a relay is called relay discovery. Relay discovery can have two models: Model A and Model B. Both U2N and U2U relay discovery support discovering both Model A and Model B.

[0071] Figure 2 The illustration shows an example of relay discovery in Model A.

[0072] In Model A, a relay UE that has discovered other nearby UEs 201 via a direct discovery or direct communication process can send / broadcast an announcement message 202. These announcement messages may include the type of discovery message, the relay's user information ID, the relay service code (RSC), the user information IDs of nearby UEs, and other information potentially available to the relay UE (e.g., relay load, etc.). The remote UE can then use this information to select a relay.

[0073] Figure 3 The illustration shows an example of relay discovery in Model B.

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

[0075] After successful discovery, a single unicast link is established between an L2 U2N relay UE and an L2 U2N remote UE. Traffic from the U2N remote UE to the network is carried out via the U2N relay UE. Data traffic from the U2N relay UE to the network and the relayed data traffic are sent through the Uu interface, and preferably separated in different Uu RLC channels through the Uu interface.

[0076] Communication between a remote UE and a relay UE can be carried using one of two different modes, referred to as Mode 1 and Mode 2. In Mode 1, resources for such communication are allocated by the network (e.g., gNB). For Mode 1 to operate correctly, both UEs can have a direct connection to the network (e.g., gNB). In this case, the Uu interface can be used for scheduling U2U communication resources. In Mode 2, a resource pool can be available for communication and configured remotely, and resources can be selected autonomously by the UE without any intervention from the gNB. When the UE is within network coverage, the resource pool can be configured by, for example, a gNB / eNB.

[0077] For L2 U2N relay, L2 U2N remote UEs (UEs communicating with the network via L2 U2N relay) can be primarily configured to use resource allocation mode 2 to relay data.

[0078] The protocol stack for L2 U2N relays is separated into user plane and control plane protocol stacks. A sidelink trunk adaptation protocol (SRAP) sublayer is introduced above the RLC sublayer of CP and UP at both the PC5 and Uu interfaces.

[0079] Figure 4 An example of a control plane protocol stack for L2 UE to network relay is depicted.

[0080] Packet Data Convergence Protocol (PDCP) 401 and Radio Resource Control (RRC) 402 terminate between the L2 U2N Remote UE and the gNB, while Sidelink Relay Adaptation Protocol (SRAP) 403, Radio Link Control (RLC) 404, Media Access Control (MAC) 405 and Physical Layer (PHY) 406 terminate at each hop, namely the link 407 between the L2 U2N Remote UE and the L2 U2N Relay UE and the link 408 between the L2 U2N Relay UE and the gNB.

[0081] Figure 5 An example of a user plane protocol stack for L2 UE to network relay is depicted.

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

[0083] The Uu SRAP sublayer supports L2 U2N remote UE identification for UL traffic. The identity information of the L2 U2N remote UE Uu radio bearer and the local remote UE ID are included in the Uu SRAP header at the UL, so that the gNB can correlate received packets with the specific PDCP entity associated with the correct Uu radio bearer of the remote UE. The PC5 SRAP sublayer at the L2 U2N remote UE supports UL bearer mapping between the remote UE Uu radio bearer and the egress PC5 relay RLC channel.

[0084] In L2 U2N relay, for downlink (DL) communication, the Uu SRAP sublayer supports DL bearer mapping at the gNB to map the end-to-end radio bearers (SRBs, DRBs) of remote UEs to a Uu relay RLC channel via the relay UE Uu interface. The UuSRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of L2 U2N remote UEs and / or different L2 U2N remote UEs and a single Uu relay RLC channel on the relay UE Uu interface.

[0085] The Uu SRAP sublayer supports remote UE identification for DL ​​traffic. The identity information of the remote UE Uu radio bearer and the local remote UE ID are included in the Uu SRAP header by the gNB at the DL, so that the relay UE can map packets received from the remote UE Uu radio bearer to its associated PC5 relay RLC channel.

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

[0087] The PC5 SRAP sublayer at the remote UE correlates received packets with the specific PDCP entity associated with the correct Uu radio bearer of the remote UE based on the identity information included in the Uu SRAP header.

[0088] The local remote UE ID can be included in both the PC5 SRAP header and the Uu SRAP header. L2 U2N relay UEs can be configured by the gNB using the local remote UE ID to be used in the SRAP header. The remote UE can obtain the local remote ID from the gNB via a Uu RRC message, which includes... RRCSetup , RRCReconfiguration , RRCResume and RRCReestablishment One or more Uu DRBs and one or more Uu SRBs can be mapped to different PC5 relay RLC channels and Uu relay RLC channels in both PC5 hops and Uu hops.

[0089] The gNB is responsible for avoiding conflicts in the use of local and remote UE IDs. The gNB can do this via... RRCReconfiguration The message sends the updated local remote ID to the relay UE to update the local remote UE ID. The serving gNB can perform the local remote UE ID update independently of the PC5 unicast link L2 ID update process.

[0090] UE discovery is defined as the process of detecting and identifying another UE in the vicinity. This detection can be performed using direct radio signals. The detection can be classified as open or restricted; for example, it is open for situations where explicit permission from the discovered UE is not required, and restricted for situations where such permission may be required.

[0091] Figure 6 An example of a protocol stack used for relay discovery is depicted.

[0092] The discovery layer 601 in a U2N relay UE can transmit relay discovery messages to remote UEs in the sidelink channel 602. The network can broadcast a maximum Uu RSRP threshold, a minimum Uu RSRP threshold, or both, which the U2N relay UE can use to determine whether it can transmit relay discovery messages to one or more U2N remote UEs. The U2N remote UE can monitor the sidelink channel in response to relay discovery messages. The discovery layer U2N remote UE 603 ​​can transmit relay discovery solicitation messages in the sidelink channel. The network can broadcast thresholds, which the U2N remote UE uses to determine whether it can transmit relay discovery solicitation messages to one or more U2N relay UEs. The U2N relay UE can monitor the sidelink channel in response to relay discovery solicitation messages.

[0093] One or more resource pools used for NR side link communication can be used for relay discovery, or the network can configure one or more resource pools dedicated to relay discovery. In system information, dedicated signaling, and / or pre-configuration, one or more resource pools dedicated to relay discovery can be configured simultaneously with one or more resource pools used for NR side link communication. Whether one or more dedicated resource pools for relay discovery are configured can vary depending on the network implementation. As an example, if one or more resource pools dedicated to relay discovery are configured, then only those dedicated resource pools will be used in the relay discovery process. As an example, if only one or more resource pools for NR side link communication are configured, then all configured transport resource pools can be used for both relay discovery and side link communication.

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

[0095] U2N remote UEs can perform radio measurements at the PC5 interface and use them for relay selection and reselection and / or higher-level criteria. Remote UEs can use SL-RSRP (Side Link Reference Received Power) and / or SD-RSRP (Side Link Discovery Reference Received Power) measurements to assist in 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 can use the SD-RSRP measurement to assess whether the PC5 link quality toward the U2N relay UE meets the relay selection criteria. For example, for relay reselection, the U2N remote UE can use the S1-RSRP measurement toward the serving U2N relay UE for relay reselection trigger evaluation criteria.

[0096] If the PC5 link quality toward the U2N relay UE, as measured by the U2N remote UE, exceeds a configured threshold (pre-configured or provided by the gNB), the U2N relay UE can be considered suitable by the U2N remote UE in terms of radio criteria. The U2N remote UE may need to search for suitable U2N relay UE candidates that meet all access stratum and higher-level criteria. Additional criteria may include, for example, PLMN ID and cell ID. If multiple suitable U2N relay UEs exist, the U2N remote UE may need to break a tie based on some implementation-specific rules.

[0097] Examples of relay selection triggering include: when the direct Uu signal strength of the current serving cell of the U2N remote UE may be lower than the configured signal strength threshold, or when the upper layer instructs the lower layer to begin selection. Examples of relay reselection triggering include: when the PC5 signal strength from the U2N remote UE to the current U2N relay UE may be lower than the (pre)configured signal strength threshold; when the U2N relay UE instructs the U2N remote UE via PC5-RRC signaling for events such as cell selection / reselection, handover, or Uu radio link failure (RLF); when the U2N remote UE receives a PC5-S link release message from the U2N relay UE; and when the U2N remote UE detects a PC5RLF or upper layer instruction.

[0098] For L2 U2N remote UEs and L3 U2N remote UEs in RRC_IDLE / INACTIVE mode, the cell (re)selection procedure and the relay (re)selection procedure can run independently. If both a suitable cell and a suitable U2N relay UE are available, the decision to select a cell or a U2N relay UE may be made by the UE. L3 U2N remote UEs can select both a cell and a U2N relay UE simultaneously.

[0099] For both L2 and L3 U2N relay UEs in RRC_IDLE / INACTIVE state, when a U2N relay UE selects a new cell, one or more PC5-RRC messages are used to notify one or more remote UEs connected to it. When an L2 / L3 U2N relay UE performs a handover or detects a Uu RLF, one or more PC5-RRC messages are also used to notify one or more L2 or L3 U2N remote UEs connected to it. Upon receiving the PC5 RRC message used for notification, the U2N remote UE can decide whether to release or maintain the unicast PC5 link. If the U2N remote UE decides to release the unicast PC5 link, it may trigger an L2 release procedure, followed by relay reselection.

[0100] 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). A UE is said to be within network coverage when the signals received in the uplink (at the base station) and downlink (at the UE) enable bidirectional communication between the UE and the network using the Uu interface. Otherwise, the UE is said to be outside network coverage.

[0101] The term "source UE" refers to a UE that is interested in communicating with another UE or network using U2U relay, U2N relay, or both.

[0102] The term "destination UE" refers to the last UE in the communication "path," that is, in UE-to-UE communication, it is the UE that the "source UE" is trying to communicate with.

[0103] The term "hop" refers to a "direct" PC5 communication link (e.g., a side link) between two UEs. Here, "direct" means that the communication does not involve any U2U relays; that is, when two UEs communicate directly. A hop refers to a link between two UEs where no relay facilitates UE-to-UE communication. Each UE can be a source UE, a destination UE, a 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; and a direct communication link between a U2U relay UE and a U2N relay UE.

[0104] The term "PC5 link" or "sidelink" refers to a direct link between two UEs without any relays in between. This is equivalent to a single hop. An end-to-end communication link between two UEs can include multiple PC5 links, meaning it can involve multiple hops.

[0105] The "path" between the source UE and the destination UE represents the communication link between the two UEs. There may be one or more U2U relay UEs in the path, resulting in multiple hops between the source and destination UEs. In the last hop, the destination UE is the final UE. Each path may include one or more hops.

[0106] A "single-hop path" is a path that has a single hop between the source UE and the destination UE, meaning there is no U2U relay UE in the path.

[0107] A "multi-hop path" is a path with multiple hops between the source UE and the destination UE, for example, a path containing at least one U2U relay UE. If there are N U2U relay UEs in the path, the path will have N+1 hops.

[0108] The term "multipath" refers to a situation where multiple paths may be established between the source UE and the destination UE, and these paths are distinct from each other. Multipath scenarios can be used for purposes such as packet replication (increasing reliability) or data aggregation (increasing throughput). One of the paths can be a single-hop path. Two paths are considered distinct if at least one hop is different.

[0109] Figure 7 The illustration shows an example of a multi-hop scenario with 3 UEs 701, 702, 703 and 2 hops 704, 705.

[0110] Multi-hop scenarios are a natural extension of single-hop scenarios, where multiple paths can be used to replicate packets to improve system reliability. UE1 701 can be the source UE, and it can be an IC or OOC. UE2 702 can be a relay UE, and it can also be an IC or OOC. UE1 cannot reach UE3, so an intermediate relay may be needed, which could be UE2 702 operating as a U2U relay. UE2 702 acts as an intermediate relay, and it can be referred to as the destination UE because it is the UE targeted by UE1, or as the first in the path. Multipath scenarios occur when the source remote UE 701 can create two separate paths to the destination (e.g., a network). UE3 703 is the destination UE, and it is within coverage, and it can operate as a U2N relay.

[0111] U2N relay UEs can have very simple connectivity architectures and network coverage. The U2N source remote UE may be outside network coverage, while the U2N relay UE must be within coverage to reach the network; the source remote UE can have a single unicast link (e.g., a sidelink) with the U2N relay UE. U2N relays can have variations in topology and coverage scenarios, such as one, two, or all UEs being within or outside coverage, and / or operating under Mode 1 / Mode 2, resource pool configurations, and serving the same or different relays for a single source UE with multiple connections to different destinations, or vice versa. When within coverage, the U2N relay UE can be in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state. Furthermore, any remote UE can initiate a relay discovery or (re)selection process.

[0112] For multipath scenarios, new conditions for discovery and relay selection can be considered (to ensure QoS requirements). Additionally, considering the different coverage situations that may arise for relays and remote UEs in a given multi-hop scenario, various new criteria can be considered to ensure optimal relay and path selection and reduce any potentially unnecessary discovery message transmissions.

[0113] Remote UEs can communicate directly (using a direct PC5 link / sidelink) or indirectly (via one or more UE-to-UE trunks). Remote UEs can also communicate with gNBs (via a combination of one or more UE-to-UE (U2U) and / or U2N trunks). Multi-hop and multipath communication are applicable to both U2U and U2N scenarios. For both multi-hop and multipath scenarios, the solutions described in this document are applicable to both U2U and U2N trunk scenarios.

[0114] A source UE communicating with a destination UE via an existing path can trigger a process to add a new path. If the source and destination UEs are communicating via an existing path and a new, potentially better path is discovered, either the source or destination UE can trigger a process to add the newly discovered path. Before deciding to switch to the new path, the UE can temporarily use both paths to evaluate whether the new path is actually better than the existing path. The classification of "better" may depend on several parameters.

[0115] The source or destination UE can monitor different paths. To distinguish paths, different source and / or destination UE IDs can be used on each path. The source UE can then duplicate a number of packets and transmit the same packets simultaneously on both paths using different IDs. Optionally, additional markers, such as PDCP headers, such as different path IDs for the first and second paths, can be included in the packets. By comparing the arrival times of packets with the same sequence number (SN) on the two paths, the remote UE can determine which path performs better in terms of latency or throughput. The source UE can then select the optimal path to use.

[0116] In one example, path selection decisions can be based on throughput. The source UE can send the same number of packets on both links, and the throughput determination (e.g., how long it takes to receive all packets on each link) can be performed at the destination UE. Based on the throughput determination (i.e., the lower latency in this case), the first path can be maintained or a switch to a new path can be made. This can be triggered by either the destination UE or the source UE, based on information provided by the destination.

[0117] In another example, the selection decision may be based on requirements, such as latency and / or total throughput and / or reliability, where the performance of each link may not be good enough for them to operate individually as single paths. In one example, when a second path is added, the first path may be suitable for one bearer (e.g., a low-latency, low-throughput bearer), while the second path may be suitable for another bearer (e.g., a high-latency, high-throughput bearer). In such cases, maintaining both paths may be the optimal decision. For example, the two paths could be used for replication (e.g., for bearers requiring high reliability); each path could be used for bearers requiring QoS matching the path's latency / throughput; or the bearer could be sent on both paths, i.e., aggregation could be performed by sending some packets of a given bearer on the 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.

[0118] A solution for trunk selection based on trunk UE coverage characteristics is described.

[0119] For example, if a source UE wants to communicate with another UE or the network, it can perform relay addition or relay reselection based on the destination of interest. During the selection process, the source UE can consider the number of hops between the candidate relay UE and the destination UE. The source UE can also consider the coverage characteristics of the candidate relay UE, i.e., whether it is within or outside network coverage. For the case of being outside coverage, the source UE can further consider other factors, such as the number of hops from the candidate relay UE to a UE within coverage, the distance the candidate relay UE has traveled since it last entered coverage, the time elapsed since the candidate relay UE left coverage, or the number of paths available to the destination UE.

[0120] The conditions for triggering relay discovery and / or relay (re)selection may vary. For example, triggering may be based on measured RSRP: reselection can be triggered when the RSRP measurement of a direct (PC5) or indirect (relay PC5 or Uu) link falls below a threshold.

[0121] Another triggering example could be based on the number of hops in the path: the availability or discovery of a new U2U relay with fewer hops to the network or destination UE compared to the current number of hops to the network or destination UE; or the availability or discovery of a new U2N relay that can be reached with fewer hops (shorter path) compared to the current number of hops to the network.

[0122] In another example, the trigger could be based on received path information, which could be included in the discovery message. For instance, if there exists a path 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 has a shorter path to the network enabled, then that path might be preferred because it is likely to be enabled.

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

[0124] Another example of a trigger could be conditional QoS for a service, where, for instance, the current service allows for reselection, thus tolerating some service interruption, as opposed to a QoS requirement that can tolerate limited service interruption. In another example, the establishment of a new QoS flow might lead to requirements for improved redundancy or additional bandwidth, potentially requiring a second path, which could trigger the selection of a second path (if the initial path already exists). The establishment of a new QoS flow could also lead to changes in requirements for improved latency, triggering relay reselection and / or path switching or path addition (e.g., increasing throughput through traffic aggregation or increasing redundancy through packet replication).

[0125] A remote (source and / or destination UE) UE can trigger a trunk reselection, for any of the reasons mentioned above or other reasons, where the reselection of two separate trunk paths can be selected. In one example, when a second path is needed, the initially established path can be used to exchange information to facilitate the selection of the second path; for example, two remote UEs can use the first path to exchange information about existing paths / trunks to facilitate the selection of the second path.

[0126] In another example, the initial trigger for relay selection might result in two paths being selected at the outset. This could be based on the QoS requirements of the service and the link quality of the paths; for example, if the link quality of one path is insufficient, and two paths are required, for example, to ensure that reliability requirements (replication) and / or bandwidth requirements (aggregation) are met.

[0127] In the example, a change in the traffic characteristics of a remote UE might cause a U2U relay UE to trigger an RRC connection establishment with the network to operate as a U2N relay. For example, a remote UE might communicate with the network via a multi-hop U2U relay and a final U2N relay. The U2U relay along this path might be within coverage but might be in an RRC_IDLE state. The U2U relay UE can trigger an RRC connection establishment with the network as a possible means of reducing the number of hops in the multi-hop path between the remote UE and the network. In this case, the triggering of RRC_CONNECTED for the relay UE could be based on latency (e.g., the current multi-hop path exceeds a configured threshold, which can be determined via measurement), or it could be based on the remote UE initiating a new QoS flow requesting a shorter path to the network (e.g., based on the exchange of QoS information at link establishment), or on some information shared between UEs in the existing path.

[0128] Discovery transmissions and relay reselection can be triggered by Access Layer (AS) criteria (e.g., received PC5 signal strength, path information, etc.) or by indications from an upper layer of the remote UE (e.g., application layer triggering). The type of established connection determines how discovery is triggered. For example, a remote UE (e.g., source and / or destination UE) with a multi-hop path to another remote UE can trigger AS-layer discovery (as opposed to waiting for upper-layer triggering) as a means of keeping alternative paths available, which can then be offered to the upper layer, for example, when path switching is required, potentially reducing latency and / or minimizing data interruption or loss. In another example, a remote UE (e.g., source and / or destination UE) configured with an end-to-end path having a hop count greater than a threshold can trigger discovery at the AS layer to continuously search for shorter paths. As yet another example, a remote UE configured with an end-to-end path having latency higher than a threshold can trigger discovery at the AS layer to continuously search for shorter paths, while this condition may be true. This threshold may be lower than the latency requirement of the service in that path.

[0129] Once a 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 the destination UE. When performing a U2U relay selection, the remote UE can utilize the relay UE's coverage and / or mobility characteristics, as well as path information. For example, if the remote UE knows (e.g., via discovery) the coverage status or other aspects of the relay UE's mobility information, it can use that information when performing a U2U relay selection. For instance, the U2U relay UE may include coverage status in the discovery message: in-coverage (IC), out-of-coverage (OOC), multi-hop or single-hop, number of hops to the IC, number of hops to the network, mobility status (fast or slow movement), etc.

[0130] In multi-hop scenarios, a remote (e.g., source) UE can select, for example, the path with the most in-coverage (IC) U2U relay UEs. In this case, the remote UE can utilize other mobility information that may be available for relay selection. For example, for OOC relays, the UE can provide distance information (e.g., distance traveled since leaving coverage, time since the relay UE entered the OOC, number of hops to another in-coverage relay UE, etc.). The remote UE can be configured with thresholds for each of these parameters, where the thresholds depend on the type of service (e.g., QoS). Alternatively, the remote UE can be able to implicitly obtain appropriate (time / distance / hop count) thresholds for relays in the path based on its QoS data (e.g., latency, throughput-based bandwidth requirements, etc.). This can then be used for relay selection purposes.

[0131] For example, a remote UE performing U2U relay selection can choose an initial path and determine a set of U2U relay candidates for a second path. The UE can then select a relay UE from this set, or alternatively, it can pre-select a path and then start a timer and / or wait for a trigger before establishing the second path. The trigger can be based on notification from the destination that a path may be insufficient or unsuitable. This can also be based on the source becoming aware that the first / initial path may be insufficient (e.g., if the amount of buffered data may increase or the consumption rate may be insufficient, additional bandwidth is required due to new QoS flows, etc.). The timer for the second path can be a timer indicating when the second path is selected (completing the selection process), or a timer indicating the feasibility of the second path, meaning that if the timer expires and the triggering conditions for selecting the second path are not met, the second path is discarded. If the selection of the second path is unsuccessful for any given reason, the UE may need to begin selecting the initial path.

[0132] In the example, a remote UE can select multiple paths to its destination (potentially via multiple relays). This may be done for purposes such as redundancy, replication, reliability, or additional bandwidth requirements. For example, a remote UE can be configured with a mapping between bearer configuration / QoS and the minimum number of paths required.

[0133] Multiple path selection can be completed at the beginning (i.e., multiple paths are initially selected simultaneously), or alternatively, the remote UE can select an initial path and add a second path as a backup if needed (e.g., additional bandwidth is required due to new QoS flows / services) or even later if needed (e.g., CBR increases, hop count increases, RSRP decreases, etc.).

[0134] In one scenario, the source and destination can leverage the original / initial path to facilitate the selection of a new (single) path or a second path. For example, if the destination UE discovers a new path to the source, it can indicate that path to the source UE. In another scenario, if the source UE initiates a new QoS flow requesting a new path, it can indicate that path to the destination UE, which can trigger the destination UE to send the new path information to the source UE.

[0135] Figure 8 The flowchart illustrates an example of relay selection based on relay UE coverage characteristics.

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

[0137] The source UE may monitor the PC5 connection link 805 for potential selection trigger events, e.g., the source UE detects RLF in any hop along the path to the destination UE, or the source UE detects that the SL-RSRP is below a predefined threshold in any hop along the path to the destination UE 806. Upon detecting SL-RLF or SL-RSRP < threshold with the destination UE, 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 within coverage, the source UE lists a set (one or more) of relay UEs based on the elapsed time t < t_{OOC}, and / or the hop count threshold hopCnt < (hopCnt_{OOC_to_IC}) and selects one relay from the listed relay UEs 808.

[0138] Figure 9 A diagram illustrating an example of multi-path relay selection based on relay UE coverage characteristics.

[0139] Candidate relay UEs transmit discovery messages 901. Among other things, the discovery messages may contain parameters such as: an indication of whether the UE may be IC or OOC (labeled IC and OOC); if OOC, the number of hops (Hop-Relay-IC) to a relay UE that is IC; and if OOC, the time (Time-Relay-IC) since the relay UE was IC. The source UE creates a candidate list 902 based on the received information. Then, the source UE selects a relay from the candidate list 903.

[0140] After establishing a path with the selected relay UE 904, the source UE continues to monitor the sidelink connection link 905 for potential selection / reselection trigger events 906. The possible trigger events are described in the preceding paragraphs. The source UE continues to monitor and process discovery messages received from candidate relays. If a path addition is triggered, the source UE can select a relay from its list of candidate relays. Otherwise, if all relays are OOC, the source UE can then check whether the values ​​for Hop-Relay-IC and Time-Relay-IC received in the discovery message are less than their configured thresholds, and the source UE can select a relay from the list of candidate relays that meets this condition.

[0141] The source UE can also classify and sort the remaining relays in a preferred order based on different criteria. The source UE can create a priority list of candidate relays. Optionally, after establishing the first path, the source UE can monitor the status of its QoS flows, such as buffer size, latency, PER, etc., and compare them with the requirements of each service. Based on this comparison and / or other factors, the source UE can decide to establish a second path with different relay UEs. The source UE can use the priority list of candidate relays to establish the second path. The source UE can run a timer after which the candidate list may become outdated, and it needs to refresh it by processing discovery messages from nearby relay UEs. As another example, a new relay UE can signal some information to the source UE, thereby 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.

[0142] The examples discussed are not intended to be limiting, as it may not be necessary to select a second path and / or the trigger for establishing a second path may be different, or the source UE may not support multipathing.

[0143] In the example discussed, the source UE may be receiving a discovery message, which includes in-coverage (IC) or out-of-coverage (OOC) information, and in the case of OOC, the hop count to the next relay UE and / or the time elapsed since the last IC of the destination UE (or candidate relay UE). However, this information may be sent by a UE already in the existing path, or even by the network itself.

[0144] In one embodiment, a relay UE may provide information about its coverage characteristics in a message (e.g., a discovery message). The relay UE may provide additional information to a remote UE, for example, in a discovery message or a message dedicated to sharing relay capabilities. Some examples include a preferred mode of resource allocation (e.g., mode 1 versus mode 2), support for carrier aggregation including, for example, the number of supported carriers, carrier type, licensed or unlicensed; support for HARQ feedback (e.g., PSFCH configuration in a resource pool); it may also provide its current status, such as RRC status (e.g., RRC_CONNECTED versus RRC_IDLE versus RRC_INACTIVE); relevant measurements, such as CSI reports; the current reachability of the U2N relay; and an indication of whether it is IC or OOC, including the distance and / or time traveled once OOC occurs. This information may be dependent on the elapsed time and / or distance traveled, wherein it stops reporting the information if the traveled time or distance exceeds a certain threshold.

[0145] In one solution, a U2U relay UE outside of coverage can connect to a network / gNB / eNB via a U2N relay and can provide this information via its own discovery message. The U2U relay UE can know (e.g., via U2N discovery) that it can connect to a U2N relay UE. The U2U relay UE can then include this information in its discovery message. This information can then be obtained by a remote UE that may wish to connect to the network. In one example, a remote UE can send a solicitation message, and the U2U relay UE's receipt of this message can trigger the U2U relay UE to advertise its capabilities. The U2U relay UE can announce that it is not a U2N relay, but that it is capable of connecting to a U2N relay.

[0146] In one example, if a remote UE can only connect to the network via multiple U2U relay UEs outside the coverage area, then discovery messages from U2N relays within the coverage area can be received by the U2U relay UEs and forwarded to the remote UE.

[0147] In another example, a discovery message announcing the reachability of a U2U relay UE to a U2N relay UE may include a hop count k, where a hop count "0" indicates that the relay itself is a U2N relay, and a hop count "k>0" indicates that the hop count of the U2N relay within coverage is "k". From the perspective of a remote UE, knowing whether the relay UE is directly connected to the gNB used for U2N discovery can be useful, as it then knows whether the relay UE is within or outside coverage, and whether it relies on another U2N and / or U2U relay to communicate with the network. This can also be beneficial for a remote UE for relay selection purposes, as it can receive multiple discovery messages indicating several paths to within coverage (e.g., U2N) relays, allowing the remote UE to utilize this hop count information for relay selection. Additionally, for multi-hop paths with one or more (U2U and / or U2N) relays within coverage and / or in RRC_CONNECTED (e.g., both U2N and U2U), this can be useful from a latency and reliability perspective.

[0148] In the example, an OOC relay UE can determine whether to transmit / forward discovery messages from other relay UEs based on the RSRP of the received discovery message. For example, if the RSRP of the received discovery message is greater than a threshold, and the received discovery message represents a relay with fewer hops to the network, the relay UE may not transmit its own discovery message because it can infer that there is a nearby relay UE with fewer hops that is already transmitting discovery messages at high power.

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

[0150] When applicable, a relay UE may also include the number of paths and information on the overlap between paths. For example, if a relay UE can reach UE'x' via multiple paths, it may include information about how many paths do not overlap, and for paths that overlap to some extent, it may include information about the number of overlapping hops (e.g., as a percentage, the ratio of overlapping hops to total hops, etc.).

[0151] The relay UE can provide (any) of the aforementioned information based on the request of the remote UE (e.g., via an indication of a solicitation request). In one example, the remote UE can indicate a need for the aforementioned information (e.g., path, coverage status, etc.) and can indicate this need in its solicitation message. In another example, if the relay UE does not receive an indication from the remote UE, the relay UE can simply provide a normal discovery (e.g., legacy discovery) without any added coverage features.

[0152] A relay UE can also indicate the unicast link status of each hop in the path. For example, a relay UE can include information about whether a unicast link has been established at any hop in the path; it can also provide information about the number of hops with established unicast links, or alternatively, a percentage relative to the total number of hops in the path. Remote UEs can use this information for path selection. For example, performing relay selection based on the fact that QoS has some latency requirements can translate to needing a setup process to create a maximum number "y" of unicast links in the path. Knowing how many hops in the path require unicast links can allow a remote UE to eliminate some of them (since latency may not be guaranteed).

[0153] In another example, the relay UE can be configured by the network to provide any of the aforementioned information. This can be accomplished by providing two different configurations, one indicating basic discovery message transmission, and the other generating an enhanced discovery message with some or all of the aforementioned information. The network can dynamically request the relay UE to change between the basic and enhanced messages, or vice versa.

[0154] A relay UE may choose to provide an enhanced discovery message (with the aforementioned information) (or a basic discovery message) only if it hears an announcement message from another relay UE, in which case the announcement message also includes this information. This may indicate that other relays have already been asked to provide this information, and therefore it should (or should not) do so as well.

[0155] When sending the above information / parameters, the relay UE can provide one or more parameters, i.e., any combination of the above parameters. For example, the network can configure a pre-configured subset of parameters, or the subset can be based on a request from a remote UE, such as in a solicitation request message. Optionally, different triggers can be used to trigger the transmission of each specific parameter.

[0156] In one example, a relay can choose to provide information about multiple paths to a given remote UE (and the number of hops for each path). In another example, a relay can choose to include only information about the best path to a given remote UE. The relay UE can monitor paths and, if a better path is found, can report the newly discovered path to the remote UE. The relay UE can choose to include only path information containing a given number of hops or fewer. For example, a solicitation message from a remote UE can indicate the maximum path length the remote UE is interested in discovering, and it can indicate all relay candidates or a specific relay candidate. For example, "Interested in relays that can provide access to the destination UE within 3 hops or less." A relay UE can use discovery solicitation messages it hears from other relay UEs to determine information about multiple paths. For example, a first relay UE can know that there may be another second relay UE that can provide a connection to the network UE via another third relay UE. Furthermore, there may be a situation where the first relay UE knows that there may be a shorter path via another relay UE, and it can report that shorter path. There may be a minimum "k" hop difference between paths to justify the triggering of a report on another path.

[0157] In one solution, as described above, the relay UE may include only limited information in the discovery message and may provide more detailed path information when requested by the remote UE (e.g., in the discovery solicitation message or in a subsequent message after the remote UE receives the discovery message from another relay UE).

[0158] In one example, when multiple similar paths exist, a relay UE can include information associated with only one path. The relay UE can select a representative path for which it includes path information. Path similarity can include, for example, paths with the same hop count or paths with a common relay UE.

[0159] A relay UE can transmit two different discovery messages at different periods / frequencies. For example, a relay UE can transmit short discovery messages more frequently, while transmitting detailed discovery messages less frequently, where the detailed discovery message may contain more details about path information. The relay UE can further indicate in the short discovery message that it will transmit detailed discovery / path information, and potentially include the scheduling or periodicity of future discovery message transmissions, allowing interested remote UEs to listen for messages at specified time intervals and / or frequencies.

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

[0161] Additionally, the geographic information of the relay UE can 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 (at least "k" hops shorter) to a remote UE via the second U2U relay UE, and the second U2U relay provides the shorter connection to the destination, but it may be in a different geographic area (as determined by region ID, distance, coordinates, or other similar parameters), then the first U2U relay UE can then decide to advertise that path information because it may be useful to a different subset of remote UEs in that geographic area.

[0162] In one example, the type of discovery (e.g., U2U or U2N) and the designation of the UEs along the path can determine the behavior of relay UEs in deciding what information (e.g., path information) they can include in their messages (e.g., their advertisement messages). For example, a UE with more than one path to the network and is a U2N relay can decide which paths to include in its own messages (e.g., advertisement messages). In one example, the hop count of each of these paths can be considered, and the relay UE can include only the shortest path in its advertisement. If multiple paths with the same distance (e.g., hop count) exist, then the relay UE can include all of those paths. In another example, the relay UE can include the shortest "n" paths or all paths less than a configured hop count "k". In yet another example, the relay can include only path information for those paths that do not overlap or whose overlap may be below a certain threshold (e.g., y% hop overlap or y% U2U relay overlap). In another example, in addition to overlapping hops, a relay can consider whether the overlap is a continuous overlap (several hops in a row) or a discontinuous overlap (only U2U relay overlap). Additionally, the relay UE can consider the link quality of the path by decomposing the link quality of overlapping hops relative to the link quality of non-overlapping hops in the path. In one example, a relay UE may sometimes transmit a discovery with only the shortest path information, and sometimes it may transmit a discovery with information about all available paths.

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

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

[0165] In an embodiment, if a remote UE discovers a path that is "k" hops shorter than the original path, it triggers relay selection. For example, if two remote UEs communicate via a multi-hop path, the discovery of a new, shorter path and / or problems with the current path may trigger relay reselection. Path shortening can be triggered by any UE along the path (e.g., by a remote UE, a relay UE) based on different triggers. The source remote UE may trigger path selection based on the source remote UE periodically transmitting discoveries and receiving a discovery response indicating that a shorter path may be available. In another example, a remote (e.g., source) UE may compare the length of a newly discovered path with existing paths and trigger relay selection only if the new path is at least some "k" hops shorter than the original path. When the UE is an IC, the value of 'k' can be pre-configured or signaled from the network. This value can be mapped to the service type / QoS of the current data and / or any potentially new data that can be served, as well as the length of the current path. Different values ​​can be configured for different types of service / QoS.

[0166] In one example, "k" can be implicitly derived from the current path length and current link performance. For instance, if the destination remote UE provides feedback based on the end-to-end (E2E) latency of the current path (e.g., based on an E2E latency exceeding a certain threshold), the source remote UE can use this feedback to calculate the maximum length of the new path (e.g., the new path needs to be at least "k" fewer hops than the current path to ensure that the latency threshold is not exceeded). This can then be used as a criterion for initiating a path shortening process. In another example, "k" can be configured based on a constant bit rate (CBR). For example, for a higher CBR, the network can configure a smaller "k" value.

[0167] The triggering of path shortening reselection can be conditional on the QoS requirements of the remote UE; that is, the remote UE can choose to trigger path shortening reselection only if QoS permits it. For example, if the service can tolerate some data loss and / or service interruption (during path handover), the remote UE can trigger path shortening. However, if the service cannot tolerate interruption, the remote UE can choose to wait. End-to-end bearer configuration can include an indication of whether path shortening is allowed when the bearer is established. For example, end-to-end bearer configuration can include a threshold buffer state below which path shortening is allowed. If the bearer's buffer state is above the threshold, the UE can choose not to perform such path shortening.

[0168] The link quality of the new path and the current path can be used to trigger a path reselection. In the example, if the source UE detects a shorter path, and the link quality of the new, shorter path is likely to be better than the link quality of the existing path, a path reselection can be triggered. This can be based on a comparison of each hop of the two paths (e.g., minimum / maximum / average), where, for example, the link quality of the worst hop on the new path may not be worse than the link quality of the best hop on the original path. This ensures that the remote UE will only switch if the new path is likely to be shorter (ensuring lower latency) and the link quality is likely to be at least as good as the link quality of the original path.

[0169] The destination UE can notify the source UE that a shorter path is needed based on some conditions that are met at the destination (e.g., the destination measures the end-to-end delay of the current path based on the conditions described herein), and then notify the source UE if one or more parameters exceed a certain threshold, and then the source UE can choose to trigger a reselection for the purpose of shortening the path.

[0170] In the example, a remote UE (e.g., the source) can be configured with a prohibit timer between relay selection triggers; that is, based on the first reselection, the source UE can prevent a second reselection from being triggered within a time period based on this prohibit timer. The UE can determine the timer value based on the current path length, the QoS characteristics of the data, resource usage (e.g., CBR), the relay coverage status of the current path (e.g., how many relays in the current path are ICs), the mobility information of OOC UEs in the path (i.e., the time / distance traveled since OOC), etc. The length of the current path can determine the length of the prohibit timer between path reselections. For example, a path that might be several hops long may require a faster action (to minimize latency) in terms of triggering a reselection. Therefore, a shorter prohibit timer can be used for a longer path, while a larger value can be used for the timer if the current path is short. In another example, the timer can be based on the current path length and "k" (as mentioned earlier, where the new path needs to be at least "k" hops shorter than the current path). When "k" is small, a longer timer can be used compared to a larger "k" value (because a larger "k" guarantees a path much shorter than the current path).

[0171] The source UE can trigger discovery message transmission (e.g., Model B solicitation) based on conditions that could indicate problems along the current path. For example, if the source (remote) UE notices an increase in its current buffer state, the arrival of new data with lower latency requirements, or measurement data that may be available to the remote UE indicating a link quality problem at any hop along the current path.

[0172] A relay UE can trigger a discovery message transmission (e.g., a Model A announcement) based on information available at the relay UE. In the example, a change in the relay's load conditions (which may be based on active connections and / or new connections since the original path was instantiated) and the relay becoming aware of the potential availability of a new, shorter path via other relay discovery messages can cause the relay UE to trigger a discovery message transmission, which the source remote UE can use as an indication to trigger a new path shortening or reselection.

[0173] In one scenario, the source UE may need to be notified of any changes to the current path to the destination UE. In an example, a relay UE communicating with the destination UE via one or more relay UEs may observe that a shorter and / or more direct path may be available to the destination UE. If the relay is part of an existing multi-hop path to the destination UE that the source UE is currently using, the UE can benefit from the newly available shorter path. The relay UE can use an RRC message on a sidelink channel to inform the source UE of this change. Alternatively, the change can be advertised via an announcement message, which can then be forwarded to the source UE directly or via another relay. The source UE can then use this information to determine whether it should trigger a relay reselection.

[0174] In multipath scenarios, path selection can be performed to ensure redundancy in replication. Path selection ensures that remote UEs only select non-overlapping paths. For example, replication may require that different paths in a multipath have no common relays (hops) to increase transmission reliability.

[0175] In the example, replication may require separate paths where the relay UEs along the paths are different (without overlap), where different paths are sufficient for replication requirements even if the UEs are using the same channel (e.g., frequency / carrier).

[0176] In the example, the UE can be configured with a threshold RSRP and a first path has been established. It can select a path above the threshold that does not overlap with the first path in any hop. If no non-overlapping path that meets the threshold RSRP requirement does not exist, then the UE can select an overlapping path above the RSRP threshold.

[0177] In another example, the UE can select a path based on the QoS of the data being served. For example, if bearer configuration requires it, the remote UE can only select non-overlapping paths. In yet another example, the bearer can allow a certain degree of overlap, for example, between a minimum and maximum overlap (based on path-shared overlap / number / percentage of common hops). The remote UE can then only select paths with overlap not exceeding these thresholds.

[0178] Overlapping in the path can be permitted for replication, provided other mechanisms exist to provide redundancy and improve reliability. Examples include carrier aggregation on overlapping paths, enabling HARQ feedback (if not already enabled), and changes to transmission parameters such as MCS, transmit power, etc. Sidelink configuration information can be provided by the network (e.g., pre-configured by the gNB). The relay UE determines which configuration to apply based on whether the paths overlap or not. When the relay UE is part of an overlapping path, it can use two different carriers. Alternately, when paths overlap, the UE can choose to utilize a more conservative MCS, while when there is no overlap, it can choose a less conservative and more aggressive MCS (e.g., a higher MCS). For non-overlapping cases, the relay UE can utilize lower transmit power, while when paths overlap, it can utilize higher transmit power.

[0179] When overlapping paths exist, and only some data requires high reliability (a relay serves multiple connections, but only a subset requires high reliability), the relay can apply different configurations to each path. This can be based on the logical channel's LCP limit and ingress-egress mapping. These changes can be implemented via pre-configuration or dynamically (e.g., changing the ingress-egress mapping from N:1 to N:M for a new logical channel).

[0180] In the example, a remote UE can maintain the identity of a set of relay UEs across a multi-hop path. This could be used to ensure no service interruptions (e.g., based on service QoS). The remote UE can do this by triggering a discovery process at the AS layer (e.g., based on the current path link quality). The remote UE can provide this information to higher layers, which can be used to facilitate path handover while ensuring service continuity if a path handover is required. Additionally, the source UE can inform the relays of the appropriate configuration to apply (because it knows the end-to-end path and whether the paths overlap).

[0181] A UE that has already selected a path can provide the network with measurement reports of other relays (e.g., relay UEs it has discovered). As discussed in the paragraphs above, this can be useful to the network when replication needs to be configured (for U2N). The network may have limited knowledge of the paths to the UE, which can limit the usefulness of reports provided by remote UEs. In one scenario, a remote UE can provide the network with measurement reports about relays it can communicate with, but these relays are also on paths that are common to (overlapping with) the current path. For example, if the gNB relies on this measurement report to configure replication, this information may be useless. For replication, it is preferable to have non-overlapping paths to maximize diversity. Therefore, providing measurement reports for overlapping paths would result in wasted signaling without any benefit.

[0182] To address this issue, the gNB can configure measurement events using conditions that provide path information or measurement reports. For example, a remote UE can be configured to report path information (partial or complete) along with measurement values ​​to the network. A remote UE can also report path information for all reachable relay UEs (e.g., U2U relays) based on received discovery messages.

[0183] In one example, a remote UE can receive a discovery message with path information from both a first relay UE and a second relay UE, and the first relay UE can reach the second relay UE. This allows the remote UE to know path information up to two hops away.

[0184] In another example, path information can be transmitted hop-by-hop. For instance, the second-closest relay UE to the gNB can obtain path information from the nearest relay UE to the gNB, the third-closest relay UE can obtain path information from the second-closest relay UE (i.e., path information between the second relay UE and the gNB), and so on, until the remote UE obtains the complete path information to the gNB. The remote UE can then provide this complete path information to the network. This information can help the network make decisions regarding measurement configuration parameters, thresholds, and event criteria.

[0185] In another example, a remote UE might only have complete path information for a limited number of hops (e.g., two hops) from the source, along with a hop count indicating the total number of hops to the U2N relay and / or network. The remote UE can then report this information (i.e., the number of hops, and the path information for the hop with the most available path information) to the network. The network might be able to use this information to infer whether there is overlap between two paths. For example, if the remote UE provides complete path information for two hops and indicates that the gNB is outside of hop "k", the network can use the value of "k" to determine the availability of a measurement report for initiating a second path. For example, if the source provides complete path information for two hops, but "k" >> 2 (say, 8), then the network can consider the report not particularly relevant when it comes to determining whether the path overlaps with the current path. On the other hand, if k is 4, then the network can be more confident that the chance of the path overlapping with the current path is small.

[0186] The remote UE can be configured with measurement event configurations, which can have one or more trigger conditions. Trigger conditions can be, for example, the minimum RSRP / RSRQ of a path, such as the minimum link quality of any hop on the path; the average / median RSRP / RSRQ of a path, such as the average link quality of all hops on the path; the maximum overlap level of a path, such as based on the number or percentage of overlapping hops, etc.

[0187] The network can also be configured with multiple events based on its objective: replication, aggregation, or path selection / reselection. It can select an appropriate threshold for each parameter.

[0188] In one example, if a network targets a replicated path, it can configure the minimum RSRP threshold for that path to a certain "RSRP_min" value while setting the overlap factor "Overlap_pct" to 0. This ensures the path has some minimum acceptable link quality while ensuring there is no overlap between the reported path and existing paths (to increase diversity). Conversely, if the network targets a second path to obtain additional paths (e.g., for aggregation of more bandwidth / throughput), it can configure a different (e.g., higher) RSRP threshold than the one used for replication, and 'Overlap_pct' can be set to a non-zero value, since the focus here is on increasing throughput, and some degree of overlap between paths is acceptable because identical packets will not be replicated.

[0189] In another example, the network can 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 used to trigger a measurement report could be a condition that the RSRP / RSRQ of all hops in the new path is better than the lowest RSRP / RSRQ of all hops in the existing path. Another example could be a condition that the new path has an RSRP / RSRQ that is better than the highest RSRP / RSRQ of all hops in the existing path. Alternatively, a measurement report can be triggered if the average RSRP / RSRQ of all hops in the new path is better than the average RSRP / RSRQ of all hops in the existing path.

[0190] In some cases, even if more than one path already exists, the network can configure measurement events (e.g., to add a third path or replace one of the paths with a new one). In these cases, the network can associate different paths with path indices / IDs and indicate in the measurement event configuration which path the UE must consider if an overlap factor threshold is met.

[0191] Figure 10 A flowchart illustrating an example of triggering relay addition is shown.

[0192] The first UE is configured by the network with relay addition or relay reselection trigger events, including trigger parameters 1001. The first UE has a direct PC5 link 1002 established with the second UE. The first UE monitors and evaluates the direct UE-UE channel for possible trigger events, where the trigger events are based on previously configured trigger parameters 1003. When a trigger event is detected at the first UE, a relay addition procedure 1004 is initiated.

[0193] Triggering conditions include radio link failure (RLF) with the established direct UE-UE channel.

[0194] The triggering condition includes the RSRP value of the direct UE-to-UE direct channel being lower than the previously configured threshold.

[0195] Figure 11 A flowchart illustrating an example of relay addition is shown.

[0196] The first UE communicates directly with the 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 candidate U2U relay UEs 1104. The discovery message includes at least information on in-coverage or out-of-coverage status, the 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 to communicate with the second UE via the selected U2U relay UE 1106.

[0197] If the candidate UE is outside the coverage area, the information for the outside area can include the number of hops between the candidate U2U relay UE and the next relay UE within the coverage area.

[0198] If the candidate UE is outside the coverage area, the information for being outside the coverage area can include the time period since the candidate U2U relay UE became within the coverage area.

[0199] In one example, during the selection process, the first UE can prefer candidate U2U relay UEs within the coverage area.

[0200] In one example, during the selection process, if there is more than one candidate relay UE within the coverage area, the candidate relay UE with the highest RSRP is preferred.

[0201] In one example, during the selection period, if no candidate relay UE is within coverage, the candidate relay UE with the shortest duration since the last time it was within coverage is preferred.

[0202] In one example, during the selection process, if no candidate relay UE exists within the coverage area, the candidate relay UE with the fewest hops to a relay UE within the coverage area is preferred.

[0203] In one example, during the selection process, the candidate U2U relay UE that is within the minimum number of hops of the first UE is preferred.

[0204] In one example, during the selection process, the candidate U2U relay UE that is within the minimum number of hops of the second UE is preferred.

[0205] Although the features and elements have been described above in specific combinations, one of those skilled in the art will appreciate that each feature or element can be used alone or in combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a first wireless transmit and receive unit (WTRU) communicating with a second WTRU via a first link as a direct link, the method comprising: Receive configuration information from the network, which includes conditions for initiating relay addition in the first link; At the first WTRU, based on the configuration information, it is detected that the condition for initiating a relay addition in the first link has been met; At the first WTRU, a discovery message is received from the candidate relay WTRU; At the first WTRU, a relay WTRU is selected from the candidate relay WTRUs based on the received discovery message; as well as At the first WTRU, a second link is established with the second WTRU, wherein the second link is via a 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 WTRU is configured to operate as a WTRU-to-WTRU relay.

3. The method according to claim 1 or 2, wherein the first link is a 5G side link via a PC5 interface.

4. The method according to any one of claims 1 to 3, wherein the condition for initiating relay addition includes detecting a radio link failure (RLF) in the first link.

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

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

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

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

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

10. The method according to 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 as a direct link, and the first WTRU comprising: At least one processor; as well as Transceiver, wherein the at least one processor and the transceiver are configured to: Receive configuration information from the network, which includes conditions for initiating relay addition in the first link; At the first WTRU, based on the configuration information, it is detected that the condition for initiating a relay addition in the first link has been met; At the first WTRU, a discovery message is received from the candidate relay WTRU; At the first WTRU, a relay WTRU is selected from the candidate relay WTRUs, based at least on the received discovery message. as well as At the first WTRU, a second link is established with the second WTRU, wherein the second link is via a 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 WTRU is configured to operate as a WTRU-to-WTRU relay.

13. The WTRU according to claim 11 or 12, wherein the first link is a 5G side link via a PC5 interface.

14. The WTRU according to any one of claims 11 to 13, wherein the condition for initiating relay addition includes detecting a radio link failure (RLF) in the first link.

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

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

17. The WTRU according to 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 according to any one of claims 11 to 17, wherein each discovery message includes an indication of whether the candidate relay WTRU is within network coverage (IC) or outside network coverage (OOC), and the OOC indication includes the number of hops between the candidate relay WTRU and the relay WTRU that is an IC.

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

20. The WTRU according to 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.

Images