Path selection for sidelink communications in nr network

Abstract

To provide methods and apparatus for establishing a unicast D2D communication link between a requesting UE and a remote UE via a relay UE.SOLUTION: According to methods in a wireless communication network, a requesting UE broadcasts 110 a request to start a communication with a remote UE (e.g., Direct Communication Request, Solicitation message) to one or more neighboring UE. The request includes a relay indication which indicates whether relay is allowed to a communication path between the requesting UE and the remote UE. According to the methods, the requesting UE also further receives 120 a response message (Request acceptance, Solicitation Response message) from one or more neighboring UE and determines 130 a communication path for D2D communications between the requesting UE and the remote UE on the basis of one or more response messages.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] The present disclosure relates generally to device-to-device (D2D) communications in wireless communication networks, and more particularly to route selection for D2D communications. [Background technology]

[0002] The Sidelink (SL) interface introduced by the Third Generation Partnership (3GPP) project in Release 12 (Rel-12) of the Long-Term Evolution (LTE) standard allows a User Equipment (UE) to communicate directly with peer UEs without sending packets to the Network (NW). A UE-to-network relaying solution is also defined to allow remote UEs outside of cell coverage to reach the network via a relay UE. The remote UE communicates with the relay UE using the SL interface, and the relay UE has an uplink connection and a downlink connection with the cell.

[0003] The first specification of the sidelink interface was primarily targeted at public use cases. Since then, many extensions have been introduced with the aim of expanding the use cases that can benefit from D2D technology. In particular, in LTE Release 14 (Rel-14) and Release 15 (Rel-15), the extension of the D2D framework was focused on supporting Vehicle-to-Everything (V2X) communications, which includes any combination of direct communication between vehicles, pedestrians, and infrastructure.

[0004] While LTE V2X is primarily aimed at road safety services, the implementation of V2X in New Radio standards spans a broader scope that includes not only basic safety services but also non-safety applications such as sensor / data sharing between vehicles for enhanced perception of the surrounding environment. As a result, a new set of applications such as vehicle platooning, cooperative vehicle steering, and remote / autonomous driving can benefit from the enhanced sidelink framework.

[0005] Currently, the NR standard supports two Proximity Service (ProSe) discovery methods that allow a UE to discover neighboring UEs 30 in the vicinity of a Discoverer UE. In the first model, called Model A, an Announcing UE broadcasts a discovery message to Monitoring UEs 30 that have permission to discover at a specified discovery interval. The discovery message contains information that the Monitoring UEs 30 may be interested in. If the discovery message contains information that the Monitoring UEs are interested in, the Monitoring UEs can respond. Both open and restricted discovery types are supported by the Model A discovery method. In the second model, called Model B, a Discoverer UE sends a request that contains information about its specific interests. A Discoveree UE that receives the request can respond with some information about the Discoverer UE's interests. For example, the Discoverer UE can include in its request information about the ProSe Application Identity corresponding to a group, and the members of the group can respond. The Model B discovery method used for Public Safety is restricted. The Monitoring UE / Discoverer UE must have the authority (e.g., through pre-provisioned parameters) to perform discovery of the appropriate services.

[0006] D2D communication between two UEs 30 can be used to relay messages from UEs that are outside of the network coverage. Model A or Model B discovery methods can be used by an Announcing / Discoverer UE to discover UEs in its vicinity to serve as UE-to-Network Relays. A UE acting as a UE-to-Network Relay is attached to the network (if not already attached) and can connect to a Packet Data Network (PDN) connection, enabling the necessary relay traffic.

[0007] Although several proposals have been made to support UE-to-UE relays, existing solutions suffer from one or more shortcomings. Specifically, existing solutions may introduce undesirable delays in relay discovery, provide limited capabilities, or require the UE to establish a unicast link to the relay in advance (which may introduce additional delays and waste resources). Additionally, existing solutions do not support relay selection by the remote UE. This limitation may create problems because the capabilities of the remote UE are not considered in relay selection.

[0008] Thus, there remains a need for a solution to overcome the shortcomings of prior art solutions. Summary of the Invention

[0009] The present disclosure provides a method and apparatus for establishing a unicast D2D communication link between a requesting UE and a remote UE via a relay UE.

[0010] According to a first aspect of the present disclosure, a procedure is provided for unicast link establishment with a remote UE without relay discovery. When a requesting UE needs to communicate with a remote UE, it broadcasts a Direct Communication Request to all UEs 30 in the vicinity of the requesting UE. The Direct Communication Request includes a relay indication indicating whether relaying and optionally multiple hops are allowed for the communication path between the requesting UE and the remote UE. Neighboring UEs 30 receiving the Direct Communication Request can either respond to the request directly or rebroadcast the request. Thus, the remote UE may receive multiple copies of the Direct Communication Request. The remote UE can respond to one or more instances of the Direct Communication Request. The selection of the communication path for D2D communication between the requesting UE and the remote UE can be performed by the remote UE or the requesting UE, or a combination of the remote UE and the requesting UE.

[0011] According to a second aspect of the present disclosure, a procedure is provided for unicast link establishment with a remote UE involving relay discovery. Each relay UE maintains a list of neighboring UEs 30 that the relay UE can reach and periodically broadcasts an announcement to indicate availability for relaying communication. The announcement includes an indication of other UEs 30 that the announcing UE can reach (e.g., reachable neighbor list). When a UE within the reachability range of the relay UE receives the broadcast announcement, the UE can decide whether it wants to use the relay UE to relay D2D communication. If it wants to use the relay UE to relay D2D communication, the receiving UE stores a copy of the reachable neighbor list for relaying in its local memory and sends a relay request to the relay UE. Upon receiving the relay request, the relay UE adds the requesting UE to its reachable neighbors and sends the updated list in the next broadcast discovery message. When a requesting UE wants to communicate with a remote UE, the requesting UE can select a relay through which the remote UE can be reached before sending a Direct Communication Request based on a local copy of the reachable neighbor list stored in memory.

[0012] A third aspect of the disclosure includes a method implemented by a UE for D2D communication. In one embodiment, the method includes broadcasting a request to one or more neighboring UEs to initiate communication with the remote UE. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. The method further includes receiving a response message from one or more of the neighboring UEs in response to the request, and determining a communication path for D2D communication between the requesting UE and the remote UE based on the one or more response messages.

[0013] A fourth aspect of the disclosure includes a UE configured for D2D communication. In one embodiment, the UE is configured to broadcast a request to initiate communication with a remote UE to one or more neighboring UEs. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. The UE is further configured to receive a response message from one or more of the neighboring UEs in response to the request, and determine a communication path for D2D communication between the requesting UE and the remote UE based on the one or more response messages.

[0014] A fifth aspect of the present disclosure includes a computer program comprising executable instructions that, when executed by processing circuitry in a UE in a wireless communication network, cause the UE to perform a method according to the third aspect.

[0015] A sixth aspect of the present disclosure includes including a computer program according to the fifth aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0016] A seventh aspect of the present disclosure includes a method implemented by a UE that relays D2D communication. In one embodiment, the method includes receiving a request broadcasted by a requesting UE to initiate communication with a remote UE. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. The method further includes forwarding the request toward the remote UE.

[0017] An eighth aspect of the present disclosure includes a UE configured to relay D2D communication. In one embodiment, the UE is configured to receive a request broadcasted by a requesting UE to initiate communication with a remote UE. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. The UE is further configured to forward the request toward the remote UE.

[0018] A ninth aspect of the present disclosure includes a computer program comprising executable instructions that, when executed by processing circuitry in a UE in a wireless communication network, cause the UE to perform a method according to the seventh aspect.

[0019] A tenth aspect of the present disclosure includes including a computer program according to the ninth aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0020] An eleventh aspect of the present disclosure includes a method implemented by a remote UE configured for D2D communication. In one embodiment, the method includes receiving one or more replicas of a request broadcast by a requesting UE to initiate communication with the remote UE. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. The method further includes transmitting a response message to the requesting UE in response to each of the one or more replicas of the request along the communication path along which the request was received.

[0021] A twelfth aspect of the present disclosure includes a remote UE configured for D2D communication. In one embodiment, the UE is configured to receive one or more replicas of a request broadcast by a requesting UE to initiate communication with the remote UE. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. The UE is further configured to transmit a response message to the requesting UE in response to each of the one or more replicas of the request along the communication path along which the request was received.

[0022] A thirteenth aspect of the present disclosure includes a computer program comprising executable instructions that, when executed by processing circuitry in a UE in a wireless communication network, cause the UE to perform a method according to the eleventh aspect.

[0023] A fourteenth aspect of the present disclosure includes including a computer program according to the thirteenth aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0024] A fifteenth aspect of the present disclosure includes a method implemented by a UE for D2D communication. In one embodiment, the method includes receiving announcements broadcasted by one or more relay UEs, each announcement including a neighbor list identifying one or more potential remote UEs reachable from the relay UE. The method further includes sending a request to a selected relay UE among the relay UEs having the remote UE in its neighbor list, the request including identification information for identifying the target remote UE. The method further includes receiving a response message from the remote UE relayed by the relay UE in response to the request.

[0025] A sixteenth aspect of the present disclosure includes a UE configured for D2D communication. In one embodiment, the UE is configured to receive announcements broadcasted by one or more relay UEs, each announcement including a neighbor list identifying one or more potential remote UEs reachable from the relay UE. The UE is further configured to send a request to a selected relay UE among the relay UEs having the remote UE in its neighbor list, the request including identification information for identifying the target remote UE. The UE is further configured to receive a response message from the remote UE relayed by the relay UE in response to the request.

[0026] A seventeenth aspect of the present disclosure includes a computer program comprising executable instructions that, when executed by processing circuitry in a UE in a wireless communication network, cause the UE to perform a method according to the fifteenth aspect.

[0027] An eighteenth aspect of the present disclosure includes including a computer program according to the seventeenth aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0028] A nineteenth aspect of the present disclosure includes a method implemented by a UE configured to relay D2D communications. In one embodiment, the method includes broadcasting an announcement to one or more neighboring UEs. The announcement includes a neighbor list identifying one or more potential remote UEs reachable from the UE. The method further includes receiving a request from a requesting UE to initiate D2D communications with a target remote UE in the neighbor list. The request includes identification information for identifying the target remote UE. The method further includes forwarding the request to the remote UE identified by the request.

[0029] A twentieth aspect of the present disclosure includes a UE configured to relay D2D communication. In one embodiment, the UE is configured to broadcast an announcement to one or more neighboring UEs. The announcement includes a neighbor list identifying one or more potential remote UEs reachable from the UE. The UE is further configured to receive a request from a requesting UE to initiate D2D communication with a target remote UE in the neighbor list. The request includes identification information for identifying the target remote UE. The UE is further configured to forward the request to the remote UE identified by the request.

[0030] A twenty-first aspect of the present disclosure includes a computer program comprising executable instructions that, when executed by processing circuitry in a UE in a wireless communication network, cause the UE to perform a method according to the nineteenth aspect.

[0031] A twenty-second aspect of the present disclosure includes including a computer program according to the twenty-first aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0032] A twenty-third aspect of the present disclosure includes a method implemented by a UE configured for D2D communication. In one embodiment, the method includes receiving an announcement broadcasted by a relay UE and, in response to the announcement, sending a relay request to the relay UE requesting the relay UE to serve as a relay for the D2D communication.

[0033] A twenty-fourth aspect of the present disclosure includes a UE configured for D2D communication. In one embodiment, the UE is configured to receive an announcement broadcasted by a relay UE and, in response to the announcement, send a relay request to the relay UE requesting the relay UE to serve as a relay for the D2D communication.

[0034] A twenty-fifth aspect of the present disclosure includes a computer program comprising executable instructions that, when executed by processing circuitry in a UE in a wireless communication network, cause the UE to perform a method according to the twenty-third aspect.

[0035] A twenty-sixth aspect of the present disclosure includes including a computer program according to the twenty-fifth aspect, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium. [Brief description of the drawings]

[0036] [Figure 1] FIG. 1 is a diagram of a wireless communication network that supports UE-to-UE relay as described herein. [Diagram 2] A diagram of an NR unicast link between two UEs 30 for D2D communication. [Diagram 3] FIG. 1 is a diagram of the Model A ProSe discovery procedure. [Figure 4] FIG. 1 is a diagram of the Model B ProSe discovery procedure. [Diagram 5] FIG. 1 is a diagram of a procedure for ProSe UE-to-Network relaying. [Figure 6A]FIG. 1 is a diagram of emergency call direct discovery using Model A. [Figure 6B] FIG. 1 is a diagram of emergency call direct discovery using Model B. [Figure 7] FIG. 1 is a diagram of a Layer-2 link establishment procedure for D2D communication. [Figure 8A] 1 illustrates a procedure for establishing a unicast link with a remote UE without relay discovery. [Figure 8B] 13 illustrates another procedure for unicast link establishment with a remote UE without relay discovery. [Figure 8C] 13 illustrates another procedure for unicast link establishment with a remote UE without relay discovery. [Figure 9] 1 illustrates a procedure for establishing a unicast link with a remote UE with relay discovery. [Figure 10] FIG. 1 illustrates a method of D2D communication implemented by a requesting UE. [Figure 11] 1 illustrates a method implemented by a relay UE for supporting D2D communication between a requesting UE and a remote UE. [Figure 12] FIG. 1 illustrates a method of D2D communication implemented by a requesting UE. [Figure 13] FIG. 1 illustrates a method of D2D communication implemented by a requesting UE. [Figure 14] 1 illustrates a method implemented by a relay UE for supporting D2D communication between a requesting UE and a remote UE. [Figure 15] FIG. 1 illustrates a method of D2D communication implemented by a remote UE. [Figure 16A] FIG. 1 illustrates a requesting UE configured for D2D communication. [Figure 16B] FIG. 2 illustrates a relay UE supporting D2D communication between a requesting UE and a responding UE. [Figure 16C] FIG. 2 is a diagram of a remote UE configured for D2D communication. [Figure 17A] FIG. 1 illustrates a requesting UE configured for D2D communication. [Figure 17B] FIG. 2 illustrates a relay UE supporting D2D communication between a requesting UE and a remote UE. [Figure 17C] FIG. 1 is a diagram of a remote UE configured for D2D communication via a relay UE. [Figure 18] FIG. 1 is a diagram of a UE configured for D2D communication using relaying. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037] With reference now to the drawings, the UE-to-UE relaying techniques according to the present disclosure will be described in the context of a wireless communication network implementing the NR communication standard, however, those skilled in the art will appreciate that the techniques are more generally applicable to any wireless communication network supporting D2D communication over a sidelink interface.

[0038] 1 illustrates a base station 20 that provides connectivity to a core network 40 for multiple UEs 30. Although a single base station 20 is illustrated in FIG 1, those skilled in the art will appreciate that a wireless communication network 10 typically includes many base stations 20. The base station 20 may also be referred to as an evolved Node B (eNB), a 5G Node B (gNB) or a next generation eNB (ng-eNB) in the NR standard.

[0039] 1 shows four UEs 30, designated UE-1 to UE-4, respectively. UE-1 to UE-3 are within the coverage area of ​​base station 20 and are capable of establishing a packet data network (PDN) connection with network 10. UE-4 is outside the coverage area of ​​base station 20.

[0040] UE-1 to UE-4 can communicate D2D with other UEs 30 in their vicinity on the sidelink (e.g., PC5 interface). UE-1 is in the vicinity of UE-3 and UE-4 and can communicate with UE-3 and UE-4 on the sidelinks SL13 and SL14, respectively. UE-2 is in the vicinity of UE-3 and can communicate with UE-3 on the sidelink SL23. UE-3 is in the vicinity of UE-1, UE-2, and UE-4 and can communicate with them on the sidelinks SL13, SL23, and SL34, respectively. Finally, UE-4 is in the vicinity of UE-1 and UE-3 and can communicate with UE-1 and UE-3 on the sidelinks SL14 and SL34, respectively. However, UE-1 and UE-4 are outside UE-2 and cannot establish direct communication with UE-2 on the sidelink. UE-1 can communicate with UE-2 via the base station 20. However, UE-4 is outside the coverage of base station 20.

[0041] One aspect of the present disclosure includes a method for enabling UE-to-UE relay for D2D communication. In the example shown in FIG. 1, the D2D communication technique allows UE-3 to serve as a relay for D2D communication between UE-2 and UE-4 or between UE-2 and UE-1.

[0042] In the NR sidelink, unicast in the access stratum is supported for services that require high reliability. There may be multiple sidelink unicast links between the same UE pair, and each unicast link can support multiple sidelink Quality of Service (QoS) flows / radio bearers, as shown in Figure 2 (3GPP TS 23.287). In the access stratum, each link can be identified by a source and destination Layer 2 identity (L2 ID). For example, PC5 unicast link 1 in Figure 2 can be identified by a pair of L2 ID1 (i.e., corresponding to application ID1) and L2 ID2 (i.e., corresponding to application ID2).

[0043] To enable D2D communication between UEs 30, a discovery method is required to enable UEs 30 to discover each other. 3GPP standard TS 23.303, §5.3.1.2 specifies two ProSe Discovery methods, the Model A discovery method (Figure 3) and the Model B discovery method (Figure 4).

[0044] Model A specifies two roles for a ProSe-enabled UE 30 participating in ProSe Direct Discovery. · Announcing UE: A UE 30 announcing certain information that can be used by nearby UEs 30 that have permission to discover. · Monitoring UE: A UE 30 that monitors specific information of interest in the vicinity of the announcing UE 30.

[0045] In this model, the Announcing UE 30 broadcasts discovery messages at a specified discovery interval, and the Monitoring UE 30 that is interested in these messages reads and processes the messages. Since the Announcing UE 30 broadcasts information about itself, such as its ProSe Application Code in the discovery message, this model is equivalent to "I am here". Both open and restricted discovery types are supported by Model A.

[0046] The Model B discovery method is shown in Figure 4. When the restricted discovery type is used, this model defines two roles for a ProSe-enabled UE 30 participating in ProSe Direct Discovery. Discoverer UE: A UE3 that sends requests containing specific information about a subject of interest to be discovered. Discoveree UE: A UE 30 that is capable of receiving a request message and responding with some information related to the discoverer's request.

[0047] In this model, the request by the Discoverer UE 30 includes information about other UEs 30 with which it wants to communicate. This is equivalent to "who is there / are you there" since the Discoverer UE 30 sends information about other UEs 30 from which it wants to receive a response. For example, the information could be a ProSe Application Identity corresponding to a group, and members of the group can respond. Public Safety discovery is considered restrictive. The Monitoring UE 30 / Discoverer UE 30 needs to have the authority (e.g., through pre-provisioned parameters) to perform discovery of the appropriate services.

[0048] Current standards provide support for direct communication via ProSe UE-to-Network Relay (TS 23.303, §5.4.4). In this procedure, a ProSe UE-to-Network Relay capable UE 30 is attached to the network (if not already attached) and is able to connect to a PDN connection, allowing the necessary relay traffic. Figure 5 shows the call flow of the procedure for ProSe UE-to-Network Relay. In this procedure, a remote UE 30 performs discovery of a ProSe UE-to-Network Relay using Model A (Figure 6A) or Model B (Figure 6B) discovery. Details of this procedure are given in TS 23.303, §5.3.7.

[0049] Briefly, the remote UE 30 performs ProSe UE-to-Network Relay discovery using Model A (FIG. 6A) or Model B (FIG. 6B) discovery. Details of this discovery procedure are described in TS 23.303, §5.3.7. Identifiers for ProSe UE-to-Network Relay discovery and selection are specified in TS 23.303, §4.6.4.3. The following parameters are used in the UE-to-Network Relay Discovery Announcement message (Model A): ProSe Relay UE ID: A link layer identifier used for direct communication and associated with a Relay Service Code. A UE-to-Network Relay must have a different ProSe Relay UE ID for each Relay Service Code. To support multiple PDN Connections, a ProSe UE-to-Network Relay is assigned a different ProSe Relay UE ID for each PDN Connection. · Announcer Information: Provides information about the announcing user. Relay Service Code: A parameter that identifies a connection service that the ProSe UE-to-Network Relay provides to a public safety application. The Relay Service Code is configured in the ProSe UE-to-Network Relay for advertisement. Additionally, the Relay Service Code can also identify an authorized user that the ProSe UE-to-Network Relay provides a service to, and select related security policies or information, for example, required for authentication and authorization between the Remote UE 30 and the ProSe UE-to-Network Relay (e.g., a Relay Service Code for a relay dedicated to police personnel is different from a Relay Service Code for a relay dedicated to firefighters, even if they potentially provide a connection to the same APN, for example to support Internet Access).

[0050] The following parameters are used in the UE-to-Network Relay Discovery Solicitation message (Model B): · Discoverer Info: Provides information about the discovering user. · Relay Service Code: Information about the connection that the Discoverer UE 30 is interested in. The Relay Service Code is set in the Remote UE 30 that is interested in the associated connection service. ProSe Relay UE ID: A link layer identifier of a UE-to-Network Relay used for direct communication and associated with a Relay Service Code. A UE-to-Network Relay must have a different ProSe Relay UE ID for each Relay Service Code. The ProSe Relay UE ID is optional.

[0051] The following parameters are used in the UE-to-Network Relay Discovery Response message (Model B): ProSe Relay UE ID: A link layer identifier used for direct communication and associated with a Relay Service Code. A UE-to-Network Relay must have a different ProSe Relay UE ID for each Relay Service Code.

[0052] Figure 7 shows the Layer-2 (L2) link establishment procedure for unicast mode of V2X communication over the PC5 reference point. 1. The UE 30 determines the destination Layer-2 ID for signaling receipt of a PC5 unicast link establishment as specified in TS 23.287, §5.6.1.4. The destination Layer-2 ID is configured in the UE 30 as specified in TS 23.287, §5.1.2.1. 2. The V2X application layer in UE-1 provides application information for PC5 unicast communication. The application information includes the service type of the V2X application (e.g., PSID or ITS-AID) and the Application Layer ID of the requesting UE. The Application Layer ID of the target UE may be included in the application information. The V2X Application Layer in UE-1 may provide V2X Application Requirements for this unicast communication. UE-1 determines the PC5 QoS parameters and PFI as specified in TS 23.287, §5.4.1.4. 3. UE-1 sends a Direct Communication Request message to initiate a unicast Layer 2 link establishment procedure. The Direct Communication Request message contains: · Source User Info: Application Layer ID of the requesting UE (i.e., Application Layer ID of UE-1). If in step 2 the V2X application layer provided the Application Layer ID of the target UE, the following information is included: o Target User Info: Application Layer ID of the target UE (i.e., the Application Layer ID of UE-2). V2X Service Info: Information about the V2X Service requesting Layer-2 link establishment (e.g., PSID or ITS-AID). · Indication of whether IP communication is used. IP Address Configuration: For IP communication, the IP address configuration is required for this link and can have one of the following values: "IPv6 Router" if the IPv6 address allocation mechanism is supported by the requesting UE 30, i.e., it acts as an IPv6 router; or "IPv6 address allocation not supported" - if the IPv6 address allocation mechanism is not supported by the requesting UE 30. · Link Local IPv6 Address: If UE-1 does not support the IP address allocation mechanism for IPv6, i.e., if the IP Address Configuration indicates "IPv6 address allocation not supported", then a link-local IPv6 address formed locally based on RFC4862. ·QoS Info: Information about the PC5 QoS Flow. For each PC5 QoS Flow, the PFI and the corresponding PC5 QoS parameters (i.e. PQI and, conditionally, other parameters such as MFBR / GFBR). · The source Layer-2 ID and destination Layer-2 ID used to send the Direct Communication Request message are determined as specified in clauses 5.6.1.1 and 5.6.1.4. ·UE-1 sends a Direct Communication Request message via PC5 broadcast using the source Layer-2 ID and destination Layer-2 ID. 4. A Direct Communication Accept message is sent to UE-1 as follows: 4a. (UE-oriented Layer-2 link establishment) If the Direct Communication Request message includes Target User Info, the target UE 30, i.e., UE-2, responds with a Direct Communication Accept message. 4b. (V2X Service Oriented Layer-2 Link Establishment) If Target User Info is not included in the Direct Communication Request message, a UE 30 that is interested in using the announced V2X Service and therefore decides to establish a Layer-2 link with UE-1 responds to the request by sending a Direct Communication Accept message (UE-2 and UE-4 in Figure 6.3.3.1-1).

[0053] The Direct Communication Accept message contains the following: · Source User Info: The Application Layer ID of the UE 30 sending the Direct Communication Accept message. ·QoS Info: Information about the PC5 QoS Flow. For each PC5 QoS Flow, the PFI and corresponding PC5 QoS parameters requested by UE-1 (i.e. PQI and, conditionally, other parameters such as MFBR / GFBR). IP Address Configuration: For IP communication, the IP address configuration is required for this link and can have one of the following values: "IPv6 Router" if the IPv6 address allocation mechanism is supported by the target UE 30, i.e. it acts as an IPv6 router; or "IPv6 address allocation not supported" if the IPv6 address allocation mechanism is not supported by the target UE 30. Link Local IPv6 Address: A link-local IPv6 address formed locally based on RFC4862 if the target UE 30 does not support the IPv6 IP address allocation mechanism, i.e., if the IP Address Configuration indicates "IPv6 address allocation not supported" and UE-1 included a link-local IPv6 address in the Direct Communication Request message. The target UE 30 must include a non-conflicting link-local IPv6 address. If the UEs 30 (i.e. both the requesting UE 30 and the target UE 30) choose to use link-local IPv6 addresses, they disable duplicate address detection as specified in RFC4862. Note 1: If either the requesting UE 30 or the target UE 30 indicates support for an IPv6 router, the corresponding address configuration procedure is performed after the Layer-2 link is established and the link-local IPv6 address is ignored. The source Layer-2 ID used to send the Direct Communication Accept message is determined as specified in clauses 5.6.1.1 and 5.6.1.4. The destination Layer-2 ID is set to the source Layer-2 ID of the received Direct Communication Request message. · Upon receiving the Direct Communication Accept message from the peer UE 30, UE-1 obtains the Layer-2 ID of the peer UE for signalling and data traffic for this unicast link for future communication. ·The V2X layer of the UE 30 that established the PC5 unicast link passes the PC5 Link Identifier assigned to the unicast link and the PC5 unicast link related information to the AS layer. The PC5 unicast link related information includes Layer-2 ID information (i.e., source Layer-2 ID and destination Layer-2 ID). This allows the AS layer to maintain the PC5 Link Identifier together with the PC5 unicast link related information. 5. V2X service data is transmitted over the established unicast link as follows: ·PC5 Link Identifier and PFI are provided to the AS layer along with V2X service data. ·UE-1 transmits V2X service data using a source Layer-2 ID (i.e., UE-1's Layer-2 ID for this unicast link) and a destination Layer-2 ID (i.e., peer UE's Layer-2 ID for this unicast link). Note 2: Because the PC5 unicast link is bidirectional, the peer UE 30 of UE-1 can transmit V2X service data to UE-1 over the unicast link with UE-1.

[0054] One aspect of the present disclosure is to provide support for UE-to-UE relay. Although there have been several proposals to support UE-to-UE relay, existing solutions have one or more shortcomings. In particular, existing solutions may introduce undesirable delays in relay discovery, provide limited capabilities, or require the UE 30 to establish a unicast link to the relay in advance (which may introduce additional delays and waste resources). Additionally, existing solutions do not provide support for relay selection by the remote UE 30. This limitation may create problems because the capabilities of the remote UE 30 are not considered in relay selection.

[0055] The solution described herein reuses the service discovery and unicast link establishment methods specified in TS 23.303 and TS 23.287 with some modifications, so that the impact on the corresponding products is small. The method supports relay selection by both the requesting UE 30 and the remote UE 30, also referred to herein as the target UE 30, and can take into account the status of the remote UE 30 for relay selection. Also, new timers are introduced for the collection of requests and responses from relays to perform relay selection. The method described herein also allows more information to be exchanged by potential relays to support the implementation of more complex relay selection techniques. For example, the method described herein can support load balancing and other relay selection policies.

[0056] One objective of the techniques described herein is to ensure that relay discovery between the requesting UE 30 and the target UE 30 is independent of how the relay UE 30 forwards traffic between the requesting UE 30 and the target UE 30, e.g. L2 or L3 relaying. The techniques rely on the idea that UE-to-UE discovery and selection can be integrated into a unicast link establishment procedure as described in clause 6.3.3 of TS 23.287.

[0057] In the following description, a UE 30 that initiates communication with a remote UE 30 is referred to as a requesting UE 30 or an initiating UE 30. A remote UE 30 is also referred to herein as a target UE 30. A UE 30 that serves as a UE-to-UE relay is called a relay UE 30.

[0058] 8A-8C illustrate a unicast link establishment procedure for establishing a unicast link with a remote UE 30 without relay discovery. The requesting UE 30 (also referred to herein as originating UE 30 or initiating UE 30) is represented as UE-1, and the remote UE 30 (also referred to herein as target UE 30 or responding UE 30) is represented as UE-2. When the requesting UE 30 (e.g., UE-1 in FIG. 8A-8C) wants to establish unicast communication with the remote UE 30 (UE-2 in FIG. 8A-8C), the requesting UE 30 broadcasts a Direct Communication Request or Solicitation message as specified in TS 23.303. The Direct Communication Request or Solicitation message is modified to include a new field called relay_indication, which indicates whether relaying is allowed for the communication. The relay_indication field may also indicate the maximum number of hops allowed for the communication path between the requesting UE 30 and the remote UE 30. In Release 17, it is assumed that the indication value is limited to a single hop.

[0059] The value of the relay_indication field can be 0 or a positive integer, e.g., 1, 2, ..., n. In one example, the requesting UE 30 selects a relay_indication value between 0 and M, chosen by the UE 30, where M represents an upper limit. The relay_indication value can be thought of as the maximum number of relays allowed by the requesting UE 30, i.e., a value of 0 means that no relays are allowed (no relaying allowed), a value of 1 means that only one relay is allowed (UE-relay-UE), etc. The maximum number of hops allowed is the number of relays plus 1, which is the direct communication path between the requesting UE 30 and the remote UE 30. This value can be set according to several approaches. In one approach, the relay_indication value can be set by the application to which the link establishment refers and can vary depending on the type of application. In another approach, the relay_indication value can be set as a chipset feature. In another approach, the relay_indication value may be pre-configured (e.g., on a SIM basis or via network signaling) or may be set by the network according to a dynamic policy that changes for different uses (e.g., via network signaling).

[0060] In some embodiments, the relay_indication field may be a Boolean value (True or False) indicating whether relaying is allowed. A Boolean value equal to True indicates that relaying is allowed. A Boolean value equal to False indicates that relaying is not allowed.

[0061] If a potential UE-to-UE Relay receives a Direct Communication Request or Solicitation message with a relay_indication greater than 0, the potential UE-to-UE Relay decides whether to forward (i.e., broadcast this message to its neighbors). The decision to forward or rebroadcast a Direct Communication Request can be based on factors such as, for example, the QoS requirements in the request, the current traffic load of the relay, the link quality between the requesting UE 30 and the relay UE 30 (e.g., determined by measuring the received power of the request message), or some other policy (e.g., serving only some specific UEs 30). Different forwarding techniques can be used for different requests. The technique to follow for forwarding a request can be driven by the chipset design or by application decision.

[0062] If a potential relay decides to forward / rebroadcast the request, the potential relay decrements the relay_indication value by 1. When forwarding a received request, a potential relay does not change any parameters contained in the received request other than the relay_indication value if integer values ​​are used. However, a potential relay may add additional information to the received request, such as relay load information, relay QoS support, etc.

[0063] If a relay receives a Direct Communication Request or Solicitation message with relay_indication value 0 and the relay is not the target of the request, the relay MAY drop the message. If a relay receives a communication request that it has already forwarded before (e.g., can be identified by some request ID), the relay MAY drop the current request.

[0064] There may be several scenarios in which multiple relay UEs 30 can be used to reach the target UE 30, or the target UE 30 may also receive a Direct Communication Request or Solicitation message directly from the requesting UE 30. The target UE 30 may choose which one to reply according to factors such as signal strength, local policies (e.g. traffic load of relay UEs 30) or operator policies (e.g. always prefer direct communication or only use some specific relay UE 30).

[0065] The requesting UE 30 may also receive response messages from multiple relay UEs 30 and even directly from the target UE 30. In this case, the source UE 30 chooses the communication path according to factors such as signal strength, local policies (e.g. traffic load of relay UEs 30) or operator policies (e.g. always prefer direct communication or only use some specific relay UE 30).

[0066] 8A, in this example, assume that Relay-1, Relay-2 and UE-2 are directly reachable from UE-1 (requesting UE 30). Relay-1 and Relay-2 all want to forward the Direct Communication Request message from UE-1. UE-2 (remote UE 30) is also reachable from Relay-1 and Relay-2.

[0067] In step 1, UE-1 wants to establish unicast communication with UE-2, which can be either through a direct link with UE-2 or via a UE-to-UE relay. UE-1 broadcasts a Direct Communication Request with relay_indication=1. The Direct Communication Request may also include a request identifier (ID). When UE-1 broadcasts the Direct Communication Request, it may optionally start a timer, denoted Timer1, which sets an upper limit on the time UE-1 waits for a response. The Direct Communication Request is received by Relay-1, Relay-2 and UE-2. Note that UE-1 does not need to know the identity of the remote UE 30. If UE-1 is aware of UE-2 based on a priori information, the request may optionally include an identifier for UE-2 or other information about the intended target.

[0068] In step 2, Relay-1 and Relay-2 decide to forward / broadcast the Direct Communication Request from UE-1. Both Relay-1 and Relay-2 rebroadcast the same Direct Communication Request with relay_indication=0 to neighboring UEs 30. If another relay receives this message, it will simply be dropped. For example, when Relay-2 receives the rebroadcast message from Relay-1, it will recognize the request ID as matching a previously forwarded request and will drop the message.

[0069] In step 3, UE-2 receives copies of the Direct Communication Request directly from UE-1, Relay-1 and Relay-2. In this case, there are three paths by which UE-1 can reach UE-2: direct, via Relay-1 and via Relay-2. In various embodiments of the method, the communication path for communication between UE-1 and UE-2 can be selected by UE-2 (remote UE 30), UE-1 (requesting UE 30) or a combination of UE-1 and UE-2.

[0070] In an embodiment where the remote UE 30 selects the communication path, the remote UE 30 starts a timer, shown as Timer2 in FIG. 8A, after receiving the first copy of the Direct Communication Request. In this example, the first copy received is a request directly from UE-1. The timer establishes an upper bound on the delay while the remote UE 30 collects copies of the Direct Communication Request propagating along different paths. The value of the timer may be a chipset implementation, set by the application, or given by the network (e.g., preconfigured or provided via network signaling). Any copies of the request received after the timer has expired can be ignored. In the example shown in FIG. 8A, the copy of the Direct Communication Request from Relay-2 is ignored because it arrives after Timer2 has expired.

[0071] After Timer2 expires, UE-2 decides which request to reply to based on factors such as signal strength (determined by measuring the strength of the received request), load on the relay (added to the request by the relay UE 30), local policy (e.g. provided by application or chipset design) or operator policy (pre-configured or provided via network signaling). Examples of selection criteria include, for example, selecting the request with the greatest signal strength, selecting the request with the highest value of the relay_indication parameter (meaning the request that has been forwarded the fewest number of times, indicating potentially the shortest path). The decision may also be based on a combination of factors. For example, if multiple requests have the same relay_indication value, it is possible to select the request associated with the greatest signal strength.

[0072] As mentioned before, if a potential relay forwards the Direct Communication Request, this relay can also add further information to the message, such as load information, QoS support, etc. The remote UE can then use that information to choose a communication path. For example, if two requests with the same relay_indication value are received, the remote UE 30 can choose the one with the lighter load.

[0073] In some embodiments, the remote UE 30 may be configured to always pick the path that receives the first copy of the request. In this case, Timer2 is not needed. Rather, the remote UE 30 directly picks the path of the first received request and drops any subsequent requests with the same Request ID that the remote UE 30 receives. Also, if the remote UE 30 policy is to always pick the path associated with the least number of hops from the requesting UE 30, the remote UE 30 may directly pick the request received by the requesting UE 30. In this case, the remote UE 30 may stop Timer2 and ignore subsequent requests with the same Request ID. In another example, when the remote UE 30 (i.e., UE-2) receives a Direct Communication Request from the requesting UE 30 (e.g., UE-1) that means a good direct link is available between UE-1 and UE-2, UE-2 may accept the request and stop Timer2, but will not process other requests forwarded from the relaying UE 30.

[0074] In some embodiments, the remote UE 30 may be configured to select one or more communication paths for the same connection. In this case, the remote UE 30 may reply to multiple Direct Communication Requests, which are selected according to policy in the same manner as if it were replying to only one request (i.e., replying to the first two received requests). In this case, the requesting UE 30 may be configured to use multiple communication paths once more than one path is selected by the remote UE 30. Alternatively, the requesting UE 30 may be optionally configured to select a single communication path (or fewer than all of the indicated communication paths) from the set of communication paths indicated by the remote UE 30.

[0075] In the example shown in FIG. 8A, it is assumed that UE-2 wants to set up a multilink connection. Thus, in step 4, UE-2 responds to the Direct Communication Request received directly from UE-1 and via Relay-1 by sending a Request Accept message on the direct communication path and via Relay-1. When Timer1 expires, UE-1 determines which communication path to use for D2D communication with UE-2. In this example, it is assumed that both responses are received before the expiration of Timer1. In some embodiments, the requesting UE 30 can be configured to always use multiple communication paths for communication with the remote UE 30 if the remote UE 30 has selected multiple paths. In other embodiments, the requesting UE 30 can be configured to select which of the multiple communication paths indicated by the remote UE 30 to use for D2D communication with the remote UE 30. In step 5, UE-1 and UE-2 engage in unicast communication using the selected path or paths.

[0076] In some embodiments, the path selection is performed by the requesting UE 30. In this embodiment, UE-1 starts Timer1 when broadcasting the Direct Communication Request and waits for a response. When Timer1 expires, UE-1 determines which communication path to use for communication with UE-2 based on any Request Accept message received prior to the timer expiry. In the example shown in FIG. 8A, UE-2 responds to the Direct Communication Request received directly from UE-1 in step 4 and the Direct Communication Request received via Relay-1. UE-1 receives both responses, one directly from UE-2 and the other via Relay-1, prior to the expiry of Timer1. The requesting UE 30 can select the communication path based on factors such as signal strength, load on the relay (added to the Request Accept message by the relay), QoS support by the relay (added to the Request Accept message by the relay), local policy (e.g., provided by application or chipset design) or operator policy (pre-configured or provided via network signaling). Examples of selection criteria include, for example, selecting the communication path associated with the greatest signal strength, selecting the communication path with the lightest load on the relay, and selecting a direct path if available. The decision may also be based on a combination of factors. For example, the requesting UE 30 may be configured to select a direct path if it meets a minimum signal quality criterion, or to select the most lightly loaded relay that meets a minimum signal quality criterion.

[0077] In some embodiments, the requesting UE 30 may be configured to always choose the path on which it receives the first Request Accept message. In this case, the requesting UE 30 may stop Timer1 and ignore any subsequent Request Accept messages received after the first message. In another example, when the requesting UE 30 (i.e., UE-2) receives a Direct Communication Request from a remote UE 30 (e.g., UE-1) that indicates a good direct link is available between UE-1 and UE-2, UE-1 may immediately select a direct communication path without waiting for Timer1 to expire and stop Timer1. In step 5, UE-1 and UE-2 engage in unicast communication using the selected path or paths.

[0078] In some embodiments, if the remote UE 30 indicates that multiple paths are available for communication, the path selection may be performed partly by the remote UE 30 and partly by the requesting UE 30. In this case, the remote UE 30 is configured to select one or more preferred paths. If the requesting UE 30 receives multiple Request Accept messages in response to the Direct Communication Request, the requesting UE 30 has the option to select from the available communication paths indicated by the remote UE 30. The requesting UE 30 may select all of the communication paths indicated by the remote UE 30, or some number less than all of the communication paths. In step 5, UE-1 and UE-2 engage in unicast communication using the selected path or paths.

[0079] Referring to Figure 8B, in this example, assume that Relay-1, Relay-2 and UE-2 are directly reachable from UE-1 (requesting UE 30). Relay-1 and Relay-2 want to forward a Direct Communication Request from UE-1. UE-2 (remote UE 30) is also reachable from Relay-1 and Relay-2.

[0080] In step 0, the UE 30 is authorised to use the services provided by the UE-to-UE relay. The UE-to-UE relay is authorised to provide the service of relaying traffic between UEs 30. Authorisation can take place once the UE / relay has registered with the network. Security related parameters may be provisioned, if required, to allow the UE 30 and the relay to verify the authorisation to each other.

[0081] In step 1, UE-1 wants to establish unicast communication with UE-2, which can be either through a direct link with UE-2 or via a UE-to-UE relay. UE-1 broadcasts a Direct Communication Request with relay_indication set to "enabled". The Direct Communication Request may also include a request identifier (ID). The Direct Communication Request is received by Relay-1 and Relay-2. The Direct Communication Request may also be received by UE-2 if UE-2 is in the vicinity of UE-1.

[0082] In step 2, Relay-1 and Relay-2 decide to forward / broadcast the Direct Communication Request from UE-1. Both Relay-1 and Relay-2 broadcast the same Direct Communication Request to neighboring UEs 30 without any relay_indication. If another relay receives this message, it will just drop it. For example, when Relay-2 receives the rebroadcast message from Relay-1, it will recognize the request ID as matching the previously forwarded request and will drop the message. When a relay forwards a Direct Communication Request, it will include its own Relay ID or Relay UE information in the message.

[0083] In step 3, UE-2 receives copies of the Direct Communication Request from Relay-1 and Relay-2.

[0084] In step 4, UE-2 chooses Relay-1 and replies with a Request Accept message via Relay-1. When Relay-1 forwards the Request Accept message, it includes its own Relay ID or Relay UE information in the message. If UE-2 receives a Direct Communication Request directly from UE-1, UE-2 may choose to set up a direct communication link by sending a Request Accept directly to UE-1.

[0085] In step 5, UE-1 receives a Request Accept from Relay-1. UE-1 chooses a route according to policy (e.g., always choose a direct route if possible), signal strength, etc. If UE-1 receives a Request Accept directly from UE-2, UE-1 may choose to set up a direct L2 link as described in clause 6.3.3 of TS 23.287. In this case, step 6 is skipped.

[0086] In step 6, UE-1 and UE-2 set up a communication link through the selected UE-to-UE relay. The link setup information may vary depending on the type of relay, e.g., L2 relay or L3 relay.

[0087] Referring to Figure 8C, assume that Relay-1, Relay-2 and UE-2 are directly reachable from UE-1 (requesting UE 30). Relay-1 and Relay-2 all want to forward the Direct Communication Request from UE-1. UE-2 (remote UE 30) is also reachable from Relay-1 and Relay-2.

[0088] In step 0, the UE 30 is authorised to use the services provided by the UE-to-UE relay. The UE-to-UE relay is authorised to provide the service of relaying traffic between UEs 30. Authorisation can take place once the UE / relay is registered with the network. Security related parameters may be provisioned, if required, to allow the UE 30 and the relay to verify authorisation to each other.

[0089] In step 1, UE-1 wants to establish unicast communication with UE-2, which can be either through a direct link with UE-2 or via a UE-to-UE relay. UE-1 broadcasts a Solicitation message with relay_indication set to "enabled". The Solicitation message may also include a request identifier (ID). The Solicitation message is received by Relay-1 and Relay-2. The Solicitation message includes UE-2 ID or UE-2's Application User Info, UE-1 ID or UE-1's Application User Info. The message may also be received by UE-2 if UE-2 is in the vicinity of UE-1.

[0090] In step 2, Relay-1 and Relay-2 decide to forward / broadcast the Solicitation message from UE-1. Both Relay-1 and Relay-2 broadcast the Solicitation message to neighboring UEs 30 without a relay_indication. If another relay receives this message, it will simply be dropped. When a relay forwards a Solicitation message, it will include its own Relay ID or Relay UE information in the message.

[0091] In step 3, UE-2 receives copies of the Solicitation message from Relay-1 and Relay-2.

[0092] In step 4, UE-2 chooses Relay-1 and replies with a Response message via Relay-1. When Relay-1 forwards the Response message, it includes its own Relay ID or Relay UE information in the message. If UE-2 receives the Solicitation message directly from UE-1, UE-2 may choose to set up a direct communication link by sending a Response message directly to UE-1.

[0093] In step 5, UE-1 receives a Request Accept from Relay-1. UE-1 chooses a route according to policy (e.g., always choose a direct route if possible), signal strength, etc. If UE-1 receives a Request Accept directly from UE-2, UE-1 may choose to set up a direct L2 link as described in clause 6.3.3 of TS 23.287. In this case, step 6 is skipped.

[0094] In step 6, UE-1 and UE-2 set up a communication link through the selected UE-to-UE relay. The link setup information may vary depending on the type of relay, e.g., L2 relay or L3 relay.

[0095] 8A-8C, the requesting UE 30 may set up a timer after sending a Direct Communication Request (or Solicitation message) to collect corresponding Request Accept (or Response) messages before making a decision. Similarly, the target UE 30 may also set up a timer after receiving a first copy of a Direct Communication Request (or Solicitation message) to collect multiple copies of the message from different routes before making a decision.

[0096] When the requesting UE 30 receives a message from the UE-to-UE relay for the first time, the requesting UE 30 may need to verify whether the relay UE 30 is authorized as a UE-to-UE relay. Similarly, the UE-to-UE relay may also need to verify whether the requesting UE 30 is authorized to use the relay service. The details of the verification and how the communication between two UEs 30 is secured through the UE-to-UE relay may be specified by the standard.

[0097] FIG. 9 is a diagram of a procedure for unicast link establishment to a remote UE 30 with relay discovery. Each relay maintains a list of neighboring UEs 30 reachable from the relay and periodically broadcasts an announcement to indicate its availability for relaying communications (step 0). The announcement includes an indication of other UEs 30 that the relay UE 30 can reach (e.g., reachable neighbor list). When a neighboring UE 30 within the reachability range of the relay UE 30 receives the broadcast announcement, the relay UE 30 can decide whether it wants to use the relay UE 30 to relay D2D communications. If it wants to use the relay UE 30 to relay D2D communications, the recipient UE 30 stores a copy of the reachable neighbor list for the relay UE 30 in its local memory and sends a relay request to the relay UE 30. Upon receiving the relay request, the relay UE 30 adds the requesting UE 30 to its reachable neighbors and sends the updated list in the next broadcast discovery message. When a requesting UE 30 wants to communicate with a remote UE 30, the requesting UE 30 can select a relay UE 30 that can reach the remote UE 30 before sending a Direct Communication Request. In this respect, selecting a relay UE 30 is equivalent to selecting a path, since the selected relay UE 30 is the first hop in the selected communication path.

[0098] In the example shown in FIG. 9, it is assumed that UE-1 cannot directly communicate with UE-2. Relay-1 and Relay-2 are reachable to both UE-1 and UE-2. In step 0, Relay-1 and Relay-2 broadcast announcements indicating their availability to relay communication. When UE-1 receives the broadcasted messages from Relay-1 and Relay-2, UE-1 decides to use both relay UEs 30 for D2D communication. In step 1, UE-1 sends a relay request to Relay-1 and Relay-2. When Relay-1 and Relay-2 receive a response from UE-1, they add UE-1 to their reachable neighbor list and send the updated list in the next broadcast discovery. In the same way, UE-2 receives an announcement from Relay-2 and decides to use Relay-2. In step 2, UE-2 sends a relay request to Relay-2. When Relay-2 receives a response from UE-2, it adds UE-1 and UE-2 to its reachable neighbor list and sends the updated list in the next broadcast discovery message. Each time an announcement is broadcast, UEs 30 that are neighbors of Relay-1 and Relay-2 update their local copies of the reachable list for Relay-2 if it has changed since the last broadcast.

[0099] When a requesting UE 30 needs to send a communication to a remote UE 30, the requesting UE 30 selects a communication path based on its local copy of the neighbor list stored in memory. Additional memory may be further stored of relay signal strength (determined by measuring the broadcast announcement), relay load (included in the announcement), QoS support provided by the relay (included in the announcement), etc. Since there may be more than one communication path available, the requesting UE 30 selects a communication path based on factors such as signal strength, relay load (included in the announcement message), QoS supported by the relay (included in the announcement message), local policy (e.g. provided by application or chipset design) or operator policy (pre-configured or provided via network signaling), as previously described. In the example shown in FIG. 9, UE-1 selects Relay-2 and in step 3 sends a Direct Communication Request to Relay-2. Relay-2 forwards the Direct Communication Request to the remote UE 30. In step 4, the remote UE 30 sends a Request Accept message via Relay-2 to the requesting UE 30. Then, UE-1 and UE-2 establish a unicast communication link via Relay-2 and start communicating.

[0100] The Relay Request or Direct Communication Request can be sent directly after receiving the broadcast message from the relay or can be sent later. The relay UE 30 can include and add a validity_timer parameter in the broadcast announcement message, which indicates how long the relay UE 30 is willing to accept the response. When sending the broadcast announcement message, the relay UE 30 starts a validity_timer and processes the response until the expiration of this timer. When the UE 30 receives the announcement message from the relay UE 30, it starts the validity_timer associated with that relay. If the UE 30 subsequently needs to establish a link with a UE 30 reachable via this relay, the UE 30 can send a request message to the relay if the validity_timer has not expired.

[0101] FIG. 10 illustrates an example method 100 implemented by a requesting UE 30 for D2D communication. The requesting UE 30 broadcasts a request (e.g., a Direct Communication Request or Solicitation message) to initiate communication with a remote UE 30 to one or more neighboring UEs 30 (block 110). The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. In some embodiments, the relay indication may further indicate a maximum number of relays or a maximum number of hops for the communication path. The requesting UE 30 further receives a response message (e.g., a Request Accept or Solicitation Response message) from one or more of the neighboring UEs 30 in response to the request (block 120). The requesting UE 30 determines a communication path for D2D communication between the requesting UE and the remote UE based on the one or more response messages (block 130).

[0102] In some embodiments of the method 100, the communication path is selected by the remote UE 30. The requesting UE 30 receives a single response message from a neighboring UE 30 and determines the communication path based on the identity of the neighboring UE 30 from which the response message was received.

[0103] In some embodiments of the method 100, the requesting UE 30 receives a single response message from a neighboring UE 30 serving as a relay, and the determined communication path includes two or more hops from the requesting UE 30 to the responding UE 30.

[0104] In some embodiments of the method 100 , the requesting UE 30 receives a single response message directly from the remote UE 30 , and the determined communication path is the path between the requesting UE 30 and the remote UE 30 .

[0105] In some embodiments of the method 100 , the requesting UE 30 receives a response message from each of one or more neighboring UEs 30 and selects a communication path based on the one or more response messages received by the requesting UE 30 .

[0106] In some embodiments of the method 100 , when the UE 30 receives a direct response message from a remote UE 30 , the UE 30 selects a route from the requesting UE 30 to the remote UE 30 .

[0107] In some embodiments of the method 100, the requesting UE 30 selects the communication path based on the path selection information included in the one or more response messages.

[0108] In some embodiments of the method 100, the routing information includes at least one of channel quality information, load information, or device capability information.

[0109] In some embodiments of the method 100, the requesting UE 30 determines the communication path based on one or more of the response messages received a predetermined time before broadcasting the request.

[0110] Some embodiments of the method 10 further include communicating with the remote UE 30 using the determined communication path.

[0111] In some embodiments of the method 100, the request message includes a Direct Communication Request and the response message includes a Request Accept message.

[0112] In some embodiments of the method 100, the request message comprises a Solicitation message and the reply message comprises a Response message.

[0113] 11 illustrates an example method 150 implemented by a relay UE 30 for relaying D2D communication between a requesting UE 30 and a remote UE 30. The relay UE 30 receives a request (e.g., a Direct Communication Request or Solicitation message) broadcast by the requesting UE to initiate communication with the remote UE 30 (block 160). The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. In some embodiments, the relay indication may further indicate a maximum number of relays or a maximum number of hops for the communication path. The relay UE 30 further forwards the request towards the remote UE (block 170).

[0114] In some embodiments of the method 150, forwarding the request towards the remote UE 30 includes forwarding the request according to a value of the relay indication.

[0115] In some embodiments of the method 150, forwarding the request towards the remote UE 30 is further responsive to at least one of a Quality of Service (QoS) requirement for the request, a load on the UE 30, or a channel quality of a communication link between the UE 30 and the requesting UE 30.

[0116] In some embodiments of the method 150, the UE 30 forwards the request when the value of the relay indication is greater than a predetermined value.

[0117] Some embodiments of the method 150 further include discarding the request when the relay indication is equal to a predetermined value.

[0118] Some embodiments of the method 150 further include decrementing a value of a relay indication in the request by a predetermined amount prior to forwarding the request.

[0119] Some embodiments of the method 150 further include relaying the D2D communication between the requesting UE 30 and a remote UE 30, where the remote UE 30 uses the determined communication path.

[0120] In some embodiments of the method 150, the request message includes a Direct Communication Request and the response message includes a Request Accept message.

[0121] In some embodiments of the method 150, the request message comprises a Solicitation message and the reply message comprises a Response message.

[0122] FIG. 12 illustrates an example method 200 implemented by a remote UE 30 for D2D communication. The remote UE 30 receives one or more replicas of a request (e.g., a Direct Communication Request or Solicitation message) broadcast by a requesting UE 30 to initiate communication with the remote UE 30 (block 210). The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE 30 and the remote UE 30. In some embodiments, the relay indication may further indicate a maximum number of relays or a maximum number of hops for the communication path. In response to each of the one or more replicas of the request, the remote UE 30 further transmits a response message (e.g., a Request Accept or Solicitation Response message) to the requesting UE 30 along the communication path along which the request was received (block 220).

[0123] Some embodiments of the method 200 further include selecting a communication path for the D2D communication between the requesting UE 30 and the remote UE 30.

[0124] In some embodiments of method 200, transmitting a response message in response to each of the one or more replicas of the request includes transmitting a single response message along the selected communication path.

[0125] Some embodiments of method 200 further include receiving multiple copies of the request along respective communication paths between the requesting UE 30 and the remote UE 30, and sending a response message in response to each of the one or more copies of the request includes sending the multiple response messages to the UE 30 along respective paths of the communication paths.

[0126] In some embodiments of the method 200, the reply message is sent in response to a request received within a predetermined time window.

[0127] Some embodiments of the method 200 further include communicating with the remote UE 30 using one of the communication paths selected by the requesting UE 30 or the remote UE 30.

[0128] In some embodiments of the method 200, the request message includes a Direct Communication Request and the response message includes a Request Accept message.

[0129] In some embodiments of the method 200, the request message comprises a Solicitation message and the reply message comprises a Response message.

[0130] FIG. 13 illustrates an example method 250 implemented by a requesting UE 30 configured for D2D communication. The requesting UE 30 receives an announcement broadcast by one or more relay UEs 30 (block 260). Each announcement includes a neighbor list identifying one or more potential remote UEs reachable from the relay UE 30. The requesting UE 30 further transmits a request (e.g., a Direct Communication Request or a Solicitation message) to a selected relay UE 30 that has the remote UE 30 in its neighbor list (block 270). The request includes identification information for identifying the targeted remote UE 30. In response to the request, the requesting UE 30 further receives a response message (e.g., a Request Accept message or a Solicitation Response message) from the remote UE relayed by the relay UE 30 (block 280).

[0131] In some embodiments of method 250, sending a request to one of the neighboring UEs having the remote UE 30 in its neighbor list includes selecting a communication path from the requesting UE 30 to the remote UE 30, the communication path including one of the neighboring UEs, and sending the request to the neighboring UE 30 over the selected communication path.

[0132] In some embodiments of method 250, selecting a communication path from the requesting UE 30 to the remote UE 30 is based at least in part on one of channel quality information indicative of channel quality between the UE 30 and the neighboring UEs, load information for the neighboring UEs, or device capability information for the neighboring UEs.

[0133] In some embodiments of the method 250, one or more of the announcements include a time parameter indicating a period during which nearby UEs 30 will accept the request.

[0134] In some embodiments of the method 250, transmitting the request to one of the neighboring UEs includes transmitting the request at an indicated time period.

[0135] Some embodiments of the method 250 further include communicating with the remote UE 30 using the determined communication path.

[0136] FIG. 14 illustrates an example method 300 implemented by a relay UE 30 for relaying D2D communication between a requesting UE 30 and a remote UE 30. The relay UE 30 broadcasts an announcement to one or more neighboring UEs 30 (block 310). The announcement includes a neighbor list that identifies one or more potential remote UEs 30 that are reachable from the relay UE 30. The announcement may be broadcast periodically. In some embodiments, the relay UE 30 receives a relay request from one or more neighboring UEs 30 requesting the relay UE 30 to serve as a UE-to-UE relay (block 320). The relay UE 300 adds these neighboring UEs 30 to its neighbor list and broadcasts the updated list at the next broadcast interval. The relay UE 30 further receives a request (e.g., a Direct Communication Request or Solicitation message) from a requesting UE to initiate D2D communication with a remote UE 30 in the neighbor list (block 330). The request includes identification information for identifying the targeted remote UE 30. The relay UE 30 further forwards the request towards the remote UE identified by the request (block 340).

[0137] Some embodiments of the method 300 further include receiving one or more relay requests from different ones of the neighboring UEs in response to the announcement, and adding the neighboring UE 30 that sent the relay request to a neighbor list for subsequent announcements.

[0138] In some embodiments of the method 300, forwarding the request towards the remote UE 30 includes forwarding the received request a predetermined period of time following the announcement.

[0139] Some embodiments of the method 300 further include receiving a response message from the remote UE 30 in response to the request, and forwarding the response message to the requesting UE 30.

[0140] In some embodiments of the method 300, the announcement includes a time parameter indicating a period for accepting a request from the requesting UE 30.

[0141] Some embodiments of the method 300 further include relaying the D2D communication between the requesting UE 30 and the remote UE 30.

[0142] FIG. 15 illustrates an example method 350 implemented by a remote UE 30 for D2D communication. The remote UE 30 receives the announcement broadcasted by the relay UE 30 (block 360). In response to the announcement, the remote UE 30 further transmits a relay request to the relay UE 30 requesting the relay UE 30 to serve as a relay for D2D communication (block 370). In some embodiments, the remote UE 30 may further receive a request (e.g., a Direct Communication Request or Solicitation message) originating from a requesting UE via the relay UE (block 380). In response to the request, the remote UE 30 further transmits a response message (e.g., a Request Accept message or a Solicitation Response message) to the requesting UE via the relay UE (block 390).

[0143] Some embodiments of the method 350 further include receiving a request originating from the requesting UE 30 via the relay UE 30, and sending a response message to the requesting UE 30 via the relay UE 30 in response to the request.

[0144] In some embodiments of the method 350, the announcement includes a time parameter indicating a period during which the relay UE 30 will accept requests to join the group.

[0145] In some embodiments of the method 350, transmitting the relay request includes transmitting the relay request at a time period indicated in the announcement.

[0146] Some embodiments of the method 350 further include communicating with the requesting UE 30 using one of the communication paths selected by the requesting UE 30 or the remote UE 30.

[0147] An apparatus may perform any of the methods described herein by implementing any functional means, module, unit, or circuitry. In one embodiment, for example, an apparatus includes individual circuits or circuitry configured to perform the steps illustrated in the method drawings. In this regard, the circuitry or circuitry may include specialized circuits and / or one or more microprocessors in conjunction with memory for performing specific functional operations. For example, the circuitry may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory, such as read-only memory (ROM), random access memory, cache memory, flash memory devices, optical storage devices, and the like. The program code stored in memory may include program instructions for performing one or more communication and / or data communication protocols, as well as instructions for performing one or more of the techniques described herein in some embodiments. In embodiments employing memory, the memory stores program code that, when executed by one or more processors, performs the techniques described herein.

[0148] 16A-16C illustrate example embodiments of a UE 400 configured for D2D communication. In each of the embodiments illustrated in FIG. 16A-16C, the UE 400 comprises an antenna array 405 including one or more antennas 410 for communicating with the base station 20 and other UEs 400. The UE 400 may be configured to function as a requesting UE, a relay UE, a remote UE, or any combination thereof.

[0149] FIG. 16A illustrates functional components of a requesting UE 400. The requesting UE 400 illustrated in FIG. 16A includes a broadcasting unit 415, a receiving unit 420, and a determining unit 425. The various units 415-425 may be implemented by one or more microprocessors, hardware circuits, firmware, or combinations thereof. The broadcasting unit 415 is configured to broadcast a request to initiate communication with a remote UE 30 (e.g., a Direct Communication Request or a Solicitation message) to one or more neighboring UEs 30. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. In some embodiments, the relay indication may further indicate a maximum number of relays or a maximum number of hops for the communication path. The receiving unit 420 is configured to receive a response message (e.g., a Request Accept message or a Solicitation Response message) from one or more of the neighboring UEs 30 in response to the request. The determining unit 425 is configured to determine a communication path for D2D communication between the requesting UE and the remote UE based on the one or more response messages.

[0150] FIG. 16B illustrates functional components of the relay UE 400. The relay UE 400 illustrated in FIG. 16B further includes a receiving unit 430 and a forwarding unit 435. The various units 430-435 may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The receiving unit 430 is configured to receive a request (e.g., a Direct Communication Request or Solicitation message) broadcasted by a requesting UE to initiate communication with the remote UE 30. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. In some embodiments, the relay indication may further indicate a maximum number of relays or a maximum number of hops for the communication path. The forwarding unit 435 is configured to forward the request toward the remote UE.

[0151] FIG. 16C illustrates functional components of the remote UE 400. The remote UE 400 illustrated in FIG. 16C further includes a receiving unit 445 and a transmitting unit 450. The various units 445-450 may be implemented by one or more microprocessors, hardware circuits, firmware, or combinations thereof. The receiving unit 445 is configured to receive one or more copies of a request (e.g., a Direct Communication Request or Solicitation message) broadcast by a requesting UE to initiate communication with the remote UE 30. The request includes a relay indication indicating whether relaying is allowed for a communication path between the requesting UE 30 and the remote UE 30. In some embodiments, the relay indication may further indicate a maximum number of relays or a maximum number of hops for the communication path. The transmitting unit 450 is configured to further transmit a response message (e.g., a Request Accept or Solicitation Response message) to the requesting UE in response to each of the one or more copies of the request along the communication path along which the request was received.

[0152] 17A-17C illustrate example embodiments of a UE 500 configured for D2D communication. In each of the embodiments illustrated in Figures 17A-17C, the UE 500 comprises an antenna array 505 including one or more antennas 510 for communicating with the base station 20. The UE 500 may be configured to function as a requesting UE, a relay UE, a remote UE, or any combination thereof.

[0153] FIG. 17A illustrates functional components of a requesting UE 500. The requesting UE 500 illustrated in FIG. 17A further comprises a first receiving unit 515, a transmitting unit 520, and a second receiving unit 525. The various units 515-525 may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The first receiving unit 515 is configured to receive announcements broadcasted by one or more relaying UEs 30. Each announcement includes a neighbor list identifying one or more potential remote UEs reachable from the relaying UE 30. The transmitting unit 520 is configured to transmit a request (e.g., a Direct Communication Request or Solicitation message) to a selected relaying UE 30 among the relaying UEs 30 having the remote UE 30 in its neighbor list, the request including identifying information (e.g., a UE ID) for identifying the targeted remote UE. The second receiving unit 525 is configured to receive a response message (eg, a Request Accept message or a Solicitation Response message) from the remote UE 30 relayed by the relay UE 30 in response to the request.

[0154] FIG. 17B illustrates functional components of the relay UE 500. The relay UE 500 illustrated in FIG. 17B further comprises a broadcast unit 530, a neighbor list unit 535, a second receiving unit 540, and a forwarding unit 545. The various units 530-545 may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The broadcast unit 530 is configured to broadcast an announcement to one or more neighboring UEs 30. The announcement includes a neighbor list that identifies one or more potential remote UEs 30 that are reachable from the relay UE 30. The announcement may be broadcast periodically. In an embodiment including the neighbor list unit 535, the relay UE 30 receives relay requests from one or more neighboring UEs 30 requesting the relay UE 30 to serve as a UE-to-UE relay, and adds these neighboring UEs 30 to its neighbor list (block 320). The broadcast 530 broadcasts the updated list at the next broadcast interval. The receiving unit 540 is configured to receive a request (e.g., a Direct Communication Request or a Solicitation message) from a requesting UE to initiate D2D communication with a remote UE in the neighbor list. The request includes identification information (e.g., a UE ID) for identifying a target remote UE 30. The forwarding unit 545 is configured to forward the request to the remote UE 30 identified by the request.

[0155] FIG. 17C illustrates functional components of the remote UE 500. The relay UE 500 illustrated in FIG. 17C further comprises a first receiving unit 550, a first transmitting unit 555, a second receiving unit 560, and a second transmitting unit 565. The various units 550-565 may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The first receiving unit 550 is configured to receive an announcement broadcasted by the relay UE 30. The first transmitting unit 555 is configured to transmit a relay request to the relay UE 30 in response to the announcement, requesting the relay UE 30 to serve as a relay for D2D communication. The second receiving unit 560 is configured to receive a request (e.g., a Direct Communication Request or Solicitation message) originating from the requesting UE 30 via the relay UE 30. The second sending unit 565 is configured to send a response message (eg, a Request Accept message or a Solicitation Response message) to the requesting UE 30 via the relay UE 30 in response to the request.

[0156] 18 illustrates a UE 600 according to another embodiment. The UE 600 includes an antenna array 610 having one or more antennas 615, communication circuitry 620, processing circuitry 660, and memory 640.

[0157] The communications circuitry 620 is coupled to the antenna 610 and includes the necessary radio frequency (RF) circuitry (e.g., a transmitter (Tx) 630 and a receiver (Rx) 640) for transmitting and receiving signals over a wireless communications channel. The processing circuitry 650 controls the overall operation of the UE 600 according to program instructions stored in memory 660. The processing circuitry 650 may include one or more microprocessors, hardware, firmware, or a combination thereof.

[0158] The memory 660 includes both volatile and non-volatile memory for storing computer program code and data required for operation by the processing circuit 650. The memory 660 may include any tangible, non-transitory computer-readable storage medium for storing data, including electronic, magnetic, optical, electromagnetic, or semiconductor data storage devices. The memory 660 stores a computer program 670 including executable instructions that configure the processing circuit 650 to implement one or more of the methods 100, 150, 200, 250, 300, 350 according to Figs. 10-15, respectively, as described herein. In this respect, the computer program 670 may include one or more code modules corresponding to the above-mentioned means or units. In general, computer program instructions and configuration information are stored in a non-volatile memory, such as a ROM, an erasable programmable read-only memory (EPROM) or a flash memory. Transient data generated during operation may be stored in a volatile memory, such as a random access memory (RAM). In some embodiments, the computer program 650 for configuring the processing circuit 650 as described herein may be stored on a removable memory, such as a portable compact disc, a portable digital video disc, or other removable medium. The computer program 670 may also be embodied as a carrier, such as an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0159] Those skilled in the art will appreciate that the embodiments herein further include corresponding computer programs, which, when executed by at least one processor of the device, cause the device to perform any of the individual operations described above. In this respect, the computer program may include one or more code modules corresponding to the means or units described above.

[0160] Embodiments further include a carrier containing such a computer program, which may include one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0161] In this regard, embodiments herein also include a computer program product comprising instructions stored on a non-transitory computer-readable (storage or recording) medium and which, when executed by a processor of the device, causes the device to operate as described above.

[0162] The embodiments further include a computer program product including program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device. The computer program product may be stored on a computer-readable recording medium.

[0163] Additional embodiments are now described, at least some of which may be described, for illustrative purposes, as being applicable to particular contexts and / or wireless network types, although the embodiments are likewise applicable to other contexts and / or wireless network types not expressly described.

[0164] Various embodiments of the present disclosure are described in the enumerated embodiments below. The embodiments are divided into two groups, denoted as Group1 and Group. The dependency relationship in the listed embodiments refers to the preceding embodiment in the same group.

[0165] Group1 - Unicast link establishment without relay discovery 1. A method implemented by a requesting user equipment (UE) for device-to-device (D2D) communication, the method comprising: broadcasting a direct communication request to one or more neighboring UEs to initiate communication with the remote UE, the direct communication request including a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE; receiving a request accept message from one or more of the neighboring UEs in response to the direct communication request; determining a communication path for D2D communication between the requesting UE and the remote UE based on the one or more request accept messages; A method comprising:

[0166] 2. A communication path is selected by the remote UE, and the requesting UE: receiving a single request accept message from a neighboring UE; 2. The method of embodiment 1, wherein the communication path is determined based on the identification information of the neighboring UE from which the request accept message is received.

[0167] 3. The method of embodiment 2, in which the requesting UE receives a single request accept message from a neighboring UE serving as a relay, and the determined communication path includes two or more hops from the requesting UE to the responding UE.

[0168] 4. The method of embodiment 2, in which the requesting UE receives a single request accept message directly from the remote UE, and the determined communication path is a direct communication path between the requesting UE and the remote UE.

[0169] 5. The requesting UE: receiving a request accept message from each of the one or more neighboring UEs; 2. The method of embodiment 1, selecting a communication path based on one or more request accept messages received by a requesting UE.

[0170] 6. The method of embodiment 5, wherein when the UE receives a request accept message directly from the remote UE, the UE selects a direct communication path from the requesting UE to the remote UE.

[0171] 7. The method of embodiment 5, in which the requesting UE selects the communication path based on the path selection information included in the one or more request accept messages.

[0172] 8. The method of embodiment 7, wherein the route selection information includes at least one of channel quality information, load information, or device capability information.

[0173] 9. The method of any one of embodiments 1 to 8, wherein the requesting UE determines the communication path based on one or more of the request acceptance messages received before a predetermined time after broadcasting the direct communication request.

[0174] 10. The method of any one of embodiments 1 to 9, further comprising communicating with a remote UE using the determined communication path.

[0175] 11. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: communication circuitry for communicating with one or more neighboring UEs over a sidelink; a processing circuit operably connected to the communications network, broadcasting a direct communication request to one or more neighboring UEs, the direct communication request including a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and a remote UE; receiving a request accept message from one or more of the neighboring UEs in response to the direct communication request; determining a communication path for D2D communication between the requesting UE and the remote UE based on the one or more request accept messages; a processing circuit configured to A user equipment (UE).

[0176] 12. The UE of embodiment 11, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 2 to 10.

[0177] 13. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: broadcasting a direct communication request to one or more neighboring UEs, the direct communication request including a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and a remote UE; receiving a request accept message from one or more of the neighboring UEs in response to the direct communication request; determining a communication path for D2D communication between the requesting UE and the remote UE based on the one or more request accept messages; A user equipment (UE) configured to perform the above.

[0178] 14. The UE of embodiment 13, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 2 to 10.

[0179] 15. A computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 1 to 10.

[0180] 16. A carrier comprising a computer program as described in embodiment 15, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0181] 17. A non-transitory computer-readable storage medium including a computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 1 to 10.

[0182] 18. A method implemented by a user equipment (UE) for relaying device-to-device (D2D) communications, the method comprising: receiving a direct communication request broadcast by a requesting UE to initiate communication with a remote UE, the direct communication request including a relay indication indicating whether relay is allowed for a communication path between the requesting UE and the remote UE; forwarding the direct communication request towards the remote UE; A method comprising:

[0183] 19. The method of embodiment 18, wherein forwarding the direct communication request towards the remote UE includes forwarding the direct communication request according to a value of the relay indication.

[0184] 20. The method of any one of embodiments 19, 20, and 22, wherein forwarding the direct communication request towards the remote UE is further responsive to at least one of a Quality of Service (QoS) requirement for the direct communication request, a load of the UE, or a channel quality of a communication link between the UE and the requesting UE.

[0185] 21. The method of embodiment 19 or 20, wherein the UE forwards the communication request directly when the value of the relay indication is greater than a predetermined value.

[0186] 22. The method of any one of embodiments 19 to 21, further comprising discarding the direct communication request when the relay indication is equal to a predetermined value.

[0187] 23. The method of any one of embodiments 19 to 21, further comprising decrementing a value of a relay indication in the direct communication request by a predetermined amount prior to forwarding the direct communication request.

[0188] 24. The method of any one of embodiments 18 to 23, further comprising relaying D2D communication between the requesting UE and the remote UE, wherein the remote UE uses the determined communication path.

[0189] 25. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: communication circuitry for communicating with one or more neighboring UEs over a sidelink; a processing circuit operably connected to the communications network, receiving a direct communication request broadcast by a requesting UE to initiate communication with a remote UE, the direct communication request including a relay indication indicating whether relay is allowed for a communication path between the requesting UE and the remote UE; forwarding the direct communication request towards the remote UE; a processing circuit configured to A user equipment (UE).

[0190] 26. The UE of embodiment 25, wherein the processing circuitry is further configured to execute a method according to any one of embodiments 19 to 24.

[0191] 27. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: receiving a direct communication request broadcast by a requesting UE to initiate communication with a remote UE, the direct communication request including a relay indication indicating whether relay is allowed for a communication path between the requesting UE and the remote UE; forwarding the direct communication request towards the remote UE; A user equipment (UE) configured to perform the above.

[0192] 28. The UE of embodiment 27, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 19 to 24.

[0193] 29. A computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform the method of any one of embodiments 18 to 24.

[0194] 30. A carrier comprising a computer program according to embodiment 29, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0195] 31. A non-transitory computer-readable storage medium including a computer program, the computer program including executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 18 to 24.

[0196] 32. A method implemented by a remote user equipment (UE) of device-to-device (D2D) communication, the method comprising: receiving one or more copies of a direct communication request broadcast by a requesting UE to initiate communication with a remote UE, the direct communication request including a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE; sending a request accept message to the requesting UE in response to each of the one or more copies of the direct communication request along the communication path along which the direct communication request was received; A method comprising:

[0197] 33. The method of embodiment 32, further comprising selecting a communication path for D2D communication between the requesting UE and the remote UE.

[0198] 34. The method of embodiment 33, wherein sending a request acceptance message in response to each of the one or more copies of the direct communication request includes sending a single request acceptance message along a selected communication path.

[0199] 35. Receiving multiple copies of a direct communication request along respective communication paths between a requesting UE and a remote UE. Further comprising: 34. The method of embodiment 33, wherein sending a request accept message in response to each of the one or more copies of the direct communication request includes sending multiple request accept messages to the UE along respective paths of the communication path.

[0200] 36. The method of any one of embodiments 32 to 35, wherein the request acceptance message is sent in response to a direct communication request received within a predetermined time window.

[0201] 37. The method of any one of embodiments 32 to 36, further comprising communicating with the remote UE using one of the communication paths selected by the requesting UE or the remote UE.

[0202] 38. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: communication circuitry for communicating with one or more neighboring UEs over a sidelink; a processing circuit operably connected to the communications network, receiving one or more copies of a direct communication request broadcast by a requesting UE to initiate communication with a remote UE, the direct communication request including a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE; sending a request accept message to the requesting UE in response to each of the one or more copies of the direct communication request along the communication path along which the direct communication request was received; a processing circuit configured to A user equipment (UE).

[0203] 39. The UE of embodiment 38, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 32 to 35.

[0204] 40. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: receiving one or more copies of a direct communication request broadcast by a requesting UE to initiate communication with a remote UE, the direct communication request including a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE; sending a request accept message to the requesting UE in response to each of the one or more copies of the direct communication request along the communication path along which the direct communication request was received; A user equipment (UE) configured to perform the above.

[0205] 41. The UE of embodiment 40, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 34 to 37.

[0206] 42. A computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 31 to 37.

[0207] 43. A carrier comprising a computer program according to embodiment 42, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0208] 44. A non-transitory computer-readable storage medium including a computer program, the computer program including executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 31 to 37.

[0209] Group2 - Unicast link establishment with relay discovery 1. A method implemented by an originating user equipment (UE) for device-to-device (D2D) communication, the method comprising: receiving announcements broadcast by one or more relay UEs, each announcement including a neighbor list identifying one or more potential remote UEs reachable from the relay UE; sending a direct communication request to a selected relay UE among the relay UEs having the remote UE in its neighbor list, the direct communication request including identification information for identifying a target remote UE; receiving a request accept message from a remote UE relayed by the relay UE in response to the direct communication request; A method comprising:

[0210] 2. Sending a direct communication request to one of the neighboring UEs that has the remote UE in its neighbor list; selecting a communication path from the requesting UE to a remote UE, the communication path including one of the neighboring UEs; sending a direct communication request to a neighboring UE on the selected communication path; 2. The method of embodiment 1, comprising:

[0211] 3. The method of embodiment 1 or 2, wherein selecting a communication path from the requesting UE to the remote UE is based at least in part on one of channel quality information indicating a channel quality between the UE and a neighboring UE, load information for the neighboring UE, or device capability information for the neighboring UE.

[0212] 4. A method as in any one of embodiments 1 to 3, wherein one or more of the announcements includes a time parameter indicating a period during which neighboring UEs will accept direct communication requests.

[0213] 5. The method of embodiment 4, wherein sending a direct communication request to one of the neighboring UEs includes sending a direct communication request at an indicated time period.

[0214] 6. The method of any one of embodiments 1 to 5, further comprising communicating with a remote UE using the determined communication path.

[0215] 7. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: communication circuitry for communicating with one or more neighboring UEs over a sidelink; a processing circuit operably connected to the communications network, receiving announcements broadcast by one or more relay UEs, each announcement including a neighbor list identifying one or more potential remote UEs reachable from the relay UE; sending a direct communication request to a selected relay UE among the relay UEs having the remote UE in its neighbor list, the direct communication request including identification information for identifying a target remote UE; receiving a request accept message from a remote UE, which is relayed by the relay UE, in response to the direct communication request; a processing circuit configured to A user equipment (UE).

[0216] 8. The UE of embodiment 7, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 2 to 6.

[0217] 9. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: receiving announcements broadcast by one or more relay UEs, each announcement including a neighbor list identifying one or more potential remote UEs reachable from the relay UE; sending a direct communication request to a selected relay UE among the relay UEs having the remote UE in its neighbor list, the direct communication request including identification information for identifying a target remote UE; receiving a request accept message from a remote UE, which is relayed by the relay UE, in response to the direct communication request; A user equipment (UE) configured to perform the above.

[0218] 10. The UE of embodiment 9, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 2 to 6.

[0219] 11. A computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 1 to 6.

[0220] 12. A carrier comprising a computer program as described in embodiment 11, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0221] 13. A non-transitory computer-readable storage medium including a computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 1 to 6.

[0222] 14. A method implemented by a user equipment (UE) for relaying device-to-device (D2D) communications, the method comprising: broadcasting an announcement to one or more neighboring UEs, the announcement including a neighbor list identifying one or more potential remote UEs reachable from the UE; receiving a direct communication request from a requesting UE to initiate D2D communication with a target remote UE in a neighbor list, the direct communication request including identification information for identifying the target remote UE; forwarding the direct communication request to a remote UE identified by the direct communication request; A method comprising:

[0223] 15. receiving one or more relay requests from different ones of the neighboring UEs in response to the announcement; 15. The method of embodiment 14, further comprising: adding the neighboring UE that sent the relay request to a neighbor list for subsequent announcements.

[0224] 16. The method of embodiment 14 or 15, wherein forwarding the direct communication request toward the remote UE includes forwarding the received direct communication request a predetermined period of time following the announcement.

[0225] 17. receiving a request accept message from the remote UE in response to the direct communication request; forwarding a request accept message to the requesting UE; 17. The method of any one of embodiments 14 to 16, further comprising:

[0226] 18. A method as in any one of embodiments 14 to 17, wherein the announcement includes a time parameter indicating a period for accepting a direct communication request from the requesting UE.

[0227] 19. The method of any one of embodiments 14 to 18, further comprising relaying D2D communication between a requesting UE and a remote UE.

[0228] 20. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: communication circuitry for communicating with one or more neighboring UEs over a sidelink; a processing circuit operably connected to the communications network, broadcasting an announcement to one or more neighboring UEs, the announcement including a neighbor list identifying one or more potential remote UEs reachable from the UE; receiving a direct communication request from a requesting UE to initiate D2D communication with a remote UE in a neighbor list, the direct communication request including identification information for identifying a target remote UE; forwarding the direct communication request to a remote UE identified by the direct communication request; a processing circuit configured to A user equipment (UE).

[0229] 21. The UE of embodiment 25, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 15 to 19.

[0230] 22. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: broadcasting an announcement to one or more neighboring UEs, the announcement including a neighbor list identifying one or more potential remote UEs reachable from the UE; receiving a direct communication request from a requesting UE to initiate D2D communication with a remote UE in a neighbor list, the direct communication request including identification information for identifying a target remote UE; forwarding the direct communication request to a remote UE identified by the direct communication request; A user equipment (UE) configured to perform the above.

[0231] 23. The UE of embodiment 27, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 15 to 19.

[0232] 24. A computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform the method of any one of embodiments 14 to 19.

[0233] 25. A carrier comprising a computer program as described in embodiment 24, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0234] 26. A non-transitory computer-readable storage medium including a computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 14 to 19.

[0235] 27. A method implemented by a user equipment (UE) for device-to-device (D2D) communications, the method comprising: receiving an announcement broadcast by a relay UE; sending a relay request to the relay UE in response to the announcement, requesting the relay UE to serve as a relay for the D2D communication; A method comprising:

[0236] 28. receiving a direct communication request originating from a requesting UE via a relay UE; sending a request accept message to the requesting UE, via the relay UE, in response to the direct communication request; 28. The method of embodiment 27, further comprising:

[0237] 29. The method of embodiment 28, wherein the announcement includes a time parameter indicating a period during which the relay UE will accept requests to join the direct communication group.

[0238] 30. The method of embodiment 29, wherein transmitting the relay request includes transmitting the relay request at a period indicated in the announcement.

[0239] 31. The method of any one of embodiments 27 to 30, further comprising communicating with the requesting UE using one of the communication paths selected by the requesting UE or the remote UE.

[0240] 32. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: communication circuitry for communicating with one or more neighboring UEs over a sidelink; a processing circuit operably connected to the communications network, receiving an announcement broadcast by a relay UE; sending a relay request to the relay UE in response to the announcement, requesting the relay UE to serve as a relay for the D2D communication; a processing circuit configured to A user equipment (UE).

[0241] 33. The UE of embodiment 32, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 28 to 31.

[0242] 34. A user equipment (UE) capable of device-to-device (D2D) communication, the UE comprising: receiving an announcement broadcast by a relay UE; sending a relay request to the relay UE in response to the announcement, requesting the relay UE to serve as a relay for the D2D communication; A user equipment (UE) configured to perform the above.

[0243] 35. The UE of embodiment 34, wherein the processing circuitry is further configured to perform a method according to any one of embodiments 28 to 31.

[0244] 36. A computer program comprising executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform the method of any one of embodiments 27 to 31.

[0245] 37. A carrier comprising a computer program as described in embodiment 36, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0246] 38. A non-transitory computer-readable storage medium including a computer program, the computer program including executable instructions that, when executed by a processing circuit in a user equipment in a wireless communication network, cause the user equipment to perform a method according to any one of embodiments 27 to 31.

Claims

1. A method (100) implemented by a requesting user equipment (UE) (30, 400, 600) for device-to-device (D2D) communication, the method (100) comprising: broadcasting (110) a request to one or more neighboring UEs to initiate communication with a remote UE (30, 400, 600), the request including a relay indication indicating whether relaying is permitted for a communication path between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600); receiving (120) a response message from one or more of the neighboring UEs in response to the request; determining (130) a communication path for the D2D communication between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600) based on the one or more response messages; A method (100).

2. The communication path is selected by a remote UE (30, 400, 600), and the requesting UE (30, 400, 600) receiving a single response message from a neighboring UE (30, 400, 600); The method (100) of claim 1, further comprising determining the communication path based on an identity of the neighboring UE (30, 400, 600) from which the response message was received.

3. 3. The method (100) of claim 2, wherein the requesting UE (30, 400, 600) receives the single response message from a neighboring UE (30, 400, 600) serving as a relay, and the determined communication path includes two or more hops from the requesting UE (30, 400, 600) to the responding UE (30, 400, 600).

4. 3. The method (100) of claim 2, wherein the requesting UE (30, 400, 600) receives the single response message directly from the remote UE (30, 400, 600), and the determined communication path is a path between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600).

5. The requesting UE (30, 400, 600), receiving a response message from each of the one or more neighboring UEs; The method (100) of claim 1, further comprising selecting the communication path based on the one or more response messages received by the requesting UE (30, 400, 600).

6. 6. The method (100) of claim 5, wherein when the UE (30, 400, 600) receives a response message directly from the remote UE (30, 400, 600), the UE (30, 400, 600) selects a route from the requesting UE (30, 400, 600) to the remote UE (30, 400, 600).

7. The method (100) of claim 5, wherein the requesting UE (30, 400, 600) selects the communication path based on routing information included in the one or more response messages.

8. The method (100) of claim 7, wherein the routing information includes at least one of channel quality information, load information, or device capability information.

9. The method (100) according to any one of claims 1 to 8, wherein the requesting UE (30, 400, 600) determines the communication path based on one or more of the response messages received a predetermined time before broadcasting the request.

10. The method (100) of any one of claims 1 to 9, further comprising communicating with the remote UE (30, 400, 600) using the determined communication path.

11. The method (100) of any one of claims 1 to 10, wherein the request message comprises a Direct Communication Request.

12. The method (100) of any one of claims 1 to 10, wherein the request message comprises a Solicitation message.

13. A user equipment (UE) (30, 400, 600) capable of D2D (device-to-device) communication, wherein the UE (30, 400, 600) broadcasting a request to one or more neighboring UEs, the request including a relay indication indicating whether relaying is allowed for a communication path between the requesting UE (30, 400, 600) and a remote UE (30, 400, 600); receiving a response message from one or more of the neighboring UEs in response to the request; determining a communication path for the D2D communication between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600) based on the one or more response messages; A user equipment (UE) (30, 400, 600) configured to perform the steps of:

14. The UE (30, 400, 600) of claim 13, further configured to perform the method according to any one of claims 2 to 12.

15. A computer program (670) comprising executable instructions which, when executed by processing circuitry in a user equipment (30, 400, 600) in a wireless communication network, cause the user equipment (30, 400, 600) to perform the method of any one of claims 1 to 12.

16. 16. A carrier comprising the computer program (670) of claim 15, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

17. A method (150) implemented by a user equipment (UE) (30, 400, 600) for relaying device-to-device (D2D) communications, the method (150) comprising: receiving (160) a request broadcast by a requesting UE (30, 400, 600) to initiate communication with a remote UE (30, 400, 600), the request including a relay indication indicating whether relaying is permitted for a communication path between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600); forwarding (170) said request towards said remote UE (30, 400, 600); The method (150),

18. 20. The method (150) of claim 17, wherein forwarding the request towards the remote UE (30, 400, 600) comprises forwarding the request depending on a value of the relaying indication.

19. 19. The method (150) of claim 17 or 18, wherein forwarding the request towards the remote UE (30, 400, 600) is further dependent on at least one of a Quality of Service (QoS) requirement for the request, a load of the UE (30, 400, 600), or a channel quality of a communication link between the UE (30, 400, 600) and the requesting UE (30, 400, 600).

20. 20. The method (150) of claim 18 or 19, wherein the UE (30, 400, 600) forwards the request when the value of the relay indication is greater than a predetermined value.

21. 21. The method (150) of any one of claims 17 to 20, further comprising discarding the request when the relay indication is equal to the predetermined value.

22. 21. The method (150) of any one of claims 17 to 20, further comprising decrementing the value of the relay indication in the request by a predetermined amount prior to forwarding the request.

23. 23. The method (150) of any one of claims 17 to 22, further comprising relaying D2D communication between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600), wherein the remote UE (30, 400, 600) uses the determined communication path.

24. 24. The method (150) of any one of claims 17 to 23, wherein the request message comprises a Direct Communication Request.

25. 24. The method (150) of any one of claims 17 to 23, wherein the request message comprises a Solicitation message.

26. A user equipment (UE) (30, 400, 600) capable of D2D (device-to-device) communication, wherein the UE (30, 400, 600) receiving a request broadcast by a requesting UE (30, 400, 600) to initiate communication with a remote UE (30, 400, 600), the request including a relay indication indicating whether relaying is permitted for a communication path between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600); forwarding said request towards said remote UE (30, 400, 600); A user equipment (UE) (30, 400, 600) configured to perform the steps of:

27. 27. The UE (30, 400, 600) of claim 26, wherein the processing circuitry is further configured to perform a method according to any one of claims 18 to 25.

28. A computer program (670) comprising executable instructions which, when executed by processing circuitry in a user equipment (30, 400, 600) in a wireless communication network, cause the user equipment (30, 400, 600) to perform the method of any one of claims 17 to 25.

29. 30. A carrier comprising the computer program (670) of claim 28, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

30. A method (200) implemented by a remote user equipment (UE) (30, 400, 600) for device-to-device (D2D) communication, the method (200) comprising: receiving (210) one or more copies of a request broadcast by a requesting UE (30, 400, 600) for initiating communication with the remote UE (30, 400, 600), the request including a relay indication indicating whether relaying is permitted for a communication path between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600); sending (220) a response message to the requesting UE (30, 400, 600) along the communication path along which the request was received in response to each of the one or more copies of the request; The method (200).

31. The method (200) of claim 30, further comprising selecting a communication path for D2D communication between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600).

32. 32. The method (200) of claim 31, wherein transmitting a response message in response to each of the one or more copies of the request comprises transmitting a single response message along the selected communication path.

33. receiving multiple copies of the request along respective communication paths between the requesting UE (30, 400, 600) and a remote UE (30, 400, 600); 33. The method (200) of claim 32, wherein transmitting a response message in response to each of the one or more copies of the request comprises transmitting a plurality of response messages to the UE (30, 400, 600) along respective routes of the communication path.

34. 34. The method (200) of any one of claims 30 to 33, wherein the response message is sent in response to a request received within a predetermined time window.

35. 35. The method (200) of any one of claims 30 to 34, further comprising communicating with the remote UE (30, 400, 600) using one of the communication paths selected by the requesting UE (30, 400, 600) or a remote UE (30, 400, 600).

36. The method (200) of any one of claims 30 to 35, wherein the request message comprises a Direct Communication Request.

37. The method (200) of any one of claims 30 to 35, wherein the request message comprises a Solicitation message.

38. A user equipment (UE) (30, 400, 600) capable of D2D (device-to-device) communication, wherein the UE (30, 400, 600) receiving one or more copies of a request broadcast by a requesting UE (30, 400, 600) for initiating communication with a remote UE (30, 400, 600), the request including a relay indication indicating whether relaying is permitted for a communication path between the requesting UE (30, 400, 600) and the remote UE (30, 400, 600); sending a response message to the requesting UE (30, 400, 600) in response to each of the one or more copies of the request along the communication path along which the request was received; A user equipment (UE) (30, 400, 600) configured to perform the steps of:

39. 39. The UE (30, 400, 600) of claim 38, wherein the processing circuitry is further configured to perform a method according to any one of claims 31 to 37.

40. A computer program (670) comprising executable instructions which, when executed by processing circuitry in a user equipment (30, 400, 600) in a wireless communication network, cause the user equipment (30, 400, 600) to perform the method of any one of claims 30 to 37.

41. 41. A carrier comprising the computer program (670) of claim 40, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

42. A method (250) implemented by an originating user equipment (UE) (30, 500, 600) for device-to-device (D2D) communication, the method (250) comprising: Receiving (260) announcements broadcast by one or more relay UEs, each announcement including a neighbor list identifying one or more potential remote UEs reachable from said relay UE; sending (270) a request to a selected one of the relay UEs having the remote UE (30, 500, 600) in its neighbor list, the request including an identification for identifying the target remote UE (30, 500, 600); receiving (280) a response message from the remote UE (30, 500, 600) relayed by the relay UE (30, 500, 600) in response to the request; The method (250).

43. sending a request to one of said neighboring UEs having the remote UE (30, 500, 600) in its neighbor list; selecting a communication path from a requesting UE (30, 500, 600) to the remote UE (30, 500, 600), the communication path including one of the neighboring UEs; sending said request to said neighboring UE (30, 500, 600) on said selected communication path; 43. The method (250) of claim 42, comprising:

44. The method (250) of claim 42 or 43, wherein selecting a communication path from the requesting UE (30, 500, 600) to the remote UE (30, 500, 600) is based at least in part on one of channel quality information indicative of a channel quality between the UE (30, 500, 600) and the neighboring UE, load information about the neighboring UE, or device capability information about the neighboring UE.

45. The method (250) according to any one of claims 42 to 44, wherein one or more of said announcements includes a time parameter indicating a period during which said neighbouring UEs (30, 500, 600) are to accept the request.

46. 46. ​​The method (250) of claim 45, wherein transmitting a request to one of the neighboring UEs includes transmitting the request during the indicated time period.

47. 47. The method (250) of any one of claims 42 to 46, further comprising communicating with the remote UE (30, 500, 600) using the determined communication path.

48. A user equipment (UE) (30, 500, 600) capable of D2D (device-to-device) communication, wherein the UE (30, 500, 600) receiving announcements broadcast by one or more relay UEs, each announcement including a neighbor list identifying one or more potential remote UEs reachable from said relay UE; sending a request to a selected one of the relay UEs having the remote UE (30, 500, 600) in its neighbor list, the request including an identification for identifying the target remote UE (30, 500, 600); receiving a response message from the remote UE (30, 500, 600) that is relayed by the relay UE (30, 500, 600) in response to the request; A user equipment (UE) (30, 500, 600) configured to perform the steps of:

49. 49. The UE (30, 500, 600) of claim 48, wherein the processing circuitry is further configured to perform a method according to any one of claims 43 to 47.

50. A computer program (670) comprising executable instructions which, when executed by processing circuitry in a user equipment (30, 500, 600) in a wireless communication network, cause the user equipment (30, 500, 600) to perform the method of any one of claims 42 to 47.

51. 51. A carrier comprising the computer program (670) of claim 50, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

52. A method (300) implemented by a user equipment (UE) (30, 500, 600) for relaying device-to-device (D2D) communications, the method (300) comprising: broadcasting (310) an announcement to one or more neighboring UEs, the announcement including a neighbor list identifying one or more potential remote UEs reachable from the UE; receiving (330) a request from a requester UE (30, 500, 600) to initiate D2D communication with a target remote UE (30, 500, 600) in the neighbor list, the request including an identification for identifying the target remote UE (30, 500, 600); forwarding (340) said request to said remote UE (30, 500, 600) identified by said request; The method (300).

53. receiving one or more relay requests from different ones of the neighboring UEs in response to the announcement; adding the neighboring UE that sent the relay request to the neighbor list for subsequent announcements; 53. The method (300) of claim 52, further comprising:

54. 54. The method (300) of claim 52 or 53, wherein forwarding the request towards the remote UE (30, 500, 600) comprises forwarding the received request a predetermined period of time following the announcement.

55. receiving a response message from the remote UE (30, 500, 600) in response to the request; forwarding the response message to the requesting UE (30, 500, 600); 55. The method (300) of any one of claims 52 to 54, comprising:

56. 56. The method (300) according to any one of claims 52 to 55, wherein said announcement comprises a time parameter indicating a period for accepting said request from said requesting UE (30, 500, 600).

57. 57. The method (300) of any one of claims 52 to 56, further comprising relaying D2D communication between the requesting UE (30, 500, 600) and the remote UE (30, 500, 600).

58. A user equipment (UE) (30, 500, 600) capable of D2D (device-to-device) communication, wherein the UE (30, 500, 600) broadcasting an announcement to one or more neighboring UEs, the announcement including a neighbor list identifying one or more potential remote UEs reachable from the UE; receiving a request from a requester UE (30, 500, 600) to initiate D2D communication with a remote UE (30, 500, 600) on the neighbor list, the request including an identification for identifying a target remote UE (30, 500, 600); forwarding said request to the remote UE (30, 500, 600) identified by said request; A user equipment (UE) (30, 500, 600) configured to perform the steps of:

59. 59. The UE (30, 500, 600) of claim 58, wherein the processing circuitry is further configured to perform a method according to any one of claims 53 to 57.

60. A computer program (670) comprising executable instructions which, when executed by processing circuitry in a user equipment (30, 500, 600) in a wireless communication network, cause the user equipment (30, 500, 600) to perform the method of any one of claims 52 to 57.

61. 61. A carrier comprising the computer program (670) of claim 60, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

62. A method (350) implemented by a user equipment (UE) (30, 500, 600) configured for device-to-device (D2D) communication, the method (350) comprising: Receiving (360) an announcement broadcast by a relay UE (30, 500, 600); sending (370) a relay request to the relay UE (30, 500, 600) in response to the announcement, requesting the relay UE (30, 500, 600) to serve as a relay for D2D communication; The method (350),

63. receiving (380) a request originating from a requesting UE (30, 500, 600) via said relay UE (30, 500, 600); sending (390) a response message to the requester UE (30, 500, 600) via the relay UE (30, 500, 600) in response to the request; 63. The method (350) of claim 62, further comprising:

64. The method (350) of claim 62 or 63, wherein said announcement comprises a time parameter indicating a period during which said relay UE (30, 500, 600) shall accept said relay request.

65. 65. The method (350) of claim 64, wherein transmitting a relay request comprises transmitting the relay request at the time period indicated in the announcement.

66. 66. The method (350) of any one of claims 62 to 65, further comprising communicating with the requesting UE (30, 500, 600) using one of the communication paths selected by the requesting UE (30, 500, 600) or a remote UE (30, 500, 600).

67. A user equipment (UE) capable of D2D (device-to-device) communication, the UE (30, 600): Receiving an announcement broadcast by a relay UE (30, 600); transmitting a relay request to the relay UE (30, 600) in response to the announcement, requesting the relay UE (30, 600) to serve as a relay for D2D communication; A user equipment (UE) (30, 600) configured to perform the steps of:

68. 68. The UE (30, 600) of claim 67, wherein the processing circuitry is further configured to perform a method according to any one of claims 63 to 66.

69. A computer program (670) comprising executable instructions which, when executed by processing circuitry in a user equipment (30, 500, 600) in a wireless communication network, cause the user equipment (30, 500, 600) to perform the method of any one of claims 62 to 66.

70. 70. A carrier comprising the computer program (670) of claim 69, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

Images