Patent Description:
The sidelink (SL) interface, introduced by the Third Generation Partnership (3GPP) project in Release <NUM> (Rel-<NUM>) of the Long Term Evolution (LTE) standard allows a user equipment (UE) to communicate directly with a peer UE without sending the packets to the network (NW). A UE-to-network relay solution is also defined such that a remote UE out of cell coverage can still reach the network via a relay UE. The remote UE communicates with the relay UE with the SL interface and the relay UE has uplink and downlink connection with the cell.

The first specification of the sidelink interface targeted mainly public uses cases. Since then, a number of enhancements have been introduced with the objective to enlarge the use cases that could benefit from the D2D technology. In particular, in LTE Release <NUM> Rel-<NUM>) and Release <NUM> (Rel-<NUM>), the extensions for the D2D framework focused on support for vehicle-to-everything (V2X) communications, including any combination of direct communications between vehicles, pedestrians and the infrastructure.

While LTE V2X mainly aims at traffic safety services, the implementation of V2X in the New Radio (NR) standard has a much broader scope including not only basic safety services but also non-safety applications, such as sensor/data sharing between vehicles, with the objective to strengthen the perception of the surrounding environment. Consequently, a new set of applications, such as vehicle platooning, cooperative maneuvering between vehicles and remote/autonomous driving may enjoy the enhanced sidelink framework.

Currently, the NR standard supports two Proximity Service (ProSe) discovery methods enabling a UE to discover neighboring UEs <NUM> in the proximity to the discovering UE. In a first model, referred to as Model A, an Announcing UE broadcast discovery messages at pre-defined discovery intervals to Monitoring UEs <NUM> its proximity that have permission to discover. The discovery message contains information that may be of interest to the Monitoring UEs <NUM>. The Monitoring UE can respond if the discovery message contains information of interest to the Monitoring UE. Both open and restricted discovery types are supported by the Model A discovery method. In a second model, referred to as Model B, a Discoverer UE transmits a request containing information about its specific interests. A Discoveree UE that receives the request can respond with some information related to the interest of the Discoverer UE. For example, a Discoverer UE can include information in its request about a 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 needs to have authorization (such as through pre-provisioned parameters) to perform discovery of the appropriate service(s).

D2D communication between two UEs <NUM> can be used to relay message from a UE outside the network coverage. The Model A or Model B discovery method can be used by an Announcing/Discoverer UE to discover a UE in its proximity serving as a UE-to-Network relay. A UE functioning as a UE-to-Network relay can attach to the network (if it is not already connected) and connect to a Packet Data network (PDN) connection enabling the necessary relay traffic.

3GPP contribution "<NPL>) describes including a relay indication into a unicast Direct Communication Request which is to a UE-to-UE Relay after its discovery. 3GPP contribution "<NPL>) describes including relay information into a broadcast Direct Communication Request. <CIT> describes D2D relay communication, in which a unicast Direct Communication Request sent after relay discovery includes a cause value to indicate that the requested one-to-one link has the purpose of relaying. <CIT> describes selection of a UE-to-network relay UE based on a discovery message. <CIT> discloses a method for supporting group communication by a user equipment in a wireless communication system, wherein a user equipment decides to act as relay on a condition that a current hop count is less than a maximum number of allowed hops.

While some proposals have been made to support UE-to-UE relay, the existing solutions suffer from one or more drawbacks. Specifically, the existing solutions can result in undesirable delays for relay discovery, provide only limited capabilities, or require the UE to establish a unicast link to a relay in advance (which can result in additional delays and waste of resources). Additionally, the existing solutions do not provide support for relay selection by a remote UE. This limitation may cause issues as capabilities of the remote UE are not considered in the relay selection.

Accordingly, there remains a need for solutions that overcome the drawbacks of the prior art solutions.

The present disclosure provides methods and apparatus for establishing a unicast D2D communication link between a requesting UE and a remote UE via a relay UE. Specifically, the presently disclosed invention provides a method according to claim <NUM>, a method according to claim <NUM>, a UE according to claim <NUM>, a computer program according to claim <NUM>, a method according to claim <NUM>, and a system according to claim <NUM>. The dependent claims define further embodiments of the invention.

Referring now to the drawings, UE-to-UE relay techniques according to the present disclosure will be described in the context of a wireless communication network implementing the NR communications standard. Those skilled in the art will appreciate, however, that the techniques are more generally applicable to any wireless communication networks supporting D2D communications over a sidelink interface.

<FIG> illustrates a base station <NUM> that provides connection for a plurality of UEs <NUM> to a core network <NUM>. Although a single base station <NUM> is shown in <FIG>, those skilled in the art will appreciate that the wireless communication network <NUM> will typically include many base stations <NUM>. The base stations <NUM> may also be referred to in the NR standards as Evolved Node Bs (eNBs), <NUM> Node Bs (gNBs) or Next Generation eNBs (ng-eNBs).

<FIG> illustrates four UEs <NUM>, denoted respectively as UE-<NUM> - UE-<NUM>. UE-<NUM> - UE-<NUM> are within the coverage area of the base station <NUM> and are capable of establishing a packet data network (PDN) connection with the network <NUM>. UE-<NUM> is outside the coverage area of the base station <NUM>.

UE-<NUM> - UE-<NUM> are capable of D2D communications over a sidelink (e.g., PC5 interface) with other UEs <NUM> in their proximity. UE-<NUM> is in the proximity of UE-<NUM> and UE-<NUM> and can communicate over sidelinks SL13 and SL14 with UE-<NUM> and UE-<NUM> respectively. UE-<NUM> is in the proximity of UE-<NUM> and can communicate with UE-<NUM> over sidelink SL <NUM>. UE-<NUM> is in the proximity of UE-<NUM>, UE-<NUM> and UE-<NUM> and can communicate with them respectively over the sidelinks SL13, SL23, and SL34. Finally, UE-<NUM> is in the proximity of UE-<NUM> and UE-<NUM> and can communicate over sidelinks SL14 and SL34 with UE-<NUM> and UE-<NUM> respectively. UE <NUM> and UE-<NUM>, however, are outside the range of UE-<NUM> and are unable to establish a direct connection with UE-<NUM> over a sidelink. UE <NUM> could communicate with UE-<NUM> via base station <NUM>. However, UE-<NUM> is outside the coverage of the base station <NUM>.

One aspect of the disclosure comprises methods to enable UE-to-UE relay for D2D communications. In the example shown in <FIG>, the D2D communication techniques allow UE-<NUM> to serve as a relay for D2D communications between UE-<NUM> and UE-<NUM> or between UE-<NUM> and UE-<NUM>.

For NR sidelink, unicast at access stratum is supported for services requiring high reliability. Between the same UE pair, there can be multiple sidelink unicast links and each unicast link can support multiple sidelink Quality of Service (QoS) flows/radio bearers as illustrated in <FIG> (3GPP TS <NUM>). At access stratum, each link can be identified by the source and destination Layer <NUM> identity (L2 ID). For instance, the PC5 unicast link <NUM> in <FIG> can be identified by the pair of L2 ID1 (i.e., corresponding to application ID1) and L2 ID2 (i.e. corresponding to application ID2).

To enable D2D communications between UEs <NUM>, a discovery method is needed to enable the UEs <NUM> to discover one another. Two ProSe Discovery methods are defined in 3GPP standard TS <NUM>, §<NUM>. <NUM>: the Model A discovery method (<FIG>) and the Model B discovery method (<FIG>).

Model A defines two roles for the ProSe-enabled UEs <NUM> that are participating in ProSe Direct Discovery.

In this model, the Announcing UE <NUM> broadcasts discovery messages at pre-defined discovery intervals and the Monitoring UEs <NUM> that are interested in these messages read them and process them. This model is equivalent to "I am here" because the Announcing UE <NUM> would broadcast information about itself, e.g., its ProSe Application Code in the discovery message. Both open and restricted discovery types are supported by Model A.

The Model B discovery method is shown in <FIG>. When restricted discovery type is used, this model defines two roles for the ProSe-enabled UEs <NUM> that are participating in ProSe Direct Discovery.

In this model, the request by the Discoverer UE <NUM> includes information about other UEs <NUM> with which it would like to communicate. It is equivalent to " who is there/are you there" because the Discoverer UE <NUM> sends information about other UEs <NUM> from which the Discoverer UE <NUM> would like to receive responses. For example, the information can be about a ProSe Application Identity corresponding to a group and the members of the group can respond. The Public Safety discovery is considered restricted. The Monitoring UE <NUM>/Discoverer UE <NUM> needs to have authorization (such as through pre-provisioned parameters) to perform discovery of the appropriate service(s).

The current standard provides support for direct communication via ProSe UE-to-Network Relay (TS <NUM>, §<NUM>. With this procedure, a ProSe UE-to-Network Relay capable UE <NUM> can attach to the network (if it is not already connected) and connect to a PDN connection enabling the necessary relay traffic. <FIG> shows the call flow of a procedure for ProSe UE-to-Network Relay. In this procedure, a remote UE <NUM> performs discovery of a ProSe UE-to-Network Relay using Model A (<FIG>) or Model B (<FIG>) discovery. The details of this procedure are described in TS <NUM>, §<NUM>.

Briefly, the remote UE <NUM> performs discovery of a ProSe UE-to-Network Relay using Model A (<FIG>) or Model B (<FIG>) discovery. The details of this discovery procedure are described in TS <NUM>, §<NUM>. The identifiers for ProSe UE-to-Network Relay discovery and selection are defined in TS23. <NUM>, § <NUM>. The following parameters are used in the UE-to-Network Relay Discovery Announcement message (Model A):.

The following parameters are used in the UE-to-Network Relay Discovery Solicitation message (Model B):.

The following parameters are used in the UE-to-Network Relay Discovery Response message (Model B):.

<FIG> illustrates the layer-<NUM> (L2) link establishment procedure for unicast mode of V2X communication over PC5 reference point.

NOTE <NUM>: PC5 unicast link is bi-directional, therefore the peer UE <NUM> of UE-<NUM> can send the V2X service data to UE-<NUM> over the unicast link with UE-<NUM>.

One aspect of the present disclosure is to provide support for UE-to-UE relay. While some proposals have been made to support UE-to-UE relay, the existing solutions suffer from one or more drawbacks. Specifically, the existing solutions can result in undesirable delays for relay discovery, provide only limited capabilities, or require the UE <NUM> to establish a unicast link to a relay in advance (which can result in additional delays and waste of resources). Additionally, the existing solutions do not provide support for relay selection by a remote UE <NUM>. This limitation may cause issues as capabilities of the remote UE <NUM> are not considered in the relay selection.

The solutions herein described reuse service discovery and unicast link establishment methods defined in TS <NUM> and TS <NUM> with a few modifications so the impact to the corresponding products is small. The methods support relay selection by both the requesting UE <NUM> and the remote UE <NUM>, also referred to herein as the target UE <NUM>, allowing consideration of the status of remote UE <NUM> for relay selection. Also, new timers are introduced for collecting requests and responses from relays in order to perform the relay selection. The methods herein described also allow more information to be exchanged by potential relays in order to support the implementation of more complex relay selection approaches. For example, the methods herein described can support load balancing and other relay selection policies.

One aim of the techniques herein described is to ensure the relay discovery between the requesting UE <NUM> and the target UE <NUM> shall not be dependent on how the relay UE <NUM> forwards traffic between the requesting UE <NUM> and the target UE <NUM>, e.g., L2 or L3 relaying. The techniques rely on the concept that UE-to-UE discovery and selection can be integrated into the unicast link establishment procedure as described in clause <NUM>. <NUM> of TS <NUM>.

In the following description, a UE <NUM> that initiates communication with a remote UE <NUM> is referred to a requesting UE <NUM> or initiating UE <NUM>. The remote UE <NUM> is also referred to herein as the target UE <NUM>. A UE <NUM> that serves as a UE-to-UE relay is called a relay UE <NUM>.

<FIG> illustrate unicast link establishment procedures for establishing a unicast link with a remote UE <NUM> without relay discovery. The requesting UE <NUM> (also referred to herein as the originating UE <NUM> or initiating UE <NUM>) is denoted UE-<NUM> and the remote UE <NUM> (also referred to as the target UE <NUM> or responding UE <NUM>) is denoted UE-<NUM>. When the requesting UE <NUM> (e.g., UE-<NUM> in <FIG>) wants to establish a unicast communication with the remote UE <NUM> (UE-<NUM> in <FIG>), the requesting UE <NUM> broadcasts a Direct Communication Request as defined in TS23. <NUM> or Solicitation message. The Direct Communication Request or Solicitation message is modified to include a new field called relay_indication to indicate whether relays are allowed for the communication. The relay_indication field also indicates a maximum number of hops allowed for a communication path between the requesting UE <NUM> and the remote UE <NUM>. For Release <NUM>, it is assumed that the value of the indication is restricted to single hop.

The value of the relay_indication field could be <NUM> or a positive integer, e.g., <NUM>, <NUM>,. In one example, the requesting UE <NUM> selects a relay_indication value between <NUM> and M selected by UE <NUM>, where M represents an upper bound. The relay_indication value can be regarded the maximum number of relays allowed by the requesting UE <NUM>, i.e., a value of <NUM> means that no relays are allowed (relaying is not admitted), a value of <NUM> means that only one relay is allowed (UE-relay-UE), and so on. The maximum number of hops allowed is the number of relays plus <NUM>, with <NUM> being the direct communication path between the requesting UE <NUM> and the remote UE <NUM>. This value can be set according to several approaches. In one approach, the relay_indication value could be set by application to which the link establishment refers and could vary according to application type. In another approach, the relay_indication value could be set as feature of the chipset. In another approach, relay_indication value could be set by the network according to pre-configured (e.g., SIM-based or via network signaling) or dynamic policies (e.g., via network signaling) that vary depending on the different applications.

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 of False indicates that relaying is not allowed.

When a potential UE-to-UE relay receives a Direct Communication Request or Solicitation message with relay_indication greater than <NUM>, it decides whether to forward (i.e., broadcast this message to its neighborhood). The decision whether to forward or rebroadcast the Direct Communication Request could, for example, be based on factors such as QoS requirements in the request, the current traffic load of the relay, the link quality between the requesting UE <NUM> and the relay UE <NUM> (e.g., determined by measuring the received power of the request message), or some other policies (e.g., it only serves some specific UEs <NUM>). Different forwarding approaches could be used for different requests. The approach followed for forwarding the request could be driven by chipset design or driven by applications decision.

If the potential relay decides to forward/rebroadcast the request, it will decrease the relay_indication value by <NUM>. When forwarding a received request, the potential relay doesn't change any parameter included in the received request except for the relay_indication value when integer values are used. The potential relay could though append additional information to the received request such as relay load info, relay QoS support, etc..

If a relay receives a Direct Communication Request or Solicitation message with a relay_indication value of <NUM> and the relay is not the target of the request, the relay can drop the message. If a relay receives a communication request (e.g., can be identified by some request ID) which it has already forwarded before, then it can drop the current one.

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

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

Referring to <FIG>, it is assumed in this example that Relay-<NUM>, Relay-<NUM> and UE-<NUM> are directly reachable by UE-<NUM> (the requesting UE <NUM>). Relay-<NUM> and Relay-<NUM> are all willing to forward Direct Communication Request messages from UE-<NUM>. UE-<NUM> (the remote UE <NUM>) can also be reachable by Relay-<NUM> and Relay-<NUM>.

In step <NUM>, UE-<NUM> wants to establish unicast communication with UE-<NUM> and the communication can be either through a direct link with UE-<NUM> or via a UE-to-UE relay. UE-<NUM> broadcasts a Direct Communication Request with a relay_indication = <NUM>. The Direct Communication Request may also include a request identifier (ID). When UE-<NUM> broadcasts the Direct Communication Request, it can optionally start a timer, denoted as Timer1, which sets an upper bound on the time period UE-<NUM> will wait for a response. The Direct Communication Request is received by Relay-<NUM>, Relay-<NUM> and UE-<NUM>. Note that UE-<NUM> need not know the identity of the remote UE <NUM>. The request may optionally include an identifier for UE-<NUM> if UE-<NUM> is aware of UE-<NUM> based on a priori information or may include other information about the intended target.

In step <NUM>, Relay-<NUM> and Relay-<NUM> decides to forward/broadcast the Direct Communication Request from UE-<NUM>. Relay-<NUM> and Relay-<NUM> both rebroadcast the same Direct Communication Request to neighboring UEs <NUM> with relay_indication=<NUM>. If another relay receives this message, it will just drop it. For example, if Relay-<NUM> receives the rebroadcast message from Relay-<NUM>, Relay-<NUM> will recognize the request ID as matching the previously forwarded request and drop the message.

In step <NUM>, UE-<NUM> receives copies of the Direct Communication Requests directly from UE-<NUM>, Relay-<NUM> and Relay-<NUM>. Now there are three paths through which UE-<NUM> can reach UE-<NUM>; the direct path, via Relay-<NUM> and via Relay-<NUM>. In various embodiments of this method, the communication path for the communication between UE-<NUM> and UE-<NUM> can be selected by UE-<NUM> (the remote UE <NUM>), UE-<NUM> (the requesting UE <NUM>), or by a combination of UE-<NUM> and UE-<NUM>.

In embodiments where the remote UE <NUM> selects the communication path, it will start a timer, denoted Timer2 in <FIG>, after it receives the first copy of the Direct Communication Request. In this example, the first copy received is the request directly from UE-<NUM>. The timer establishes an upper bound on the delay while the remote UE <NUM> collects copies of the Direct Communication Requests propagating along different paths. The value of the timer could be a chipset implementation, set by an application or provided by the network (e.g., pre-configured or provided via network signaling). Any copy of the request received after the timer expires can be ignored. In the example shown in <FIG>, the copy of the Direct Communication Request from Relay-<NUM> is ignored because it arrives after Timer2 expires.

After Timer2 ends, UE-<NUM> 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 <NUM>), local policy (e.g., provided by an application or chipset design) or operator policies (pre-configured or provided via network signaling). Examples of selection criterion comprise, for instance, selecting the request with the highest signal strength, selecting the request with the highest value of relay_indication parameter (meaning that is the request that has been forwarded the fewest number of times, potentially indicating the shortest path). Decisions can also be based on a combination of factors. For example, if multiple requests have the same relay_indication value, the request associated to highest signal strength could be selected.

As previously noted, when a potential relay forwards the Direct Communication Request, it can also add more information into the message, such as load information, QoS support, etc. In this case, the remote UE can use that information to choose the communication path. For example, if two requests with the same relay_indication value have been received, the remote UE <NUM> can select the one with the lightest load.

In some embodiments, the remote UE <NUM> can be configured to always choose the path from which it receives the first copy of the request. In this case, Timer2 is not needed. Rather, the remote UE <NUM> directly chooses the path of the first received request and drops any subsequent requests that it receives having the same request ID. Also, if the remote UE <NUM> policy is to always choose the path associated to the smallest number of hops from the requesting UE <NUM>, the remote UE <NUM> can directly select a request received by the requesting UE <NUM>. In this case, the remote UE <NUM> can stop Timer2 and ignore subsequent requests with the same request ID. In another example, when the remote UE <NUM> (i.e., UE-<NUM>) receives a Direct Communication Request from the requesting UE <NUM> (e.g., UE-<NUM>) implying a good direct link between UE-<NUM> and UE-<NUM> available, UE-<NUM> may accept the request, stop Timer2 and not process other requests forwarded from relay UEs <NUM>.

In some embodiments, the remote UE <NUM> could be configured to select one or more communications paths for the same connection. In this case, the remote UE <NUM> could reply to multiple Direct Communication Requests, which are selected according to policies in a similar way as in case of replying to only one request (i.e., reply to the first two received requests, etc.). In this case, the requesting UE <NUM> could be configured to use multiple communication paths when two or more paths are selected by the remote UE <NUM>. Alternatively, the requesting UE <NUM>, can be configured to optionally select a single communication path (or less than all of the indicated communication paths) from the set of communication paths indicated by the remote UE <NUM>.

In the example shown in <FIG>, it is assumed that UE-<NUM> wants to setup a multi-link connection. Therefore, at step <NUM>, UE-<NUM> replies to the Direct Communication Request received directly from UE-<NUM> and as well as the Direct Communication Request received via Relay-<NUM> by sending a Request Accept message over the direct communication path and via Relay-<NUM>. When Timer1 ends, UE-<NUM> determines the communication path to use for D2D communication with UE-<NUM>. In this example, it is assumed that both responses are received prior to the expiration of Timer1. In some embodiments, the requesting UE <NUM> can be configured to always use multiple communication paths for communication with the remote UE <NUM> when the remote UE <NUM> has selected multiple paths. In other embodiments, the requesting UE <NUM> can be configured to select which of the multiple communication paths indicated by the remote UE <NUM> to use for D2D communication with the remote UE <NUM>. In step <NUM>, UE-<NUM> and UE-<NUM> engage in unicast communication using the selected path or paths.

In some embodiments, path selection is performed by the requesting UE <NUM>. In this embodiment, UE-<NUM> starts Timer1 when it broadcasts the Direct Communication Request and waits for a response. When Timer1 expires, UE-<NUM> determines which communication path to use for communication with UE-<NUM> based on any Request Accept messages received prior to the timer expiration. In the example shown in <FIG>, UE-<NUM> responds at step <NUM> to the Direct Communication Request received directly from UE-<NUM> and to the Direct Communication Request received via Relay-<NUM>. UE-<NUM> receives both responses prior to the expiration of Timer1; one directly from UE-<NUM> and one via Relay-<NUM>. The requesting UE <NUM> can select the communication path based on factors such as signal strength, load on the relay (added by the relay to the Request Accept message), QoS support by the relay (added by the relay to the Request Accept message), local policy (e.g., provided by an application or chipset design) or operator policies (pre-configured or provided via network signaling). Examples of selection criterion comprise, for instance, selecting the communication path associated with the highest signal strength, selecting the communication path with the lightest load on the relay, selecting the direct path if available. Decisions can also be based on a combination of factors. For example, the requesting UE <NUM> can be configured to select the direct path if it meets a minimum signal quality standard, or to select the relay with the lightest load that meets the minimum signal quality standard.

In some embodiments, the requesting UE <NUM> can be configured to always choose the path over which it receives the first Request Accept message. In this case, the requesting UE <NUM> can stop Timer1 and ignore any subsequent Request Accept messages received after the first. In another example, when the requesting UE <NUM> (i.e., UE-<NUM>) receives a Direct Communication Request from the remote UE <NUM> (e.g., UE-<NUM>) implying a good direct link between UE-<NUM> and UE-<NUM> available, UE-<NUM> may immediately select the direct communication path without waiting for Timer1 to expire and stop Timer1. In step <NUM>, UE-<NUM> and UE-<NUM> engage in unicast communication using the selected path or paths.

In some embodiments, the path selection may be performed in part by the remote UE <NUM> and in part by the requesting UE <NUM> where the remote UE <NUM> has indicated multiple paths available for the communication. In this case, the remote UE <NUM> is configured to select one or more preferred paths. When the requesting UE <NUM> receives multiple Request Accept messages in response to a Direct Communication Request, it has the option to select from the available communication paths indicated by the remote UE <NUM>. The requesting UE <NUM> could select all of the communication paths indicated by the remote UE <NUM>, or some number less than all of the communication paths. In step <NUM>, UE-<NUM> and UE-<NUM> engage in unicast communication using the selected path or paths.

Referring to <FIG>, it is assumed in this example that Relay-<NUM>, Relay-<NUM> and UE-<NUM> are directly reachable by UE-<NUM> (the requesting UE <NUM>). Relay-<NUM> and Relay-<NUM> are willing to forward Direct Communication Requests from UE-<NUM>. UE-<NUM> (the remote UE <NUM>) can also be reachable by Relay-<NUM> and Relay-<NUM>.

In step <NUM>, UEs <NUM> are authorized to use the service provided by the UE-to-UE relays. UE-to-UE relays are authorized to provide service of relaying traffic among UEs <NUM>. The authorization can be done when UEs/relays are registered to the network. Security related parameters may be provisioned so that a UE <NUM> and a relay can verify the authorization of each other if needed.

In step <NUM>, UE-<NUM> wants to establish unicast communication with UE-<NUM> and the communication can be either through a direct link with UE-<NUM> or via a UE-to-UE relay. UE-<NUM> broadcasts a Direct Communication Request with a relay_indication set to 'enabled. ' The Direct Communication Request may also include a request identifier (ID). The Direct Communication Request is received by Relay-<NUM>, Relay-<NUM>. The Direct Communication Request may also be received by UE-<NUM> is it is in close proximity to UE-<NUM>.

In step <NUM>, Relay-<NUM> and Relay-<NUM> decide to forward/broadcast the Direct Communication Request from UE-<NUM>. Relay-<NUM> and Relay-<NUM> both broadcast the same Direct Communication Request to neighboring UEs <NUM> without a relay_indication. If another relay receives this message, it will just drop it. For example, if Relay-<NUM> receives the rebroadcast message from Relay-<NUM>, Relay-<NUM> will recognize the request ID as matching the previously forwarded request and drop the message. When a relay forwards the Direct Communication Request, it includes its Relay ID or Relay UE info in the message.

In step <NUM>, UE-<NUM> receives copies of the Direct Communication Requests from Relay-<NUM> and Relay-<NUM>.

In step <NUM>, UE-<NUM> chooses Relay-<NUM> and replies with Request Accept message via Relay-<NUM>. When Relay-<NUM> forwards the Request Accept message, it also includes its Relay ID or Relay UE info in the message. If UE-<NUM> directly receives the Direct Communication Request from UE-<NUM>, it may choose to setup a direct communication link by sending the Request Accept directly to UE-<NUM>.

In step <NUM>, UE-<NUM> receives the Request Accept from Relay-<NUM>. UE-<NUM> chooses a path according to policies (e.g., always choose direct path if it is possible), signal strength, etc. If UE-<NUM> receives a Request Accept directly from UE-<NUM>, it may choose to setup a direct L2 link as described in clause <NUM>. <NUM> of TS <NUM>. In this case, step <NUM> is skipped.

In step <NUM>, UE-<NUM> and UE-<NUM> setup a communication link through chosen the UE-to-UE relay. The link setup information may vary depending on the type of relay, e.g., L2 or L3 relaying.

Referring to <FIG>, it is assumed that Relay-<NUM>, Relay-<NUM> and UE-<NUM> are directly reachable by UE-<NUM> (the requesting UE <NUM>). Relay-<NUM> and Relay-<NUM> are all willing to forward Direct Communication Request from UE-<NUM>. UE-<NUM> (the remote UE <NUM>) can also be reachable by Relay-<NUM> and Relay-<NUM>.

In step <NUM>, UE-<NUM> wants to establish unicast communication with UE-<NUM> and the communication can be either through a direct link with UE-<NUM> or via a UE-to-UE relay. UE-<NUM> broadcasts a Solicitation message with a relay_indication set to 'enabled'. The Solicitation message may also include a request identifier (ID). The Solicitation message is received by Relay-<NUM> and Relay-<NUM>. The Solicitation message includes, UE-<NUM> ID or UE-<NUM> Application User Info, UE-<NUM> ID or UE-<NUM> Application User Info. The message may also be received by UE-<NUM> if it is in the proximity of UE-<NUM>.

In step <NUM>, Relay-<NUM> and Relay-<NUM> decides to forward/broadcast the Solicitation message from UE-<NUM>. Relay-<NUM> and Relay-<NUM> both broadcast the Solicitation message to neighboring UEs <NUM> without a relay_indication. If another relay receives this message, it will just drop it. When a relay forwards the Solicitation message, it includes its Relay ID or Relay UE info in the message.

In step <NUM>, UE-<NUM> receives copies of the Solicitation message from Relay-<NUM> and Relay-<NUM>.

In step <NUM>, UE-<NUM> chooses Relay-<NUM> and replies with a Response message via Relay-<NUM>. When Relay-<NUM> forwards the Response message, it also includes its Relay ID or Relay UE info in the message. If UE-<NUM> directly receives the Solicitation message from UE-<NUM>, it may choose to setup a direct communication link by sending the Response message directly to UE-<NUM>.

In order to make a relay or path selection in the embodiments shown in <FIG>, the requesting UE <NUM> can setup a timer after sending out the Direct Communication Request (or Solicitation message) for collecting the corresponding Request Accept (or Response) messages before making a decision. Similarly, the target UE <NUM> can also setup a timer after receiving the first copy of the Direct Communication Request (or Solicitation message) for collecting multiple copies of the message from different paths before making a decision.

The first time that a requesting UE <NUM> receives a message from a UE-to-UE relay, the requesting UE <NUM> may need to verify if the relay UE <NUM> is authorized be a UE-to-UE relay. Similarly, the UE-to-UE relay may also need to verify if the requesting UE <NUM> is authorized to use the relay service. The verification details and the how to secure the communication between two UEs <NUM> through a UE-to-UE relay can be defined by standard.

<FIG> illustrates a procedure for unicast link establishment to a remote UE <NUM> with relay discovery. Each relay maintains a list of neighbor UEs <NUM> it can reach and periodically broadcasts an announcement to indicate its availability for relaying communications (step <NUM>). The announcement includes an indication (e.g., the reachable neighbor list) of other UEs <NUM> that the relay UE <NUM> can reach. When a neighboring UE <NUM> within reach of the relay UE <NUM> receives the broadcast announcement, it can decide whether it wants to use the relay UE <NUM> to relay D2D communications. If so, the receiving UE <NUM> stores a copy of the reachable neighbor list for the relay UE <NUM> in its local memory sends a relay request to the relay UE <NUM>. Upon receipt of the relay request, the relay UE <NUM> adds the requesting UE <NUM> to its reachable neighbor and sends the updated list in the next broadcast discovery message. When the requesting UE <NUM> wants to communicate with a remote UE <NUM>, it can choose a relay UE <NUM> able to reach the remote UE <NUM> before it sends a Direct Communication Request. In this regard, choosing a relay UE <NUM> is equivalent to choosing a path because the relay UE <NUM> chosen is the first hop in the selected communication path.

In the example shown in <FIG>, it is assumed that UE-<NUM> cannot directly communicate with UE-<NUM>. Relay-<NUM> and Relay-<NUM> can reach both UE-<NUM> and UE-<NUM>. In step <NUM>, Relay-<NUM> and Relay-<NUM> broadcast an announcement indicated their availability to relay communications. When UE-<NUM> receives the broadcast message from Relay-<NUM> and Relay-<NUM>, it decides to use both relay UEs <NUM> for D2D communications. At step <NUM>, UE-<NUM> sends a relay request to Relay-<NUM> and Relay-<NUM>. When Relay-<NUM> and Relay-<NUM> receive the responses from UE-<NUM>, it adds UE-<NUM> to its reachable neighbor list and sends the updated list in the next broadcast discovery. UE-<NUM> likewise receives the announcement from Relay-<NUM> and decides to use Relay-<NUM>. At step <NUM>, UE-<NUM> sends a relay request to Relay-<NUM>. When Relay-<NUM> receives the responses from UE-<NUM>, it adds UE-<NUM> and UE-<NUM> to its reachable neighbor list and sends the updated list in the next broadcast discovery message. Each time the announcement is broadcast, the UEs <NUM> in the neighborhood of Relay-<NUM> and Relay <NUM>-will update their local copy of the reachable list for Relay-<NUM> if it has changed since the last broadcast.

When a requesting UE <NUM> needs to send a communication to a remote UE <NUM>, it selects a communication path based on its local copies of the neighbor lists stored in memory. Additional memory can also be stored, such as the signal strength of the relay (determined by measuring the broadcast announcement), the load of the relay (contained in the announcement, the QoS support provided by the relay (contained in the announcement), tec. There may be more than one communication path available so the requesting UE <NUM> select the communication path as previously described based on factors such as signal strength, load on the relay (included in the announcement message), QoS support by the relay (included in the announcement message), local policy (e.g., provided by an application or chipset design) or operator policies (pre-configured or provided via network signaling). In the example shown in <FIG>, UE-<NUM> selects Relay-<NUM> and sends a Direct Communication Request to Relay-<NUM> at step <NUM>. Relay-<NUM> forwards the Direct Communication Request to the remote UE <NUM>. At step <NUM>, the remote UE <NUM> sends a Request Accept message to the requesting UE <NUM> via Relay-<NUM>. UE-<NUM> and UE-<NUM> then establish a unicast communication link via Relay-<NUM> and begin communication.

A relay request or Direct Communication Request can be sent directly after reception of broadcast message from the relay, or it could be sent later. The relay UE <NUM> can include add a validity_timer parameter in the broadcast announcement message, which indicates how long the relay UE <NUM> will accept responses. When sending a broadcast announcement message, the relay UE <NUM> starts the validity_timer and processes responses until the expiration of this timer. When UE <NUM> receives the announcement message from a relay UE <NUM>, it starts a validity_timer associated with that relay. If the UE <NUM> subsequently needs to establish a link with a UE <NUM> that can be reached via this relay, the UE <NUM> can send a request message to the relay if the validity_timer has not expired.

<FIG> illustrates an exemplary method <NUM> implemented by requesting UE <NUM> for D2D communication. The requesting UE <NUM> broadcasts a request (e.g., Direct Communication Request or Solicitation message) initiating communication with a remote UE <NUM> to one or more neighboring UEs <NUM> (block <NUM>). The request comprises a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. According to the invention, the relay indication further indicates a maximum number of hops for the communication path. The requesting UE <NUM> further receives, responsive to the request, a response message (e.g., Request accept or Solicitation Response message) from one or more of the neighboring UEs <NUM> (block <NUM>). The requesting UE <NUM> determines a communication path for the D2D communication between the requesting UE and the remote UE based on the one or more response messages (block <NUM>).

In some embodiments of the method <NUM>, the communication path is selected by a remote UE <NUM>. The requesting UE <NUM> receives a single response message from a neighboring UE <NUM> and determines the communication path based on an identity of the neighboring UE <NUM> from which the response message is received.

In some embodiments of the method <NUM>, the requesting UE <NUM> receives the single response message from a neighboring UE <NUM> serving as a relay and the determined communication path includes two or more hops from the requesting UE <NUM> to the resp UE <NUM>.

In some embodiments of the method <NUM>, the requesting UE <NUM> receives the single response message directly from the remote UE <NUM> and the determined communication path is a path between the requesting UE <NUM> and the remote UE <NUM>.

In some embodiments of the method <NUM>, the requesting UE <NUM> receives a response message from each of one or more neighboring UE <NUM>; and selects the communication path based on the one or more response messages received by the requesting UE <NUM>.

In some embodiments of the method <NUM>, the UE <NUM> selects a path from the requesting UE <NUM> to the remote UE <NUM> when it receives a response message directly from the remote UE <NUM>.

In some embodiments of the method <NUM>, the requesting UE <NUM> selects the communication path based on path selection information contained in the one or more response messages.

In some embodiments of the method <NUM>, the path selection information comprises at least one of channel quality information; load information, or device capability information.

In some embodiments of the method <NUM>, the requesting UE <NUM> determines the communication path based on one or more of the response messages received in a predetermined time prior after broadcasting the request.

Some embodiments of the method <NUM> further comprises communicating with the remote UE <NUM> using the determined communication path.

In some embodiments of the method <NUM>, the request message comprises a Direct Communication Request and the response message comprises a Request accept message.

In some embodiments of the method <NUM>, the request message comprises a Solicitation message and the response message comprises a Response message.

<FIG> illustrates an exemplary method <NUM> implemented by relay UE <NUM> for relaying D2D communication between a requesting UE <NUM> and a remote UE <NUM>. The relay UE <NUM> receives a request (e.g., Direct Communication Request or Solicitation message) broadcast by a requesting UE initiating communication with a remote UE <NUM> (block <NUM>). The request comprises a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. According to the invention, the relay indication further indicates a maximum number of hops for the communication path. The relay UE <NUM> further forwards the request towards the remote UE (block <NUM>).

In some embodiments of the method <NUM>, forwarding the request towards the remote UE <NUM> comprises forwarding the request depending on a value of the relay indication.

In some embodiments of the method <NUM>, forwarding the request towards the remote UE <NUM> is further dependent on at least one of a Quality of Service (QoS) requirement for the request, a load of the UE <NUM>, or a channel quality of a communication link between the UE <NUM> and the requesting UE <NUM>.

In some embodiments of the method <NUM>, the UE <NUM> forwards the request when the value of the relay indication is greater than a predetermined value.

Some embodiments of the method <NUM> further comprise discarding the request when the relay indication equals the predetermined value.

Some embodiments of the method <NUM> further comprise decrementing the value of the relay indication in the request by a predetermined amount prior to forwarding the request.

Some embodiments of the method <NUM> further comprise relaying D2D communications between the requesting UE <NUM> and the remote UE <NUM>. with the remote UE <NUM> using the determined communication path.

<FIG> illustrates an exemplary method <NUM> implemented by remote UE <NUM> for D2D communication. The remote UE <NUM> receives one or more copies of a request (e.g., Direct Communication Request or Solicitation message) broadcast by a requesting UE <NUM> initiating communication with a remote UE <NUM> (block <NUM>). The request comprises a relay indication indicating whether relaying is allowed for a communication path between the requesting UE <NUM> and the remote UE <NUM>. According to the invention, the relay indication further indicates a maximum number of hops for the communication path. The remote UE <NUM> further sends to the requesting UE <NUM>, responsive to each of one or more copies of the request, a response message (e.g., Request Accept or Solicitation Response message) along the communication path on which the request was received (block <NUM>).

Some embodiments of the method <NUM> further comprise selecting a communication path for D2D communication between the requesting UE <NUM> and the remote UE <NUM>.

In some embodiments of the method <NUM>, sending, responsive to each of one or more copies of the request, a response message comprises sending a single response message along the selected communication path.

Some embodiments of the method <NUM> further comprise receiving multiple copies of the request along respective communication paths between the requesting UE <NUM> and remote UE <NUM>, wherein sending, responsive to each of one or more copies of the request, a response message comprises sending multiple response messages to the UE <NUM> along respective ones of the communication paths.

In some embodiments of the method <NUM>, the response messages are sent in response to requests received in a predetermined time window.

Some embodiments of the method <NUM> further comprise communicating with the remote UE <NUM> using one of the communication paths selected by the requesting UE <NUM> or remote UE <NUM>.

<FIG> illustrates an exemplary method <NUM> implemented by requesting UE <NUM> configured for D2D communication. The requesting UE <NUM> receives announcements broadcast by one or more relay UEs <NUM> (block <NUM>). Each announcement includes a neighbor list identifying one or more potential remote UEs reachable by the relay UE <NUM>. The requesting UE <NUM> further sends a request (e.g., Direct Communication Request or Solicitation message) to a selected one of the relay UEs <NUM> having a remote UE <NUM> in its neighbor list (block <NUM>). The request comprises identifying information for identifying a targeted remote UE <NUM>. The requesting UE <NUM> further receives, responsive to the request, a response message (e.g., Request Accept message or Solicitation Response message) from the remote UE relayed by the relay UE <NUM> (block <NUM>).

In some embodiments of the method <NUM>, sending a request to one of the neighboring UEs having a remote UE <NUM> in its neighbor list comprises selecting a communication path from the requesting UE <NUM> to the remote UE <NUM>, the communication path including one of the neighboring UEs, and sending the request to the neighboring UE <NUM> on the selected communication path.

In some embodiments of the method <NUM>, selecting a communication path from the requesting UE <NUM> to the remote UE <NUM> is based at least in part on one of channel quality information indicating channel quality between the UE <NUM> and the neighboring UEs, load information for the neighboring UEs, or device capability information for the neighboring UEs.

In some embodiments of the method <NUM>, one or more of the announcements include a time parameter indicating time period during which the neighboring UE <NUM> will accept requests.

In some embodiments of the method <NUM>, sending a request to one of the neighboring UEs comprises sending the request during the indicated time period.

Some embodiments of the method <NUM> further comprise communicating with the remote UE <NUM> using the determined communication path.

<FIG> illustrates an exemplary method <NUM> implemented by relay UE <NUM> for relaying D2D communication between a requesting UE <NUM> and a remote UE <NUM>. The relay UE <NUM> broadcasts an announcement to one or more neighboring UEs <NUM> (block <NUM>). The announcement includes a neighbor list identifying one or more potential remote UEs <NUM> reachable by the relay UE <NUM>. The announcement can be broadcast periodically. In some embodiments, the relay UE <NUM> receives a relay request from one or more neighboring UEs <NUM> requesting the relay UE <NUM> to serves as a UE-to-UE relay (block <NUM>). The relay UE <NUM> adds these neighboring UEs <NUM> to its neighbor list and broadcasts the updated list in the next broadcast interval. The relay UE <NUM> further receives a request (e.g., Direct Communication Request or Solicitation message) from a requesting UE initiating D2D communication with a remote UE <NUM> in the neighbor list (block <NUM>). The request comprises identifying information for identifying a targeted remote UE <NUM>. The relay UE <NUM> further forwards the request to the remote UE identified by the request (block <NUM>).

Some embodiments of the method <NUM> further comprise receiving, responsive to the announcement, one or more relay requests from different ones of the neighboring UEs, and adding the neighboring UEs <NUM> that sent the relay requests to the neighbor list for subsequent announcements.

In some embodiments of the method <NUM>, forwarding the requests towards the remote UE <NUM> comprises forwarding the requests received in a predetermined time period following the announcement.

Some embodiments of the method <NUM> further comprise receiving, responsive to the request, a response message from the remote UE <NUM>, and forward the response message to the requesting UE <NUM>.

In some embodiments of the method <NUM>, the announcement includes a time parameters indicating a time period for accepting the request from the requesting UE <NUM>.

Some embodiments of the method <NUM> further comprise relaying D2D communications between the requesting UE <NUM> and the remote UE <NUM>.

<FIG> illustrates an exemplary method <NUM> implemented by remote UE <NUM> for D2D communication. The remote UE <NUM> receives an announcement broadcast by a relay UE <NUM> (block <NUM>). The remote UE <NUM> further sends to the relay UE <NUM> responsive to the announcement, a relay request requesting the relay UE <NUM> to serve as a relay for D2D communication (block <NUM>). In some embodiments, the remote UE <NUM> may further receive, via the relay UE, a request (e.g., Direct Communication Request or Solicitation message) originating from a requesting UE (block <NUM>). The remote UE <NUM> may further send, responsive to the request, a response message (e.g., Request Accept message or Solicitation Response message) to the requesting UE via the relay UE (block <NUM>).

Some embodiments of the method <NUM> further comprise receiving, via the relay UE <NUM>, a request originating from a requesting UE <NUM>, and sending, responsive to the request, a response message to the requesting UE <NUM> via the relay UE <NUM>.

In some embodiments of the method <NUM>, the announcement includes a time parameter indicating time period during which the relay UE <NUM> will accept the request to join the group.

In some embodiments of the method <NUM>, sending a relay request comprises sending the relay request during the time period indicated in the announcement.

Some embodiments of the method <NUM> further comprise communicating with the requesting UE <NUM> using one of the communication paths selected by the requesting UE <NUM> or remote UE <NUM>.

An apparatus can perform any of the methods herein described by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose 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, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

<FIG> illustrate exemplary embodiments of a UE <NUM> configured for D2D communication. In each of the embodiments shown in <FIG>, the UE <NUM> comprises an antenna array <NUM> including one or more antenna <NUM> for communicating with a base station <NUM> and with other UEs <NUM>. The UE <NUM> can be configured to function as a requesting UE, a relay UE, a remote UE, or any combination thereof.

<FIG> illustrates functional components of a requesting UE <NUM>. The requesting UE <NUM>, shown in <FIG>, comprises a broadcasting unit <NUM>, a receiving unit <NUM> and a determining unit <NUM>. The various units <NUM>-<NUM> may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The broadcasting unit <NUM> is configured to broadcast a request (e.g., Direct Communication Request or Solicitation message) initiating communication with a remote UE <NUM> to one or more neighboring UEs <NUM>. The request comprises a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. According to the invention, the relay indication further indicates a maximum number of hops for the communication path. The receiving unit <NUM> is configured to receive, responsive to the request, a response message (e.g., Request Accept message or Solicitation Response message) from one or more of the neighboring UEs <NUM>. The determining unit <NUM> is configured to determine a communication path for the D2D communication between the requesting UE and the remote UE based on the one or more response messages.

<FIG> shows the functional components of a relay UE <NUM>. The relay UE <NUM>, shown in <FIG>, further comprises a receiving unit <NUM> and a forwarding unit <NUM>. The various units <NUM>-<NUM> may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The receiving unit <NUM> is configured to receives a request (e.g., Direct Communication Request or Solicitation message) broadcast by a requesting UE initiating communication with a remote UE <NUM>. The request comprises a relay indication indicating whether relaying is allowed for a communication path between the requesting UE and the remote UE. According to the invention, the relay indication further indicates a maximum number of hops for the communication path. The forwarding unit <NUM> is configured to forward the request towards the remote UE.

<FIG> illustrates the functional components of a remote UE <NUM>. The remote UE <NUM>, shown in <FIG>, further comprises a receiving unit <NUM> and a sending unit <NUM>. The various units <NUM>-<NUM> may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The receiving unit <NUM> is configured to receive one or more copies of a request (e.g., Direct Communication Request or Solicitation message) broadcast by a requesting UE initiating communication with a remote UE <NUM>. The request comprises a relay indication indicating whether relaying is allowed for a communication path between the requesting UE <NUM> and the remote UE <NUM>. According to the invention, the relay indication further indicates a maximum number of hops for the communication path. The sending unit <NUM> is configured to further send to the requesting UE, responsive to each of one or more copies of the request, a response message (e.g., Request Accept message or Solicitation Response message) along the communication path on which the request was received.

<FIG> illustrate exemplary embodiments of a UE <NUM> configured for D2D communication. In each of the embodiments shown in <FIG>, the UE <NUM> comprises an antenna array <NUM> including one or more antenna <NUM> for communicating with a base station <NUM>. The UE <NUM> can be configured to function as a requesting UE, a relay UE, a remote UE, or any combination thereof.

<FIG> shows the functional components of a requesting UE <NUM>. The requesting UE <NUM>, shown in <FIG>, further comprises a first receiving unit <NUM>, a sending unit <NUM> and a second receiving unit <NUM>. The various units <NUM>-<NUM> may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The first receiving unit <NUM> is configured to receive announcements broadcast by one or more relay UEs <NUM>. Each announcement includes a neighbor list identifying one or more potential remote UEs reachable by the relay UE <NUM>. The sending unit <NUM> is configured to send a request (e.g., Direct Communication Request or Solicitation message) to a selected one of the relay UEs <NUM> having a remote UE <NUM> in its neighbor list, the request comprising identifying information (e.g., UE ID) for identifying a targeted remote UE. The second receiving unit <NUM> is configured to receive, responsive to the request, a response message (e.g., Request Accept message or Solicitation Response message) from the remote UE <NUM> relayed by the relay UE <NUM>.

<FIG> shows the functional components of a relay UE <NUM>. The relay UE <NUM>, shown in <FIG>, further comprises a broadcast unit <NUM>, a neighbor list unit <NUM>, a second receiving unit <NUM>, and a forwarding unit <NUM>. The various units <NUM>-<NUM> may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The broadcast unit <NUM> is configured to broadcast an announcement to one or more neighboring UEs <NUM>. The announcement includes a neighbor list identifying one or more potential remote UEs <NUM> reachable by the relay UE <NUM>. The announcement can be broadcast periodically. In embodiments including the neighbor list unit <NUM>, the relay UE <NUM> receives a relay request from one or more neighboring UEs <NUM> requesting the relay UE <NUM> to serves as a UE-to-UE relay and adds these neighboring UEs <NUM> to its neighbor list (block <NUM>). The broadcast <NUM> broadcasts the updated list in the next broadcast interval. The receiving unit <NUM> is configured to receive a request (e.g., Direct Communication Request or Solicitation message) from a requesting UE initiating D2D communication with a remote UE in the neighbor list. The request comprises identifying information (e.g., UE ID) for identifying a targeted remote UE <NUM>. The forwarding unit <NUM> is configured to forward the request to the remote UE <NUM> identified by the request.

<FIG> shows the functional components of a remote UE <NUM>. The remote UE <NUM>, shown in <FIG>, further comprises a first receiving unit <NUM>, a first sending unit <NUM>, a second receiving unit <NUM> and a second sending unit <NUM>. The various units <NUM>-<NUM> may be implemented by one or more microprocessors, hardware circuits, firmware, or a combination thereof. The first receiving unit <NUM> is configured to receives an announcement broadcast by a relay UE <NUM>. The first sending unit <NUM> is configured to sends to the relay UE <NUM> responsive to the announcement, a relay request requesting the relay UE <NUM> to serve as a relay for D2D communication. The second receiving unit <NUM> is configured to receive, via the relay UE <NUM>, a request (e.g., Direct Communication Request or Solicitation message) originating from a requesting UE <NUM>. The second sending unit <NUM> is configured to send, responsive to the request, a response message (e.g., Request Accept message or Solicitation Response message) to the requesting UE <NUM> via the relay UE <NUM>.

<FIG> illustrates a UE <NUM> according to another embodiment. The UE <NUM> comprises an antenna array <NUM> having one or multiple antennas <NUM>, communication circuitry <NUM>, processing circuitry <NUM>, and memory <NUM>.

The communication circuitry <NUM> is coupled to the antennas <NUM> and comprises the radio frequency (RF) circuitry (e.g., transmitter (Tx) <NUM> and receiver (Rx) <NUM>) needed for transmitting and receiving signals over a wireless communication channel. The processing circuitry <NUM> controls the overall operation of the UE <NUM> according to program instructions stored in memory <NUM>. The processing circuitry <NUM> may comprise one or more microprocessors, hardware, firmware, or a combination thereof.

Memory <NUM> comprises both volatile and non-volatile memory for storing computer program code and data needed by the processing circuitry <NUM> for operation. Memory <NUM> may comprise any tangible, non-transitory computer-readable storage medium for storing data including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. Memory <NUM> stores a computer program <NUM> comprising executable instructions that configure the processing circuitry <NUM> to implement one or more of the methods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> according to <FIG> respectively as described herein. A computer program <NUM> in this regard may comprise one or more code modules corresponding to the means or units described above. In general, computer program instructions and configuration information are stored in a non-volatile memory, such as a ROM, erasable programmable read only memory (EPROM) or flash memory. Temporary data generated during operation may be stored in a volatile memory, such as a random access memory (RAM). In some embodiments, computer program <NUM> for configuring the processing circuitry <NUM> as herein described may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program <NUM> may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Claim 1:
A method (<NUM>) for device-to-device, D2D, communication, the method (<NUM>) comprising:
a requesting user equipment, UE, (<NUM>, <NUM>, <NUM>) broadcasting (<NUM>) a Direct Communication Request initiating communication with a remote UE (<NUM>, <NUM>, <NUM>) to one or more neighboring UEs, the Direct Communication Request comprising a relay indication indicating whether relaying is allowed for a communication path between the requesting UE (<NUM>, <NUM>, <NUM>) and the remote UE (<NUM>, <NUM>, <NUM>) and having a value set by the requesting UE (<NUM>, <NUM>, <NUM>) to a maximum number of relays allowed for the communication path, wherein the Direct Communication Request is forwarded by a UE (<NUM>, <NUM>, <NUM>) if the value of the relay indication in the Direct Communication request as received by the UE (<NUM>, <NUM>, <NUM>) is greater than zero and the value of the relay indication is decreased with each forwarding of the Direct Communication Request;
the requesting UE (<NUM>, <NUM>, <NUM>) receiving (<NUM>), responsive to the Direct Communication Request, a response message from one or more of the neighboring UEs; and
the requesting UE (<NUM>, <NUM>, <NUM>) determining (<NUM>) a communication path for the D2D communication between the requesting UE (<NUM>, <NUM>, <NUM>) and the remote UE (<NUM>, <NUM>, <NUM>) based on the one or more response messages.