Handling of Connection Rejection via a U2U Relay Associated with a Backoff Time Instead of the Source End WTRU

Abstract

A system and method for handling connection rejection via a wireless transmit / receive unit (WTRU)-WTRU (U2U) relay associated with a backoff time, instead of a source end WTRU, are described herein. The relay WTRU can retry establishing a connection with a target WTRU, instead of the source WTRU, based on receiving a rejection (e.g., having a backoff value) from the target WTRU. The source WTRU can associate a rejection message with the target WTRU, and the relay WTRU may be available to reach other target WTRUs. The relay WTRU can send the rejection message to other source WTRUs for the same target WTRU (e.g., if the backoff duration is active and ongoing).

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 457,616, filed on April 6, 2023, the content of which is incorporated herein by reference in its entirety.

Background Art

[0002] Mobile communications using wireless communication are continuously evolving. The fifth generation may be referred to as 5G. Previous (conventional) generations of mobile communications can be, for example, the fourth generation (4G) long - term evolution (LTE).

Summary of the Invention

[0003] A system and method for handling connection rejections via a wireless transmit / receive unit (WTRU) - WTRU (U2U) relay associated with a back - off time, instead of a source - end WTRU, are described herein. The relay WTRU can retry establishing a connection with a target WTRU on behalf of the source WTRU, for example, based on receiving a rejection (e.g., having a back - off value) from the target WTRU. The source WTRU can associate a rejection message with the target WTRU, and the relay WTRU can be available to reach other target WTRUs. The relay WTRU can send the rejection message to other source WTRUs for the same target WTRU (e.g., if the back - off duration is active and ongoing).

[0004] The relay WTRU can retry establishing a connection with the target WTRU instead of the source WTRU. For example, the relay WTRU can receive a first rejection message from the target WTRU. The first rejection message can be associated with a first direct communication request (DCR) transmission or a first link modification request (LMR) transmission. The first rejection message can indicate congestion. The first rejection message can indicate a rejection cause value. The first rejection message can indicate a backoff value. The first DCR or the first LMR may be associated with the source WTRU. The relay WTRU can determine the number of retransmissions associated with the source WTRU (e.g., the number of retransmissions associated with a request to establish a connection). The WTRU can send a second rejection message to the source WTRU. The second rejection message can be sent based on whether the number of retransmissions associated with the source WTRU is less than a threshold (e.g., the maximum number of allowed retransmissions). The second rejection message to the source WTRU can indicate whether the relay WTRU will attempt (e.g., make an attempt) one or more retransmission attempts on behalf of the source WTRU. The second rejection message can indicate the number of retransmission attempts.

[0005] For example, if the number of retransmission attempts associated with the source WTRU is less than a threshold, the relay WTRU performs one or more of the following. The relay WTRU can track a duration associated with a backoff value (e.g., indicated by a first rejection message). The relay WTRU can include in a second rejection message to the source WTRU an indication that the relay WTRU will attempt (e.g., attempt) to perform a retransmission attempt on behalf of the source WTRU. The relay WTRU can transmit a second DCR / LMR transmission to the target WTRU on behalf of the source WTRU (e.g., based on a determination that the backoff value has elapsed). For example, if the number of retransmission attempts is greater than or equal to the threshold, the relay WTRU can decide to abort the direct link establishment. The second rejection message can indicate identification information associated with the target WTRU. The second rejection message can indicate that the maximum number of retries has been reached.

[0006] The relay WTRU can, for example, send a rejection message to the source WTRU without attempting to establish a connection with the target WTRU if the relay WTRU has already received a rejection for a different source WTRU than the target WTRU. The WTRU can receive a first message from the target WTRU. The first message can indicate a rejection associated with a first request to establish a first connection between a first source WTRU and the target WTRU. The first message can indicate a backoff value associated with the target WTRU. The relay WTRU can receive a second message from a second source WTRU. The second message can be associated with a second request to establish a second connection between the second source WTRU and the target WTRU using the relay WTRU. The relay WTRU can send a third message to the second source WTRU indicating that the target WTRU rejected a first request to establish a first connection between the first source WTRU and the target WTRU. The third message can indicate a cause value (e.g., indicating that the target WTRU previously rejected a request to establish a first connection between the first source WTRU and the target WTRU). The relay WTRU can, for example, send the third message without attempting to establish with the target WTRU (e.g., because the relay WTRU has already received a rejection for the first source WTRU and the target WTRU). The relay WTRU can determine that a duration associated with the backoff value has expired. The WTRU can send a fourth message to the target WTRU (e.g., based on the determination that the duration associated with the backoff value has expired). The fourth message can be associated with one or more of a first request to establish a first connection between the first source WTRU and the target WTRU or a second request to establish a second connection between the second source WTRU and the target WTRU. The fourth message can be sent, for example, based on a determination that the number of retransmissions associated with establishing a connection with the target WTRU is less than a threshold.The relay WTRU can determine the number of retransmissions. The relay WTRU can receive from the target WTRU a fifth message indicating that a second request to establish a second connection between the second source WTRU and the target WTRU has been rejected. The relay WTRU can determine (e.g., based on the fifth message) that the number of retransmissions associated with establishing a connection with the target WTRU is above a threshold. The relay WTRU can send a rejection message to the second source WTRU associated with a pending link establishment connection request (e.g., based on the determination that the number of retransmissions associated with establishing a connection with the target WTRU is above a threshold).

[0007] The WTRU can send a connection establishment request to the target WTRU. The connection establishment request may be a DCR or an LMR. The WTRU can receive a backoff value associated with a connection establishment rejection associated with the target WTRU. The backoff value associated with the connection establishment rejection may be received in response to the sent connection establishment request. The WTRU can receive a first message indicating that the WTRU should retry connection establishment with the target WTRU. The first message may indicate a value associated with a waiting period duration. The WTRU can track a duration associated with the backoff value. Tracking of the duration can be initiated based on receipt of a third message from the target WTRU. Tracking of the duration can be initiated based on a determination that the waiting period duration has expired. The WTRU can determine to retry connection establishment with the target WTRU. The determination to retry connection establishment with the target WTRU can be based on receiving a third message from the target WTRU indicating to retry connection establishment. The determination to retry connection establishment with the target WTRU can be based on a determination that the duration associated with the backoff value has expired. In one example, the WTRU can be a relay WTRU. In the case of a relay WTRU, the connection establishment rejection may be associated with a first source WTRU. The relay WTRU can send a message to the source WTRU indicating that the target WTRU was requested to wait (e.g., based on receipt of a rejection message). The relay WTRU can attempt to establish a connection between the source WTRU and the target WTRU.

Brief Description of the Drawings

[0008]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

[0009] FIG. 1A is a diagram illustrating an exemplary 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, broadcast, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through sharing of system resources including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC).

[0010] As shown in Figure 1A, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. 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 may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or "STA", may be configured to transmit and / or receive wireless signals and may be user equipment (UE), a mobile station, a fixed subscriber unit or a mobile subscriber unit, a subscriber-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or a Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless devices operating in an industrial and / or automated processing chain context), a home appliance device, a device operating in a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may also be referred to interchangeably as a UE.

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

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

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

[0014] More specifically, as described above, the communication system 100 may be a multiple access system, and may use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117. 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 UL Packet Access (HSUPA).

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

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

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

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

[0019] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

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

[0022] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 can include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A can be configured to communicate with a base station 114a that can employ a cellular-based wireless technology and a base station 114b that can employ IEEE802 wireless technology.

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

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

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

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

[0027] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have a multimode function. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

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

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

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

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

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

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

[0034] The RAN104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of the eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU102a, 102b, 102c via the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB160a may transmit and / or receive radio signals from the WTRU102a, for example, using multiple antennas.

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

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

[0037] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, and 160c within the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can perform functions such as authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0038] SGW 164 can be connected to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. SGW 164 can generally route and transfer user data packets between the WTRUs 102a, 102b, and 102c. SGW 164 can perform other functions such as the function of anchoring the user plane during handover between eNodeBs, the function of triggering paging when DL data is available to the WTRUs 102a, 102b, and 102c, and the function of managing and storing the contexts of the WTRUs 102a, 102b, and 102c.

[0039] SGW 164 can be connected to PGW 166, but PGW 166 can provide access to a packet-switched network such as the Internet 110 to the WTRUs 102a, 102b, and 102c to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-compatible devices.

[0040] CN 106 can facilitate communication with other networks. For example, CN 106 can provide access to a circuit-switched network such as PSTN 108 to the WTRUs 102a, 102b, and 102c to facilitate communication between the WTRUs 102a, 102b, and 102c and legacy landline communication devices. For example, CN 106 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN 106 and PSTN 108. In addition, CN 106 can provide the WTRUs 102a, 102b, and 102c with access to another network 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] The WTRU is described as a wireless terminal in FIGS. 1A - 1D, but in certain representative embodiments, it is contemplated that such a terminal can use a wired communication interface to the communication network (e.g., temporarily or permanently).

[0042] In an exemplary embodiment, the other network 112 can be a WLAN.

[0043] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP can have access to or an interface to another type of wired network / wireless network that carries traffic entering and / or exiting the Distribution System (DS) or the BSS. Traffic destined for an STA that originates outside the BSS can reach and be sent to the STA through the AP. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP so as to be sent to their respective destinations. Traffic between STAs within the BSS can be transmitted, for example, through the AP. The source STA can send the traffic to the AP, and the AP can send the 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 the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In a particular exemplary embodiment, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS mode of communication can be referred to herein as the "ad hoc" communication mode.

[0044] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may 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 a width dynamically set via signaling. The primary channel can be the operating channel of the BSS, but can also be used by the STA to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0045] A High Throughput (HT) STA can use a 40 MHz wide channel for communication, and this 40 MHz wide channel can be formed, for example, through a combination of the primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

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

[0047] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequency are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro communication range area. The MTC device may have limited capabilities, including support for certain capabilities, e.g., support for certain and / or limited bandwidths (e.g., supporting only these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0048] A WLAN system that supports a plurality of channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operation mode. In an example of 802.11ah, the primary channel is 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., supports only) the 1 MHz mode even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the status of the primary channel. For example, due to an STA transmitting to the AP (supporting only the 1 MHz operation mode), when the primary channel is in operation, even if most of the frequency band remains in an operation pause and may be available, the entire available frequency band may be considered to be in operation.

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

[0050] FIG. 1D is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0051] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, gNB 180a may transmit and / or receive radio signals to and from WTRU 102a using, for example, multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of such component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0052] The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, and 102c can communicate with the gNBs 180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

[0053] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchor points. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, 160c, etc. For example, WTRUs 102a, 102b, and 102c can implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c can function 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.

[0054] 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 decision-making, handover decision-making, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, and routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in Figure 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0055] CN 115 shown in Figure 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the aforementioned elements is depicted as part of CN 115, it should be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0056] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can play roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of the registration area, termination of NAS signaling, and mobility management. Network slices can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of services being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF 162 can provide control plane functions for exchange between RAN 113 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

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

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

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

[0060] In view of FIGS. 1A-1D and the corresponding descriptions of FIGS. 1A-1D, one or more of the functions described herein with respect to one or more of WTRU102a-102d, base stations 114a-114b, eNodeBs 160a-160c, MME162, SGW164, PGW166, gNBs 180a-180c, AMF182a-182b, UPF184a-184b, SMF183a-183b, DN185a-185b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0061] An emulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation 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 emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device and / or use terrestrial wireless communication to conduct tests for testing purposes.

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

[0063] A system and method for handling connection rejection via a wireless transmit / receive unit (WTRU)-WTRU (U2U) relay associated with a backoff time is described herein instead of a source end WTRU. The relay WTRU can retry establishing a connection with a target WTRU on behalf of the source WTRU, for example, based on receiving a rejection (e.g., having a backoff value) from the target WTRU. The source WTRU can associate a rejection message with the target WTRU, and the relay WTRU may be available to reach other target WTRUs. The relay WTRU can send the rejection message to other source WTRUs for the same target WTRU (e.g., if the backoff duration is active and ongoing).

[0064] The relay WTRU can retry establishing a connection with the target WTRU on behalf of the source WTRU. For example, the relay WTRU can receive a first rejection message from the target WTRU. The first rejection message may be associated with a first direct communication request (DCR) transmission or a first link modification request (LMR) transmission. The first rejection message may indicate congestion. The first rejection message may indicate a rejection cause value. The first rejection message may indicate a backoff value. The first DCR or the first LMR may be associated with the source WTRU. The relay WTRU can determine the number of retransmissions associated with the source WTRU (e.g., the number of retransmissions associated with a request to establish a connection). The WTRU can send a second rejection message to the source WTRU. The second rejection message may be sent based on whether the number of retransmissions associated with the source WTRU is less than a threshold (e.g., the maximum number of allowed retransmissions). The second rejection message to the source WTRU can indicate whether the relay WTRU will attempt (e.g., try) one or more retransmission attempts on behalf of the source WTRU. The second rejection message may indicate the number of retransmission attempts.

[0065] For example, if the number of retransmission attempts associated with the source WTRU is less than a threshold, the relay WTRU performs one or more of the following. The relay WTRU can track a duration associated with a backoff value (e.g., indicated by a first rejection message). The relay WTRU can include in a second rejection message to the source WTRU an indication that the relay WTRU will attempt (e.g., attempt) to perform a retransmission attempt on behalf of the source WTRU. The relay WTRU can transmit a second DCR / LMR transmission to the target WTRU on behalf of the source WTRU (e.g., based on a determination that the backoff value has elapsed). For example, if the number of retransmission attempts is greater than or equal to the threshold, the relay WTRU can decide to abort direct link establishment. The second rejection message can indicate identification information associated with the target WTRU. The second rejection message can indicate that the maximum number of retries has been reached.

[0066] The relay WTRU can, for example, send a rejection message to the source WTRU without attempting to establish a connection with the target WTRU if the relay WTRU has already received a rejection for a different source WTRU than the target WTRU. The WTRU can receive a first message from the target WTRU. The first message can indicate a rejection associated with a first request to establish a first connection between a first source WTRU and the target WTRU. The first message can indicate a backoff value associated with the target WTRU. The relay WTRU can receive a second message from a second source WTRU. The second message can be associated with a second request to establish a second connection between the second source WTRU and the target WTRU using the relay WTRU. The relay WTRU can send a third message to the second source WTRU indicating that the target WTRU rejected a first request to establish a first connection between the first source WTRU and the target WTRU. The third message can indicate a cause value (e.g., indicating that the target WTRU previously rejected a request to establish a first connection between the first source WTRU and the target WTRU). The relay WTRU can, for example, send the third message without attempting to establish with the target WTRU (e.g., because the relay WTRU has already received a rejection for the first source WTRU and the target WTRU). The relay WTRU can determine that a duration associated with the backoff value has expired. The WTRU can send a fourth message to the target WTRU (e.g., based on the determination that the duration associated with the backoff value has expired). The fourth message can be associated with one or more of a first request to establish a first connection between the first source WTRU and the target WTRU or a second request to establish a second connection between the second source WTRU and the target WTRU. The fourth message can be sent, for example, based on a determination that the number of retransmissions associated with establishing a connection with the target WTRU is less than a threshold.The relay WTRU can determine the number of retransmissions. The relay WTRU can receive from the target WTRU a fifth message indicating that a second request to establish a second connection between the second source WTRU and the target WTRU has been rejected. The relay WTRU can determine that the number of retransmissions associated with connection establishment with the target WTRU is above a threshold (e.g., based on the fifth message). The relay WTRU can send a rejection message to the second source WTRU associated with a pending link establishment connection request (e.g., based on the determination that the number of retransmissions associated with connection establishment with the target WTRU is above a threshold).

[0067] The WTRU can send a connection establishment request to the target WTRU. The connection establishment request may be a DCR or an LMR. The WTRU can receive a backoff value associated with a connection establishment rejection associated with the target WTRU. The backoff value associated with the connection establishment rejection can be received in response to the sent connection establishment request. The WTRU can receive a first message indicating that the WTRU should retry establishing a connection with the target WTRU. The first message can indicate a value associated with the duration of a waiting period. The WTRU can track the duration associated with the backoff value. Tracking of the duration can be started based on the receipt of a third message from the target WTRU. Tracking of the duration can be started based on a determination that the duration of the waiting period has expired. The WTRU can decide to retry establishing a connection with the target WTRU. The decision to retry establishing a connection with the target WTRU can be based on receiving a third message from the target WTRU indicating that the connection establishment should be retried. The decision to retry establishing a connection with the target WTRU can be based on a determination that the duration associated with the backoff value has expired. In one example, the WTRU can be a relay WTRU. In the case of a relay WTRU, the connection establishment rejection can be associated with a first source WTRU. The relay WTRU can send a message to the source WTRU indicating that (e.g., based on receipt of a rejection message) the target WTRU was requested to wait. The relay WTRU can attempt to establish a connection between the source WTRU and the target WTRU.

[0068] A relay (e.g., a U2U relay) can retransmit, for example, when it receives a rejection message with a backoff time instead of the source-end WTRU (e.g., when received). The U2U relay can be provisioned with an RSC (e.g., it can receive configuration information indicating the RSC). The RSC can indicate support for "managed peer connection failure handling". The U2U relay can receive a direct communication request (DCR) or a link modification request (LMR) from the source WTRU and establish a connection via the relay. The request can specify whether the U2U relay can handle a congestion condition retransmission procedure, for example, instead of the source WTRU (e.g., by including "source-WTRU-managed failure" or "relay-managed failure"). The U2U relay can send the DCR or LMR to the target WTRU. The U2U relay can receive a DC rejection or link modification rejection message from the target WTRU, for example, along with a code (e.g., #5 or #13) and a backoff time. The U2U relay can send a message to the source WTRU, for example, indicating that it may be waiting for a backoff interval and may be performing some retransmissions instead of the source WTRU. For example, the U2U relay can send a DC rejection / LM rejection to the source-end WTRU. The DC rejection / LM rejection can include a code (e.g., a new code) indicating the cause "congestion situation at the target WTRU and the relay is retrying" and a retransmission value (e.g., a retransmission count and / or a retransmission time). The DC rejection / LM rejection can be of the message type "waiting for DCR" or "waiting for link modification". The U2U relay can send a DC rejection or a link modification rejection to the source WTRU, for example, along with a code indicating the cause "retransmission unsuccessful", if the PC5 link establishment between the U2U relay and the target WTRU can fail. The source WTRU can decide whether to wait to establish the connection. The source-end WTRU can receive a message indicating "congestion situation and retransmission at the target WTRU".The source-end WTRU can, for example, increase or stop the retransmission time of the DCR based on receiving a message (e.g., because the relay processes the re-trial). The source-end WTRU can, for example, cancel (e.g., decide to cancel) the link establishment procedure via the relay (alternatively) by sending a link release request or a PC5-S message (e.g., DCCancel / LMCancel). A relay that receives a message (e.g., a link release request or a PC5-S message) can set its re-trial value (e.g., re-trial counter) to 0 and ignore any response from the target-end WTRU related to the link establishment / link modification procedure.

[0069] Direct communication (e.g., ProSe direct communication) can be established.

[0070] Figures 2 and 3 show exemplary procedures for communication (e.g., 5G ProSe communication) via a WTRU-to-WTRU (U2U) relay (e.g., 5G WTRU-to-WTRU relay). In the example, the source-end WTRU can discover the target WTRU. The target WTRU can establish a connection with the U2U relay through a direct communication request (DCR) or a link modification request (LMR), or can modify a link (e.g., an existing link) with the U2U relay. The U2U relay can, for example, establish a connection with the target-end WTRU via a DCR or an LMR. The U2U relay can, for example, associate a plurality (e.g., two) of direct links (e.g., 5G ProSe direct links), one with the source WTRU and the other with the target WTRU, for example, if successful (e.g., during the communication process between the source-end WTRU and the target WTRU).

[0071] Figure 2 shows exemplary ProSe communication via a ProSe layer 3 WTRU-to-WTRU relay. Figure 3 shows exemplary ProSe communication via a ProSe layer 2 WTRU-to-WTRU relay.

[0072] The PC5 link between the source ProSe End WTRU and the ProSe WTRU - to - WTRU relay can be shared among multiple target ProSe End WTRUs (e.g., when one source ProSe End WTRU communicates with multiple target ProSe End WTRUs). The PC5 link can be established (e.g., individually) between the ProSe WTRU - to - WTRU relay and the target ProSe End WTRU. Layer 2 link modification procedures can be used, for example, for sharing the PC5 link.

[0073] A message (e.g., a direct link establishment execution rejection / direct link modification execution rejection message) can include an information element (e.g., a PC5 signaling protocol cause information element (IE)) set to a certain value (e.g., #13 congestion situation). This can occur when the DCR or LMR fails. The rejection message can include a cause value (e.g., #13 congestion situation) when the DCR or LMR is rejected (e.g., at that time), for example, through a direct link establishment execution rejection / direct link modification execution rejection message.

[0074] The target WTRU can provide a back - off value (e.g., a timer value) to the initiating WTRU in a message (e.g., a direct link establishment execution rejection message). The target WTRU may refrain from accepting any direct link establishment execution request for relaying when a back - off value for, for example, NAS - level mobility management congestion control (e.g., via a timer) is active (e.g., in execution).

[0075] The target WTRU can send a message (e.g., a direct link modification execution rejection message). The message can be sent via signaling. The message can indicate a cause value (e.g., using the PC5 signaling protocol cause value #5 "Lack of resources for 5G ProSe direct link"). The target WTRU can send a message (e.g., a direct link modification execution rejection message) if, for example, 5G ProSe direct link modification fails (e.g., due to a congestion problem or other temporary lower layer problems causing resource constraints).

[0076] ProSe direct link release can be executed and / or provided.

[0077] Either end WTRU of the communication can release the link. The request (e.g., direct link release request execution) can include an IE value indicating a cause, e.g., #13 congestion situation. The end WTRU can trigger WTRU - network relay reselection, for example, when the end WTRU of the communication releases the link. The end WTRU can trigger WTRU - to - network relay reselection, for example, when there is a request (e.g., direct link release request execution or direct link release request execution) with a cause IE value.

[0078] The source WTRU can establish a connection to the target WTRU via a U2U relay. The U2U relay can forward the rejection back to the source WTRU if, for example, the target WTRU rejects PC5 link establishment or modification. The source WTRU can choose to re - establish the connection or re - select the U2U relay and / or the target WTRU.

[0079] The target WTRU can indicate the reason for rejection (e.g., in a PC5 link establishment / modification rejection message (#13, #5)). When processing a rejection message (e.g., DCR / LMR) in an inter-WTRU relay or source WTRU (e.g., when processing), the value may be ignored (e.g., not considered). For example, if a rejection cause value (e.g., capable of providing a backoff time (e.g., #5, #13)) is received in an inter-WTRU relay or source WTRU, the inter-WTRU relay or source WTRU processing can refrain from being explained (e.g., not be explained).

[0080] The U2U relay can assist in processing the rejection message to improve overall performance, for example, if the rejection message and its payload (e.g., cause IE value) are available to the U2U relay.

[0081] In a scenario where the target WTRU shares a (e.g., single) PC5 link towards the U2U relay, communicating with one or more source WTRUs can be considered. For example, scenarios where one or more target WTRUs communicate with the same source WTRU via the same U2U relay (e.g., the PC5 link between the U2U relay and the source WTRU is shared) can be taken into account.

[0082] The processing of direct communication and link modification rejection messages can include one or more of the following scenarios, i.e., the U2U relay can attempt to re-establish the connection on behalf of the source WTRU, the U2U relay can notify the source WTRU about the rejection message and cause value received from the target WTRU (e.g., while being immediately available for processing any other message), the U2U relay can process incoming requests from multiple source WTRUs (e.g., all), etc.

[0083] The relay can retry on behalf of the source-end WTRU. The relay can retry, for example, on the basis of (e.g., when received) receiving a rejection with a backoff time (e.g., a timer) on behalf of the source-end WTRU.

[0084] Figure 4 shows an exemplary flow for a U2U relay to process a DC / LM rejection message and enable retrying on behalf of the source WTRU. As shown in Figure 4, the relay can retry on the basis of (e.g., when received) receiving a rejection with a backoff time (e.g., a timer) on behalf of the source-end WTRU. One or more of the following can describe the actions as shown in Figure 4, as well as other examples and optional procedures.

[0085] As shown at 400 in Figure 4, the U2U relay can be provisioned with a Relay Service Code (RSC). The RSC can indicate its support for "Managed Peer Connection Failure Handling".

[0086] As shown at 410 in Figure 4, service authorization and provisioning can be performed for the source-end WTRU (e.g., the source ProSe-end WTRU), the target-end WTRU (e.g., the ProSe-end WTRU), and / or the WTRU-to-WTRU relay (e.g., the ProSe WTRU-to-WTRU relay). The source ProSe-end WTRU can perform discovery of the ProSe WTRU-to-WTRU relay. The end WTRUs and the relay can be provisioned with an RSC having an indication of support for "Managed Peer Connection Failure Handling". For example, the U2U relay can provide this RSC to manage recovery of a connection failure with the target WTRU on behalf of the source WTRU (e.g., in the case of congestion at the target WTRU).

[0087] As shown at 420 in FIG. 4, the source WTRU can determine whether to use an existing PC5 link towards the U2U relay WTRU. For example, if the existing PC5 link can be selected, the LMR can be sent to the U2U relay. The DCR can be sent to the U2U relay (e.g., if not). The source WTRU can specify, for example, by including "source-WTRU managed failure" or "relay managed failure" and / or one or more of the following, whether the U2U relay can retry on behalf of the source WTRU, i.e., the number of (e.g., maximum) retries the U2U relay can perform, the (e.g., maximum) time it can wait, etc. These values can be negotiated, for example, between the source WTRU and the relay during PC5 link establishment / modification.

[0088] As shown at 430 in FIG. 4, the U2U relay can determine whether to use an existing PC5 link towards the target WTRU. The LMR can be sent to the target WTRU, for example, if the existing PC5 link is selected. The DCR can be sent to the target WTRU (e.g., if not).

[0089] As shown at 440 in FIG. 4, the target WTRU can respond to the U2U relay with a DC reject or link modification reject message having a cause code (e.g., #5 or #13). The target WTRU can respond with a backoff time (e.g., a timer). The target WTRU can respond with a DC reject or LMR message having a cause code, along with the backoff time to the U2U relay.

[0090] As shown at 450 in FIG. 4, the U2U relay can, for example, locally start tracking the backoff time (e.g., via a backoff timer) when the source WTRU indicates that the U2U relay can retry establishing a connection to the target WTRU in the initial DCR / LMR (e.g., at 420 in FIG. 4), or when the RSC is provisioned to support "managed peer connection failure handling". Different U2U relays can choose to do different things, for example, based on agreed-upon failure management.

[0091] As shown at 460 in FIG. 4, the U2U relay can, for example, send a message to the source-end WTRU indicating one or more of the following, a cause code received from the target WTRU indicating that the relay may be waiting and may have performed some retries (e.g., a specified number of retries), and that the rejection may be from the target WTRU. The message can include a DC accept, LM accept, DC reject, or LM reject message type (any of which) with a (e.g., new) code indicating the cause "congestion situation at the target WTRU and relay is retrying". The message can be of a different (e.g., new) message type, for example, "DC waiting", "link correction waiting", or DC Ack.

[0092] The source-end WTRU that receives a message with "congestion situation and relay is retrying" can increase the retry time (e.g., a timer) for the DCR / LMR or can stop tracking time (e.g., because the relay can handle the retry).

[0093] The source-end WTRU can (alternatively, for example) determine to cancel link establishment / modification (e.g., via a relay). For example, the source-end WTRU can cancel the link by sending a link release request (e.g., a ProSe link release request) or a (e.g., new) PC5-S message (e.g., DCCancel / LMCancel). In this case, the relay receiving this message can set the number of retransmission attempts to zero (0) (e.g., via a retransmission counter) and can ignore any response from the target-end WTRU related to this link establishment or modification procedure.

[0094] (For example, as shown in 460 of FIG. 4) This message can be used, for example, for the U2U relay to periodically notify the source WTRU that the U2U relay is still retrying.

[0095] As shown in 470 of FIG. 4, the U2U relay WTRU can retransmit a DCR / LMR message to the target WTRU at the end of a duration (e.g., timer expiration) if, for example, the number of retransmissions is less than the number of retries performed so far and the elapsed time is less than the maximum time the source WTRU is waiting (e.g., as specified by the source WTRU). As shown in FIG. 4, the actions at 440, 450, 460, and 470 can be repeated (e.g., several times). The action associated with 460 of FIG. 4 can be performed (e.g., only once) when a first rejection message is received at the relay (e.g., at that time). It can be understood that, based on the actions associated at 410 and 420 by the source WTRU and the relay, the relay may be processing retransmissions and the process at 460 may be optional.

[0096] As shown in 480 of FIG. 4, the target WTRU can respond, for example, with a rejection message (e.g., DC reject / LM reject).

[0097] As shown at 490 in FIG. 4, for example, when the (e.g., maximum) number of retries is reached, the relay may send a DC rejection or a link modification rejection, along with a (e.g., new) code that may indicate the cause "unsuccessful retry". This message can indicate that "the maximum retry attempt has been made".

[0098] For example, when link establishment is successful, the relay may send an acceptance message such as a DC acceptance or an LM acceptance (e.g., where the cause IE is set to "successful retry").

[0099] In the example, for example, the U2U relay can use a DCA message to notify the source WTRU of a pending connection establishment / modification with the target WTRU (e.g., with respect to 460 in FIG. 4). The U2U relay can send an LMR message to the source WTRU that can include an indication of successful completion of the connection with the target WTRU. The U2U relay can receive an LMA message from the source WTRU to confirm the source WTRU acceptance of the connection / communication with the target WTRU. The U2U relay can send a link release request message indicating, for example, unsuccessful completion of the connection with the target WTRU.

[0100] The source end WTRU can associate a rejection message with the target end WTRU. The relay may be available for reaching other target WTRUs.

[0101] Figure 5 shows an exemplary flow to enable a source WTRU to be notified of a target WTRU's rejection and the cause thereof. This message to be notified to the source WTRU can enable the source WTRU to understand that the rejection is originated from the target WTRU. The rejection may not be originated from the U2U relay. The same U2U relay can be (re)used to reach the same or different target WTRUs. As shown in Figure 5, the source-end WTRU can associate the rejection message with the target-end WTRU. The relay may be available for reaching other target WTRUs.

[0102] As shown at 510 in Figure 5, the source WTRU can send a request to establish a connection with target WTRU #1 via the U2U relay. Then, target WTRU #1 can reject the request.

[0103] As shown at 520 in Figure 5, the U2U relay WTRU can respond to the source WTRU with a DC / LM rejection message having a cause value. The (e.g., new) cause value can indicate that it was target end WTRU #1 that rejected the request. The specified message and cause value can refer to the target WTRU (e.g., may not refer to the U2U relay). It can indicate to the source WTRU that a retry cannot be processed by the U2U relay. This message can include the cause value that target WTRU #1 sent to the U2U relay along with its rejection message (e.g., security issue). The U2U relay can manage a time window for waiting for multiple response messages, for example, in a scenario where the U2U relay sends messages to multiple target WTRUs. The U2U relay can send an integrated rejection to the source WTRU, for example, at the end of the time window (e.g., after waiting until then).

[0104] As shown at 530 in FIG. 5, the source WTRU can start tracking a retry time (e.g., via a retry timer) based on, for example, a received backoff value. The source WTRU can associate the retry time (e.g., a timer) with the target end WTRU#1.

[0105] As shown at 540 in FIG. 5, the source end WTRU can (re)select the same (e.g., after a backoff timer) or another target end WTRU (e.g., target WTRU#2) to reach, for example, the same U2U relay. This can be possible, for example, if the source WTRU (e.g., currently) recognizes that a previous rejection came from the target WTRU (e.g., rather than the U2U relay), and thus the U2U relay may be available to process other requests.

[0106] The relay can directly send a rejection to a second source end WTRU, for example, when a backoff time is being tracked (e.g., when its backoff timer is running).

[0107] FIG. 6 shows an exemplary flow that can allow (e.g., enable) a U2U relay to process multiple requests to the same target WTRU (e.g., from two or more source WTRUs) when the target WTRU has previously rejected a request (e.g., when it has rejected). The scenario can include cases where the target WTRU shares a link (e.g., a single PC5 link) with the U2U relay when communicating with, for example, multiple source WTRUs.

[0108] As shown in FIG. 6, the relay can (e.g., directly) send a rejection to a second source end WTRU when the backoff time is active or being tracked (e.g., when its backoff timer is running).

[0109] As shown at 610 in FIG. 6, permissions and discoveries can be carried out (e.g., as described herein). As shown at 620 in FIG. 6, source WTRU#1 can send DCR / LMR to the U2U relay (e.g., as described herein). As shown at 630 in FIG. 6, the U2U relay can send DCR / LMR to the target WTRU (e.g., as described herein). As shown at 640 in FIG. 6, the target WTRU can respond with a rejection message (e.g., as described herein). As shown at 650 in FIG. 6, the U2U relay can start tracking a backoff time (e.g., via a backoff timer) as described herein.

[0110] As shown at 660 in FIG. 6, the U2U relay WTRU can send a message to source WTRU#1. The message can notify that the target WTRU rejected the DCR / LMR with a cause value and a backoff time (e.g., a timer). The relay or the source WTRU can handle a retry procedure with the target WTRU. The relay can continue to track the rejection and the backoff time from the target WTRU. The relay can continue to track the state of the target WTRU, e.g., "rejected" or "congested".

[0111] As shown at 670 in FIG. 6, the U2U relay can receive DCR / LMR from source WTRU#2 for communication with the same target end WTRU (e.g., which returned a rejection message with a backoff time to the relay at 640 in FIG. 6).

[0112] As shown at 680 in FIG. 6, the U2U relay WTRU can transmit a response message to source WTRU #2, for example, with a (e.g., new) cause value / message type to source WTRU #2 (e.g., if the back-off time has not expired). This message can indicate that the target end WTRU previously rejected a request (e.g., via a (e.g., new) cause code). In the example, this indication can include the cause of the rejection (e.g., congestion) indicated by the target WTRU. This message can indicate that this message can be an immediate response, that the U2U relay is not attempting to establish a connection, and that it can retry when the current back-off time expires. It can specify the remaining time of the current back-off time. In the example, this message can be optional.

[0113] The relay can use the back-off time associated with the target WTRU for each source WTRU requesting the source (e.g., as an alternative). In this case, the relay can respond to source WTRU #2, for example, without sending a request to the target WTRU, and can start tracking the source WTRU #2 back-off time (e.g., via a timer).

[0114] As shown at 490 in FIG. 7, the U2U relay can track (e.g., all) outstanding requests (e.g., associate them with the back-off time in progress), and for example, when the U2U relay processes a retry with the target WTRU, apply the back-off time in progress to the (e.g., all) received requests for the same target WTRU (e.g., the request of source WTRU #2).

[0115] As shown at 492 in FIG. 7, the backoff time can expire at the U2U relay. For example, when the U2U relay processes a retry with a target WTRU, the U2U relay can send (e.g., all) pending DCR / LMR requests from (e.g., each) corresponding source WTRU to the target end WTRU. The relay can process the backoff time for each source WTRU (e.g., alternatively) and can send the pending requests (e.g., only that request) from the source WTRU associated with the expired backoff time to the target WTRU. When the U2U relay is not processing a retry, the U2U relay can (e.g., alternatively) “normally” reset the state associated with the target WTRU (e.g., upon expiration of the backoff time).

[0116] As shown at 494 in FIG. 7, for example, after the U2U relay sends DCR / LMR (e.g., multiple DCR / LMRs associated with multiple pending source end WTRUs) to the target WTRU, the target WTRU can send a rejection message (e.g., a DC / LM rejection with a cause IE) to the U2U relay. The U2U relay can determine that the maximum number of retries has occurred.

[0117] As shown at 496 in FIG. 7, for example, when the U2U relay processes a retry with a target WTRU and the U2U relay receives a rejection message from the target end WTRU and reaches the maximum retry, the relay can send the rejection message back to the source end WTRU (e.g., both source end WTRUs as shown in FIG. 6). This message can indicate “retry unsuccessful”. This message can also indicate that “the maximum retry attempt has been made”. If the retry is successful, this message can indicate “retry successful”.

[0118] The target radio transceiver unit (e.g., WTRU) can enable a standby-retry response (e.g., transmit / receive).

[0119] The standby-retry response can be applied to the WTRU-to-WTRU communication scenario.

[0120] A U2U relay can be used (e.g., as described herein), which may be applicable to the direct WTRU-to-WTRU communication scenario where no relay is used. In such a scenario, the above-described U2U relay procedure can be applied to the target WTRU.

[0121] For example, the target WTRU can refrain from (e.g., not be able to) accepting (e.g., currently) a DCR / LMR. The target WTRU can delay / accept the request later (e.g., the target WTRU can predict that the cause of the rejection will be resolved in the next few seconds). There may be no way for the target WTRU to convey this to the relay or source WTRU other than, for example, completely rejecting (e.g., all together) the request.

[0122] The target WTRU can refrain from rejecting (e.g., not directly reject) the request. For example, the target WTRU can request the requesting WTRU (e.g., the relay or another WTRU) to wait. The message can include a (e.g., new) code that may refer to the cause "wait - retry later" (e.g., as specified for the U2U relay as described herein) and can indicate how long to wait.

[0123] The source WTRU can delay the start of the backoff time (e.g., based on reception (e.g., upon reception)) until, for example, it receives a follow-up / update message from the target WTRU or until the waiting period specified by the target WTRU has elapsed. Otherwise, the source WTRU can stop waiting and, for example, start the backoff time and retry with a different (e.g., new) configuration (if any) when the time expires (e.g., once), such as when the source WTRU receives a message with the cause IE "retry" (e.g., a DC / LM rejection).

[0124] The relay may receive a response to the DCR / LMR. The relay can delay the start of the backoff time (e.g., until it receives a follow-up / update message from the target WTRU or until the waiting period specified by the target WTRU has elapsed). The U2U relay can delay sending a DC / LM rejection message to the source WTRU, for example, when the relay receives a response to the DCR / LMR from the target WTRU that has "the requesting WTRU waits and will retry later" (e.g., at that time). The U2U relay can respond (e.g., immediately) to a (new) DCR / LMR message received from another WTRU indicating that "the target WTRU has requested to wait", for example, when multiple source WTRUs attempt to send DCR / LMR to the same target WTRU (when attempting). The U2U relay can receive a message (e.g., DC / LM rejection) with a cause IE "retry", for example, when the target WTRU may accept the request (e.g., be able to accept) but prefers the connection to be re-established. In this scenario, the U2U relay starts the backoff time and can retry with a different (e.g., new) configuration, for example, when the time has expired (e.g., once) (if any).

[0125] A relay (e.g., a U2U relay) can retry, for example, when it receives a rejection message with a backoff time instead of the source-end WTRU (e.g., when received). The U2U relay can be provisioned with an RSC (e.g., it can receive configuration information indicating the RSC). The RSC can indicate support for "managed peer connection failure handling". The U2U relay can receive a DCR or an LMR from the source WTRU and establish a connection via the relay. The request can specify whether the U2U can handle the congestion condition retry procedure, for example, instead of the source WTRU (e.g., by including "failure managed by the source WTRU" or "failure managed by the relay"). The U2U relay can send the DCR or the LMR to the target WTRU. The U2U relay can receive a DC rejection or a link modification rejection message from the target WTRU, for example, together with a code (e.g., #5 or #13) and a backoff time. The U2U relay can send a message to the source WTRU and, for example, indicate that it is waiting for the backoff interval and performing some retries instead of the source WTRU. For example, the U2U relay can send a DC rejection / LM rejection to the source-end WTRU. The DC rejection / LM rejection can include a code (e.g., a new code) indicating the cause "congestion situation at the target WTRU and the relay is retrying" and a retry value (e.g., a retry count and / or a retry time). The DC rejection / LM rejection can be of the message type "waiting for DCR" or "waiting for link modification". The U2U relay can send a DC rejection or a link modification rejection to the source WTRU, for example, together with a code indicating the cause "retry unsuccessful" if the PC5 link establishment between the U2U relay and the target WTRU fails. The source WTRU can decide whether to wait for the connection to be established. The source-end WTRU can receive a message indicating "congestion situation and retry at the target WTRU".The source-end WTRU can increase or stop the retransmission time of the DCR (e.g., based on receiving a message, e.g., because the relay processes a reattempt). The source-end WTRU can (alternatively, e.g.) cancel the link establishment procedure via the relay (e.g., decide to cancel) by sending, e.g., a link release request or a PC5-S message (e.g., DCCancel / LMCancel). A relay that receives a message (e.g., a link release request or a PC5-S message) can set its reattempt value (e.g., reattempt counter) to 0 and ignore any response from the target-end WTRU related to the link establishment / link modification procedure. In an example, the source-end WTRU can associate a rejection message with the target-end WTRU (e.g., the relay may be available for reaching other target WTRUs). The source WTRU can send a DCR / LMR to establish a connection with the target WTRU (e.g., via the relay). The source WTRU can receive a message from the U2U relay that can include a cause value indicating that the relay has performed some reattempts on behalf of the source WTRU (e.g., the cause value may not apply to the relay but may apply to the target-end WTRU. E.g., DCR-wait-reattempt, LMR-wait-reattempt, DC rejection, LM rejection, etc.). The source WTRU can associate the rejection condition with the target-end WTRU and refrain from associating the rejection condition with the U2U relay itself. The source WTRU can send a DCR / LMK to establish a connection with another target WTRU via, e.g., the relay that received the DC rejection / LM rejection (e.g., the same relay).

[0126] In an example, the relay can (e.g., directly) send a rejection to a second source end WTRU when, for example, a backoff time is being tracked (e.g., a backoff timer is operating) (e.g., at that time). The U2U relay can receive a DCR / LMR from a second source WTRU to communicate with, for example, the same target end WTRU (e.g., which may have returned a rejection with a backoff time to the relay). The U2U relay can handle a retry procedure with the second source WTRU. The U2U relay WTRU can track the backoff time. The backoff time may be associated with the target WTRU. While tracking the backoff time, the U2U relay WTRU can send (e.g., immediately) a rejection message (e.g., DCR-wait-retry, LMR-wait-retry, DC rejection, LM rejection, etc.) to the second source WTRU with a cause value indicating that the target end WTRU previously rejected a request without attempting to reach the target WTRU. The U2U relay can track outstanding requests from the source WTRU (e.g., associate it with the ongoing / tracked backoff time). The U2U relay can apply the tracked backoff time to requests to the same target end WTRU. The U2U relay can send (e.g., when the backoff time has expired and / or the retry count has exceeded 0) outstanding (e.g., all outstanding) DCR / LMR requests from the corresponding source WTRU to the target end WTRU. For example, if the U2U relay receives a rejection message from the target end WTRU and reaches the maximum retry, the relay can send back the rejection message to all source end WTRUs waiting for a link establishment / modification response.

[0127] In an example, the wait-retry response can be sent / received at the target (e.g., using or without using a relay). For example, the target WTRU can receive a DCR / LMR to establish a connection (e.g., via a relay or directly from the source WTRU). The target WTRU can send a DC / LM reject message having a cause indicating that the "requesting WTRU is waiting to retry later". Optionally, the message can be of a different (e.g., new) message type, such as, for example, "DCR waiting" or "link modification waiting". The message can indicate how long the source WTRU and / or the U2U relay can wait before retrying or triggering a response from the target WTRU and / or a WTRU reselection procedure. The U2U relay can receive a message indicating a cause indicating that the "requesting WTRU is waiting to retry later". The U2U relay can delay the start of tracking the backoff time until, for example, it receives a follow-up / update message from the target WTRU or until the waiting period specified by the target WTRU has elapsed. The U2U relay can delay the transmission of the DC / LM reject message to the source WTRU. The U2U relay can respond (e.g., immediately) to a DCR / LMR message received from another WTRU to indicate that "the target WTRU has requested to wait". The U2U relay can receive a message (e.g., DC / LM reject) having a cause IE "retry" if, for example, the target WTRU can accept the request but prefers that the connection be re-established (e.g., conditions associated with re-establishing the connection are determined). In this case, the U2U relay starts tracking the backoff time and can retry with a different configuration, for example, when the time expires. The U2U can, for example, when the time expires (e.g., then), send a pending DCR / LMR message from another source WTRU to the target WTRU. The source WTRU can receive a message from the target WTRU indicating a cause indicating that the "requesting WTRU is waiting to retry later".The source WTRU can delay the start of tracking the backoff time, for example, until it receives a follow-up / update message from the target WTRU or until the waiting period specified by the target WTRU has elapsed. Otherwise, the source WTRU starts tracking the backoff time and, when the time expires, for example, if the source WTRU receives a message (e.g., DC / LM rejection) with the cause IE "Retry", it can retry with a different configuration (if any).

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

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

[0130] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via a wired connection and / or a wireless connection) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disk (DVD), etc. A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, a radio network controller (RNC), and / or any host computer.

Claims

1. A relay wireless transmit / receive unit (WTRU), comprising: a processor, the processor comprising: receiving a first rejection message from the target WTRU, the first rejection message being associated with at least one of a first direct communication request (DCR) transmission associated with the source WTRU or a link modification request (LMR) transmission associated with the source WTRU; determining a number of retransmissions associated with the source WTRU; A relay wireless transmit / receive unit (WTRU) configured to: send a second rejection message to the source WTRU if the number of retransmissions associated with the source WTRU is less than a threshold, the second rejection message indicating whether the relay WTRU will make one or more retransmission attempts on behalf of the source WTRU.

2. The processor, determining that a number of retransmissions associated with the source WTRU is less than the threshold; determining that a time duration associated with the backoff value has elapsed; The relay WTRU of claim 1, further configured to: transmit at least one of a second DCR transmission associated with the source WTRU or a second LMR transmission associated with the source WTRU to the target WTRU based on the determination that the duration associated with the backoff value has elapsed.

3. The relay WTRU of claim 2 , wherein the rejection message to the source WTRU further indicates that the relay WTRU will make a retransmission attempt on behalf of the source WTRU.

4. The relay WTRU of claim 3 , wherein the rejection message to the source WTRU further indicates a number of retransmission attempts.

5. The processor, determining that a number of retransmissions associated with the source WTRU is greater than or equal to the threshold; The relay WTRU of claim 1 , further configured to: determine to abort a direct link establishment.

6. The relay WTRU of claim 5 , wherein the rejection message to the source WTRU further indicates an identity associated with the target WTRU.

7. The relay WTRU of claim 5 , wherein the rejection message to the source WTRU further indicates that a maximum number of retries has been reached.

8. The relay WTRU of claim 1 , wherein the first rejection message from the target WTRU indicates congestion.

9. The relay WTRU of claim 1 , wherein the first rejection message from the target WTRU indicates a rejection cause value and the backoff value.

10. The relay WTRU of claim 1 , wherein the threshold is a maximum number of retransmissions allowed.

11. 1. A method comprising: receiving a first rejection message from a target WTRU, the first rejection message being associated with at least one of a first direct communication request (DCR) transmission associated with a source WTRU or a link modification request (LMR) transmission associated with the source WTRU; determining a number of retransmissions associated with the source WTRU; if the number of retransmissions associated with the source WTRU is less than a threshold, sending a second rejection message to the source WTRU, the second rejection message indicating whether the relay WTRU will make one or more retransmission attempts on behalf of the source WTRU; A method comprising:

12. The processor, determining that a number of retransmissions associated with the source WTRU is less than the threshold; determining that a time duration associated with the backoff value has elapsed; 12. The method of claim 11, further configured to: transmit at least one of a second DCR transmission associated with the source WTRU or a second LMR transmission associated with the source WTRU to the target WTRU based on the determination that the time duration associated with the backoff value has elapsed.

13. The method of claim 12 , wherein the rejection message to the source WTRU further indicates that the relay WTRU will make a retransmission attempt on behalf of the source WTRU.

14. The method of claim 13 , wherein the rejection message to the source WTRU further indicates a number of retransmission attempts.

15. The method further comprising: determining that a number of retransmissions associated with the source WTRU is greater than or equal to the threshold; The method of claim 11 , further comprising: determining to abort the direct link establishment.

16. The method of claim 15 , wherein the rejection message to the source WTRU further indicates an identity associated with the target WTRU.

17. The method of claim 15, wherein the rejection message to the source WTRU further indicates that a maximum number of retries has been reached.

18. The method of claim 11 , wherein the first rejection message from the target WTRU indicates congestion.

19. The method of claim 11 , wherein the first rejection message from the target WTRU indicates a rejection cause value and the backoff value.

20. The method of claim 11 , wherein the threshold is a maximum number of retransmissions allowed.

Images