Method for optimizing relay reselection for sidelink communications

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 for 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 type 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. Unlike the traditional base station (BS)-UE communication over the Uu interface, the communication described in this invention is 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: First, a relay discovery procedure is required for the source / target UE to discover UE nodes in their vicinity. If direct sidelink communication is possible between the source and target UEs, no U2U relay is required. However, if the source UE cannot communicate directly 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 the event 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, necessitating a U2U relay reselection procedure 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] Various proposals for U2U relay discovery, selection, and reselection methods are currently being proposed, and some are being discussed in the 3GPP SA2 group in the 5G System Phase 2 Study Group ProSe for Release 18.

[0009] As mentioned above, sidelink communication between source and destination UEs via U2U relays generally 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 Figure 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 periodic announce messages, instead of performing broadcasts that may interfere with many UEs, the messages are sent in a groupcast format. U2U relay discovery begins in step 3, where the U2U relay periodically sends announce messages in 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., UE-R's Layer 2 identifier) -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] Several variations of Relay Discovery Model A have also been proposed in 3GPP. For example, instead of using the group member discovery procedure in steps 1 and 2, another procedure called the 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. Furthermore, the announce message format includes a relay service code (RSC).

[0015] Another variation of Relay Discovery Model A exists 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 recipient UE of the announce message. In this case, the periodic announce message is sent in a broadcast format. In addition, a Relay Service Code (RSC) is also included in the announce 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 solicit and reply messages are used for relay discovery. The procedure for 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 their corresponding nodes using the prerequisite group member discovery procedure. After Step 1, UE-1 recognizes that the target user is not in direct range via NR PC5. UE-1 then solicits potential U2U relays in Step 3 by sending a solicitation message containing the following parameters: -Type=Request -Disco Type = UE-to-UE relay detection Discoverer Info (i.e., the UE-1 user's upper layer identifier) -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 UE-R user's upper layer identifier) -UE-R's ProSe UE ID (i.e., UE-R's Layer 2 identifier) - 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] Several variations of Relay Discovery Model B have also been 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 Solicit 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 determined using a direct discovery procedure or previous direct communication information. Furthermore, a Relay Service Code (RSC) is also included in the Announce message format.

[0021] Several other variants of the relay discovery model exist. These variants do not consider the prerequisite group member discovery or direct discovery procedure to obtain Layer 2 IDs or previous direct communication. In this case, the solicitation message is a broadcast message. 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 various 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 current 3GPP discussions integrates relay discovery, relay selection, and PC5-signaling (PC5-S) procedures to reduce signaling overhead. Therefore, the procedure starts directly with a direct communication request from the source UE to the target UE. The direct communication request (DCR) is a message in the PC5-S protocol that initiates 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 Model B variant.

[0023] For relay reselection (e.g., in the case of relay reselection due to sidelink failure caused by a sudden change in UE mobility or radio propagation conditions), two state-of-the-art proposals have been made 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 reselection. The second proposal involves negotiation between the source UE and 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 Figure 3, the source UE decides to perform U2U relay reselection, as shown in step 2 of Figure 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 this 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 Figure 3, the target UE decides to change from Relay 1 to a new UE-UE relay. The new U2U relay is selected 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 the 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 ID of the candidate U2U relay in the discovery message.

[0027] Next, 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, namely 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.

[0029] However, when the current relay fails due to transient radio conditions or sidelink failure (which may be caused by a sudden change in UE mobility or radio propagation conditions), relay reselection becomes necessary. In particular, considering sudden sidelink failures, which 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 relay reselection proposals in the art as described above are not practical because they require negotiation between the source UE and the target UE via the current U2U relay.

[0030] According to the current proposal in 3GPP, when such a sudden side link 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 may result in service outages. The current solution proposed in 3GPP cannot guarantee service continuity and QoS continuity.

[0031] Even so, current methods for negotiation between a source UE and a target UE via a U2U relay in the art can somehow predict potential performance degradation by monitoring sidelink radio conditions and subsequently trigger negotiation between the source UE and the target UE while the current sidelink communication via the U2U relay is still good. However, in certain communication scenarios, such as vehicle-to-everything (V2X) or high-speed trains, or scenarios with rapidly changing radio propagation conditions, such as deep fading, blockages, or moving scattering objects, a sudden sidelink failure may occur before the source UE and the target UE can negotiate a reselected U2U relay. In such an event, the above-mentioned methods in the art cannot solve the problem, and according to current proposals 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 U2U relay in the vicinity, 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, in which the source / target UE either restarts the relay discovery procedure from the beginning 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. Therefore, 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 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 will be sent to. In particular, the request message includes an indication of a return address to the source user equipment, target user equipment or first U2U relay to which a response message will be sent in order to inform at least one candidate U2U relay that received 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 about 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 load, QoS sustainability, and application level information.

[0039] According to one embodiment of the present 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 present invention, the method comprises, 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 sending 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 in the relay reselection.

[0042] Advantageously, the method according to the invention comprises: 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 is made based on the following metrics: - the radio link quality; -Service support information and -implementation-specific priorities and This is based on at least one of the following:

[0047] Furthermore, according to yet another embodiment of the present invention, the method according to the present invention comprises: 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 that is executed by a processor, the program code being adapted to perform the method of the invention as described above.

[0049] Other features and advantages of the present invention will be described in the following exemplary embodiments, and those skilled in the art can clearly understand the contents 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 explanation of the drawings]

[0051] [Figure 1] FIG. 1 illustrates a relay detection model A in the art. [Figure 2] FIG. 1 illustrates a relay detection model B in the art. [Figure 3] FIG. 1 illustrates a negotiation-based relay reselection model in the art. [Figure 4] FIG. 1 illustrates an embodiment of U2U relay reselection in accordance with the present invention. [Figure 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] 1 is a flowchart illustrating a decision flow for handling messages according to the present invention. [Figure 7] FIG. 1 illustrates one embodiment of U2U relay reselection as an alternative to two-hop relay in accordance with the present invention. [Figure 8] FIG. 1 illustrates one embodiment of U2U relay reselection plus itself for multi-hop relay in accordance with the present invention. [Figure 9] FIG. 1 illustrates an embodiment of an example of U2U relay reselection with higher layer information. DETAILED DESCRIPTION OF THE INVENTION

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

[0053] This exemplary method includes the following steps. Step 1: A connection between a source UE and a 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 through 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 side link 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 Relay 1 observes a link failure on either the source UE-U2U Relay 1 link or the U2U Relay 1-target UE link; b. U2U Relay1 monitors the source UE-U2U Relay1 link and / or the U2U Relay1-target UE link and observes changes in radio link conditions that may indicate either an upcoming link failure or the existence of a U2U Relay with potentially better radio link conditions to relay; and c. Periodically, or when the link quality drops below a given level, in which case the reselected relay is kept on 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 described above. The request message includes Layer 2 IDs of both the source UE and the 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 for sidelink communication from the source UE to the 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 can occur, and embodiments of these sub-scenarios 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 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 above-mentioned Relay Discovery Model B. 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, and embodiments of these sub-scenarios 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 explanation will be given below.

[0060] Step 6: Once a new U2U relay is reselected, a connection between the source UE and the target UE is established via the new U2U relay. This Layer 2 link connection can be initiated by either the source UE or the new U2U relay, as will be described in detail 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 Figure 4 described above. After this part, a list of candidate U2U relays is obtained and stored in a waiting list at the 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 when the selection point is at the source UE or the target UE. In this case, when relay reselection needs to occur (e.g., because the link quality has become too poor), the relay provides the source UE or the target UE with a list of candidate U2U relays from the waiting list. For example, the relay constructs 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 the target UE on behalf of the candidate U2U relay. Therefore, the source UE or the target UE is not affected by the use of the waiting list.

[0064] The advantage of using a waiting list is that it improves service continuity: indeed, if one link quality suddenly deteriorates, a new relay is picked up from the waiting list without first having to 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 periodically when radio conditions are deteriorating.

[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 solicit message is how U2U Relay 1 knows the Layer 2 ID of other U2U Relays so that it can send the solicit message. This is shown in Figure 5, where: One scenario is that the Layer 2 ID of a potential U2U relay, e.g., a U2U relay in the vicinity of U2U Relay 1, is 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 TS23.303) between U2U Relay 1 and a potential U2U relay, (2) If a previous relay discovery procedure (either Model A or B, or any other procedure described in Section 3.1) exists and the current U2U relay has already discovered 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, for example, considering that all U2U relays are infrastructure nodes providing sidelink relay capabilities in a vehicle / train private network, the application level server can directly provide each U2U relay with each other's Layer 2 ID 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 IDs of potential U2U relays are 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 Relay Discovery Model B 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) - Source UE ProSe UE ID (i.e., source UE Layer 2 ID) - 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 the source UE / target UE / current U2U relay 1 itself in the request message, and service context information such as E2E QoS of the sidelink communication from the source UE to the 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 around the recipient, and if forwarding of the request is possible, can also indicate additional constraints on forwarding the request message (e.g., maximum number of hops to forward, etc.).

[0072] -Step 4 In step 4, U2U relays that receive the request message and consider themselves candidates for relay reselection send 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 Solicit message is unicast / groupcast (which means the Layer 2 ID of the receiver is indicated), the U2U relay with the Layer 2 ID corresponding to the receiver will receive the Solicit 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 this unicast / groupcast Solicit message, it will simply discard this message.

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

[0076] Furthermore, after the candidate U2U relay determines whether to decode and respond, it also checks the solicit message forwarding section to see if it has the authority to broadcast this solicit message to its neighbors. If the answer is yes, the candidate U2U relay also checks the solicit forwarding constraints when forwarding this solicit message and updates this field accordingly. For example, if a maximum forwarding hop count exists in the solicit forwarding constraints, the U2U relay decrements this value by 1 when forwarding the solicit message. In addition, to reduce duplication of forwarding, all U2U relays perform solicit message broadcast forwarding only once for solicit messages with the same triplet 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 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, target UE, and current U2U relay 1. With the Layer 2 IDs of the source UE and 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, the service context information received in the request message also allows the U2U relay to 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 target-side QoS based on the direct detection procedure / direct communication request feedback of the direct communication link quality (e.g., signal strength) and a pre-configured lookup table of QoS profiles for QoS partitioning.

[0079] If 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 required 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 a 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 provided 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, and the response message is sent backward 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., 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), the candidate U2U relay's 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 recipient 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 the response message is sent to and who makes the final decision regarding relay reselection.

[0089] If the initial U2U relay decides to reselect the relay, it indicates this decision to the reselected U2U relay, which initiates a direct communication request to establish Layer 2 links 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, and the reselected U2U relay 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 two-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 replace the current U2U relay with a relay and add ourselves to find an 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 connects 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 an additional U2U relay, but the service context information included in this request message is not E2E QoS requirements 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 via the link to the current U2U relay and the target UE-side QoS via the link to the target UE. This split is based on the target UE-side QoS input received in the request message. After performing 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 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 service assistance information will be described in detail, and in particular, some example embodiments of how the service context information provided by 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 a 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 provided sidelink flow. More precisely, the initial PQI (PC5 QoS identifier) ​​and associated QoS profile and parameters constitute the service context information. The QoS profile and parameters are, for example, 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 it is sent from the source UE to the current U2U relay during Layer 2 link establishment / modification 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 Solicit message to obtain the Layer 2 IDs of the source UE and target UE and the above-mentioned 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 target UE can be established. Upon receiving the DCR, the source UE and 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 acknowledgment to roughly estimate the sidelink quality. Furthermore, Relay 2 can either (1) be pre-configured or (2) be configured by a cellular base station when a look-up table of supported QoS profiles for associated source-side PC5 QoS parameters and associated target-side PC5 QoS parameters exists within the base station's coverage.

[0100] For the relevant source side PC5 QoS parameters at relay 2, assume the pre-configured lookup table of supported QoS profiles is: [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 line 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 the target UE. For illustration purposes, assume that the target-side PC5 QoS that is maintained is PQI=21, 26, 28.

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

[0105] Assuming 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 the 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: PQI=21, GFBR=xx1, Target: PQI=21, GFBR=yy1), (Source: PQI=21, GFBR=xx1, Target: PQI=26, GFBR=yy1), (Source: PQI=21, GFBR=xx1, Target: PQI=28, GFBR=yy1), (Source: PQI=26, GFBR=xx1, Target: PQI=21, GFBR=yy1), (Source: PQI=26, GFBR=xx1, Target: PQI=26, GFBR=yy1).

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

[0108] Once relay reselection is decided, Layer 2 link establishment procedures can be established between the source UE and the reselected relay and between this relay and the target UE, and the corresponding QoS can be 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, the source UE may choose the first U2U relay candidate among the above in order to have better QoS sustainability.

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

[0115] In this embodiment, all U2U relays (RSUs) have fixed locations whose locations are known in advance. It is assumed that all U2U relays join a service group whose purpose is to perform U2U ProSE relaying, and their Layer 2 IDs are pre-distributed among all members in the group. That is, each RSU knows the Layer 2 IDs of other RSUs in its vicinity and also knows how to contact distant 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 according to higher layer information, such as the target UE's current location, the target UE's velocity 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 current location (if the current U2U relay RSU can predict or obtain such information) or some 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 this case, when RSU2 is reselected to take the place of RSU3, RSU2 can accurately start traffic relaying using 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, the present invention proposes a method for optimizing relay reselection for communication between two UEs in the context of out-of-network UE-to-UE communication over a sidelink PC5 interface. After a connection between a source UE and a target UE is set up via a first U2U relay, the current first U2U relay is aware of the E2E QoS requirements of the current service flow because it is this U2U relay that is responsible for dividing the E2E QoS into source-side QoS and target-side QoS. In the event of a sudden sidelink failure, the source UE and target UE do not have enough time to negotiate relay reselection. Instead of having the source UE perform the relay discovery and selection procedure again, the present invention allows the current U2U relay to directly or indirectly determine a group of U2U relays suitable to relay instead of or in addition to itself. This method does not require negotiation between the source UE and the target UE, which has the advantage over source-target UE negotiation-based relay reselection methods during a sudden link failure. In addition, since the first U2U relay is the one relaying the communication, it initially has information about the application flow between the source UE and the target UE. Therefore, when the first U2U relay directly or indirectly determines a suitable group U2U relay to relay instead of or in addition to itself, it can take such kind of flow / application service context information 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 about the performance of each candidate UE when the candidate UE is selected based on the service context information about the flow / application requirements.

[0119] Also, as will be known to those skilled in the art, the above-described examples according to the present invention can be implemented in many ways, such as, for example, 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 software 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, etc. 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 invention which arises from the appended claims.

Claims

1. 1. A method for performing relay reselection for sidelink communication between a source user equipment and a target user equipment, the sidelink communication having been initially established via a first U2U (User-to-User) relay, the method comprising: The first U2U relay sends a relay reselection request message to at least one surrounding U2U relay; At least one candidate U2U relay among the at least one surrounding U2U relay sends a response message in response to the request message for relay reselection; Including, The request message includes service context information regarding service traffic passing through the first U2U relay, the service context information including end-to-end (E2E) QoS.

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, 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 sending a response message in response to the request message is based on the service context information.

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

6. 2. The method of claim 1, wherein the response message includes service support information provided by the candidate U2U relay including a prediction regarding the performance of the candidate U2U relay, the service support information including an end-to-end (E2E) QoS or a relay load.

7. 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.

8. after sending the response message, determining, by the source user equipment, the target user equipment, or the first U2U relay according to a destination of the response message, at least one second U2U relay for relay reselection; The method of claim 1 , comprising:

9. The method of claim 8 , 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.

10. Determining at least one second U2U relay for the relay reselection includes determining the at least one second U2U relay from among the at least one candidate U2U relay based on service support information; 9. The method of claim 8, further comprising: wherein the service support information comprises end-to-end (E2E) QoS or relay loading.

11. determining at least one second U2U relay for relay reselection; determining that the first U2U relay will perform U2U relay reselection periodically, or when a side link failure occurs, or when a transition in radio link conditions that may cause a future link failure is detected, or when it is detected that there is a U2U relay with better radio link conditions for relaying; The method of claim 8, comprising:

Images