Methods, architectures, apparatuses, and systems for wtru-to-network relay discovery and selection in multi-hop connectivity

Abstract

Procedures, methods, architectures, apparatus, systems, devices, and computer program products including a first device-to-device relay wireless transmit / receive unit (WTRU) configured for multi-hop communication between a remote WTRU and a device-to-network relay WTRU, the first device-to-device relay WTRU configured for receiving a first relay discovery message from any of: (1) the device-to-network relay WTRU, (2) a second device-to-device relay WTRU, and (3) the remote WTRU; determining a cumulative propagation delay associated with the multi-hop communication; and broadcasting a second relay discovery message including information indicating the cumulative propagation delay based on the first relay discovery message.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 615,341, filed December 28, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, apparatuses, and systems for network relay and computation, such as methods, apparatuses, and systems for using quantum communication and computation to perform network relay link establishment in multi-hop connections. Attached Figure Description

[0003] A more detailed understanding can be obtained from the detailed description given below by way of example in conjunction with the accompanying drawings. Like this detailed description, the figures in such drawings are exemplary. Therefore, the figures (each figure) and the detailed description should not be considered limiting, and other equally valid examples are possible and likely to occur. Furthermore, similar reference numerals (“reference numerals”) in the figures indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system. Figure 1B It's shown in the diagram. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system. Figure 1C It's shown in the diagram. Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system. Figure 1D It's shown in the diagram. Figure 1A The diagram shows another example RAN and another example CN used in the communication system. Figure 2 The diagram illustrates an architecture model for using Proximity Service (ProSe) WTRU to network (e.g., UE to network) relay; Figure 3 This is a diagram illustrating ProSe WTRU to network (e.g., UE to network) relay; Figure 4 This is a diagram illustrating a multi-hop WTRU to network / U2N relay discovery architecture according to one embodiment; Figure 5 This is a diagram illustrating a multi-hop WTRU to network / U2N relay discovery architecture according to another embodiment; Figure 6 This is a diagram illustrating the multi-hop link establishment process; Figure 7This is a diagram illustrating a method for WTRU to network relay discovery and selection in a multi-hop connection according to one embodiment; Figure 8 This is a diagram illustrating a method for WTRU to network relay discovery and selection in a multi-hop connection according to another embodiment; Figure 9 This is a diagram illustrating a method for establishing a WTRU to network relay PC5 link in a multi-hop connection according to one embodiment; and Figure 10 This is a diagram illustrating a method for WTRU to network relay discovery and selection in a multi-hop connection according to another embodiment. Detailed Implementation

[0004] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the description below. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with the embodiments and other examples described, disclosed, or otherwise explicitly, implicitly, and / or inherently provided (collectively, the “Provided”). Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it is to be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0005] Example communication system.

[0006] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. About Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may be utilized, performed, arranged, and / or adapted and / or configured for use with the methods, apparatuses, and systems provided herein.

[0007] Figure 1AThis is a system diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, 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 (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and so on.

[0008] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include (or be) 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 the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and so on. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0009] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d, for example, to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b can be any of a base transceiver station (BTS), Node-B (NB), eNode-B (eNB), home Node-B (HNB), home eNode-B (HeNB), gNode-B (gNB), NR NodeB (NR NB), station controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b can include any number of interconnected base station and / or network elements.

[0010] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive 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. The 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 one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector or any sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

[0012] More specifically, as described above, the communication system 100 can be a multi-access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 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 Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

[0014] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0015] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0016] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., 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 Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), and so on.

[0017] For example, Figure 1A Base station 114b can be a wireless router, home Node-B, home eNode-B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, 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 one 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 one 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 any of the following: small cells, picocells, or femtocells. Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0018] RAN 104 / 113 can communicate with CN 106 / 115, 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 different 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 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1A As not shown, but to be understood, RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs employing the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) employing any of GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

[0019] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 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). 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 / 114 or a different RAT.

[0020] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the 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 to communicate with base station 114b, which may employ IEEE 802 radio technology.

[0021] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1BAs shown, among other things, WTRU 102 may include, in particular, 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 components / peripherals 138. It will be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0022] Processor 118 may 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) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may 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 may be integrated together in, for example, an electronic package or chip.

[0023] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) on 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 one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In one embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0024] 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. For example, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals on air interface 116.

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

[0026] 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 therefrom. 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 and store information from any type of suitable 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 user identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102, such as a server or home computer (not shown).

[0027] 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 that powers the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

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

[0029] Processor 118 may be further coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, components / peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., 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, and so on. Components / peripherals 138 may include one or more sensors, such as gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

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

[0031] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted 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.

[0032] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it will 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 on 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 receive radio signals from WTRU 102a.

[0033] 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 the uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0034] 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. While each of the foregoing elements is described as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0035] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c 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, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 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.

[0036] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 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, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

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

[0038] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, facilitating communication between WTRU 102a, 102b, and 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, 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.

[0039] Despite WTRU in Figure 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.

[0040] In a representative embodiment, another network 112 may be a WLAN.

[0041] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can 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 is sometimes referred to as the "ad-hoc" communication mode in this document.

[0042] 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 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. 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.

[0043] 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.

[0044] 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 consecutive 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, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which 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 two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC) layer, entities, etc.

[0045] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support 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, including support for (e.g., only) 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).

[0046] 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 designated 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 the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for a STA that supports (e.g., only supports) the 1 MHz mode (e.g., an MTC-type device), 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, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and can be available.

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

[0048] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0049] RAN 113 may include gNBs 180a, 180b, and 180c; however, it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on 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 WTRUs 102a, 102b, and 102c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, 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 can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, 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).

[0050] 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., including a variable number of OFDM symbols and / or a continuously variable absolute time).

[0051] 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 of 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.

[0052] 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, dual connectivity, interoperability between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and so on. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other on the Xn interface.

[0053] Figure 1DThe CN 115 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 at least one Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 113 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 NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing, for example, 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 established for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, and / or so on. AMF 162 can provide control plane functions for handover between RAN 113 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 Wi-Fi.

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

[0056] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This N3 interface can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110), for example, 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-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0057] CN 115 can facilitate communication with other networks. For example, CN 115 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 115 and PSTN 108. Furthermore, CN 115 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 may be connected to the local data network (DN) 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0058] Given Figure 1A-1D as well as Figure 1A-1D As described herein, one or more, or all, of the functions described in any of the following can be performed by one or more emulation components / devices (not shown): WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or one or more other components / devices described herein. An emulation device can be one or more devices configured to emulate one or more, or all, 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.

[0059] Simulation devices can be designed to perform tests on one or more 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. Simulation devices can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.

[0060] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may 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).

[0061] The following are acronyms / abbreviations for terms and phrases commonly used in this application: DCR / DCA Direct Connection Request / Acceptance LMR / LMA Link Modification Request / Acceptance MH_U2N_RSC: Multi-hop specific RSC provided by U2N relays MH U2U RSC U2U trunk provides multi-hop specific RSC RSC Relay Service Code UE / WTRU for source / target UE and U2U trunk communication U2N relay UE to network relay / WTRU to network relay U2U relay UE to UE relay / WTRU to WTRU relay ProSe WTRU to network (e.g., UE to network) relay entities can provide support for network connectivity for remote WTRUs (e.g., UEs) (see [link]). Figure 3 ).

[0062] If a remote WTRU (e.g., UE) is outside NR coverage and cannot communicate directly with the core network (or is within NR coverage but prefers to communicate using PC5), the remote WTRU (e.g., UE) can discover and select a WTRU-to-network (e.g., UE-to-network) relay. The remote WTRU (e.g., UE) can establish a PC5 session with the WTRU-to-network (e.g., UE-to-network) relay, and / or the WTRU-to-network (e.g., UE-to-network) relay can establish a PDU session (or PDN connection in an EPC) for the remote WTRU (e.g., UE). After IP address / prefix allocation, traffic between the remote WTRU (e.g., UE) and the network can be relayed by the WTRU-to-network (e.g., UE-to-network) relay, such as... Figure 4 As shown.

[0063] For 5G ProSe WTRU to network (e.g. UE to network) relay discovery, both Model A and Model B discovery are supported: (1) Model A can use a single discovery protocol message (announcement), and / or (2) Model B can use two discovery protocol messages (solicitation and response).

[0064] Additional information for relay discovery can be found using (e.g., only) Model A.

[0065] Proposals from 3GPP studies to support multi-hop enhancements for U2N and U2U relays in Rel-19 are discussed.

[0066] Multi-hop U2N relays enable remote WTRUs (e.g., UEs) to discover and communicate with U2N relays via one or more U2U relays. Multi-hop U2U relays also enable terminal WTRUs (e.g., UEs) to discover and communicate with each other via more than one U2U relay. Multi-hop U2U relay procedures can also be used in the context of a U2N relay when multiple relays assist in establishing a connection between a remote WTRU (e.g., UE) and a U2N relay WTRU (e.g., UE), which can be considered as a terminal WTRU (e.g., UE) of the U2U relay.

[0067] Multi-hop capability may be considered critical for mission-critical communications (e.g., first responders) and may often require enhanced coverage (e.g., indoors).

[0068] When enabled for multi-hop communication, a remote WTRU (e.g., a UE) can reach a U2N trunk via more than one hop. One or more U2U trunks may exist, facilitating the establishment of multi-hop connections between the remote WTRU (e.g., a UE) and the U2N trunk WTRU (e.g., a UE). To achieve such multi-hop communication between the remote WTRU (e.g., a UE) and the U2N trunk WTRU (e.g., a UE), the following issues can be addressed.

[0069] Methods and apparatus are provided for discovering relay WTRUs (e.g., UEs) via multi-hop WTRU to network (e.g., UE to network).

[0070] In cases where a remote WTRU (e.g., a UE) desires to connect to a network via a relay WTRU (e.g., a U2N relay), current procedures may assume that there is a U2N relay available (e.g., always) near the remote WTRU (e.g., the UE) to establish a U2N relay connection. This may not actually be the case, and the remote WTRU (e.g., the UE) may not (e.g., cannot) discover any nearby U2N relay WTRUs (e.g., the UEs). However, a U2N relay can be reached via one or more U2U relays. For multi-hop discovery and selection of U2N relays, methods and apparatus are proposed that allow a remote WTRU (e.g., the UE) to discover and select U2N relays via one or more U2U relay UEs.

[0071] A method and apparatus are provided for establishing a relay WTRU (e.g., UE) PC5 link via a multi-hop WTRU to network (e.g., UE to network).

[0072] In a scenario where (for example) a remote WTRU (e.g., a UE) has discovered a U2N trunk via one or more U2U trunk UEs, the next step may be to establish a PC5 link between the remote WTRU (e.g., a UE) and the discovered and selected U2N trunk WTRU (e.g., a UE). The discovery process on multiple hops may involve one or more U2U trunk WTRUs (e.g., UEs), and there may be alternative routes from the remote WTRU (e.g., a UE) to the U2N trunk WTRU (e.g., a UE). Furthermore, there may be end-to-end (E2E) QoS requirements based on ProSe services, which may (e.g., need to) be considered for path selection and connection establishment. In such a scenario, methods and apparatus are proposed to allow a remote WTRU (e.g., a UE) to establish a PC5 link to the discovered U2N trunk via (one or more) U2U trunk UEs.

[0073] In single-hop scenarios, a remote WTRU (e.g., a UE) establishing a connection to the network via a U2N relay can select a nearby U2N relay WTRU (e.g., a UE) that meets E2E QoS requirements and supports the desired relay service. In multi-hop scenarios, where the connection between the remote WTRU (e.g., a UE) and the U2N relay may be via multiple hops, E2E QoS requirements become more critical, and per-hop QoS impacts the E2E connection. In the case of multi-hop relays with E2E QoS requirements, methods and apparatus are proposed for determining per-hop QoS during initial connection establishment and for determining per-hop QoS when modifying or updating existing links.

[0074] Methods and apparatus for U2N relay discovery and connection establishment are provided.

[0075] According to some embodiments, upon receiving a U2N relay discovery message, if a multi-hop indication or a multi-hop specific RSC is present, the U2U relay can generate a U2U relay discovery message to be broadcast by the U2U relay.

[0076] According to some embodiments, if a multi-hop indication or multi-hop specific RSC is present in a U2N relay discovery message or a U2U relay discovery message, a U2U relay can perform per-hop QoS determination and can calculate the cumulative propagation delay up to that hop.

[0077] According to some embodiments, the U2U relay discovery notification message may include multi-hop propagation delay, i.e., a list having a timestamp for each hop or a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops. According to some embodiments, the propagation delay is accumulated, i.e., the sum of the propagation delays for each hop or the total multi-hop propagation delay.

[0078] According to some embodiments, a U2U trunk WTRU (e.g., a UE) can send DCR or LMR messages to another U2U trunk or U2N trunk, including multi-hop indication, MH_U2N_RSC, MH_U2U_RSC, a list of U2U trunk user information for other U2U trunks, U2N trunk user information, and remote WTRU (e.g., UE) user information.

[0079] According to some embodiments, one or more (e.g., each) hop U2U relays can determine per-hop QoS or cumulative QoS. For any hop where the cumulative propagation delay is large, i.e., if it exceeds the E2E delay budget up to that hop, it may stop sending any DCR messages. It can send a Direct Communication Rejection message to a remote WTRU (e.g., a UE) with the reason value set to "QoS not satisfied" or a similar value stating that QoS cannot be achieved.

[0080] In this disclosure, “U2U relay UE” and “U2U relay” are used interchangeably.

[0081] In this disclosure, "U2N relay UE" and "U2N relay" are used interchangeably.

[0082] This disclosure provides the following procedure for multi-hop U2N relay discovery and connection establishment via one or more U2U relays. A remote WTRU (e.g., UE) may not be able to discover any nearby U2N relay WTRU (e.g., UE), (e.g., then) a U2N relay can be reached via one or more U2U relays. In this case, the current U2N relay procedure can be enhanced so that the remote WTRU (e.g., UE) can locate the U2N relay WTRU (e.g., UE) via one or more U2U relay UEs using a multi-hop connection. One or more (e.g., each) WTRUs (e.g., UEs) involved in multi-hop discovery and connection establishment (e.g., remote WTRUs (e.g., UEs), U2N relay WTRUs (e.g., UEs), U2U relay UEs) may be pre-configured or equipped with multi-hop specific configurations and authorizations, such as authorizations based on the capability / subscription and multi-hop enable indications for one or more (e.g., each) WTRUs (e.g., UEs), including E2E QoS with a maximum time delay budget, the maximum number of allowed hops (max #hops), multi-hop specific RSCs (such as MH_U2N_RSC, MH_U2U_RSC), and a list of E2E QoS parameters linked to one or more (e.g., each) multi-hop specific RSCs.

[0083] For multi-hop connections between a remote WTRU (e.g., a UE) and a U2N relay established via a U2N relay WTRU (e.g., a UE) and a network connection, the remote WTRU (e.g., a UE) can discover the U2N relay with the assistance of one or more U2U relays (e.g., multi-hop facilitating U2U relay WTRUs (e.g., UEs) or U2N relay UEs) broadcasting discovery messages on behalf of the terminal WTRU (e.g., a UE). This discovery can be accomplished using Model A discovery (e.g., announcement messages that may include multi-hop indication, MH_U2N_RSC, MH_U2U_RSC, E2E QoS, per-hop QoS, cumulative QoS, U2N relay user information, and a list of U2U relay user information) or Model B discovery (e.g., solicitation and response messages that include multi-hop indication, MH_U2N_RSC, MH_U2U_RSC, E2E QoS, per-hop QoS, cumulative QoS, U2N relay user information, and a list of U2U relay user information).

[0084] For any hop, the intermediate U2U relay WTRU (e.g., UE) can estimate the per-hop QoS and / or can calculate the cumulative QoS, e.g., up to the propagation delay of that hop, and can (e.g., then) compare the cumulative QoS with the E2E QoS for optimal routing. The U2U relay assisting each hop can (e.g., needs to) determine the per-hop QoS based on the E2E QoS requirements so that those requirements can be met.

[0085] Once a remote WTRU (e.g., UE) has discovered and selected a U2N relay, a connection can be established via the selected route, which may include one or more U2U relay WTRUs (e.g., UEs). The remote WTRU (e.g., UE) can initiate a direct link establishment by sending a Direct Communication Request (DCR), which may include a multi-hop indication, MH_U2N_RSC, a U2U relay user information [list], and E2E QoS. The U2U relay WTRU (e.g., UE) further broadcasts this message, but if a link already exists between peer WTRUs (e.g., UEs) (between a U2U relay WTRU (e.g., UE) and a U2N relay WTRU (e.g., UE) or between two U2U relay UEs), the message may be a DCR message or a Direct Link Modification (LMR) message. The content of this message can be the same as the first DCR message from a remote WTRU (e.g., a UE), and can also be the same as the MH_U2U_RSC, per-hop QoS, cumulative QoS, and discovery payload from a U2N relay WTRU (e.g., a UE).

[0086] According to some embodiments, independent discovery may not exist, i.e., integrated discovery in cases where discovery is not performed and the remote WTRU (e.g., UE) does not discover the U2N relay. In this case, the remote WTRU (e.g., UE) may send a DCR message that includes the information elements as described above for DCR messages plus the user information of the desired U2N relay. Multi-hop routing may be performed by the U2N relay or the remote WTRU (e.g., UE) based on DCR / DCA messages (or other messages exchanged during link establishment, such as DSMC) and the accumulated QoS included in those messages.

[0087] Methods and apparatus are provided for relay discovery via multi-hop WTRU to network (e.g., UE to network).

[0088] According to some embodiments, one or more (e.g., each) WTRUs (e.g., UEs) (i.e., remote WTRUs (e.g., UEs), U2U trunks, and U2N trunks) may be pre-configured or equipped with multi-hop specific configurations and authorizations, such as multi-hop indications for indicating that multi-hop is enabled, based on, etc. Figure 4 and Figure 5 Multi-hop authorization of capabilities / subscriptions and additional parameters listed in Step 1.

[0089] According to some embodiments, a U2U relay WTRU (e.g., a UE) can receive a U2N relay discovery announcement message or a U2U relay discovery announcement message, including a multi-hop indication, a multi-hop specific relay service code (MH_U2N_RSC) for U2N relay services, an E2E QoS associated with the MH_U2N_RSC, and U2N relay user information.

[0090] According to some embodiments, a U2U relay WTRU (e.g., a UE) can perform per-hop QoS determination and calculate the cumulative propagation delay up to that hop. A mapping table can be created whereby the per-hop QoS calculation is associated with user information of one or more (e.g., each) of nearby available terminal WTRUs (e.g., UEs). For any hop where the cumulative propagation delay up to that hop exceeds the E2E delay budget, the U2U relay can ignore the discovery message and may not send it further.

[0091] According to some embodiments, a U2U relay WTRU (e.g., a UE) can generate a U2U relay discovery announcement message to be broadcast by the U2U relay. The U2U relay discovery announcement message may include multi-hop propagation delay, i.e., a list having a timestamp for each hop or a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops. According to some embodiments, the propagation delay is accumulated, i.e., the sum of the propagation delays for each hop or the total multi-hop propagation delay.

[0092] According to some embodiments, a remote WTRU (e.g., a UE) can perform U2N relay selection and routing based on QoS parameters, for example, by accumulating propagation delay or so-called multi-hop propagation delay (e.g., ... Figure 4 (As explained in step 5) is compared with the required E2E propagation delay budget, which may be based on a list of QoS parameters associated with one or more (e.g., each) RSCs.

[0093] According to some embodiments, a U2U relay WTRU (e.g., a UE) can receive a U2N relay discovery announcement message from a U2N relay. This message includes a multi-hop indication, a multi-hop specific relay service code (MH_U2N_RSC) for U2N relay services, an E2E QoS associated with MH_U2N_RSC, and U2N relay user information. The U2U relay can (e.g., locally) store the information received from the U2N relay WTRU (e.g., the UE) and its corresponding parameters.

[0094] According to some embodiments, a U2U relay WTRU (e.g., a UE) can receive a U2N relay discovery solicitation message from a remote WTRU (e.g., a UE), which includes a multi-hop indication, a multi-hop specific relay service code (MH_U2N_RSC) for U2N relay services, and an E2E QoS associated with MH_U2N_RSC.

[0095] According to some embodiments, a U2U relay WTRU (e.g., a UE) can generate a U2U relay discovery solicitation message to be broadcast by the U2U relay.

[0096] According to some embodiments, a U2U relay WTRU (e.g., a UE) may receive a U2U relay discovery response message from a U2N relay WTRU (e.g., a UE) or from another U2U relay WTRU (e.g., a UE). The message may include, for example, U2N relay user information, multi-hop indication, cumulative propagation delay (a list of timestamps for each hop, a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops, or the sum of all measured propagation delays), and a list of one or more U2U relay UEs as received in a solicitation message.

[0097] According to some embodiments, a U2U relay WTRU (e.g., UE) can perform per-hop QoS determination and calculate the cumulative propagation delay up to that hop. A mapping table can be created in which the per-hop QoS calculation is associated with user information of one or more (e.g., each) of nearby available terminal WTRUs (e.g., UEs).

[0098] According to some embodiments, a remote WTRU (e.g., a UE) can perform U2N relay selection and routing based on QoS parameters, for example, by accumulating propagation delay or so-called multi-hop propagation delay (e.g., ... Figure 5 The comparison (as explained in the document) is made with the required E2E propagation delay budget, which can be based on a list of QoS parameters associated with one or more (e.g., each) RSCs.

[0099] Methods and apparatus are provided for establishing PC5 relay links via multi-hop WTRU to network (e.g., UE to network).

[0100] According to some embodiments, a remote WTRU (e.g., a UE) may use a U2U relay user information [list] (e.g., one or more (e.g., each) selected U2U relay user information IDs) to send a DCR / LMR including routing information, where routes may be selected based on prior discoveries. It may include a multi-hop indication, MH_U2N_RSC, U2N relay user information, remote WTRU (e.g., UE) user information, and a list of E2E QoS parameters associated with the RSC.

[0101] According to some embodiments, a U2U relay WTRU (e.g., a UE) can receive a DCR / LMR message from a remote WTRU (e.g., a UE). This message includes routing information using a list of U2U relay user information, such as user information IDs of one or more (e.g., each) selected U2U relays, where routing can be selected based on prior discovery. The DCR message may include a multi-hop indication, MH_U2N_RSC, U2N relay user information, remote WTRU (e.g., UE) user information, and a list of E2EQoS parameters associated with the RSC.

[0102] According to some embodiments, a U2U trunk WTRU (e.g., a UE) can send DCR or LMR messages to another U2U trunk or U2N trunk, including multi-hop indication, MH_U2N_RSC, MH_U2U_RSC, a list of U2U trunk user information for other U2U trunks, U2N trunk user information, and remote WTRU (e.g., UE) user information.

[0103] According to some embodiments, one or more (e.g., each) U2U relay WTRUs (e.g., UEs) can determine per-hop QoS or cumulative QoS. For any hop where the cumulative propagation delay is estimated to be large, i.e., if it exceeds the E2E delay budget up to that hop, it may stop sending any DCR messages. It can send a Direct Communication Rejection message to a remote WTRU (e.g., UE) with the reason value set to "QoS not satisfied" or a similar value stating that QoS cannot be achieved.

[0104] According to some embodiments, if no prior discovery is performed, a U2U trunk WTRU (e.g., UE) or U2N trunk WTRU (e.g., UE) can determine per-hop QoS or cumulative QoS based on DCR or DCA messages or other messages transmitted during link establishment.

[0105] According to some embodiments, a U2U trunk WTRU (e.g., a UE) can receive a Direct Communication Acceptance (DCA) or Link Modification Acceptance (LMA) message from a U2N trunk WTRU (e.g., a UE) or from another U2U trunk WTRU (e.g., a UE). The message includes a list of U2U trunk user information along the routed U2U trunk, U2N trunk user information, remote WTRU (e.g., UE) user information, and a list of E2E QoS parameters per RSC.

[0106] According to some embodiments, a U2U trunk WTRU (e.g., a UE) can use the same method as when receiving a DCA / LMA message from a U2N trunk. Figure 4 The procedure specified in steps 3 and 5 is similar to that used to perform per-hop QoS determination. If multiple U2U relays are involved in a multi-hop communication link, one or more (e.g., each) U2U relays can perform this step.

[0107] According to some embodiments, a U2U relay WTRU (e.g., a UE) can further pass DCA / LMA messages to another U2U relay or a remote WTRU (e.g., a UE). Before sending the DCA / LMA, the U2U relay can calculate the per-hop QoS with the remote WTRU (e.g., a UE) or other U2U relay at the next hop based on the E2E QoS and the calculated per-hop QoS of one or more U2U relays received at the earlier hop. If the conditions are not met, it can send a direct communication rejection or link modification rejection message with the reason values ​​described above.

[0108] According to some embodiments, a U2N relay WTRU (e.g., a UE) can initiate a new PDU session establishment procedure or a PDU session modification procedure when receiving a DCR / LMR message from a U2U relay WTRU or a remote WTRU. Based on the DCR or LMR message, the U2N relay can establish a new PDU session or update an existing PDU session. In the case of multi-hop communication, when establishing or modifying a PDU session, the U2N relay can (e.g., needs to) manage the PQI mapping of the remote WTRU (e.g., the UE), rather than the mapping of the U2U relay WTRU (e.g., the UE). In existing single-hop specifications, the U2N relay can consider the remote WTRU (e.g., the UE) at the first hop, while in this case, it can (e.g., needs to) consider the remote WTRUs (e.g., the UE) at multiple hops hidden behind one or more U2U relay UEs.

[0109] Methods and apparatus are provided for discovering relay WTRUs (e.g., UEs) via multi-hop WTRU to network (e.g., UE to network).

[0110] Figure 4 This is a diagram illustrating multi-hop U2N relay discovery (Model A).

[0111] For WTRU-to-network (e.g., UE-to-network) relay discovery using the Model A discovery procedure, the U2N relay can periodically broadcast U2N relay discovery announcement messages. In multi-hop scenarios, the U2U relay WTRU (e.g., UE) can send a U2U relay discovery message (e.g., U2U relay announcement or U2U relay solicitation message) upon receiving a U2N relay discovery announcement message (which may include a multi-hop indication or a multi-hop specific relay service code). The U2U relay can determine the per-hop QoS based on E2E QoS before sending the U2U relay discovery message, and the E2E QoS from the U2N relay can be based on a list of QoS parameters supported per RSC. The U2U relay can send a U2U relay discovery message when the per-hop QoS determined by the U2U relay meets the E2E QoS requirements. If the per-hop QoS determined by the U2U relay cannot satisfy the E2E QoS per RSC, the U2U relay may ignore the U2N relay discovery announcement message received from the U2N relay and not send a U2U relay discovery message.

[0112] One or more (e.g., each) WTRUs (e.g., UEs) (i.e., remote WTRUs (e.g., UEs), U2U trunks, and U2N trunks) may be pre-configured or equipped with multi-hop specific configurations and authorizations, such as: multi-hop indications indicating that multi-hop is enabled, capability / subscription-based multi-hop authorizations, multi-hop parameters (e.g., multi-hop specific RSCs (e.g., MH_U2N_RSC, MH_U2U_RSC)), a list of supported E2E QoS parameters (e.g., maximum time delay budget), and the maximum allowed number of hops linked to one or more (e.g., each) RSCs (step 4.1).

[0113] U2N relays can send U2N relay discovery announcement messages, which include a multi-hop indication, a multi-hop specific relay service code (RSC) (MH_U2N_RSC) for U2N relay services, a timestamp, a hop counter value initially set to zero, an E2E QoS associated with MH_U2N_RSC, and U2N relay user information (step 4.2).

[0114] When a U2U relay receives a U2N relay discovery announcement message, it can perform per-hop QoS determination (step 4.3).

[0115] When a U2U trunk WTRU (e.g., a UE) is enabled for multi-hop, it can create a mapping table in which it associates per-hop QoS calculations with user information of one or more (e.g., each) of nearby available U2N trunks, remote WTRUs (e.g., UEs), or U2U trunk WTRUs (e.g., UEs).

[0116] For U2U relays, if the cumulative propagation delay of that hop has exceeded the E2E delay budget for any hop, the U2U relay can ignore the message and stop sending any discovery messages.

[0117] U2U relays can view the multi-hop specific relay service code (MH_U2N_RSC) and / or multi-hop indication for U2N relays in the received U2N relay discovery message received from U2N relays. If present, it can generate a U2U relay advertisement message to be broadcast by the U2U relay (step 4.4).

[0118] According to some embodiments, there may be situations where two alternatives are supported: U2U relay discovery announcement messages and U2U relay discovery solicitation messages. However, (e.g., only) the U2U relay discovery announcement messages are shown in the figures for illustration and discussed below. For the case using discovery solicitation messages, a similar procedure as described below for Model B can be followed.

[0119] U2U relays can create announcement messages based on information collected by the U2U relays. This information may include information about available U2N relays, as well as discovery payloads, multi-hop indications, MH_U2N_RSC, MH_U2U_RSC, and E2E QoS associated with MH_U2N_RSC, received from the U2N relay WTRU (e.g., UE). U2U relay discovery messages may include information about a single U2N relay, or may include a list of one or more U2N relay UEs covering some or all available U2N relays in the vicinity of the U2U relay.

[0120] Receiving a U2N relay advertisement message can be triggered by a U2U relay WTRU (e.g., a UE) sending a U2U relay advertisement message, or / and the U2U relay advertisement message can be a periodic, time-based message. This message can include information about the U2N relay collected by the U2U relay. The most important aspect of this step is the definition of the discovery message, i.e., that the U2U relay may be receiving a U2N relay advertisement message, and based on this, it may be sending a U2U relay advertisement message.

[0121] U2U relays can send U2U relay discovery announcement messages that include some or all of the additional information elements to indicate the availability of U2N relays via multiple hops, such as (one or more) U2N relay user information, U2N relay multi-hop indication, timestamps for each hop, propagation delay values ​​that can be added for one or more (e.g., each) hops from one or more (e.g., each) relays, and cumulative propagation delay (i.e., the sum of propagation delays per hop, also known as multi-hop propagation delay).

[0122] According to some embodiments, in the case of a second or third hop, a U2U relay may include a list of user information for all U2U relay UEs involved in the previous hop, cumulative propagation delay, and / or per-hop delay information with or without timestamps.

[0123] In existing procedures for U2U relay discovery using Model A, a U2U relay WTRU (e.g., UE) can send an announcement message with information about nearby terminal WTRUs (e.g., UE). However, in a multi-hop scenario, the U2U relay WTRU (e.g., UE) in the notification message can send information about the terminal WTRU (e.g., UE), which can be set as a U2N relay WTRU (e.g., UE) in the first hop. But in the second hop or subsequent hops, the U2U relay WTRU (e.g., UE) in the notification message can include terminal WTRU (e.g., UE) information, as well as additional information about other WTRUs (e.g., UE) (e.g., U2N relays, U2U relays, remote WTRUs (e.g., UEs) that are not nearby but are mentioned in the received discovery message). The terminal WTRU (e.g., UE) information is set as another U2U relay WTRU (e.g., UE), but it can also include information about the initiating U2N relay WTRU (e.g., UE) and multiple U2U relay WTRUs (e.g., UEs). (That is, the U2U relay notification message can include messages about the terminal WTRU (e.g., UE) (e.g., a nearby remote WTRU (e.g., UE) or U2N relay or U2U relay).

[0124] The per-hop QoS determination in step 4.5 can be the same as in step 4.3 above. According to some embodiments, the delay calculated in this step 4.5 can be not only the per-hop delay between itself and the U2U relay at the last hop, but also the delay between itself and the U2N relay via other U2U relays, i.e., the cumulative delay. To support this, it can include a list of timestamps for each hop, a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops, or the sum of all measured propagation delays.

[0125] Step 4.6 can be the same as step 4.4, except that the U2U relay discovery announcement message can be triggered based on receiving a U2U relay discovery announcement message from another U2U relay WTRU (e.g., UE). In step 4.4, this could be based on a U2N relay discovery message. The IE in the message can remain the same as in step 4.4, that is, the discovery information received from the U2U relay in the previous hop, plus the user information of the announcing relay, and a list of cumulative delay values ​​or per-hop delay values ​​updated to the current hop will be included in the U2U relay announcement message.

[0126] Remote WTRUs (e.g., UEs) can perform U2N relay selection and routing based on QoS parameters, for example, by comparing the cumulative propagation delay or so-called multi-hop propagation delay (a list of timestamps for each hop, a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops with a required E2E propagation delay budget, which can be based on a list of QoS parameters associated with one or more (e.g., each) RSCs (step 4.7).

[0127] A remote WTRU (e.g., a UE) can establish a connection with a U2N trunk WTRU (e.g., a UE) via one or more U2U trunks. Figure 6 The document provides a detailed solution for establishing a PC5 link (step 4.8).

[0128] Figure 5 This is a diagram illustrating multi-hop U2N relay discovery (Model B).

[0129] For WTRU-to-network (e.g., UE-to-network) relay discovery using the Model B discovery procedure, the remote WTRU (e.g., UE) can trigger the discovery procedure by sending a U2N relay discovery solicitation message that includes a multi-hop indication. When the U2U relay WTRU (e.g., UE) receives a U2N relay discovery solicitation message from the remote WTRU (e.g., UE), which may include a multi-hop indication and / or MH_U2N_RSC, it can generate a U2U relay discovery solicitation message that includes parameters as listed in the detailed solution below.

[0130] There may be a situation where a U2U relay has previously received a U2N relay discovery notice from a U2N relay WTRU (e.g., a UE). In this case, the U2U relay WTRU (e.g., a UE) can (e.g., locally) store this information and use it when a remote WTRU (e.g., a UE) can trigger U2N relay discovery using Model B. That is, the U2U relay can send a response message including the stored information to the remote WTRU (e.g., a UE) (or to another U2U relay if it receives a solicitation message from another U2U relay), instead of sending a solicitation message to the U2N relay.

[0131] In step 5.1, one or more (e.g., each) WTRUs (e.g., UEs) (i.e., remote WTRUs (e.g., UEs), U2U trunks, and U2N trunks) may be pre-configured or equipped with multi-hop specific configurations and authorizations, such as: an indication of whether multi-hop is enabled / disabled, multi-hop authorizations for acting as remote UE / U2U trunk WTRUs (e.g., UEs) or U2N trunks, E2E QoS including maximum time delay budget, maximum number of hops, multi-hop specific RSCs (e.g., MH_U2N_RSC, MH_U2U_RSC), and a list of E2E QoS parameters linked to one or more (e.g., each) multi-hop specific RSCs.

[0132] In step 5.2, the U2U trunk can receive a discovery announcement message from the U2N trunk, which includes a multi-hop indication, a multi-hop specific trunk service code (MH_U2N_RSC) for U2N trunk services, and an E2E QoS associated with MH_U2N_RSC.

[0133] In step 5.3, if step 5.2 occurs, (for example, then) the U2U trunk (for example, local) can save information about the U2N trunk WTRU (for example, UE) and its corresponding parameters.

[0134] A remote WTRU (e.g., a UE) can send a U2N relay discovery solicitation message, which includes a multi-hop indication, a multi-hop specific relay service code (MH_U2N_RSC) for U2N relay services, a timestamp, a hop counter value initially set to zero, and an E2E QoS associated with MH_U2N_RSC (step 5.4).

[0135] In step 5.5a (Discovery solicitation message from U2U relay to another U2U relay), U2U relay 1 can look for the multi-hop specific relay service code (MH_U2N_RSC) and / or multi-hop indication for U2N relay in the received U2N relay discovery solicitation message received from a remote WTRU (e.g., UE), and if present, (e.g., then) U2U relay 1 will use it as a trigger to generate a U2U relay discovery solicitation message to be broadcast by the U2U relay.

[0136] U2U relay discovery solicitation messages may include information about the remote WTRU (e.g., UE), multi-hop indication, MH_U2N_RSC, MH_U2U_RSC, E2E QoS associated with MH_U2N_RSC, discovery payload received from the remote WTRU (e.g., UE), and user information of the U2U relay WTRU (e.g., UE) itself. One aspect of this step may be the definition of the discovery message, i.e., that the U2U relay can receive a U2N relay discovery solicitation message (from a remote UE), and based on this, it can send a U2U relay discovery solicitation message. The U2U relay may forward the U2U relay discovery solicitation message to another U2U relay WTRU (e.g., UE) or a U2N relay WTRU (e.g., UE). One or more (e.g., each) solicitation messages may include user information of a single U2U relay WTRU (e.g., UE), or a list of user information for one or more U2U relay UEs.

[0137] In step 5.5b, U2U relay 2 may forward the discovery solicitation message from U2U relay 1 to U2N relay WTRU (e.g., UE). The discovery solicitation message may include all IEs received as in 5a, and may additionally include a list of one or more U2U relay UEs involved in the previous hop, including itself.

[0138] In step 5.6, the U2N relay (e.g., then) may send a U2U relay discovery response message to the U2U relay 2 from which it received the U2U relay discovery solicitation message. The U2U relay discovery response message may include, for example, U2N relay user information, multi-hop indication, cumulative propagation delay (if calculated by the U2N relay WTRU (e.g., UE)) (a list of timestamps per hop, a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops, or the sum of all measured propagation delays), and may return a list of one or more U2U relay UEs received in the solicitation message.

[0139] In step 5.7, based on the received discovery response message, U2U relay 2 can determine the per-hop QoS between itself and U2N relay WTRU (e.g., UE). When enabled for multi-hop, the U2U relay WTRU (e.g., UE) can create a mapping table in which it associates the per-hop QoS calculation with user information of one or more (e.g., each) of the nearby available U2N relay WTRUs (e.g., UE).

[0140] According to some embodiments, it is assumed that steps 5.2 and 5.3 occur before step 5.4. In this case, steps 5.5b and 5.6 can be skipped. In this case, U2U relay 2 can utilize (e.g., locally) stored information as in step 5.2 to determine nearby available U2N relay WTRUs (e.g., UEs), calculate per-hop QoS, and also the cumulative latency. It can compare the results with E2E QoS information received from the U2N relay and send a U2U relay discovery response message as a reply to the U2U relay solicitation message.

[0141] In step 5.8(a), U2U relay 2 (e.g., then) may send a U2U relay discovery response message to U2U relay 1 from which the solicitation message has been received. The response message may include available U2N relays (e.g., U2N relay user information), multi-hop indication, MH_U2N_RSC, and cumulative propagation delays calculated by one or more (e.g., each) U2U relay WTRUs (e.g., UEs) at one or more (e.g., each) hops.

[0142] In step 5.8(b), U2U relay 1 may (e.g., then) send a U2N relay discovery response message to a remote WTRU (e.g., UE) from which the solicitation message has been received. The response message may include available U2N relays (e.g., U2N relay user information), a multi-hop indication, MH_U2N_RSC, and the cumulative propagation delay calculated by one or more (e.g., each) U2U relay WTRUs (e.g., UEs) at one or more (e.g., each) hops.

[0143] In step 5.8 (a / b), a U2U relay may send information about a U2N relay independently in a separate solicitation response message, or it may send a solicitation response message that includes a list of all U2N relays with information for all received solicitation response messages.

[0144] In step 5.9, the remote WTRU (e.g., UE) may perform U2N relay selection and routing based on QoS parameters, for example, by comparing the cumulative propagation delay or so-called multi-hop propagation delay (a list of timestamps for each hop, a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops with a desired E2E propagation delay budget, which may be based on a list of QoS parameters associated with one or more (e.g., each) relays.

[0145] In step 5.10, a remote WTRU (e.g., a UE) can establish a connection with a U2N relay WTRU (e.g., a UE). Figure 6 A detailed solution was provided.

[0146] A method and apparatus are provided for establishing a relay WTRU (e.g., UE) PC5 link via a multi-hop WTRU to network (e.g., UE to network).

[0147] Figure 6 This is a diagram illustrating the establishment of multi-hop links.

[0148] For a PC5 link established via a multi-hop WTRU to the network (e.g., UE to the network), it can be assumed that the remote WTRU (e.g., UE) has discovered the U2N relay WTRU (e.g., UE) via multiple hops using one or more U2U relay UEs. This discovery can be as described above. Figure 4 and Figure 5 The solution is executed as discussed in the present paper. Once the remote WTRU (e.g., UE) has discovered the U2N relay, it can (e.g., then) establish a connection via a selected route, which may include one or more U2U relay WTRUs (e.g., UEs). The remote WTRU (e.g., UE) can initiate a direct link establishment by sending a Direct Communication Request (DCR). The U2U relay WTRU (e.g., UE) further broadcasts this message, but if a link already exists between the peer WTRUs (e.g., UEs) (between a U2U relay WTRU (e.g., UE) and a U2N relay WTRU (e.g., UE) or between two U2U relay UEs), the message can be either a DCR message or a Direct Link Modification (LMR) message.

[0149] According to some embodiments, independent discovery, i.e., integrated discovery, may not exist when discovery is not performed and the remote WTRU (e.g., UE) does not discover the U2N relay. In this case, the remote WTRU (e.g., UE) may send a DCR message, which includes the information elements as described above for a DCR message plus the desired user information of the U2N relay (if available through configuration or due to previous communication). Multi-hop routing can be performed by the U2N relay or by the remote WTRU (e.g., UE) based on the DCR / DCA message by calculating cumulative QoS. For example, the U2N relay may receive a DCR message that may include cumulative QoS information from a U2U relay. The U2N relay may further calculate the total multi-hop QoS (E2E from the remote WTRU (e.g., UE) to the U2N relay). The U2N determines whether to respond to the remote WTRU (e.g., UE) request based on the multi-hop QoS determination.

[0150] Based on DCR or LMR messages, U2N trunks can establish new PDU sessions or update existing PDU sessions.

[0151] In step 6.0a: authorization and provision of parameters for multi-hop relays as described in Solution 1.

[0152] In step 6.0b: as previously, for example in Figure 4 or Figure 5 The discovery procedure described in [the document / document].

[0153] The link establishment process may include any of the following steps.

[0154] In step 6.1, the remote WTRU (e.g., UE) may select a path based on step 6.0b and may send a DCR (or LMR) including routing information using a U2U relay user information [list] (e.g., one or more (e.g., each) selected U2U relay user information IDs), which may include a multi-hop indication, MH_U2N_RSC, U2N relay user information, remote WTRU (e.g., UE) user information, and a list of E2E QoS parameter information associated with the RSC.

[0155] In step 6.2, if there is no PC5 link between the U2U trunk and the next U2U trunk in the user information list, or if the user information list of the U2N trunk is empty, the U2U trunk may send a DCR message to the next U2U trunk in the list (i.e., the user information list) or to the U2N trunk. The DCR message includes a multi-hop indication, MH_U2N_RSC, MH_U2U_RSC, the U2U trunk user information [list] of other U2U trunks, the U2N trunk user information, and the remote WTRU (e.g., UE) user information.

[0156] In step 6.2, if there is a PC5 link between the U2U trunk and the next U2U trunk in the user information list, or if the user information list of the U2N trunk is empty, the U2U trunk can send an LMR message to the next U2U trunk in the list (i.e., the user information list) or to the U2N trunk. The LMR message includes a multi-hop indication, MH_U2N_RSC, MH_U2U_RSC, the U2U trunk user information [list] of other U2U trunks, the U2N trunk user information, and the remote WTRU (e.g., UE) user information.

[0157] LMR may be new information compared to the procedures currently prescribed for U2N trunks. A U2N trunk can (e.g., needs to) identify the remote WTRU (e.g., UE) behind the U2U trunk. This means that a U2N trunk can (e.g., needs to) consider remote WTRU (e.g., UE) information without considering (e.g., only) U2U trunk information. A U2N trunk can receive DCR or LMR, which may include a list of one or more U2U trunk UE user information that suggests the U2N trunk WTRU (e.g., UE) tracks this information for each remote WTRU (e.g., UE).

[0158] Existing procedures for DCR and LMR can be used, but now U2N relays may (e.g., need) consider not only remote WTRU (e.g., UE) information, but also U2U relay information.

[0159] According to some embodiments, one or more (e.g., each) hops of the U2U relay can determine per-hop QoS or cumulative QoS. For any hop where the cumulative propagation delay is estimated to be large, i.e., if it exceeds the E2E delay budget up to that hop, it may stop sending any DCR messages. It can send a Direct Communication Rejection message to the remote WTRU (e.g., the UE) with the reason value set to "QoS not satisfied" or a similar value stating that the QoS cannot be achieved. It will then stop sending any Direct Communication Request messages.

[0160] In step 6.3, the U2N relay can initiate a new PDU session establishment procedure or a PDU session modification procedure based on step 6.2. Based on DCR or LMR messages, the U2N relay can establish a new PDU session or update an existing PDU session. In the case of multi-hop communication, when establishing or modifying a PDU session, the U2N relay can (e.g., needs to) manage the PQI mapping of remote WTRUs (e.g., UEs), rather than the mapping of U2U relay WTRUs (e.g., UEs). In existing single-hop specifications, the U2N relay considers the remote WTRU (e.g., UE) that may be in the first hop, while in this case, it may (e.g., needs to) consider remote WTRUs (e.g., UEs) that may be hidden behind one or more U2U relay UEs. In other words, for multi-hop relays, the 5GC can accept PDU session establishment or modification based on the authorization results of the remote WTRUs (e.g., UEs) and the involved U2U relays.

[0161] In step 6.4, when the U2N relay receives a DCR / LMR message from the U2U relay, it can accept the DCR / LMR message and send a DCA / LMA message to the U2U relay WTRU (e.g., UE). The DCA / LMA message includes a list of U2U relay user information along the route-selected U2U relay, U2N relay user information, remote WTRU (e.g., UE) user information, and E2E QoS.

[0162] In step 6.5, when a DCA / LMA message is received from the U2N relay, the U2U relay can use... Figure 4 A similar procedure as specified in step 4.3 is used to perform per-hop QoS determination. If multiple U2U relays are involved in a multi-hop communication link, one or more (e.g., each) U2U relays can perform this step.

[0163] When a U2N trunk can send a DCA / LMA to a U2U trunk, it can include E2E QoS in the DCA / LMA message. The U2U trunk can (for example, needs to) determine the per-hop QoS between the U2N trunk and the U2U trunk.

[0164] In step 6.6, the U2U relay can further pass a DCA / LMA message to another U2U relay or remote WTRU (e.g., UE). This DCA / LMA message includes U2U relay user information, remote WTRU (e.g., UE) user information, and E2E QoS. The DCA or LMA message (e.g., then) includes the per-hop QoS calculated by the U2U relay. Before sending the DCA / LMA, the U2U relay can calculate the per-hop QoS at the next hop with the remote WTRU (e.g., UE) or other U2U relays based on the E2E QoS and the calculated per-hop QoS of one or more U2U relays received at the earlier hop.

[0165] Figure 7 This is a flowchart illustrating a representative method 700 implemented from a first device / WTRU to a device / WTRU (U2U) relay WTRU 102. (Reference) Figure 7 Representative method 700 may include, at block 710, receiving a first relay discovery announcement message from a device / WTRU to a network (U2N) relay WTRU or from a second device-to-device relay WTRU. At block 720, representative method 700 may include broadcasting a second relay discovery announcement message. At block 730, representative method 700 may include receiving a first DCR message (DCR) or a first Link Modification Request (LMR) message from a third device-to-device relay WTRU. At block 740, representative method 700 may include sending a second DCR message or a second LMR message to a device-to-network relay WTRU or to a second device-to-device relay WTRU. At block 750, representative method 700 may include receiving a DCA message or an LMA message from a device-to-network relay WTRU or from a second device-to-device relay WTRU. At block 760, representative method 700 may include sending a DCA / LMA message to a third device-to-device relay WTRU.

[0166] According to some embodiments, the discovery notification message includes any one of the following: multi-hop indication, multi-hop specific RSC (MH_U2N_RSC) for device-to-network relay service, timestamp, hop counter value, E2EQoS associated with MH_U2N_RSC, and U2N relay user information.

[0167] According to some embodiments, representative method 700 may further include determining per-hop QoS and determining a mapping table that associates the determined per-hop QoS with user information of one or more (e.g., each) of available terminal WTRUs near the first device-to-device relay WTRU.

[0168] According to certain embodiments, the discovery notification message includes any of the following: a list of propagation delay values ​​measured from one or more (e.g., each) relays for one or more (e.g., each) hops, and the cumulative propagation delay.

[0169] According to some embodiments, the second DCR / LMR message includes any one of the following: multi-hop indication, MH_U2N_RSC, RSC for device-to-device relay service (MH_U2U_RSC, U2U), a list of user information for other device-to-device relays, device-to-network user information, and remote WTRU.

[0170] Figure 8 This is a flowchart illustrating a representative method 800 implemented from a first device / WTRU to a device / WTRU (U2U) relay WTRU 102. (Reference) Figure 8 Representative method 800 may include, at block 810, receiving a first relay discovery announcement message from a device-to-network relay WTRU. At block 820, representative method 800 may include receiving a discovery solicitation message from a remote WTRU. At block 830, representative method 800 may include broadcasting a second relay discovery announcement message. At block 840, representative method 800 may include receiving a discovery response message from a device-to-network relay WTRU or from a second device-to-device relay WTRU. At block 850, representative method 800 may include receiving a first DCR message (DCR) or a first LMR message from a third device-to-device relay WTRU. At block 860, representative method 800 may include sending a second DCR message or a second LMR message to a device-to-network relay WTRU or to a second device-to-device relay WTRU. At block 870, representative method 800 may include receiving a DCA message or an LMA message from a device-to-network relay WTRU or from a second device-to-device relay WTRU. At box 880, representative method 800 may include sending a DCA / LMA message to a third device-to-device relay WTRU.

[0171] According to some embodiments, representative method 800 may further include determining per-hop QoS and determining a mapping table that associates the determined per-hop QoS with user information of one or more (e.g., each) of available terminal WTRUs near the first device-to-device relay WTRU.

[0172] According to some embodiments, the response message is found to include any of the following: A list of propagation delay values ​​measured from one or more (e.g., each) relays for each hop, including a timestamp for each hop and a cumulative propagation delay.

[0173] According to some embodiments, the second DCR / LMR message includes any one of the following: multi-hop indication, multi-hop specific RSC (MH_U2N_RSC) for device-to-network relay service, RSC (MH_U2U_RSC, U2U) for device-to-device relay service, a list of user information for other device-to-device relays, device-to-network user information, and remote WTRU.

[0174] Figure 9 This is a flowchart illustrating a representative method 900 implemented from a first device / WTRU to a device / WTRU (U2U) relay WTRU 102. (Reference) Figure 9 Representative method 900 may include, at block 910, receiving a first DCR message (DCR) or a first LMR message from a remote WTRU. At block 920, representative method 900 may include sending a second DCR message or a second LMR message to a device-to-network relay WTRU or a second device-to-device relay WTRU. At block 930, representative method 900 may include receiving a DCA message or an LMA message from a device-to-network relay WTRU or a second device-to-device relay WTRU. At block 940, representative method 900 may include sending a DCA / LMA message to a third device-to-device relay WTRU.

[0175] According to certain embodiments, the first DCR / LMR message includes any of the following: routing information using device-to-device user information, user information IDs of one or more (e.g., each) selected device-to-device relay WTRUs along the route, multi-hop indication, MH_U2N_RSC, device-to-network relay user information, remote WTRU user information, and a list of E2E QoS parameters associated with a multi-hop specific RSC.

[0176] According to some embodiments, the second DCR / LMR message includes any one of the following: multi-hop indication, multi-hop specific RSC (MH_U2N_RSC) for device-to-network relay service, RSC (MH_U2U_RSC, U2U) for device-to-device relay service, a list of user information for other device-to-device relays, device-to-network user information, and remote WTRU.

[0177] According to certain embodiments, the DCA / LMA message includes any of the following: routing information using device-to-device user information, user information IDs of one or more (e.g., each) selected device-to-device relay WTRUs along the route, multi-hop indication, MH_U2N_RSC, device-to-network relay user information, remote WTRU user information, and a list of E2E QoS parameters associated with a multi-hop specific RSC.

[0178] According to some embodiments, representative method 900 may further include determining per-hop QoS and determining a mapping table that associates the determined per-hop QoS with user information of one or more (e.g., each) of available terminal WTRUs near the first device-to-device relay WTRU.

[0179] Figure 10 This is a flowchart illustrating a representative method 1000 for multi-hop communication between a remote WTRU and a device-to-network relay WTRU, implemented by a first device / WTRU to device / WTRU (U2U) relay WTRU 102.

[0180] refer to Figure 10 Representative method 1000 may include receiving a first relay discovery message at block 1010 from any of the following: (1) a device-to-network relay WTRU, (2) a second device-to-device relay WTRU, and (3) a remote WTRU.

[0181] At box 1020, representative method 1000 may include determining the cumulative propagation delay associated with multi-hop communication.

[0182] At box 1030, representative method 1000 may include broadcasting a second relay discovery message based on a first relay discovery message, the second relay discovery message including information indicating cumulative propagation delay.

[0183] At box 1040, representative method 1000 may include receiving a first direct connection request (DCR) message or a first link modification request (LMR) message from a third device to a device relay WTRU.

[0184] At box 1050, representative method 1000 may include sending a second DCR message based on the first DCR message or a second LMR message based on the first LMR message to a device-to-network relay WTRU or to a second device-to-device relay WTRU.

[0185] At box 1060, representative method 1000 may include receiving a Direct Communication Acceptance (DCA) message or a Link Modification Acceptance (LMA) message from a device to a network relay WTRU or from a second device to a device relay WTRU.

[0186] At box 1070, representative method 1000 may include sending a DCA message or an LMA message to a third device-to-device relay WTRU.

[0187] According to some embodiments, a second DCR message or a second LMR message is sent based on cumulative propagation less than a threshold.

[0188] According to some embodiments, the first relay discovery message is a discovery notification message, and / or the second relay discovery message is a discovery notification message.

[0189] According to some embodiments, the first relay discovery message is a discovery solicitation message, and / or the second relay discovery message is a discovery notification message.

[0190] According to some embodiments, representative method 1000 may include receiving a discovery response message from a device to a network relay WTRU or from a second device to a device relay WTRU.

[0191] According to some embodiments, the second relay discovery message may include information indicating one or more device-to-device relay WTRUs near the first device-to-device relay WTRU.

[0192] According to some embodiments, the second relay discovery message may include information indicating any of the following: (1) a multi-hop indication, (2) a multi-hop specific relay service code (RSC) for the device-to-network relay service (MH_U2N_RSC), (3) a timestamp, (4) a hop counter value, (5) an end-to-end (E2E) quality of service (QoS) associated with MH_U2N_RSC, and (6) user information associated with the device-to-network relay.

[0193] According to some embodiments, representative method 1000 may include determining at least one per-hop QoS and determining a mapping table that associates the at least one per-hop QoS with user information associated with one or more available terminal WTRUs near a first device-to-device relay WTRU.

[0194] According to certain embodiments, second relay discovery may include information indicating any of the following: (1) one or more timestamps for each hop associated with multi-hop communication, and (2) a propagation delay value measured from each relay for each hop associated with multi-hop communication.

[0195] According to certain embodiments, the second DCR message or the second LMR message may include information indicating any of the following: (1) multi-hop indication, (2) MH_U2N_RSC, (3) RSC (MH_U2U_RSC, U2U) for device-to-device relay service, (4) user information list of device-to-device relay WTRU, (5) device-to-network relay WTRU user information, and (6) remote WTRU user information.

[0196] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which are intended to illustrate various aspects. Many modifications and variations can be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. No element, action, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly provided so. Based on the foregoing description, functionally equivalent methods and apparatuses within the scope of this disclosure will be apparent to those skilled in the art, in addition to those methods and apparatuses listed herein. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of equivalents thereof. It should be understood that this disclosure is not limited to specific methods or systems.

[0197] For simplicity, the foregoing embodiments are discussed in terms of the terminology and structure of devices with infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0198] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" can refer to any of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE," the term "remote," and / or the term "head-mounted display" and its abbreviation "HMD" can mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device particularly configured with some or all of the constructs and functions of a WTRU and having wireless and / or wired capabilities (e.g., tetherable); (iv) a device configured with fewer than all the constructs and functions of a WTRU and having wireless and / or wired capabilities; or (iv) something like that. Figure 1A-1D Details of an example WTRU that can represent any WTRU described herein are provided. As another example, this document... The above text and The following textThe various embodiments disclosed herein are described as utilizing head-mounted displays. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and some or all of this disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive, realistic experience.

[0199] Furthermore, the methods provided herein can be implemented in computer programs, 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 memory 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, WTRU (e.g., UE), terminal, base station, RNC, or any host computer.

[0200] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) providing any suitable voltage.

[0201] Furthermore, in the embodiments provided above, a processing platform, computing system, controller, and other devices, including a processor, are mentioned. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be referred to as being “executed,” “computer-executed,” or “CPU-executed.”

[0202] Those skilled in the art will understand that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. Electrical systems represent data bits that can cause a final transformation or reduction of electrical signals, and data bits are maintained in memory locations within memory systems, thereby reconfiguring or otherwise altering the CPU's operation and other signal processing. The memory location maintaining the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.

[0203] Data bits can also be maintained on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system. The computer-readable medium can include cooperative or interconnected computer-readable media that reside exclusively on the processing system or are distributed across multiple interconnected processing systems, which may be local or remote within the processing system. It should be understood that the embodiments are not limited to the above-described memories, and other platforms and memories may support the provided methods.

[0204] In the illustrative embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0205] There is little difference between the hardware and software implementations of the various aspects of the system. The use of hardware or software is often (but not always, as the choice between hardware and software may become important in certain contexts) a design choice representing a cost-efficiency trade-off. Various means can exist to implement the processes and / or systems and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred means can vary depending on the context of the deployment of the processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are of paramount importance, the implementer may choose a primarily hardware and / or firmware approach. If flexibility is of paramount importance, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0206] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Within the scope of such block diagrams, flowcharts, and / or examples encompassing one or more functions and / or operations, those skilled in the art will understand that each function and / or operation in such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide variety of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing circuitry and / or writing code for software and / or firmware in accordance with this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as a program product in various forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.; and transmission media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0207] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently integrate such described devices and / or processes into data processing systems using engineering practice. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface and applications, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0208] The topics described herein sometimes illustrate different components included within or connected to other components. It should be understood that the architectures depicted are merely examples, and many other architectures can indeed be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieve the same functionality is effectively “associated” to achieve the desired functionality. Therefore, any two components combined in this document to achieve a particular function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be so associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operational coupling include, but are not limited to, physically matable and / or physically interactive components and / or wirelessly interactive components and / or logically interactive components.

[0209] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art may appropriately translate from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural arrangements may be explicitly described herein.

[0210] Those skilled in the art will understand that, generally, the terminology used herein, and especially in the appended claims (e.g., the body of the appended claims), is generally intended as “open” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “comprising” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if the intent is to describe a specific number of items in the appended claims, such intent will be explicitly detailed in the claims, and if no such description is provided, such intent does not exist. For example, the term “single” or similar language may be used where the intent is to describe only one item. To aid understanding, the appended claims and / or the description herein may include the use of introductory phrases “at least one” and “one or more” to introduce the description of the claims. However, the use of such phrases should not be construed as implying that a claim recitation introduced by the indefinite article "a" or "an" limits any particular claim to include only one such recitation, even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "an" or "a" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce a claim recitation. Furthermore, even if the specific number of recitations in an introduced claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number of recitations (e.g., the simple statement "two recitations" without other modifiers means at least two recitations, or two or more recitations). Furthermore, in cases where conventions such as "at least one of A, B, and C" are used, generally, such a construction is intended to be based on the meaning of the convention as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In cases where conventions such as "at least one of A, B, or C" are used, generally, such a construction is intended to be based on the meaning of the convention as would be understood by a person skilled in the art (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that any transition words and / or phrases that actually represent two or more alternative terms, whether in the specification, claims, or drawings, should be understood to imply the possibility of including one, any, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, as used herein, the term “any one of…” following a list of multiple items and / or multiple item categories is intended to include, alone or in combination with other items and / or other item categories, “any one,” “any combination,” “any multiple,” and / or “any combination of multiples.” Furthermore, as used herein, the term “set” is intended to include any number of items, including zero. Furthermore, as used herein, the term “quantity” is intended to include any number, including zero. And as used herein, the term “multiple” is intended to be synonymous with “multiple.”

[0211] Furthermore, in cases where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is therefore also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0212] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also include any and all possible subscopes and combinations thereof. Any listed scope can be readily considered sufficiently descriptive and makes it possible to decompose the same scope into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. Those skilled in the art will also understand that all language (such as “up to,” “at least,” “greater than,” “less than,” etc.) includes the stated numbers and refers to a scope that can subsequently be decomposed into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1-3 subscopes refers to a group having 1, 2, or 3 subscopes. Similarly, a group having 1-5 subscopes refers to a group having 1, 2, 3, 4, or 5 subscopes, and so on. Furthermore, the claims should not be construed as being limited to the provided order or elements unless expressly stated otherwise. Additionally, the use of the term "means for..." in any claim is intended to refer to... The claim format is either device plus function, and any claim without the term "device for..." is not intended to be so.

Claims

1. A method implemented by a first device-to-device relay wireless transmit / receive unit (WTRU), wherein, The first device-to-device relay WTRU is configured for multi-hop communication between a remote WTRU and a device-to-network relay WTRU, the method comprising: Receive a first relay discovery message from any of the following: (1) the device-to-network relay WTRU, (2) the second device-to-device relay WTRU, and (3) the remote WTRU; Determine the cumulative propagation delay associated with the multi-hop communication; A second relay discovery message is broadcast based on the first relay discovery message, the second relay discovery message including information indicating the cumulative propagation delay; The third device to device relay WTRU receives a first direct connection request (DCR) message or a first link modification request (LMR) message; Send a second DCR message based on the first DCR message or a second LMR message based on the first LMR message to the device-to-network relay WTRU or to the second device-to-device relay WTRU; Receive Direct Communication Acceptance (DCA) messages or Link Modification Acceptance (LMA) messages from the device to the network relay WTRU or from the second device to the device relay WTRU; and Send the DCA message or the LMA message to the third device-to-device relay WTRU.

2. The method according to claim 1, wherein, The second DCR message or the second LMR message is sent based on the cumulative propagation being less than a threshold.

3. The method according to any one of claims 1-2, wherein, The first relay discovery message is a discovery notification message, and / or the second relay discovery message is a discovery notification message.

4. The method according to any one of claims 1-2, wherein, The first relay discovery message is a discovery solicitation message, and / or the second relay discovery message is a discovery notification message; and includes receiving a discovery response message from the device to network relay WTRU or from the second device to device relay WTRU.

5. The method according to any one of claims 1-4, wherein, The second relay discovery message includes information indicating one or more device-to-device relay WTRUs near the first device-to-device relay WTRU.

6. The method according to any one of claims 1-5, wherein, The second relay discovery message includes information indicating any of the following: (1) multi-hop indication, (2) multi-hop specific relay service code (RSC) (MH_U2N_RSC) for device-to-network relay service, (3) timestamp, (4) hop counter value, (5) end-to-end (E2E) quality of service (QoS) associated with the MH_U2N_RSC, and (6) user information associated with the device-to-network relay.

7. The method according to any one of claims 1-6, further comprising: Determine at least the QoS per hop; as well as A mapping table is determined to associate the at least per-hop QoS with user information associated with one or more available terminal WTRUs near the first device-to-device relay WTRU.

8. The method according to any one of claims 1-7, wherein, The second relay discovery includes information indicating any of the following: (1) one or more timestamps for each hop associated with the multi-hop communication, and (2) a propagation delay value measured from each relay for each hop associated with the multi-hop communication.

9. The method according to any one of claims 1-8, wherein, The second DCR message or the second LMR message includes information indicating any of the following: (1) multi-hop indication, (2) MH_U2N_RSC, (3) RSC (MH_U2U_RSC, U2U) for device-to-device relay service, (4) user information list of device-to-device relay WTRU, (5) device-to-network relay WTRU user information, and (6) remote WTRU user information.

10. A first device-to-device relay wireless transmit / receive unit (WTRU) comprising a processor, a transceiver, and a memory, the first device-to-device relay WTRU being configured for multi-hop communication between a remote WTRU and a device-to-network relay WTRU, the processor, the transceiver, and the memory being configured for: Receive a first relay discovery message from any of the following: (1) the device-to-network relay WTRU, (2) the second device-to-device relay WTRU, and (3) the remote WTRU; Determine the cumulative propagation delay associated with the multi-hop communication; A second relay discovery message is broadcast based on the first relay discovery message, the second relay discovery message including information indicating the cumulative propagation delay; The third device to device relay WTRU receives a first direct connection request (DCR) message or a first link modification request (LMR) message; Send a second DCR message based on the first DCR message or a second LMR message based on the first LMR message to the device-to-network relay WTRU or to the second device-to-device relay WTRU; Receive Direct Communication Accept (DCA) messages or Link Modification Accept (LMA) messages from the device to the network relay WTRU or from the second device to the device relay WTRU; as well as Send the DCA message or the LMA message to the third device-to-device relay WTRU.

11. The first device-to-device relay WTRU according to claim 10, wherein, The second DCR message or the second LMR message is sent based on the cumulative propagation being less than a threshold.

12. The first device-to-device relay WTRU according to any one of claims 10-11, wherein, The first relay discovery message is a discovery notification message, and / or the second relay discovery message is a discovery notification message.

13. The first device-to-device relay WTRU according to any one of claims 10-11, wherein, The first relay discovery message is a discovery solicitation message, and / or the second relay discovery message is a discovery notification message; and wherein the first device-to-device relay WTRU is configured to receive a discovery response message from the device-to-network relay WTRU or from the second device-to-device relay WTRU.

14. The first device-to-device relay WTRU according to any one of claims 10-13, wherein, The second relay discovery message includes information indicating one or more device-to-device relay WTRUs near the first device-to-device relay WTRU.

15. The first device-to-device relay WTRU according to any one of claims 10-14, wherein, The second relay discovery message includes information indicating any of the following: (1) multi-hop indication, (2) multi-hop specific relay service code (RSC) (MH_U2N_RSC) for device-to-network relay service, (3) timestamp, (4) hop counter value, (5) end-to-end (E2E) quality of service (QoS) associated with the MH_U2N_RSC, and (6) user information associated with the device-to-network relay.

16. The first device-to-device relay WTRU according to any one of claims 10-15, wherein, The processor, the transceiver, and the memory are configured as follows: Determine at least the QoS per hop; as well as A mapping table is determined to associate the at least per-hop QoS with user information associated with one or more available terminal WTRUs near the first device-to-device relay WTRU.

17. The first device-to-device relay WTRU according to any one of claims 10-16, wherein, The second relay discovery includes information indicating any of the following: (1) one or more timestamps for each hop associated with the multi-hop communication, and (2) a propagation delay value measured from each relay for each hop associated with the multi-hop communication.

18. The first device-to-device relay WTRU according to any one of claims 10-17, wherein, The second DCR message or the second LMR message includes information indicating any of the following: (1) multi-hop indication, (2) MH_U2N_RSC, (3) RSC (MH_U2U_RSC, U2U) for device-to-device relay service, (4) user information list of device-to-device relay WTRU, (5) device-to-network relay WTRU user information, and (6) remote WTRU user information.

Images