Method for optimizing relay reselection for sidelink communication

Abstract

The present invention relates to a method for optimizing relay reselection of sidelink communication between a source user equipment and a target user equipment, the method comprising: a first U2U relay sending a relay reselection request message to at least one U2U relay in the vicinity, where the sidelink communication is initially established via the first U2U relay; and at least one candidate U2U relay among the at least one U2U relay in the vicinity sending a response message in response to the relay reselection request message, thereby improving the efficiency of the relay reselection.

Description

[Technical field]

[0001] The present invention relates to the relaying of sidelink communications between two user equipments, namely a source user equipment and a target user equipment, and in particular to a method for optimizing relay reselection of such sidelink communications. [Background technology]

[0002] User-to-User (U2U) relay for 5G New Radio (NR) Proximity Service (ProSe) is a key technology in 3GPP™.

[0003] A U2U relay is a kind of User Equipment (UE) node that can be used as a relay. When a source UE wants to communicate with a target UE but cannot contact the target UE directly, the source UE can use a U2U relay to convey information and contact the target UE. Different from the traditional Base Station (BS)-UE communication over the Uu interface, the communication described in this invention is a device-to-device (D2D) sidelink communication over the PC5 interface.

[0004] Conventional sidelink communication from a source UE to a target UE via a U2U relay potentially requires several steps, such as: First, a relay discovery procedure is needed for source / target UEs to discover UE nodes in their vicinity. If direct sidelink communication is possible between source and target UEs, no U2U relay is needed. However, if the source UE cannot directly communicate with the target UE, the source UE needs to find UEs in its vicinity (by knowing the Layer 2 IDs of the nodes) that can act as U2U relays to contact the target UE.

[0005] Second, a relay / path / route selection procedure is used to select the most suitable U2U relay for communication between the source UE and the target UE.

[0006] Finally, once the optimal relay / path / route is selected, each pair of UE nodes needs to establish a Layer 2 communication link over which sidelink communication will take place.

[0007] In case of a sidelink failure due to a sudden change in UE mobility or radio propagation conditions (e.g. deep fading or blockage), the established sidelink may become unavailable and a U2U Relay Reselection procedure is required for the source UE to find a new U2U Relay and re-establish sidelink communication to the target UE via this new U2U Relay node.

[0008] There are currently various proposals for methods of U2U relay discovery, selection, and reselection, some of which are being discussed in the 3GPP SA2 group in the 5G system Phase 2 study item ProSe for Release 18.

[0009] As mentioned above, sidelink communication between source UE and destination UE via U2U relay typically involves three steps throughout the entire procedure: relay discovery, relay selection, and sidelink establishment signaling, followed by communication over the established link.

[0010] In particular, there are three state-of-the-art methods for relay detection proposed in 3GPP, which are described below.

[0011] The first approach is called Relay Discovery Model A. In this model, each U2U relay actively sends periodic announcement information to surrounding UEs indicating that it can act as a U2U relay to contact target UEs. The procedure of Relay Discovery Model A is shown in Figure 1.

[0012] As shown in Fig. 1, in steps 1 and 2 of Relay Discovery Model A, the source UE (UE-1 in the figure) and the U2U relay (UE-R in the figure) acquire the Layer 2 IDs of the nodes using a prerequisite procedure called group member discovery. This procedure is specified in LTE ProSe communication. In this case, when the U2U relay sends a periodic announce message, instead of performing a broadcast that may interfere with many UEs, this message is sent in a groupcast format. The U2U relay discovery starts from step 3, where the U2U relay periodically sends an announce message with the following format: -Type=Announcement -Disco Type (detection type) = UE-to-UE relay detection -Announcer Info (i.e., the upper layer identifier of the UE-R user) -UE-R's ProSe UE ID (i.e., the Layer 2 identifier of the UE-R) -List of "Target User Info" parameters Here, "Target User Info" is a higher layer parameter that identifies the target user. To support Layer 2 communication via stateful U2E relay, "Target User Info" also includes the Layer 2 identifier of the target user's UE. "Target User Info" may also include parameters collected during group member discovery in step 2.

[0013] Thereafter, in step 4 of FIG. 1, the source UE (UE-1) communicates with the target UE (UE-2 in the figure) via the U2U relay (UE-R).

[0014] Some variations of the relay discovery model A are also proposed in 3GPP. For example, instead of using the group member discovery procedure in steps 1 and 2, another procedure called direct discovery procedure can be used to obtain the layer 2 ID. This procedure is also specified in LTE ProSe communication. If there has been previous direct communication between the UEs, the previously determined layer 2 ID can also be used. In addition, the announce message format includes a relay service code (RSC).

[0015] There is another variation of Relay Discovery Model A in which there is no prerequisite procedure such as Group Member Discovery or Direct Discovery that allows the U2U Relay to obtain the Layer 2 ID of the Announcement Message recipient UE. In this case, the periodic Announcement message is sent in a broadcast format. In addition, a Relay Service Code (RSC) is also included in the Announcement message format.

[0016] The second relay discovery model proposed in 3GPP is Relay Discovery Model B. In this model, instead of using periodic announce messages, reactive on-demand solicitation and response messages are used for relay discovery. The procedure of Relay Discovery Model B is shown in Figure 2.

[0017] Similar to Model A, in steps 1 and 2 of Relay Discovery Model B, the source UE and U2U relay obtain the Layer 2 IDs of the corresponding nodes using the prerequisite group member discovery procedure. After step 1, UE-1 realizes that the target user is not in direct range via NR PC5. Then, in step 3, UE-1 solicits potential U2U relays by sending a solicitation message containing the following parameters: -Type=Request -Disco Type = UE-to-UE relay detection -Discoverer Info (i.e., the higher layer identifier of the UE-1 user) -UE-1's ProSe UE ID (i.e., UE-1's Layer 2 identifier) - List of "Target User Info" parameters.

[0018] Upon receiving the Request message, in step 4 of Figure 2, the UE-R recognizes that it can act as a U2U relay and replies with a Response message containing the following parameters: -Type=Response -Disco Type = UE-to-UE relay detection -Discoverer Info (i.e., the upper layer identifier of the UE-R user) -UE-R's ProSe UE ID (i.e., the Layer 2 identifier of the UE-R) - List of "Target User Info" parameters.

[0019] Thereafter, in step 5 of FIG. 2, the source UE (UE-1) communicates with the target UE (UE-2) via the U2U relay (UE-R).

[0020] Some variations of the relay discovery model B are also proposed in 3GPP. For example, instead of having UE1 perform group member discovery to obtain layer 2 IDs of potential U2U relays in step 1, the solicitation message is a broadcast message. Also, similar to the variations in model A, instead of having the U2U relay perform group member discovery in step 2, the layer 2 IDs can be identified using a direct discovery procedure or previous direct communication information. In addition, a relay service code (RSC) is also included in the announce message format.

[0021] There are several other variants of the relay discovery model, which do not take into account the prerequisite group member discovery or direct discovery procedure to obtain a layer 2 ID or previous direct communication. In this case, the solicitation message is a broadcast message, and when a potential U2U relay receives the solicitation message, it forwards the solicitation message by broadcasting it to its neighbors according to its capabilities as a U2U relay. This procedure is similar to the traditional ad-hoc on-demand distance vector (AODV) algorithm in mobile ad-hoc networks (MANETs). The target UE can receive several forwarding solicitation messages from different U2U relays. The target UE can select one U2U relay and send a response message, which is forwarded to the source UE by the selected U2U relay, or it can send a response message to each U2U relay that forwards the solicitation message. In the latter case, each U2U relay forwards the response message to the source UE, which makes the final selection regarding the optimal U2U relay.

[0022] A third relay discovery model proposed in the current 3GPP discussions integrates relay discovery, relay selection, and PC5-signaling (PC5-S) procedures to reduce signaling overhead. Thus, the procedure is initiated directly with a direct communication request from the source UE to the target UE. A direct communication request (DCR) is a message in the PC5-S protocol that initializes a layer 2 link establishment between two UE nodes. Since the source UE cannot directly contact the target UE, the U2U relay that receives the DCR message forwards and broadcasts the DCR message to its neighbors using a method similar to AODV described above in the variant of model B.

[0023] For relay reselection (e.g., in case of relay reselection due to sidelink failure caused by sudden change in UE mobility or radio propagation conditions), there are two state-of-the-art proposals in 3GPP. The first and simplest method is to restart the relay discovery procedure described above from the beginning. In this way, the source UE can learn updated information of potential U2U relays and perform the reselection. The second proposal involves negotiation between the source UE and the target UE via the current U2U relay. The procedure of this negotiation-based relay reselection model is shown in Figure 3.

[0024] In this negotiation-based relay reselection model, after connection setup between two UEs via Relay 1 in step 1 of Fig. 3, the source UE decides to perform U2U relay reselection, as shown in step 2 of Fig. 3. This can be triggered when it receives a Relay Discovery message from another U2U relay and the signal quality with this U2U relay is better than the signal quality with the current U2U relay (Relay 1). Alternatively, if the source UE finds that the signal quality with Relay 1 is not good enough, it initiates a discovery message to find a candidate UE-UE relay that can provide a better connection.

[0025] After the source UE identifies the candidate U2U relays, the source UE sends a U2U relay reselection request to the target UE using the connection via Relay 1 (step 3 in Figure 3), and the request message includes a list of candidate U2U relay IDs ordered by the source UE's priority, e.g., based on the signal quality of the U2U relays.

[0026] Then, in step 4 of Fig. 3, the target UE decides to change from Relay 1 to a new UE-UE relay. The new U2U relay is chosen from the candidate list included in the reselection request. This decision can be based on the new U2U relay that provides the best signal quality, and can also be based on the order of candidate U2U relay IDs received from the source UE. If the target UE has not received a relay discovery message from a candidate U2U relay or is not connected to a candidate U2U relay, the target UE can perform a U2U relay discovery procedure using the IDs of the candidate U2U relays in the discovery message.

[0027] Then, in step 5 of Figure 3, the target UE sends a response including the ID of the new U2U relay to the source UE via Relay 1. If a new U2U relay is not selected, the target UE may not respond to the source UE or may send a response indicating relay reselection failure.

[0028] Finally, once a new U2U relay, i.e. Relay 2, is selected, a new connection is set up between the source UE and the target UE via the new U2U relay in step 6 of FIG. 3 .

[0029] However, when the current relay fails due to radio condition transition or sidelink failure (which may be caused by sudden changes in UE mobility or radio propagation conditions), relay reselection is required. In particular, considering sudden sidelink failures that are highly likely to occur in high mobility scenarios such as V2X or high-speed train communications, or fast-varying channels or complex environments with various interruption effects, the above-mentioned proposals of relay reselection in the art are not realistic since they require negotiation between source UE and target UE via the current U2U relay.

[0030] According to the current proposal in 3GPP, when such a sudden sidelink failure occurs, there is no option but to restart the relay discovery procedure from the beginning. However, restarting the relay selection procedure is far from optimal. Starting and completing the relay discovery procedure from the beginning is time consuming and also causes service outages. The current solution proposed in 3GPP cannot guarantee service continuity and QoS continuity.

[0031] Even so, the current methods of negotiation between source UE and target UE via U2U relay in the art can somehow anticipate potential performance degradation by monitoring sidelink radio conditions, and then trigger negotiation between source UE and target UE while the current sidelink communication via U2U relay is still good. However, in certain communication scenarios such as vehicle-to-everything (V2X) or high-speed trains, or scenarios with fast-changing radio propagation conditions, e.g., deep fading, blockages, moving scattering objects, sudden sidelink failures may occur before source UE and target UE negotiate a reselected U2U relay. In such an event, the above-mentioned methods in the art cannot solve the problem, and according to the current proposal in 3GPP, it is inevitable to restart the relay discovery and selection procedure. In addition, the relay reselection criteria proposed in the above methods are based on sidelink signal quality and cannot fully reflect application-level requirements such as QoS. Summary of the Invention [Problem to be solved by the invention]

[0032] The present invention aims to address these problems in the art and to optimize relay reselection. [Means for solving the problem]

[0033] In this regard, according to one aspect of the present invention, there is provided a method for optimizing relay reselection for sidelink communication between a source user equipment and a target user equipment, in particular in the context of off-network UE-to-UE communication based on a sidelink PC5 interface, the method comprising: - a first U2U relay sending a relay reselection request message to at least one surrounding U2U relay, where the sidelink communication is initially established via the first U2U relay; At least one candidate U2U relay among at least one surrounding U2U relay sends a response message in response to the relay reselection request message; Includes.

[0034] Such an arrangement differs from state-of-the-art proposals for relay reselection, where the source / target UE either restarts the relay discovery procedure from scratch or negotiates relay reselection between the source and target UEs via the current relay. In the present invention, the current relay, i.e., the first U2U relay, initiates the relay reselection procedure by sending a solicitation message to find a suitable second U2U relay for relay reselection. Thus, the present invention is more efficient for relay reselection under certain circumstances, such as a sudden sidelink failure event.

[0035] Advantageously, the request message includes the Layer 2 IDs of both the source user equipment and the target user equipment. In addition, the request message includes an indication as to which node (source, target or relay) the response is to be sent to. In particular, the request message includes an indication of a return address to the source user equipment, the target user equipment or the first U2U relay to which a response message is to be sent in order to inform at least one candidate U2U relay that receives the request message.

[0036] Advantageously, the request message further includes service contextual information regarding the service traffic passing through the first U2U relay.

[0037] Advantageously, the response message includes the Layer 2 ID of at least one candidate U2U relay. In particular, the response message may further include service support information provided by the candidate U2U relay including predictions regarding the candidate U2U relay's own performance.

[0038] Advantageously, the service context information or service support information includes any one of end-to-end (E2E) QoS, relay loading, QoS sustainability, and application level information.

[0039] According to one embodiment of the invention, during the step of transmitting a response message in response to the request message, The response message is sent to the first U2U relay, or A response message is sent to the source user equipment or the target user equipment.

[0040] According to one embodiment of the invention, the method includes, before the step of sending the request message, - establishing a connection between a source user equipment and a target user equipment via a first U2U relay; Including, The method further comprises, after the step of transmitting the response message, determining at least one second U2U relay for relay reselection by the first U2U relay; Includes.

[0041] Advantageously, at least one candidate U2U relay receives the solicitation message and decides to volunteer as the second U2U relay for the relay reselection.

[0042] Advantageously, the method according to the invention comprises the steps of: making a relay reselection decision and selecting at least one second U2U relay for relay reselection from among the at least one candidate U2U relay based on the service support information; Further includes.

[0043] Advantageously, the step of determining at least one second U2U relay for relay reselection comprises: - the first U2U relay directly or indirectly determines at least one second U2U relay suitable for relaying instead of or in addition to the first U2U relay, Includes.

[0044] Therefore, in addition to having the UE relay directly or indirectly decide a group of UE relays suitable to relay instead of or in addition to itself, the present invention proposes a decision process that can include service context information and service assistance information regarding end-to-end (E2E) QoS, relay loading, QoS sustainability, and application level information. Thus, the present invention can ensure service continuity and QoS continuity / sustainability during relay reselection for communication between two UEs when radio conditions change due to, for example, mobility, blocking, or deep fading.

[0045] Furthermore, according to another embodiment of the present invention, during the step of transmitting a relay reselection request message, If the first U2U relay knows the Layer 2 ID of at least one candidate U2U relay, the first U2U relay sends a solicitation message to at least one candidate U2U relay in a unicast or groupcast format; If not, The first U2U relay sends a solicitation message in a broadcast format.

[0046] Additionally, during the step of making a relay reselection decision, the relay reselection decision may be made based on the following metrics: the radio link quality; -Service support information, -implementation specific priorities and This is based on at least one of the following:

[0047] Moreover, according to yet another embodiment of the present invention, the method according to the present invention comprises the steps of: - Establishing a new connection between the source user equipment and the target user equipment via a second U2U relay; Further includes:

[0048] According to another aspect of the invention there is provided a computer program comprising program code which is executed by a processor, the program code being adapted to carry out the inventive method as described above.

[0049] Other aspects and advantages of the present invention are described in the following exemplary embodiments. Those skilled in the art can clearly understand the content and technical effects of the present invention obtained based on these exemplary embodiments.

[0050] Other features and advantages of the present invention will become apparent from the following description, taken in conjunction with the accompanying drawings. [Brief description of the drawings]

[0051] [Figure 1] FIG. 1 illustrates a relay detection model A in the art. [Diagram 2] FIG. 1 illustrates a relay detection model B in the art. [Diagram 3] FIG. 1 illustrates a negotiation-based relay reselection model in the art. [Figure 4] FIG. 1 illustrates an embodiment of U2U relay reselection according to the present invention. [Diagram 5]1 is a flowchart illustrating a decision flow for sending a request message by a current U2U relay according to the present invention. [Figure 6] 4 is a flow chart illustrating a decision flow for handling a message according to the present invention. [Figure 7] FIG. 1 illustrates one embodiment of U2U relay reselection as an alternative to a two-hop relay in accordance with the present invention. [Figure 8] FIG. 1 illustrates one embodiment of U2U relay-plus-self reselection for multi-hop relay in accordance with the present invention. [Figure 9] A diagram illustrating one embodiment of an example of U2U relay reselection with higher layer information. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0052] Fig. 4 shows an exemplary embodiment of a relay reselection method according to the present invention. The figure illustrates off-network U2U communication based on a sidelink PC5 interface, where a source user equipment, source UE, can connect to a target user equipment, target UE, via any one of U2U relays 1-3.

[0053] The exemplary method includes the following steps. Step 1: A connection between source UE and target UE via U2U Relay 1 is established by using relay discovery, selection and link establishment methods in the art, such as current 3GPP proposals as described above. Once the layer 2 link is established, traffic is forwarded via U2U Relay 1, which can be either an L2 or L3 U2U relay.

[0054] Step 2: U2U relay 1 decides to perform U2U relay reselection, which can be triggered by any one of the following situations: a. When a sidelink failure event occurs and the source user equipment UE and the target user equipment UE do not have time to negotiate relay selection before the event occurs, the U2U Relay1 observes a link failure on either the source UE-U2U Relay1 link or the U2U Relay1-target UE link; b. U2U Relay1 monitors the source UE-U2U Relay1 link and / or the U2U Relay1-target UE link and observes any changes in radio link conditions that may indicate either an upcoming link failure or that there is a U2U Relay with potentially better radio link conditions to relay; and Periodically, or when the link quality drops below a given level. In this case, the reselected relay is kept in a waiting list for when relay reselection is required, as described below.

[0055] Step 3: U2U Relay 1 sends a relay reselection request message to other U2U relays in the vicinity (U2U Relay 2 and U2U Relay 3 in the figure). The format of this request message is different from the format in Relay Discovery Model B as described above. The request message includes Layer 2 IDs of both source UE and target UE, and optionally service context information about the service traffic that previously passed through U2U Relay 1. The service context information includes E2E QoS of sidelink communication from source UE to target UE, application level information about the traffic, QoS sustainability requirements, etc. A detailed description of the request message format will be provided later.

[0056] Furthermore, in step 3, many sub-scenarios may occur, the embodiments of which are described below.

[0057] Step 4: Among the U2U relays in the vicinity of U2U relay 1, those that receive the request message and consider themselves as candidate U2U relays for relay reselection send a response message in response to the request message. The format of this response message is different from that proposed in the relay discovery model B above. This response message includes the layer 2 ID of this U2U relay and other service support information that can be used for relay selection. The service support information includes, but is not limited to, this U2U relay's prediction of source side QoS and target side QoS for E2E QoS in the request message, the load of this U2U relay, QoS sustainability, etc. A detailed description of this response message format will be given later.

[0058] Additionally, in step 4, many sub-scenarios may occur, the embodiments of which are described below.

[0059] Step 5: A relay reselection decision is made. This decision can be made either by the source / target UE or by the U2U Relay 1, depending on how the response message procedure in step 4 is implemented. A more detailed description will be given later.

[0060] Step 6: Once a new U2U relay is reselected, a connection between the source UE and the target UE via the new U2U relay is established. This Layer 2 link connection can be initiated by either the source UE or the new U2U relay. A detailed description will be given later.

[0061] In one exemplary embodiment, a waiting list may be used and the reselection procedure as described above may be divided in time into two parts: The first part consists of steps 2-4 in Fig. 4 mentioned above. After this part, a list of candidate U2U relays is obtained and stored in a waiting list at a selection point. The selection point can be a relay UE, a source UE or a target UE. This list can be updated periodically, i.e. this part of the procedure is executed periodically.

[0062] The second part consists of steps 5 and 6 described above, i.e. relay selection from the waiting list and setup with the new relay. The criteria for candidate selection are the same as when the full selection procedure is performed sequentially.

[0063] Optionally, the relay UE can store the waiting list even if the selection point is at the source UE or target UE. In this case, when relay reselection needs to be performed (e.g., when the link quality becomes too poor), the relay provides the source UE or target UE with a list of candidate U2U relays from the waiting list. For example, the relay builds a response message from the waiting list when a response message is received from a candidate U2U relay, and provides the response message to the source UE or target UE on behalf of the candidate U2U relay. Thus, the source UE or target UE is not affected by the use of the waiting list.

[0064] The advantage of using the waiting list is that it improves service continuity: in fact, if one link quality suddenly degrades, a new relay is picked up from the waiting list without the need to first find a candidate U2U relay among the surrounding relays.

[0065] A relay may decide to build or update the waiting list based on various criteria, for example, periodically, or only when radio conditions deteriorate.

[0066] Steps 3-6 of the embodiment of FIG. 4 are described in more detail below.

[0067] -Step 3 In step 3, the first U2U relay, i.e., U2U Relay 1, sends a Relay Reselection Request message to find a U2U relay (or a group of U2U relays if multi-hop relay is enabled) on its behalf or as a group of U2U relays including itself (if multi-hop relay is enabled).

[0068] The first aspect of the solicitation message is how U2U Relay 1 knows the Layer 2 ID of other U2U Relays so that it can send the solicitation message. This is shown in Figure 5, where: One scenario is that the Layer 2 IDs of potential U2U relays, e.g., U2U relays in the vicinity of U2U relay 1, are already known by the current U2U relay 1. This can occur, for example, due to the following circumstances: (1) If there is previous sidelink direct communication / direct discovery / group member discovery (see LTE ProSe TS 23.303) between U2U Relay 1 and a potential U2U Relay, (2) If a previous relay detection procedure (either Model A or B, or any other procedure described in Section 3.1) exists and the current U2U relay has already detected other potential U2U relays, (3) If the layer 2 IDs of other potential U2U relays have been provided to the current U2U relay by the application level server, e.g., considering that all U2U relays are infrastructure nodes providing sidelink relay capabilities of vehicle / train private networks, the application level server can directly provide each U2U relay with each other's layer 2 IDs using application level signaling. In such a case, the current U2U relay can send a solicitation message to the targeted candidate U2U relays in a unicast or groupcast format.

[0069] Another scenario is that the layer 2 ID of the potential U2U relay is not known by the current U2U relay. In this case, there are two possibilities for the current U2U relay. Possibility 1 is that the current U2U relay initiates a group member discovery / direct discovery / direct communication request procedure to discover candidate U2U relays in the vicinity and obtain their layer 2 IDs. Possibility 2 is that a solicitation message is broadcast by the current U2U relay.

[0070] The second aspect of the solicitation message is its format. In contrast to the solicitation message in the relay discovery model B described above, the solicitation message contains the following parameters: -Type=Request -Disco Type=U2U Relay Reselection -Discoverer Info (i.e. the upper layer identifier of the current U2U relay) - ProSe UE ID of the current U2U relay (i.e., Layer 2 ID of the current U2U relay) - The ProSe UE ID of the source UE (i.e., the Layer 2 ID of the source UE) - ProSe UE ID of the target UE (i.e., Layer 2 ID of the target UE) - (Optional) A list of "service context information" parameters - (Optional) Enable (or disable) Solicit Message Forwarding, which is a constraint on Solicit Message Forwarding; Response message recipient indicator (possible recipients are either the source UE, or the target UE, or the current U2U relay, or an intermediate U2U relay if multi-hop routing is enabled) - List of "Target User Info" parameters.

[0071] In this case, preferably, the current U2U relay 1 provides the recipient with Layer 2 IDs of source UE / target UE / current U2U relay 1 itself in the request message, and service context information such as E2E QoS of sidelink communication from source UE to target UE, application level information about the traffic, QoS sustainability requirements, etc. Optionally, the current U2U relay 1 can also indicate whether the recipient of the request message can or cannot forward this message to other candidate U2U relays in the recipient's vicinity, and if the request forwarding is possible, additional constraints on the request message forwarding (e.g. maximum number of hops to forward, etc.).

[0072] -Step 4 In step 4, any U2U relay that receives the Solicitation message and considers itself a candidate for relay reselection sends a Response message.

[0073] The first aspect of the reply message is what other U2U relays do when they receive the solicit message, which is shown in Figure 6 and relates to the solicit message scenario described in Figure 5.

[0074] As shown in Figure 6, if the solicitation message is unicast / groupcast (meaning that the layer 2 ID of the receiver is indicated), the U2U relay with the layer 2 ID corresponding to the receiver will receive the solicitation message and proceed to the next step (step 5) to see if it can be a candidate U2U relay for relay reselection. If the U2U relay is not the intended receiver of the unicast / groupcast solicitation message, it will simply discard the message.

[0075] The situation is more complicated when the solicitation message is broadcast, also as shown in Figure 6. A U2U relay that receives the broadcasted solicitation message first decodes the message and then proceeds to the next step (step 5) to see if it can be a candidate U2U relay for relay reselection.

[0076] Furthermore, after the candidate U2U relay decides whether to decode and respond, the candidate U2U relay also checks the solicitation message forwarding part to see if it has the authority to forward this solicitation message to its neighbors in a broadcast format. If the answer is yes, the candidate U2U relay also checks the solicitation forwarding constraints when forwarding this solicitation message and updates this field accordingly. For example, if a maximum forwarding hop count exists in the solicitation forwarding constraints, the U2U relay decreases this value by 1 when forwarding the solicitation message. Also, to reduce the duplication of forwarding, all U2U relays perform the solicitation message broadcast forwarding only once for the solicitation messages with the same triplet set of source UE / target UE / current U2U relay Layer 2 ID.

[0077] The second aspect of the response message is how each U2U relay that receives the request message can determine whether it can be a volunteer for relay reselection.

[0078] If the request message is a unicast / groupcast message dedicated to the received U2U relay or if the request message is a groupcast message, the U2U relay can decode the request message and obtain the layer 2 IDs of the source UE, the target UE, and the current U2U relay 1. With the layer 2 IDs of the source UE and the target UE, the U2U relay can verify whether it can establish a direct communication link with them using the direct detection procedure / direct communication request (see LTE ProSe TS23.303). Furthermore, if direct communication is possible, with the service context information received in the request message, the U2U relay can also predict and generate service assistance information for the possible direct communication link. The service assistance information can be used for relay selection. For example, assume that the E2E QoS of the service traffic is included in the request message. In that case, the U2U relay can predict the source side QoS and the target side QoS based on the feedback of the direct detection procedure / direct communication request of the direct communication link quality (e.g., signal strength) and the pre-configured look-up table of the QoS profile of the QoS split.

[0079] If the candidate U2U relays perform relay discovery in Model A above, this implies that each candidate U2U relay periodically broadcasts an announce message informing other UEs in the vicinity that it can be a U2U relay. Such a procedure can also improve relay reselection.

[0080] In this case, the Layer 2 IDs of the source UE and target UE are not mandatory for the candidate U2U relay, since the source UE and target UE can obtain their own Layer 2 IDs during the Model A announcement and establish Layer 2 links with the candidate U2U relay.

[0081] However, the service context information and service assistance information are still useful for optimizing relay selection. When the current U2U relay sends a solicitation message with the service context information and the candidate U2U relay in model A receives such information, the candidate U2U relay can add the service assistance information to the broadcast announcement as a personal performance prediction given the flow / application requirements specified in the service context information. In this way, the source UE can make a better reselection when it receives the enhanced version of the announcement message during proximity sensing.

[0082] The third aspect of the reply message is to whom the U2U relay should send the reply message. The candidate U2U relay can obtain information about the recipient of the reply message from the reply message recipient indicator field in the request message. The reply message recipient indicator field specifies the return address to which the reply message should be sent. Various exemplary implementations are given below. -The response message is sent to the first U2U relay (U2U relay 1, i.e., the U2U relay that first sends the request message). In this case, the first U2U relay can receive multiple response messages from different candidate U2U relays.

[0083] A response message is sent to the source / target UE, where the source / target UE may receive multiple response messages from different candidate U2U relays.

[0084] -If the request message is a broadcast request forwarded by an intermediate U2U relay, the candidate U2U relay sends a response message to the intermediate U2U relay, which is sent backwards until it reaches the U2U relay that originally sent the request broadcast.

[0085] The fourth aspect of the response message is its format, the response message format. In contrast to the response message in the relay discovery model B described above, this response message includes the following parameters: -Type=Response -Disco Type=U2U Relay Reselection -Discoverer Info (i.e., the upper layer identifier of the candidate U2U relay) - ProSe UE ID of the candidate U2U relay (i.e., Layer 2 identifier of the candidate U2U relay) -List of "Target User Info" parameters - (Optional) A list of "service assistance information" parameters.

[0086] In the response message, the candidate U2U relay can provide service support information such as its QoS split expectation for E2E QoS (i.e., source-side QoS and target-side QoS), candidate U2U relay load, QoS sustainability, etc. This service support information can be used for relay reselection.

[0087] -Step 5 In step 5, a relay reselection decision is made by the source UE, the target UE or the first U2U relay depending on who the response message is sent to. The receiver entity of the response message may receive multiple messages from different candidate U2U relays and may make a final decision based on (1) radio link quality (e.g., signal strength), (2) the service assistance information mentioned above, (3) implementation specific preferences (e.g., preferring routing with fewer hops when multi-hop is considered, or preferring U2U relays in a certain geolocation region), or (4) a combination of these metrics.

[0088] -Step 6 In step 6, the layer 2 link establishment procedure can be initiated by different entities depending on who sends the response message and who makes the final decision regarding relay reselection.

[0089] If the first U2U relay decides to relay reselection, it indicates this decision to the reselected U2U relay, which initiates a direct communication request to establish a layer 2 link with both the source UE and the target UE. If the source / target UE makes the final decision regarding relay reselection, it initiates the direct communication request. In this case, if the reselected U2U relay is an L2 relay, the direct communication request from the source (target) UE to the target (source) UE is relayed by the reselected U2U relay. If the reselected U2U relay is an L3 relay, the direct communication request is from the source (target) UE to the reselected U2U relay, which initiates a second direct communication request from itself to the target (source) UE.

[0090] Furthermore, in the context of the present invention, the initial first U2U relay 1 can directly or indirectly determine group candidate U2U relays suitable to relay instead of or in addition to itself.

[0091] When replacing the current U2U relay, only 2-hop U2U relay (source UE-U2U relay-target UE) is considered. After relay reselection, the first U2U relay 1 connecting with the source UE and target UE is replaced by U2U relay 2, as shown in Figure 7.

[0092] If we relay instead of the current U2U relay and add ourselves to find the optimized relay, this is a multi-hop U2U relay, as shown in Figure 8.

[0093] In one exemplary embodiment of Figure 8, it is the current U2U relay 1 that initiates the solicitation message to find a group of candidate U2U relays (relays 2-4) in addition to the current U2U relay 1 itself. For example, in Figure 8, after reselection, the source UE is connected to the target UE via both U2U relays 1 and 2. The difference from the first case of selecting a relay as an alternative is in the service context information and service support information.

[0094] For example (without loss of generality), consider the QoS information as service context / assistance information and consider the scenario shown in FIG. 8. The current relay node sends a request message to find additional U2U relays, but the service context information included in this request message is not E2E QoS requirement as in the case of finding an alternative U2U relay. In this scenario, the service context information is the target UE side QoS that the current U2U relay negotiated with the target UE during sidelink communication before relay reselection. Upon receiving this request message, each candidate U2U relay can predict its own performance by providing a QoS split for the relay node side QoS over the link to the current U2U relay and the target UE side QoS over the link to the target UE. This split is based on the target UE side QoS input received in the request message. After making the QoS split and including it in the service assistance information of the response message, each U2U candidate must send this response message to the current U2U relay that initiates the request. Upon receiving multiple copies of the response message from multiple candidate U2U relays, the current U2U relay node can select the optimal additional node based on the service assistance information.

[0095] Optionally, in case of multiple additional hop U2U relays (e.g., U2U relay 2 in FIG. 8 relays as an additional U2U relay, and this additional U2U relay 2 relays to the target UE), the above-mentioned procedure is performed one after another (the newly selected additional U2U relay 2 repeats what the relay node did to find additional successor U2U relay nodes).

[0096] Next, the service context information and the service assistance information will be described in detail, and in particular, some example embodiments of how the service context information provided from the current U2U relay and the service assistance information provided by the candidate U2U relay can be used to optimize relay reselection will be described.

[0097] The first embodiment relates U2U relay reselection to QoS prediction. In this embodiment, the current U2U relay initiates the request message as described in step 3 of the present invention. The service context information included in the request message is the E2E QoS of the currently offered sidelink flow. More precisely, the first PQI (PC5 QoS identifier), the associated QoS profile and parameters are the service context information. The QoS profile and parameters are e.g. resource type, priority, packet delay budget (PDB), packet error rate (PER) and guaranteed flow bit rate (GFBR), which are parameters indicating application flow characteristics / constraints. This information is available at the current U2U relay when sending the request message, since they are sent from the source UE to the current U2U relay during the Layer 2 link establishment / change between the source UE and the current U2U relay.

[0098] For example, in one particular embodiment, the current U2U relay sends a request message with included service context information as follows: PQI: 23, GFBR: 1Mbps

[0099] One candidate U2U relay, for example Relay 2, can decode the solicitation message to obtain the Layer 2 IDs of the source UE, the target UE, and the above service context information. Relay 2 can use the Layer 2 IDs to send a DCR to the source / target UE to verify whether a Layer 2 link with the source UE and the target UE can be established. Upon receiving the DCR, the source UE and the target UE can respond with a “Direct Communication Accept” to confirm that the sidelink between Relay 2 and the source / target UE is available. Upon receiving the “Direct Communication Accept”, Relay 2 can use the received signal level of this acknowledgement to roughly estimate the sidelink quality. Furthermore, Relay 2 is either (1) pre-configured or (2) configured by the cellular base station when a look-up table of supported QoS profiles of the associated source side PC5 QoS parameters and the associated target side PC5 QoS parameters exists within the coverage of the base station.

[0100] For the relevant source side PC5 QoS parameters in relay 2, assume that the pre-configured lookup table of supported QoS profiles is as follows: [Table 1]

[0101] According to the E2E QoS service context information, PQI:23, GFBR:1Mbps.

[0102] Since the line with PQI=22 has a very large PER, the source side PC5 QoS that may satisfy the above E2E QoS is the lines with PQI=21, 26, and 28.

[0103] Assuming that relay 2 has a similar table for target side PC5 QoS, it performs the same method to estimate the sidelink capacity of the sidelink between relay 2 and target UE. For illustration purposes, assume that the maintained target side PC5 QoS is PQI=21, 26, 28.

[0104] Since the delay budget for E2E QoS is 100ms, the sum of source side PC5 QoS and target side PC5 QoS must respect this delay constraint, therefore the combination of source side PQI=26 and target side PQI=28 cannot be used.

[0105] Assuming that the received signal level of the “Direct Communication Accept” message from the source UE is SINR_s (not excluding other possible physical layer measurements such as RSRP, RSRQ, etc.), Relay 2 can roughly estimate the sidelink capacity of the sidelink at the source UE side as C_s=log(1+SINR_s). The source / target side PC5 QoS parameter GFBR can be roughly estimated as C_s*BW (C_t*BW for target side, where BW is the system bandwidth).

[0106] Finally, the response message of Relay 2 includes the service support information for the following pairs (supported PQI, estimated GFBR) of supported source side PC5 QoS and target side PC5 QoS: (Source side: PQI=21, GFBR=xx1, Target side: PQI=21, GFBR=yy1), (Source side: PQI=21, GFBR=xx1, Target side: PQI=26, GFBR=yy1), (Source side: PQI=21, GFBR=xx1, Target side: PQI=28, GFBR=yy1), (Source side: PQI=26, GFBR=xx1, Target side: PQI=21, GFBR=yy1), (Source side: PQI=26, GFBR=xx1, Target side: PQI=26, GFBR=yy1).

[0107] Assume that another candidate U2U relay 3 performs the same procedure as relay 2 and sends a response message with service support information of supported source side PC5 QoS and target side PC5 QoS pairs to the source UE. When the source UE receives multiple response messages from different candidate U2U relays, it can make a final decision on relay selection based on the service support information. The decision criteria can be entirely implementation specific, for example, selecting a U2U relay that can provide an exactly matched pair of source side PC5 QoS split and target side PC5 QoS split considering congestion control parameters at the source UE, for example, selecting relay 2 with pair (source side: PQI=26, GFBR=xx1, target side: PQI=26, GFBR=yy1). Alternatively, the source UE can take a margin on the delay if the application is really delay critical. For example, the source UE may select Relay 2 with a pair (source side: PQI=21, GFBR=xx2, target side: PQI=21, GFBR=yy2) with an estimated E2E PDB of 40 ms for an E2E QoS requirement of 100 ms as delay requirement, or the source UE may select a better combination with GFBR if the delay and PER constraints are met.

[0108] Once relay reselection is decided, a Layer 2 link establishment procedure between the source UE and the reselected relay and between this relay and the target UE can be established and the corresponding QoS agreed upon.

[0109] Another embodiment relates to U2U relay reselection with QoS sustainability. In this embodiment, QoS sustainability is a parameter that defines the reliability of providing a given QoS level in time. For example, QoS sustainability can be (low, medium, high) and can be calculated according to, for example, node mobility, load forecast, battery level (power consumption).

[0110] For example, in one particular embodiment, the current U2U relay sends a request message containing service context information such as: PQI: 23, GFBR: 1Mbps

[0111] The candidate U2U relay can return a response message containing the following service support information: (Source side: PQI=26, GFBR=x1, QoS sustainability: medium, Target side: PQI=26, GFBR=y1, QoS sustainability: high).

[0112] Another candidate U2U relay can reply with the following service support information: (Source side: PQI=21, GFBR=x1, QoS sustainability: low; Target side: PQI=21, GFBR=y1, QoS sustainability: low).

[0113] In this case, in order to have better QoS sustainability, the source UE may choose the first U2U relay candidate among the above.

[0114] Yet another embodiment relates to U2U relay reselection with higher layer information, in which we assume that the U2U relays are road side units (RSUs) deployed along railway tracks for non-public railway track communication networks as shown in FIG.

[0115] In this embodiment, all U2U relays (RSUs) are fixedly located with their locations known in advance. It is assumed that all U2U relays join a service group that aims to perform U2U ProSE relaying, and their layer 2 IDs are pre-distributed among all members in the group. That is, each RSU knows exactly the layer 2 IDs of other RSUs in its vicinity, and also knows how to contact far-away RSUs via multi-hop routing.

[0116] In this embodiment, the current U2U relay RSU3 initiates the request message as described in step 3. The current U2U relay RSU3 can predict the next relay to serve the target UE by higher layer information, such as the target UE's current location, the target UE's speed information, and the location of the candidate U2U relay (RSU2). The service context information included in the request message can be the target UE's train's current location (if the current U2U relay RSU can predict or obtain such information) or some kind of predicted information about the time of the target UE in the vicinity of RSU2. The service context information can also include the last data packet relayed from RSU3 to the target UE, in which case, when RSU2 is reselected to take the place of RSU3, RSU2 can accurately start traffic relaying with the data that was not successfully transmitted by RSU3 due to sidelink switching.

[0117] The service support information sent from the candidate RSU2 to the source UE (RSU1) may include an estimate of the serving time of the RSU2 as a U2U relay, so that upon receiving this information, the source UE (RSU1) can optimize its buffer and cache mechanisms for relaying.

[0118] In view of the above, in the present invention, a method is proposed to optimize relay reselection of communication between two UEs in the context of out-of-network UE-to-UE communication over sidelink PC5 interface. After the connection between source UE and target UE is set up via the first U2U relay, the current first U2U relay is aware of the E2E QoS requirements of the current service flow, since it is this U2U relay that is responsible for splitting the E2E QoS into source-side QoS and target-side QoS. In the case of sudden sidelink failure, the source UE and target UE do not have enough time to negotiate relay reselection, so instead of making the source UE perform the relay discovery and selection procedure again, in the present invention, the current U2U relay directly or indirectly determines a group U2U relay suitable to relay instead of or in addition to itself. In this method, no negotiation is required between the source UE and target UE, which has an advantage over the source-target UE negotiation based relay reselection method during sudden link failure. In addition, since the first U2U relay is the one that relays the communication, it has the information about the application flow between the source UE and target UE first. Therefore, when having the first U2U relay directly or indirectly determine a group U2U relay suitable for relaying instead of or in addition to itself, such kind of flow / application service context information can be taken into consideration for better decision. Furthermore, as mentioned above, the decision process can include service support information provided by the candidate U2U relays, which is a prediction on the performance of each candidate UE when the candidate UE is selected based on the service context information on the flow / application requirements.

[0119] Also, as will be appreciated by those skilled in the art, the above described examples according to the present invention can be implemented in many ways, such as program instructions for execution by a processor, software modules, microcode, a computer program product on a computer readable medium, logic circuits, application specific integrated circuits, firmware, etc. Embodiments of the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, the present invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

[0120] Furthermore, embodiments of the present invention may take the form of a computer program product accessible from a computer usable or computer readable medium providing program code for use by or in connection with a computer, processing device, or any instruction execution system. As used herein, a computer usable or computer readable medium may be any apparatus that can contain, store, communicate, or deliver a program for use by or in connection with an instruction execution system, apparatus, or device. The medium may be an electronic, magnetic, optical, or semiconductor system (or apparatus or device). Examples of computer readable media include, but are not limited to, semiconductor or solid state memory, magnetic tape, removable computer diskettes, RAM, read only memory (ROM), rigid magnetic disks, optical disks, and the like. Current examples of optical disks include compact disk read only memory (CD-ROM), compact disk read / write (CD-R / W), and DVD.

[0121] The embodiments described herein above are illustrative of the present invention. Various modifications can be made to the embodiments without departing from the scope of the present invention which arises from the appended claims.

Claims

1. 1. A method for optimizing relay reselection for sidelink communication between a source user equipment and a target user equipment, comprising: a first User-to-User (U2U) relay sending a relay reselection request message to at least one U2U relay in the vicinity, wherein the sidelink communication is initially established via the first U2U relay; At least one candidate U2U relay among the at least one surrounding U2U relay transmits a response message in response to the request message for relay reselection; A method comprising:

2. The method of claim 1 , wherein the request message includes Layer 2 IDs of both the source user equipment and the target user equipment.

3. 3. The method of claim 1 or 2, wherein the request message includes an indication of a return address to the source user equipment, the target user equipment or the first U2U relay to which the response message is sent, in order to inform the at least one candidate U2U relay to receive the request message.

4. The method of claim 1 , wherein the request message includes service context information regarding service traffic passing through the first U2U relay.

5. The method of claim 4 , wherein sending a response message in response to the request message is based on the service context information.

6. The method of claim 1 , wherein the response message includes a Layer 2 ID of the at least one candidate U2U relay.

7. The method of claim 1 , wherein the response message includes service support information provided by the candidate U2U relay including a prediction regarding a performance of the candidate U2U relay.

8. The method of claim 4 or 7, wherein the service context information or the service support information comprises End-to-End (E2E) QoS, relay loading, QoS sustainability, or application level information.

9. during transmitting a response message in response to the request message; the response message is sent to the first U2U relay; or The method of claim 1 , wherein the response message is sent to the source user equipment or the target user equipment.

10. before sending the request message, establishing a connection between the source user equipment and the target user equipment via the first U2U relay; Including, after sending the response message, determining at least one second U2U relay for relay reselection by the first U2U relay; The method of claim 1 , comprising:

11. The method of claim 10 , wherein the at least one candidate U2U relay receives the solicitation message and decides to volunteer as the second U2U relay for the relay reselection.

12. making a relay reselection decision and selecting the at least one second U2U relay from among the at least one candidate U2U relay for the relay reselection based on the service support information; The method of claim 7 or 10, further comprising:

13. determining at least one second U2U relay for relay reselection, the first U2U relay directly or indirectly determining the at least one second U2U relay suitable for relaying instead of or in addition to the first U2U relay; The method of claim 10, comprising:

14. determining at least one second U2U relay for relay reselection, determining that the first U2U relay performs U2U relay reselection periodically or when a side link failure or a transition in radio link conditions is detected; The method of claim 10, comprising:

15. A computer program comprising a program code that is executed by a processor, the program code being adapted to perform a method according to any one of claims 1 to 14 when executed by the processor.

Images