Method and apparatus for integrated discovery support with UE-to-UE relays

Abstract

Methods and apparatus for integrated discovery support with UE-to-UE relays. In an embodiment, a method implemented in a first wireless transmit / receive unit (WTRU) for performing integrated discovery when there is an existing sidelink connection between the first WTRU or a second WTRU and at least one WTRU-to-WTRU relay includes: transmitting a direct communication request message including a proximity-based service parameter to the second WTRU via the at least one WTRU-to-WTRU relay; receiving, from a second WTRU via one of the at least one WTRU-to-WTRU relay, a link modification request message including information related to a proximity-based service parameter; transmitting a link modification response to at least one WTRU to one of the WTRU relays; and receiving a direct communication accept message from the at least one WTRU to one of the WTRU relays.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 436,736, filed January 3, 2023, and U.S. Provisional Patent Application No. 63 / 444,460, filed February 9, 2023, each of which is incorporated herein by reference in its entirety. Technical Field

[0002] This disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, apparatuses, and systems for integrated discovery support with user equipment-to-user equipment (UE-to-UE) relay. Background Technology

[0003] For discovery integrated into PC5 unicast link establishment (so-called integrated discovery), the source user equipment (source UE) can send a Direct Communication Request (DCR) message in broadcast without selecting a UE-to-UE relay (UE-to-UE relay), allowing multiple UE-to-UE relays to send / forward DCRs to the target UE. After sending / forwarding the DCR message, each UE-to-UE relay can expect a response from the target UE using a Direct Communication Accept (DCA) message. Upon receiving the DCA message, a UE-to-UE relay can respond / forward the message to the source UE using a DCA message.

[0004] However, PC5 link sharing should be used. More specifically, when there is an existing PC5 connection between the end user equipment (UE) and the UE-to-UE trunk (e.g., already exists), the existing PC5 link should be reused (e.g., using a link modification procedure) rather than establishing a new PC5 link.

[0005] Furthermore, when the source UE establishes a service-oriented PC5 link (e.g., the target UE user information is not included in the DCR message), the UE-to-UE relay does not have information about potential target UEs with which the source UE can communicate.

[0006] From a protocol perspective, race conditions can occur between DCR / DCA messages and link modification procedures that need to be resolved. For example, a UE-to-UE relay can receive a DCR message from a source UE, which triggers the transmission of a DCR message to a target UE. The target UE responds by sending a DCA message or by initiating a link modification procedure. Similarly, a UE-to-UE relay can respond to the source UE by sending a DCA message or by initiating a link modification procedure.

[0007] Therefore, it is necessary to clarify how a UE-to-UE relay will be triggered to send a response including a DCA message to the source UE when using link modification with the target UE, and how the source UE will determine whether the DCR message has been responded to when the link modification process is performed between the UE-to-UE relay and the source UE.

[0008] Furthermore, for Layer 3 (L3) relays, the source UE can request end-to-end Quality of Service (QoS), and the QoS for each PC5 connection can be determined by the UE-to-UE relay. For integration discovery, it should be clarified how to configure PC5 QoS.

[0009] When using integrated discovery, a PC5 link establishment process needs to be defined between two terminal UEs via UE-to-UE relay. Summary of the Invention

[0010] In an embodiment, a method implemented in a first wireless transmit / receive unit (WTRU) for performing integration discovery when an existing sidelink connection exists between the first WTRU or a second WTRU and at least one WTRU-WTRU relay may include the step of transmitting a Direct Communication Request (DCR) message including proximity-based service (ProSe) parameters to the second WTRU via at least one WTRU-WTRU relay. The method may further include the step of receiving a Link Modification Request message including information related to the ProSe service parameters from the second WTRU via one of the at least one WTRU-WTRU relay. The method may further include the step of transmitting a Link Modification Response message to one of the at least one WTRU-WTRU relay; and the step of receiving a Direct Communication Acceptance (DCA) message from one of the at least one WTRU-WTRU relay.

[0011] In another embodiment, a method implemented in a WTRU-WTRU relay may include the step of receiving a DCR message from a first WTRU, the DCR message including information containing Quality of Service (QoS) and service-related information based on proximity. The method may further include the step of determining a first QoS parameter value for the link between the first WTRU and the WTRU-WTRU relay. The method may further include the step of transmitting a DCR message to a second WTRU. The method may further include the step of receiving a second QoS parameter value from the second WTRU for the link between the second WTRU and the WTRU-WTRU relay; and the step of determining, based on the first and second QoS parameter values, whether direct communication between the first and second WTRUs is permitted.

[0012] In another embodiment, a method for performing integration discovery implemented in a Wireless Transmit / Receive Unit (WTRU) may include the step of receiving a direct communication request message, comprising a first communication request from a first source WTRU, from each WTRU-WTRU relay in a first group of WTRU-WTRU relays. The method may include the step of receiving a link modification request message, comprising a second communication request from the first source WTRU, from each WTRU-WTRU relay in a second group of WTRU-WTRU relays. The method may include the step of selecting a WTRU-WTRU relay in the first and second groups of WTRU-WTRU relays for communication with the first source WTRU; and the step of transmitting a link modification rejection message to all WTRU-WTRU relays in the second group of WTRU-WTRU relays that were not selected for communication with the source WTRU.

[0013] Given that the selected WTRU-WTRU relay originates from a first group of WTRU-WTRU relays and an existing sidelink connection has been established between the WTRU and the selected WTRU-WTRU relay, the method may include the step of transmitting a direct communication rejection message to the selected WTRU-WTRU relay. The method may include the following steps: including performing a link modification process using the selected WTRU-WTRU relay to modify the existing sidelink connection. The step of selecting a WTRU-WTRU relay may include: selecting a third group of WTRU-WTRU relays from the first and second groups of WTRU-WTRU relays, the third group of WTRU-WTRU relays transmitting a direct communication request message or a link modification request message originating from the same source WTRU serving the same ProSe service as the WTRU; and selecting a WTRU-WTRU relay from the third group of WTRU-WTRU relays based on any one of signal strength, local policy, and carrier policy for each relay service code. Given that the selected WTRU-WTRU relay originates from a first group of WTRU-WTRU relays, the method may include the following steps: transmitting a direct communication accept message to the selected WTRU-WTRU relay, and transmitting additional link modification reject messages to all WTRU-WTRU relays in the second group of WTRU-WTRU relays. The direct communication accept message and link modification reject message may include information indicating any one of proximity-based service, information about the source WTRU, and information about the WTRU. The direct communication accept message may be transmitted via unicast. The link modification reject message may be transmitted via unicast. The additional link modification reject message and link modification reject message may be transmitted via unicast.

[0014] In an embodiment, a wireless transmit / receive unit (WTRU) including a processor, a transceiver unit, and a storage unit can be configured to receive a DCR message including a first communication request from a first source WTRU from each WTRU-WTRU relay in a first group of WTRU-WTRU relays. The WTRU can be configured to receive a link modification request message including a second communication request from the first source WTRU from each WTRU-WTRU relay in a second group of WTRU-WTRU relays. The WTRU can be configured to select a WTRU-WTRU relay in the first and second groups of WTRU-WTRU relays for communication with the first source WTRU; and to transmit a link modification rejection message to a WTRU-WTRU relay in the second group that was not selected for communication with the source WTRU. Attached Figure Description

[0015] A more detailed understanding can be obtained from the detailed description given below by way of example, taken in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are illustrative. Therefore, the figures and detailed description should not be considered limiting, and other equally valid examples are possible and feasible. Furthermore, similar reference numerals (“ref.”) in the figures indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system; Figure 1B It's shown in the diagram. Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system. Figure 1C It's shown in the diagram. Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system. Figure 1D It's shown in the diagram. Figure 1A The system diagram shown in the figure illustrates a further example RAN and a further example CN used within the communication system. Figure 2 This is an example of a message sequence graph for proximity-based service (ProSe) discovery integrated into the sidelink establishment process; Figure 3 This is an example of a message sequence diagram for integrated discovery of a link modification process between a Wireless Transmit / Receive Unit (WTRU) and a WTRU-to-WTRU relay; Figure 4 This is an example of a message sequence diagram of an integrated discovery process between a WTRU and a WTRU-to-WTRU relay with a link modification rejection / acceptance procedure; Figure 5 Here is an example of a message sequence diagram of an integrated discovery process between WTRUs with direct communication rejection, including WTRU-to-WTRU relays and WTRUs; and Figure 6 This is a flowchart illustrating an example of a method for performing integration discovery implemented in WTRU according to one embodiment. Detailed Implementation

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

[0017] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Regarding Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network can utilize, perform, arrange, and / or adapt to and / or configure the methods, apparatuses, and systems provided herein.

[0018] Figure 1AThis is a system diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Extended OFDM (ZT UW DTS-sOFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0019] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include (or) user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

[0023] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

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

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

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

[0028] Figure 1A Base station 114b can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In embodiments, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of small cells, pico cells, or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0029] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but to be understood, RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs employing the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) employing any of GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

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

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

[0032] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1BAs shown, among other things, WTRU 102 may also include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other components / peripherals 138. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing components.

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

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

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

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

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

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

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

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

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

[0042] Figure 1CThe diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

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

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

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

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

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

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

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

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

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

[0052] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneling DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode in this document.

[0053] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

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

[0055] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing are performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC) layer, entities, etc.

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

[0057] WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can 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 limited by STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and is likely available.

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

[0059] Figure 1D The diagram illustrates a system diagram of RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0060] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement cooperative multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0061] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0062] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / be connected to gNBs 180a, 180b, and 180c, and also communicate with / be connected to another RAN (such as eNode-B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

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

[0064] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0065] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c, for example, based on the type of service utilized by WTRU 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, services for MTC access, and / or the like. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as Wi-Fi.

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

[0067] UPFs 184a and 184b can be connected via an N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. The N3 interface can provide WTRUs 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication, for example, between WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0068] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or may communicate with such an IP gateway. Additionally, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

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

[0070] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices (e.g., network nodes) can be directly coupled to another device for testing and / or can be used to perform tests via over-the-air wireless communication.

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

[0072] Proximity-based services (ProSe) include services that can be provided by 5G systems based on neighboring WTRUs. 5G ProSe can have functions such as 5G ProSe direct discovery, 5G ProSe direct communication, 5G ProSe WTRU to network relay, and 5G ProSe WTRU to WTRU relay.

[0073] In 5G ProSe, after a unicast link is established between two WTRUs, several unicast link management procedures can be defined.

[0074] The first unicast link management procedure can be the release of a Layer 2 link at the PC5 reference point. Therefore, the WTRU can release a Layer 2 link by exchanging a disconnect request message and a disconnect response message. When releasing a Layer 2 link, the WTRU can delete all context data associated with the Layer 2 link, and the ProSe layer of each WTRU can use the PC5 link identifier to notify the Access Layer (AS) layer that the unicast link has been released, indicating the released unicast link.

[0075] The second unicast link management process can be a Layer 2 link modification for a unicast link. If the WTRU needs to add (one or more) new PC5 QoS flows, modify (one or more) existing QoS flows, or delete (one or more) existing QoS flows in an existing PC5 unicast link, the WTRU can exchange a link modification request message and a link modification response message with the requested action and associated QoS information, as well as optional PC5 QoS rules. The QoS information may include information about (one or more) PC5 QoS flows, and for each PC5 QoS flow, this includes a PC5 QoS flow identifier (PFI), the corresponding PC5 QoS parameters (e.g., a PC5 5G NR standardized QoS identifier (PQI) and other conditional parameters such as maximum flow bit rate / guaranteed flow bit rate), and optional (one or more) associated ProSe identifiers. The ProSe layer of each WTRU can provide information about the unicast link modification to the AS layer. This allows the AS layer to update the context associated with the modified unicast link.

[0076] The third unicast link management procedure can be Layer 2 link maintenance at the PC5 reference point. The WTRU can exchange keepalive messages and keepalive Ack messages to detect whether a specific PC5 unicast link is still active. The keepalive procedure can be initiated based on triggers, such as those from the AS layer or internal timers. The WTRU can minimize keepalive signaling, for example, canceling the procedure if data is successfully received on the PC5 unicast link. The WTRU that initiated the keepalive procedure can determine subsequent actions based on the signaling outcome, such as continuing implicit Layer 2 link release.

[0077] 5G ProSe can define several features, such as 5G ProSe direct discovery, 5G ProSe direct communication, 5G ProSe WTRU to network relay, and 5G ProSe WTRU to WTRU relay. 5G ProSe WTRU to WTRU relay enables indirect communication between two 5G ProSe terminal UEs (e.g., terminal WTRUs). For 5G ProSe WTRU to WTRU relay, 5G ProSe WTRU to WTRU relay discovery and 5G ProSe communication via WTRU to WTRU relay can be defined.

[0078] For 5G ProSe WTRU-to-WTRU relay discovery, both Model A and Model B discovery are supported. Model A can use a single discovery protocol message (announcement). Model B can use two discovery protocol messages (request and response).

[0079] It can also support discovery during the PC5 unicast link establishment process.

[0080] 5G ProSe communication via WTRU-WTRU relays is possible using 5G ProSe Layer 2 WTRU-WTRU relays or 5G ProSe Layer 3 WTRU-WTRU relays. For both Layer 2 and Layer 3 WTRU-WTRU relays, 5G ProSe communication establishment with a discovery process can be defined. Discovery can be defined and integrated into the PC5 unicast link establishment process.

[0081] Using a Layer 2 WTRU-to-WTRU relay, an end-to-end PC5 link can be established between terminal UEs (e.g., terminal WTRUs) via the WTRU-to-WTRU relay. PC5 signaling messages can then be exchanged between terminal UEs (e.g., terminal WTRUs).

[0082] Using a Layer 3 WTRU-to-WTRU relay, each terminal UE (e.g., terminal WTRU) can establish a PC5 link with the WTRU-to-WTRU relay, and the WTRU-to-WTRU relay can forward messages to the terminal UE (e.g., terminal WTRU). PC5 signaling messages can be exchanged between the terminal UE and the WTRU-to-WTRU relay.

[0083] Discovery integrated into PC5 unicast link establishment (so-called integrated discovery) can combine the discovery process into unicast connection establishment via WTRU-WTRU relay by omitting the process used for 5G ProSe WTRU-WTRU relay discovery. One advantage of this process is that remote WTRUs and WTRU relays may not need to perform separate 5G ProSe WTRU-WTRU relay discovery.

[0084] For discovery integrated into PC5 link establishment, when a WTRU allows a WTRU to relay another WTRU in a Direct Communication Request (DCR) message to another WTRU, the WTRU can indicate this by including relay_indication in the broadcast DCR message. Direct communication can be interchangeably referred to as relay communication.

[0085] When a WTRU-to-WTRU relay receives a DCR message that includes relay_indication, the WTRU-to-WTRU relay can participate in the process and broadcast a DCR message without relay_indication in its vicinity.

[0086] Figure 2 This is an example of a message sequence diagram for 5G ProSe discovery integrated into the establishment process of a side link (e.g., a PC5 unicast link).

[0087] In a direct communication request from the source WTRU (UE-1), without user information for the target WTRU (UE-2), only the requested ProSe service information may be included; this is known as service-oriented PC5 link establishment. In this case, when there is a target WTRU (UE-2) interested in the ProSe service requested by the source WTRU (UE-1), the target WTRU (UE-2) may respond to the direct communication request directly to the source WTRU (UE-1) or via the WTRU to the WTRU relay (relay-1 or relay-2).

[0088] If a direct communication request from the source WTRU (UE-1) includes user information of the target WTRU (UE-2) (which is referred to as the user-oriented PC5 link establishment), then only the requested target WTRU (UE-2) can respond to the direct communication request directly to the source WTRU (UE-1) or via the WTRU to the WTRU relay (relay-1 or relay-2).

[0089] At step 1, multiple WTRU-WTRU relays (Relay-1 and Relay-2) can receive DCR messages from the source WTRU (UE-1). The DCR message broadcast by the source WTRU (UE-1) may include a relay_indication enable command.

[0090] In steps 2 and 3, when the target WTRU (UE-2) receives a DCR message from one or more WTRU-to-WTRU relays (relay-1 and relay-2), the target WTRU (UE-2) can select the WTRU-to-WTRU relay to respond.

[0091] At step 5, the target WTRU (UE-2) can transmit a DCA message to the selected WTRU-to-WTRU relay (relay-1).

[0092] At step 8, the selected WTRU-WTRU relay (relay-1) can transmit DCA messages to the source WTRU (UE-1).

[0093] At step 4, a security establishment process can occur between the target WTRU (UE-2) and the selected WTRU-WTRU relay (relay-1). At step 7, a security establishment process can occur between the source WTRU (UE-1) and the selected WTRU-WTRU relay (relay-1).

[0094] At step 6, an IP address assignment process can occur between the target WTRU (UE-2) and the selected WTRU-to-WTRU relay (relay-1). At step 9, an IP address assignment process can occur between the source WTRU (UE-1) and the selected WTRU-to-WTRU relay (relay-1).

[0095] Furthermore, in cases where a source WTRU communicates with multiple target WTRUs, the side link (e.g., a PC5 link) between the source WTRU and the WTRU-to-WTRU relay can be shared for each relay service code (RSC) among the multiple target WTRUs, while the side link (e.g., a PC5 link) can be established separately for each RSC between the WTRU-to-WTRU relay and the target WTRU. For shared side links (e.g., PC5 links), a Layer 2 link modification procedure can be used. The same principle for shared side links (e.g., PC5 links) can be applied to target WTRUs communicating with multiple source WTRUs.

[0096] The following description illustrates an example of the process for establishing a side link (e.g., a PC5 link) between two WTRUs (e.g., two terminal UEs) via a WTRU-to-WTRU relay when using integrated discovery. More specifically, the sharing of a side link (e.g., a PC5 link) between a WTRU (e.g., a terminal UE) and a WTRU-to-WTRU relay via a side link (e.g., a PC5 link) modification process is described in detail.

[0097] In an embodiment, the method for performing integration discovery when there is an existing side link (e.g., PC5) connection between the source WTRU and the WTRU-WTRU relay and / or between the WTRU-WTRU and the target WTRU can be characterized by the following functions: signaling transactions that resolve conflicts between direct communication request / accept messages and link modification request / response messages, and end-to-end QoS negotiation that resolves conflicts between direct communication request / accept messages and link modification request / response messages.

[0098] DCR and DCA messages can be used to establish new sidelink (e.g., PC5) connections, and link modification request and response messages can be used to modify existing sidelink (e.g., PC5) connections for sidelink (e.g., PC5) sharing purposes. DCR messages can be sent via broadcast. DCA messages can be transmitted via unicast. Link modification request and response messages can be transmitted via unicast.

[0099] If a source WTRU sends a DCR message to a target WTRU, the source WTRU can expect to receive a DCA from the target WTRU or the WTRU-to-WTRU relay. If a source WTRU sends a Link Modification Request message to a target WTRU, the source WTRU can expect a Link Modification response from the target WTRU. If the response to a DCR message or Link Modification Request message is not received until a timer expires, the source WTRU can retransmit the DCR message or Link Modification Request message to the target WTRU. However, when there is an existing link between the source WTRU and the WTRU-to-WTRU relay that can be shared for communication with other target WTRUs, due to link sharing, the source WTRU or WTRU-to-WTRU relay sending the DCR message may not receive a DCA message in response, but instead receive a Link Modification Request message.

[0100] In an embodiment, if the source WTRU broadcasts a DCR message to the target WTRU, the source WTRU may assume that the request message is responded to when it receives a DCA message from the target WTRU or a link modification request message with suitable parameters (e.g., the same ProSe and associated QoS parameters requested in the direct communication request message and / or the target user information and source user information of the target WTRU).

[0101] Additionally, in this embodiment, a message including a transaction number can be used to check whether a message has been responded to. For example, when a DCR message with a transaction number value is transmitted, if a DCA message with the same transaction number value is received, it can be considered that the message has been received. Similarly, if the source WTRU receives a link modification request message with a transaction number value identical to the one in the DCR message, the source WTRU can consider that the DCR message has been responded to.

[0102] Alternatively, in an embodiment, after the source WTRU broadcasts a DCR message to the target WTRU, if the source WTRU receives a link modification request message from the target WTRU (as a response to the DCR message), the source WTRU may consider the DCR to be obsolete and discard any processes associated with the direct communication request message.

[0103] For end-to-end QoS management, if a source WTRU requests a connection to a target WTRU via a WTRU-to-WTRU relay, this may include information about the requested ProSe and the end-to-end QoS requirements of the ProSe. Based on the requested end-to-end QoS requirements, the WTRU-to-WTRU relay can set (e.g., per-hop) QoS requirements for the side link (e.g., PC5 link) between the source WTRU and the WTRU-to-WTRU relay, and for the side link (e.g., PC5 link) between the WTRU-to-WTRU relay and the target WTRU.

[0104] In the event that the source WTRU requests an end-to-end QoS requirement, the WTRU-WTRU relay can respond to the source WTRU with a QoS requirement for the link between the source WTRU and the WTRU-WTRU relay, after negotiating a QoS requirement for the target WTRU and another link between the WTRU and the WTRU-WTRU relay (e.g., per hop).

[0105] If a WTRU-WTRU relay sends at least (e.g., per hop) a QoS parameter for the link between the target WTRU and the WTRU-WTRU relay for an end-to-end connection between the source WTRU and the target WTRU, the WTRU-WTRU relay may consider the end-to-end connection accepted if the target WTRU responds with the same value for at least one QoS parameter for the link between the target WTRU and the WTRU-WTRU relay (e.g., per hop).

[0106] When a WTRU-to-WTRU relay transmits QoS parameters (e.g., per hop) for the link between the target WTRU and the WTRU-to-WTRU relay for an end-to-end connection between the source WTRU and the target WTRU, the WTRU-to-WTRU relay can check whether the target WTRU responds with a QoS parameter value that differs from the QoS parameter value transmitted by the WTRU-to-WTRU relay for the link between the target WTRU and the WTRU-to-WTRU relay (e.g., per hop). If it is unacceptable, the WTRU-to-WTRU relay can consider the end-to-end connection rejected.

[0107] If the QoS parameters for the link between the target WTRU and the WTRU-WTRU relay are agreed upon based on the stated values ​​and end-to-end QoS requirements, the WTRU-WTRU relay can calculate the QoS parameters for the link between the source WTRU and the WTRU-WTRU relay.

[0108] Figure 3This is an example of a message sequence diagram for integrated discovery with link modification procedures between WTRU-WTRU relays and WTRUs (e.g., terminal UEs). At step 0, WTRUs (UE-1 and UE-2) can be authorized and configured with parameters to use the services provided by the WTRU-to-WTRU relays (Relay-1 and Relay-2). Furthermore, the WTRU-to-WTRU relays (Relay-1 and Relay-2) can be authorized and configured with parameters to provide services for relaying traffic between WTRUs (UE-1 and UE-2).

[0109] At step 1, the source WTRU (UE-1) may broadcast a DCR message to initiate unicast communication with the target WTRU (UE-2). The DCR message may include relay_indication, source WTRU (UE-1) user information, target WTRU (UE-2) user information, application ID, and WTRU-to-WTRU relay service code (if any). The source WTRU (UE-1) may include the requested ProSe service and QoS information related to the ProSe service.

[0110] When a source WTRU (UE-1) requests to establish a connection with any target WTRU that supports the requested ProSe service, the source WTRU (UE-1) may send a DCR message without indicating any target WTRU user information.

[0111] The source WTRU (UE-1) may include the value of the message transaction number of the DCR message.

[0112] At step 2, the WTRU-WTRU relays (Relay-1 and Relay-2) can receive a DCR message including relay_indication from the source WTRU (UE-1). The WTRU-WTRU relays (Relay-1 and Relay-2) can decide to participate in the process and (e.g., in their vicinity) broadcast another DCR message without relay_indication.

[0113] Each DCR message from each of the WTRU-WTRU relays may include source WTRU user information (UE-1 user information), target WTRU user information (UE-2 user information), and WTRU-WTRU relay information. A DCR message from either of the WTRU-WTRU relays (Relay-1 or Relay-2) may include the requested ProSe service as received in step 1, and derived QoS information relating to the ProSe service for the link between the WTRU-WTRU relay and the target WTRU (UE-2).

[0114] When the DCR received from the source WTRU (UE-1) by the WTRU-to-WTRU relay (Relay-1 and Relay-2) does not include the target WTRU (UE-2) user information, the DCR from each WTRU-to-WTRU relay (Relay-1 and Relay-2) does not include the target WTRU (UE-2) user information.

[0115] WTRU to WTRU relays (relay-1 and relay-2) may include the value of another message transaction number for their DCR messages.

[0116] In step 3, if the target WTRU (UE-2) receives a DCR from one or more WTRU-to-WTRU relays (Relay-1 and Relay-2), the target WTRU (UE-2) can select the WTRU-to-WTRU relay that the target WTRU (UE-2) will respond to. The target WTRU (UE-2) can select the WTRU-to-WTRU relay based on the signal strength from the WTRU-to-WTRU relay, local policies, and operator policies (if any) for each relay service code.

[0117] If the DRC received by the target WTRU (UE-2) does not include the target WTRU (UE-2) user information, the target WTRU (UE-2) may decide to respond to the requested DRC if it supports the requested ProSe service.

[0118] If the target WTRU (UE-2) is connected to an existing side link (e.g., PC5) between the selected WTRU-WTRU relay, steps 4 and 5 can be performed, and steps 6 to 8 can be omitted.

[0119] If the target WTRU (UE-2) needs to establish a new side link (e.g., PC5) with the selected WTRU-to-WTRU relay, steps 4 and 5 can be omitted, and steps 6 to 8 can be performed.

[0120] At step 4, the target WTRU (UE-2) can respond to the DCR message from the selected WTRU-WTRU relay (Relay-1) by transmitting a Link Modification Request message to the WTRU-WTRU relay (Relay-1). The Link Modification Request message may include source WTRU (UE-1) user information, target WTRU (UE-2) user information, and WTRU-WTRU relay (Relay-1) information. The Link Modification Request message may include the requested ProSe service and QoS information related to the ProSe service of the link between the selected WTRU-WTRU relay (Relay-1) and the target UE as received in step 2.

[0121] The link modification request message may include the same message transaction number value as the message transaction number received in step 2 from the selected WTRU to the WTRU relay (relay-1).

[0122] Alternatively, the target WTRU (UE-2) may include the requested ProSe service received in step 2, as well as QoS information relating to the ProSe service for the link between the WTRU-WTRU relay (relay-1) and the target WTRU, which is modified based on the target WTRU's judgment of the value received in step 2.

[0123] At step 5, if the WTRU-to-WTRU relay (Relay-1) receives a link modification request message (such as included in the DCR message transmitted in step 2) containing user information of the source WTRU (UE-1) and the target WTRU (UE-2), the WTRU-to-WTRU relay (Relay-1) may consider that the DCR message has been responded to. Alternatively, if the link modification request message includes a message transaction number that is the same as the message transaction number in the DCR transmitted in step 2, the WTRU-to-WTRU relay (Relay-1) may consider that the DCR message transmitted in step 2 was responded to by a link modification request from the target WTRU (UE-2).

[0124] At step 6, if necessary, a security establishment occurs between the target WTRU (UE-2) and the selected (e.g., 5G ProSe) WTRU to WTRU relay (relay-1).

[0125] At step 7, the target WTRU (UE-2) may reply with a DCA message to the WTRU-to-WTRU relay (Relay-1). The DCA message may include source WTRU (UE-1) user information, target WTRU (UE-2) user information, and WTRU-to-WTRU relay (Relay-1) information. The DCA message may include the requested ProSe service and QoS information related to the ProSe service for the link between the relay and the target UE, as received in step 2.

[0126] The DCA message may include the same message transaction number value as the message transaction number received from the selected relay in step 2.

[0127] At step 8, for IP traffic, an IPv6 prefix or IPv4 address is assigned to the target (e.g., 5G ProSe Layer 3) WTRU (UE-2).

[0128] If the DCR message transmitted in step 2 is successfully responded to in steps 4 to 5 or steps 6 to 8, the WTRU to WTRU relay (relay-1) can respond to the DCR message transmitted from the source WTRU (UE-2) in step 1.

[0129] If there is an existing side link (e.g., PC5) connection between the source WTRU (UE-1) and the WTRU-to-WTRU relay (relay-1), perform steps 9 and 10, and omit steps 11 to 13.

[0130] In the case of establishing a new side link (e.g., PC5) connection between the WTRU-to-WTRU relay (relay-1) and the source WTRU (UE-1), steps 9 and 10 are omitted, and steps 11 to 13 can be performed.

[0131] At step 9, the WTRU-to-WTRU relay (Relay-1) can respond to the DCR message from the source WTRU (UE-1) by transmitting a Link Modification Request message to the source WTRU (UE-1). The Link Modification Request can be transmitted over an existing side link (e.g., PC5) connection between the source WTRU (UE-1) and the WTRU-to-WTRU relay (Relay-1).

[0132] When a link modification request message is used in response to a DCR message from a source WTRU (UE-1), the link modification request message may include user information of the source WTRU (UE-1), user information of the target WTRU (UE-2), and user information of the WTRU-WTRU relay (relay-1).

[0133] The link modification request message may include the requested ProSe service and QoS information related to the ProSe service for the link between the WTRU-WTRU relay (relay-1) and the source WTRU (UE-1), which is derived from the end-to-end QoS information received in step 1.

[0134] The link modification request message may include the same message transaction number as the message transaction number received from the source WTRU (UE-1) in step 1.

[0135] At step 10, if the source WTRU (UE-1) receives a link modification request, and if it includes the user information of the source WTRU (UE-1) and the user information of the target WTRU (UE-2) as included in the DCR message transmitted in step 1, or if the link modification request message includes the same message transaction number as the value of the message transaction number in the DCR transmitted in step 1, then the source WTRU (UE-1) can consider the DCR message to be responded to with a link modification request message, and the source WTRU (UE-1) can respond with a link modification response message.

[0136] At step 11, if necessary, a security establishment can occur between the source WTRU (UE-1) and the WTRU-to-WTRU relay (relay-1).

[0137] At step 12, the WTRU to WTRU relay (relay-1) can respond to the source WTRU (UE-1) by transmitting a DCA message to the source WTRU (UE-1).

[0138] The DCA message may include user information for the source WTRU (UE-1), user information for the target WTRU (UE-2), and user information for the WTRU-to-WTRU relay (relay-1). The DCA message may include the requested ProSe service and QoS information related to the ProSe service for the link between the WTRU-to-WTRU relay (relay-1) and the source WTRU (UE-1), which may be derived based on the end-to-end QoS information received in step 1.

[0139] The DCA message may include the same message transaction number value as the message transaction number received from the source WTRU (UE-1) in step 1.

[0140] At step 13, for IP traffic, an IPv6 prefix or IPv4 address can be assigned to the source (e.g., 5G ProSe Layer 3) WTRU (UE-1).

[0141] In another embodiment, the method for performing integration discovery when there is an existing side link (e.g., PC5) connection between the source WTRU and the WTRU-to-WTRU relay and / or between the WTRU-to-WTRU and the target WTRU can be characterized by the following functionality: (1) After receiving a DCR message from the source WTRU, the WTRU-to-WTRU relay UE can verify whether a side link (e.g., PC5) connection with the target WTRU already exists based on the target WTRU information. If there is no existing side link (e.g., PC5) connection between the WTRU-to-WTRU relay and the target WTRU, the WTRU-to-WTRU relay can send a DCR message including the requested ProSe service and the target WTRU information. If the WTRU-to-WTRU relay finds an available side link (e.g., PC5) connection with the target WTRU, the WTRU-to-WTRU relay may send a link modification request to provide a connection between the source WTRU and the target WTRU for the ProSe service as requested in the DCR message from the source WTRU, wherein the WTRU-to-WTRU relay and the target WTRU have a shared side link (e.g., PC5 link); (2) the target WTRU may compare the DCR message received from the WTRU-to-WTRU relay with the link modification request message to select the WTRU-to-WTRU relay for the connection with the source WTRU for the requested ProSe service. (3) If the WTRU-to-WTRU relay that sent the link modification request message to the target WTRU is not selected for the connection between the target WTRU and the source WTRU, the target WTRU may send a link modification rejection message to notify that the WTRU-to-WTRU relay was not selected. (4) After selecting a WTRU-to-WTRU relay for the connection between the source WTRU and the target WTRU, the target WTRU can respond to the selected WTRU-to-WTRU relay with a response message corresponding to the request message from the WTRU-to-WTRU relay. For example, the target WTRU can send a Link Modification Accept (LMA) message in response to a Link Modification Request and can send a DCA message in response to a DCR message.

[0142] In an embodiment, when a target WTRU receives a DCR and link modification request message from a WTRU-to-WTRU relay, the target WTRU can examine the requested ProSe service, the source WTRU information in the received DCR and link modification request messages, and the target WTRU information to determine whether those messages originate from the same source WTRU serving the same ProSe service as the target WTRU. Based on this determination, the target WTRU can select a WTRU-to-WTRU relay that appears to be the most suitable for the connection with the source WTRU.

[0143] Alternatively, the source WTRU can include a "request ID" in the DCR message, and WTRU-to-WTRU can include that request ID in the DCR and link modification request messages transmitted to the target WTRU. The target WTRU can then examine DCR and link modification requests with the same request ID to determine if they originated from the same request from the same source WTRU.

[0144] Figure 4 This is an example of a message sequence diagram of an integrated discovery link process between a WTRU (e.g., a terminal UE) and a WTRU-to-WTRU relay, which has a link modification rejection / acceptance procedure.

[0145] At step 0, the source WTRU (e.g., UE-1) and the destination WTRU (e.g., UE-2) can be authorized and configured with parameters to use the services provided by the WTRU-WTRU relays (e.g., relay-1 and relay-2). The WTRU-WTRU relays can be authorized and configured with parameters to provide services for relaying traffic between the source WTRU and the destination WTRU.

[0146] At step 1, the source WTRU (e.g., UE-1) may request to establish unicast communication with the target WTRU (e.g., UE-2) and thus may broadcast DCR messages.

[0147] The source WTRU (e.g., UE-1) may include the value of the request ID for the DCR message.

[0148] DCR can include sidelink (e.g., PC5 link) sharing policies (e.g., link sharing PREFERRED, REQUIRED, NOT NEEDED). Link sharing policies can be applied and configured on a per-ProSe or RSC basis in WTRU / WTRU to WTRU trunks. For example, a particular ProSe service or RSC may require dedicated connection usage across WTRU to WTRU trunks (e.g., link sharing is not allowed) to implement security / traffic isolation.

[0149] At step 2, when a DCR is received from the source WTRU (e.g., UE-1), WTRU-to-WTRU relays (e.g., relay-1 and relay-2) may decide to participate in the process. As a default operation, WTRU-to-WTRU relays may broadcast a direct communication request message in their vicinity.

[0150] If an existing side link (e.g., PC5) connection exists between the WTRU-to-WTRU relay (e.g., relay-2) and the target WTRU (e.g., UE-2), the WTRU-to-WTRU relay (e.g., relay-2) may send a link modification request message on the existing side link (e.g., PC5) connection instead of broadcasting a DCR message. If an existing side link (e.g., PC5) exists with the target WTRU (e.g., UE-2), the WTRU-to-WTRU relay (e.g., relay-2) may decide, based on the link sharing policy, to request a new link with a DCR message or reuse an existing link with a link modification request, as described above.

[0151] The DCR message may include source WTRU (e.g., UE-1) user information, destination WTRU (e.g., UE-2) user information, and WTRU-to-WTRU relay (e.g., relay-2) information. The message may include the requested ProSe service as received in step 1.

[0152] If a link modification request message is transmitted in step 2, the link modification request message may include source WTRU (e.g., UE-1) user information. It may include target WTRU (e.g., UE-2) user information and WTRU-WTRU relay (e.g., relay-2) information and the requested ProSe service as received in step 1.

[0153] When the received DCR message does not include the target WTRU user information, in step 2, the WTRU to WTRU relay (e.g., relay-2) may not include the target WTRU user information in the DCR.

[0154] WTRU-WTRU relays (e.g., relay-2) can include the value of the request ID, such as that received from the source WTRU on the DCR message, in DCR messages and link modification request messages.

[0155] In step 3, when the target WTRU (e.g., UE-2) receives a DCR message and a link modification request message from one or more WTRU-to-WTRU relays for establishing a connection with the source WTRU (e.g., UE-1) via the WTRU-to-WTRU relay, the target WTRU (e.g., UE-2) can verify that the received DCR message and link modification request message originate from the same source WTRU for the same requested ProSe service. This can be verified by comparing included parameters such as, for example, source WTRU user information, application ID, and the requested ProSe service. Alternatively, it can be verified by comparing the included request ID.

[0156] In a WTRU-WTRU relay that transmits a DCR or link modification request for the same source WTRU (e.g., UE-1), the target WTRU (e.g., UE-2) can select the WTRU-WTRU relay to which the target WTRU will respond. The target WTRU can select the WTRU-WTRU relay based on signal strength, local policies, and operator policies for each RSC (if any). For example, the target WTRU (e.g., UE-2) can prioritize the WTRU-WTRU relay by granting privileges to a relay (e.g., relay-2) with sidelink (e.g., PC5 link) sharing opportunities to avoid the overhead of additional sidelink (e.g., PC5 link) establishment and maintenance (e.g., with relay-1), and according to the sidelink (e.g., PC5 link) sharing policy.

[0157] When the received DCR message does not include the target WTRU user information, the target WTRU (e.g., UE-2) may decide to respond to the DCR message if it supports the requested ProSe service.

[0158] In step 4, in option (Option A), if the WTRU-to-WTRU relay has transmitted a link modification request message for establishing a connection with the source WTRU, but the WTRU-to-WTRU relay was not selected for the connection with the source WTRU, the target WTRU may send a link modification rejection to the WTRU-to-WTRU relay. The link modification rejection may indicate that the WTRU-to-WTRU relay was not selected for the connection between the source WTRU (e.g., UE1) and the target WTRU (e.g., UE2). Upon receiving a link modification rejection, the WTRU-to-WTRU relay may consider the request in step 2 rejected, and the request no longer needs to be requested or retransmitted. The link modification rejection message may include an indication / reason code indicating that the target WTRU did not select the WTRU-to-WTRU relay for that particular connection request. Alternatively, the link modification rejection message may indicate that link sharing is not allowed based on the target WTRU's link sharing policy. In this latter case, the WTRU-to-WTRU relay may instead retransmit the DCR in response to initiating a new link establishment.

[0159] The link modification rejection message may include source WTRU (e.g., UE-1) user information, target WTRU (e.g., UE-2) user information, WTRU-to-WTRU relay information, the requested ProSe service, and may include the same request ID value as received in step 2 from WTRU-to-WTRU relay (e.g., relay-2).

[0160] In step 5, in option (Option B), if the WTRU-to-WTRU relay has already transmitted a link modification request message for establishing a connection with the source WTRU (e.g., UE-1), and the WTRU-to-WTRU relay is selected for the connection with the source WTRU, then the target WTRU (e.g., UE-2) can send a link modification acceptance to the WTRU-to-WTRU relay. Steps 6, 7, and 8 do not proceed because the WTRU-to-WTRU relay (e.g., relay-1) was not selected for the connection between the source and target WTRUs.

[0161] The link modification acceptance message may include source WTRU (e.g., UE-1) user information, target WTRU (e.g., UE-2) user information, WTRU-WTRU relay information, the requested ProSe service, and the request ID.

[0162] When the target WTRU selects a WTRU-WTRU relay (e.g., relay-1) that has already transmitted the DCR for the connection to the source WTRU, and there is no existing side link (e.g., PC5) connection between the target WTRU and the selected WTRU-WTRU relay for the connection to the source WTRU, the target WTRU can perform steps 6, 7 and 8.

[0163] At step 6, in option (option C), if necessary, the target WTRU (e.g., UE2) can trigger the establishment of a security connection between the target WTRU (e.g., UE-2) and the selected (e.g., 5G ProSe) WTRU to WTRU relay (e.g., relay-1).

[0164] At step 7, the target WTRU can reply with a DCA message to the selected WTRU-to-WTRU relay (e.g., relay-1).

[0165] The DCA message may include source WTRU user information, target WTRU user information, selected WTRU-WTRU relay (e.g., relay-1) information, and the requested ProSe service.

[0166] The message may include the same request ID value as received in step 2 from the selected WTRU to the WTRU relay.

[0167] At step 8, for IP traffic, an IPv6 prefix or IPv4 address can be assigned to the target (e.g., 5G ProSe Layer 3) WTRU.

[0168] When the direct communication request transmitted in step 2 is successfully responded to, the WTRU to WTRU relay can respond to the direct communication request message transmitted from the source WTRU in step 1.

[0169] If the selected WTRU-WTRU relay (e.g., relay-1) receives a response from the target WTRU, steps 9 through 13 can be performed, whereby the target WTRU accepts a DCR or link modification request to connect with the source WTRU. If another WTRU-WTRU relay (e.g., relay-2) receives a response from the target WTRU that accepted the request, steps 9 through 13 will be performed between the source WTRU (e.g., UE-1) and another WTRU-WTRU relay (e.g., relay-2).

[0170] In option (Option D), if another WTRU-to-WTRU relay needs to establish a new side link (e.g., PC5) connection with the source WTRU (e.g., UE-1), steps 9, 10, and 11 can be performed, and steps 12 and 13 can be omitted.

[0171] In option (Option E), if there is an existing side link (e.g., PC5) connection between the source WTRU (e.g., UE-1) and the WTRU-WTRU relay (relay-1), then steps 12 and 13 are performed, and steps 9, 10 and 11 are omitted.

[0172] At step 9, according to option D, if necessary, a security establishment can occur between the source WTRU (e.g., UE-1) and the WTRU-to-WTRU relay (e.g., relay-1).

[0173] At step 10, the WTRU to WTRU relay (e.g., relay-1) can respond to the source WTRU (e.g., UE-1) with a DCA message.

[0174] The DCA message may include user information for the source WTRU, the target WTRU, and the WTRU-WTRU relay (e.g., relay-1). The message may also include the requested ProSe service.

[0175] This message may include the same request ID value received from the source WTRU in step 1.

[0176] At step 11, for IP traffic, an IPv6 prefix or IPv4 address can be assigned to the source (e.g., 5G ProSe Layer 3) WTRU.

[0177] At step 12, in option (Option E), if an existing side link (e.g., PC5) connection exists between the WTRU-to-WTRU relay (e.g., relay-1) and the source WTRU, the WTRU-to-WTRU relay (e.g., relay-1) may send a direct communication rejection message with a rejection reason (e.g., "Use existing link"). The rejection reason may indicate that a new side link (e.g., PC5) connection between the source WTRU and the WTRU-to-WTRU relay (e.g., relay-1) has not been established for connection to the target WTRU, and that the existing side link (e.g., PC5) connection between the source WTRU and the WTRU-to-WTRU relay (e.g., relay-1) may (e.g., already exists) exist and should be reused. The direct communication rejection message may include an indication / reason code indicating that the existing link is available for link sharing.

[0178] This message may include the same request ID value received from the source WTRU in step 1.

[0179] At step 13, after receiving a direct communication rejection message with the reason of “using existing link”, the source WTRU (UE-1) may trigger a link modification process between the source WTRU and the WTRU-WTRU relay (e.g., relay-1) to update the existing side link (e.g., PC5) connection to add ProSe service for connection with the target WTRU (e.g., UE-2).

[0180] Alternatively, when a DCA is received (or when an LMA is received in the case of selected trunk-2), the link modification process can be triggered by the WTRU to WTRU trunk (e.g., trunk-1). In that case, step 12 can be omitted.

[0181] In another embodiment, the method for performing integration discovery when there is an existing side link (e.g., PC5) connection between the source WTRU and the WTRU-to-WTRU relay and / or between the WTRU-to-WTRU and the target WTRU can be characterized by the following functions: (1) After receiving a DCR message from the source WTRU, the WTRU-to-WTRU relay may send a DCR message including the requested ProSe service and information about the potential target WTRU. (2) The target WTRU may compare the messages received from the WTRU-to-WTRU relay and select the WTRU-to-WTRU relay for connection with the source WTRU for the requested ProSe service. (3) When the relay WTRU is selected and there is an existing connection between the WTRU-to-WTRU relay and the target WTRU, the target WTRU may decide to reuse the existing side link (e.g., PC5) for connection with the source WTRU. In this case, the target WTRU may respond with a direct communication rejection message, where the rejection code indicates the existence of an existing connection. (4) After sending a direct communication rejection message, a link modification procedure is performed between the target WTRU and the WTRU-WTRU relay to modify the existing side link (e.g., PC5) used for the connection to the source WTRU. (5) When the WTRU-WTRU relay responds to the source WTRU based on the response from the target WTRU and the WTRU-WTRU relay finds an existing side link (e.g., PC5) connection between the source WTRU and the WTRU-WTRU relay, the WTRU-WTRU relay can respond with a direct communication rejection message with a rejection code indicating the existence of an existing connection. After sending a direct communication rejection, a link modification procedure is performed between the source WTRU and the WTRU-WTRU relay to modify the existing side link (e.g., PC5) used for the connection to the target WTRU.

[0182] In an embodiment, when a target WTRU receives a direct communication request message from a WTRU-to-WTRU relay, the target WTRU can examine the requested ProSe service, the source WTRU user information in the received direct communication request message, and the target WTRU user information (if provided) to determine whether those messages originate from the same source WTRU for the same ProSe service. Based on this determination, the target WTRU can select a WTRU-to-WTRU relay that appears to be the most suitable for the connection with the source WTRU.

[0183] Alternatively or additionally, the request ID may be included in the direct communication request message in the same way as the direct communication request message received from the source WTRU. The target WTRU may examine direct communication request messages with the same request ID to assess whether they originate from the same request from the same source WTRU.

[0184] Figure 5 This is an example of a message sequence diagram of an integrated discovery process between WTRU-WTRU relays and WTRUs with direct communication rejection.

[0185] At step 0, the source WTRU (e.g., UE-1) and the destination WTRU (e.g., UE-2) can be authorized and configured with parameters to use the services provided by the WTRU-to-WTRU relay. The WTRU-to-WTRU relay can be authorized and configured with parameters to provide a service that relays traffic between the source WTRU (e.g., UE-1) and the destination WTRU (e.g., UE-2). The source WTRU (e.g., UE-1), the destination WTRU (e.g., UE-2), and the WTRU-to-WTRU relay can be configured with security parameters (e.g., confidentiality keys) associated with the RSC by the ProSe Key Management Function (PKMF).

[0186] At step 1, the source WTRU (e.g., UE-1) may request unicast communication for a specific application ID and / or ProSe service, and may broadcast a direct communication request. The direct communication request may include source WTRU (e.g., UE-1) user information, application ID, and relay service code (if any), and may include the requested ProSe service and target WTRU (UE-2) user information.

[0187] The source WTRU (e.g., UE-1) may include the value of the request ID for the direct communication request message. The source WTRU (e.g., UE-1) may use security parameters to protect the confidentiality of parameters (e.g., request ID, requested ProSe service) and prevent replay (e.g., using a time-based counter).

[0188] In step 2, when a direct communication request message is received from the source WTRU (e.g., UE-1), the WTRU-to-WTRU relays (e.g., relay-1 and relay-2) may decide to participate in the process. By default, the WTRU-to-WTRU relays may broadcast the direct communication request message in their vicinity.

[0189] The direct communication request message may include source WTRU (e.g., UE-1) user information, target WTRU (e.g., UE-2) user information (if received from the source WTRU), and WTRU-to-WTRU relay information. The message may include the requested ProSe service as received in step 1.

[0190] When the received direct communication request message does not include the target WTRU user information, the WTRU-to-WTRU relay information does not include the target WTRU user information in the direct communication request in step 2.

[0191] WTRU to WTRU relays may include information indicating the value of the request ID of a direct communication request message received as in step 1. WTRU to WTRU relays may use security parameters to protect the confidentiality of parameters in the direct communication request message (e.g., request ID, requested ProSe service) and prevent replay.

[0192] In step 3, when the target WTRU (e.g., UE-2) receives a direct communication request message from one or more WTRU-to-WTRU relays for establishing a connection with the source WTRU (e.g., UE-1) via the WTRU-to-WTRU relay, the target WTRU (e.g., UE-2) can verify whether the received direct communication request message originates from the same source WTRU for the same requested ProSe service. This can be verified by comparing included parameters such as, for example, source WTRU user information, application ID, and the requested ProSe service. Alternatively, it can be verified by comparing the included request ID.

[0193] In a WTRU-to-WTRU relay that transmits a direct communication request message for the same source WTRU, the target WTRU can select the WTRU-to-WTRU relay that the target WTRU (e.g., UE-2) will respond to. The target WTRU (e.g., UE-2) can select the WTRU-to-WTRU relay based on signal strength, local policies, and operator policies for each relay service code (if any).

[0194] At step 4, if an existing side link (e.g., PC5) connection exists between the target WTRU (e.g., UE-2) and the selected WTRU-WTRU relay (e.g., relay-2), the target WTRU may send a direct communication rejection with the rejection reason "use existing link". For example, it may indicate that a new side link (e.g., PC5) connection between the target WTRU and the selected WTRU-WTRU relay may not have been established for the connection with the source WTRU, and the existing side link (e.g., PC5) connection between the target WTRU and the selected WTRU-WTRU should be reused.

[0195] This message may include the same request ID value received in step 2. The target WTRU can use security parameters to protect the confidentiality of parameters (e.g., request ID) in the direct communication rejection message and prevent replay.

[0196] In step 5, a link modification procedure can be performed between the source WTRU and the selected WTRU-WTRU relay (e.g., relay-2) to update the existing side link (e.g., PC5) connection to add ProSe service for the connection with the source WTRU. The link modification procedure can be triggered by the target WTRU or by the selected WTRU-WTRU relay (e.g., relay-2). The WTRU-WTRU relay (e.g., relay-2) can verify the security of the direct communication rejection message parameters and verify that they match the parameters in the direct communication request message. If the communication rejection message verification is successful, the WTRU-WTRU relay can continue with the link modification procedure; otherwise, the WTRU-WTRU relay can ignore the direct communication rejection message.

[0197] In Option A, if the selected WTRU-to-WTRU relay (e.g., relay-2) needs to establish a new side link (e.g., PC5) connection with the source WTRU (e.g., UE-1), steps 6, 7, and 8 can be performed, and steps 9 and 10 can be omitted.

[0198] In Option B, if there is an existing side link (e.g., PC5) connection between the source WTRU and the selected WTRU-WTRU relay (e.g., relay-2), steps 9 and 10 can be performed, and steps 6, 7, and 8 can be omitted.

[0199] At step 6, if necessary, a security establishment occurs between the source WTRU (e.g., UE-1) and the selected WTRU-to-WTRU relay (e.g., relay-2).

[0200] At step 7, the selected WTRU-WTRU relay (e.g., relay-2) can respond to the source WTRU (e.g., UE-1) with a direct communication receive message.

[0201] The direct communication receive message may include user information for the source WTRU, user information for the target WTRU, and user information for the selected WTRU-WTRU relay (e.g., relay-2). The message may also include the requested ProSe service.

[0202] This message may include the same request ID value received from the source WTRU in step 1.

[0203] At step 8, for IP traffic, an IPv6 prefix or IPv4 address can be assigned to the source (e.g., 5G ProSe Layer 3) WTRU.

[0204] At step 9, if an existing side link (e.g., PC5) connection exists between the selected WTRU-WTRU relay (e.g., relay-2) and the source WTRU, the selected WTRU-WTRU relay (e.g., relay-2) may send a direct communication rejection, indicating that a new side link (e.g., PC5) connection between the source WTRU and the selected WTRU-WTRU relay (e.g., relay-2) has not been established for the connection to the target WTRU, and the existing side link (e.g., PC5) connection between the source WTRU and the selected WTRU-WTRU relay (e.g., relay-2) should be reused.

[0205] This message may include the same request ID value received from the source WTRU in step 1. WTRU-to-WTRU relays can use security parameters to protect the confidentiality of parameters (e.g., request ID) in direct communication rejection messages and prevent replay.

[0206] At step 10, after sending a direct communication rejection message to the source WTRU, a link modification procedure can be performed between the source WTRU and a selected WTRU-WTRU relay (e.g., relay-2) to update (e.g., the existing) side link (e.g., PC5) connection to add ProSe service for the connection to the target WTRU. The link modification procedure can be triggered by the source WTRU or the selected WTRU-WTRU relay (e.g., relay-2). The selected WTRU-WTRU relay (e.g., relay-2) may not send a direct communication rejection message to the source WTRU and may trigger the link modification procedure. The source WTRU can verify the security of the direct communication rejection message parameters and verify that they match the parameters in the direct communication request message. If the communication rejection message verification is successful, the source WTRU can continue with the link modification procedure; otherwise, the source WTRU can ignore the direct communication rejection message.

[0207] In an embodiment, a method implemented in a first radio transmit / receive unit (WTRU) for performing integration discovery when an existing sidelink connection exists between the first WTRU or the second WTRU and at least one WTRU-to-WTRU relay may include the step of transmitting a Direct Communication Request (DCR) message including proximity-based ProSe service parameters to the second WTRU via at least one WTRU-to-WTRU relay. The method may further include the step of receiving a Link Modification Request (LCR) message including information related to the ProSe service parameters from the second WTRU via one of the at least one WTRU-to-WTRU relay. The method may further include the step of transmitting a Link Modification Response (LCR) message to one of the at least one WTRU-to-WTRU relay; and the step of receiving a Direct Communication Acceptance (DCA) message from one of the at least one WTRU-to-WTRU relay.

[0208] The DCR message may include any one of relay_indication, first WTRU user information, second WTRU user information, application ID, and relay service code. The first WTRU may include ProSe service and QoS information related to the ProSe service. The method may further include a step of determining that the received information is related to proximity-based service parameters. The DCR message may include a message transaction number value, and wherein the link modification request message includes the message transaction number value. The DCR message may include information containing Quality of Service (QoS) and proximity-based service-related information, such that the method may include a step of receiving QoS requirements for the link between the WTRU-to-WTRU relay and the first WTRU from the WTRU-to-WTRU relay. The DCR message may be transmitted broadcast. The link modification request message may be transmitted unicast. The link modification response message may be transmitted unicast.

[0209] In an embodiment, the method implemented in a WTRU-WTRU relay may include the step of receiving a Direct Communication Request (DCR) message from a first WTRU, the DCR message including information containing Quality of Service (QoS) and service-related information based on proximity. The method may further include the step of determining a first QoS parameter value for the link between the first WTRU and the WTRU-WTRU relay. The method may include the step of transmitting a DCR message to a second WTRU. The method may include the step of receiving a second QoS parameter value from the second WTRU for the link between the second WTRU and the WTRU-WTRU relay; and the step of determining whether direct communication between the first WTRU and the second WTRU is accepted based on the first and second QoS parameter values. The method may further include the step of transmitting the first QoS parameter value for the link between the first WTRU and the WTRU-WTRU relay to the first WTRU.

[0210] refer to Figure 6A method 600 for performing integration discovery, implemented in a Wireless Transmit / Receive Unit (WTRU), may include the step of receiving 610 a direct communication request message including a first communication request from a first source WTRU from each WTRU-WTRU relay in a first group of WTRU-WTRU relays. Method 600 may include the step of receiving 620 a link modification request message including a second communication request from a first source WTRU from each WTRU-WTRU relay in a second group of WTRU-WTRU relays. Method 600 may include the step of selecting 630 WTRU-WTRU relays in the first and second groups of WTRU-WTRU relays for communication with the first source WTRU; and the step of transmitting 640 a link modification rejection message to all WTRU-WTRU relays in the second group that were not selected for communication with the source WTRU.

[0211] Given that the selected WTRU-WTRU relay originates from a first group of WTRU-WTRU relays and an existing sidelink connection has been established between the WTRU and the selected WTRU-WTRU relay, method 600 may include the step of transmitting a direct communication rejection message to the selected WTRU-WTRU relay. Method 600 may include the following steps: including performing a link modification process using the selected WTRU-WTRU relay to modify the existing sidelink connection. The step of selecting a WTRU-WTRU relay may include: selecting a third group of WTRU-WTRU relays from the first and second groups of WTRU-WTRU relays, the third group of WTRU-WTRU relays transmitting a direct communication request message or a link modification request message originating from the same source WTRU serving the same ProSe service as the WTRU; and selecting a WTRU-WTRU relay from the third group of WTRU-WTRU relays based on any one of signal strength, local policy, and carrier policy for each relay service code. Given that the selected WTRU-WTRU relay originates from a first group of WTRU-WTRU relays, method 600 may include the following steps: transmitting a direct communication accept message to the selected WTRU-WTRU relay, and transmitting additional link modification reject messages to all WTRU-WTRU relays in the second group of WTRU-WTRU relays. The direct communication accept message and link modification request message may include information indicating any one of proximity-based service, information about the source WTRU, and information about the WTRU. The direct communication accept message may be transmitted via unicast. The link modification request message may be sent via unicast. The link modification reject message and other link modification reject messages may be sent via unicast.

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

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

[0214] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE," the term "remote," and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of the various embodiments of a WTRU; (iii) in particular a device configured with some or all of the structure and functions of a WTRU and having wireless and / or wired capabilities (e.g., tetherable); (iv) a device configured with less than all the structure and functions of a WTRU and having wireless and / or wired capabilities; or (iv) the like. Figure 1A-1DDetails of an example WTRU, which may represent any WTRU described herein, are provided. As another example, various disclosed embodiments herein are described using a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of the embodiments disclosed herein and the various disclosures can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adapted, realistic experience.

[0215] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROMs and Digital Universal Discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

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

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

[0218] Those skilled in the art will understand that the actions and symbols representing operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause a transformation or reduction of electrical signals and the maintenance of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and other signal processing. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

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

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

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

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

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

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

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

[0226] Those skilled in the art will understand that, in general, the terminology used herein, and particularly in the appended claims (e.g., the body of the appended claims), is intended to be “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if it is intended to introduce a specific number of claim statements, such an intention will be explicitly stated in the claims, and without such a statement, such an intention does not exist. For example, the term “single” or similar language may be used where only one item is intended. To aid understanding, the appended claims and / or the description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claim statements. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article “a” or “an” will limit any particular claim that includes such an introduced claim statement to only one embodiment of such a statement, even when the same claim includes the introductory phrase “one or more” or “at least one” and an indefinite article, such as “a” or “an” (e.g., “a” and / or “an” should be interpreted as meaning “at least one” or “one or more”). The same applies to the use of definite articles used to introduce claim statements. Furthermore, even if a specific number of introduced claim statements are explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number stated (e.g., in the absence of other modifiers, a bare statement of “two statements” means at least two statements, or two or more statements). Furthermore, in instances where the convention of "at least one of A, B, and C" is used, generally, in the sense that a person skilled in the art would understand, the intended construction is such that (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). In instances where the convention of "at least one of A, B, or C" is used, generally, in the sense that a person skilled in the art would understand, the intended construction is such that (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). Those skilled in the art will further understand that, in fact, any extractive terms and / or phrases presenting two or more alternative terms in the specification, claims, or drawings should be understood to include the possibility of including one term, any one of the terms, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, as used herein, the term “any one of…” followed by a list of multiple items and / or categories of multiple items is intended to include items alone or in combination with other items and / or categories of items, “any one of,” “any combination,” “any multiple,” and / or “any combination of multiples of.” Additionally, as used herein, the term “set” is intended to include any number of items, including zero. Furthermore, as used herein, the term “quantity” is intended to include any quantity, including zero. And as used herein, the term “many” is intended to be synonymous with “multiple.”

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

[0228] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “up to,” “at least,” “greater than,” “less than,” and the like includes the stated number and refers to a scope that can subsequently be divided into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1-3 units means a group having 1, 2, or 3 units. Similarly, a group having 1-5 units means a group having 1, 2, 3, 4, or 5 units, and so on.

[0229] Furthermore, unless otherwise stated, the claims should not be construed as limited to the order or elements provided. Additionally, the use of the term "means for..." in any claim is intended to invoke the claim format of 35 USC §112, ¶6 or means plus function, and any claim without the term "means for..." is not intended to be so.

Claims

1. A method implemented in a Wireless Transmitter / Receiver Unit (WTRU), comprising: The WTRU relay receives a direct communication request message, including a first communication request from the first source WTRU; The link modification request message, which includes a second communication request from the first source WTRU, is received from the second WTRU to the WTRU relay. Select a WTRU-WTRU relay in the first WTRU-WTRU relay and the second WTRU-WTRU relay for communication with the first source WTRU; as well as Under the condition that the first WTRU-to-WTRU relay is the selected WTRU-to-WTRU relay, a link modification rejection message is transmitted to the second WTRU-to-WTRU relay, wherein the link modification rejection message includes a first indication that the second WTRU-to-WTRU relay has not been selected by the WTRU.

2. The method according to claim 1, wherein, Provided that the selected WTRU-WTRU relay is the first WTRU-WTRU relay and an existing side link connection has been established between the WTRU and the selected WTRU-WTRU relay, a direct communication rejection message is transmitted to the selected WTRU-WTRU relay, wherein the direct communication rejection message includes a second indication regarding the existence of an existing connection.

3. The method of claim 2, comprising performing a link modification process with the selected WTRU-WTRU relay to modify the existing side link connection.

4. The method according to claim 1, wherein, The selection of the first WTRU to WTRU trunk is based on any one of the following: signal strength, local policy, and carrier policy for each trunk service code.

5. The method according to claim 1, wherein, The link modification rejection message is a first link modification rejection message, wherein, under the condition that the selected WTRU-WTRU relay is the first WTRU-WTRU relay, a direct communication accept message is transmitted to the selected WTRU-WTRU relay, and a second link modification rejection message is transmitted to the second WTRU-WTRU relay.

6. The method according to claim 1, wherein, Direct communication request messages and link modification request messages include information indicating any one of proximity-based services, information about the first source WTRU, and information about the WTRU.

7. The method according to claim 5, wherein, In direct communication, messages are transmitted via unicast.

8. The method according to claim 1, wherein, Link modification request messages are transmitted via unicast.

9. The method according to claim 5, wherein, The second link modification rejection message is transmitted via unicast.

10. The method according to claim 1, wherein, Link modification rejection messages are transmitted via unicast.

11. A wireless transmit / receive unit (WTRU), comprising a processor, a transceiver unit, and a storage unit, and configured to: The WTRU relay receives a direct communication request message, including a first communication request from the first source WTRU; The link modification request message, which includes a second communication request from the first source WTRU, is received from the second WTRU to the WTRU relay. Select a WTRU-WTRU relay in the first WTRU-WTRU relay and the second WTRU-WTRU relay for communication with the first source WTRU; as well as Under the condition that the first WTRU-to-WTRU relay is the selected WTRU-to-WTRU relay, a link modification rejection message is transmitted to the second WTRU-to-WTRU relay, wherein the link modification rejection message includes a first indication that the second WTRU-to-WTRU relay has not been selected by the WTRU.

12. The WTRU of claim 11, configured to transmit a direct communication rejection message to the selected WTRU-WTRU relay provided that the selected WTRU-WTRU relay is a first WTRU-WTRU relay and an existing side link connection between the WTRU and the selected WTRU-WTRU relay has been established, wherein the direct communication rejection message includes a second indication regarding the existence of an existing connection.

13. The WTRU of claim 12, configured to perform a link modification procedure with the selected WTRU-to-WTRU relay to modify the existing side link connection.

14. The WTRU of claim 11, configured to select a first WTRU to a WTRU relay based on any one of signal strength, local policy, and operator policy for each relay service code.

15. The WTRU according to claim 11, wherein, The link modification rejection message is a first link modification rejection message, wherein the WTRU is configured to transmit a direct communication accept message to the selected WTRU-WTRU relay, provided that the selected WTRU-WTRU relay is the first WTRU-WTRU relay, and to transmit a second link modification rejection message to the second WTRU-WTRU relay.

16. The WTRU of claim 11, wherein, Direct communication request messages and link modification request messages include information indicating any one of proximity-based services, information about the first source WTRU, and information about the WTRU.

17. The WTRU according to claim 15, wherein, In direct communication, messages are transmitted via unicast.

18. The WTRU according to claim 11, wherein, Link modification request messages are transmitted via unicast.

19. The WTRU according to claim 15, wherein, The second link modification rejection message is transmitted via unicast.

20. The WTRU of claim 11, wherein, Link modification rejection messages are transmitted via unicast.

Images