Method for optimizing relay reselection of sidelink communication

Abstract

The present invention relates to a method of optimizing relay reselection of a sidelink communication between a source user equipment and a target user equipment, said method comprising:-sending, by a first U2U relay, a request message for relay reselection to at least one adjacent U2U relay wherein the sidelink communication is initially established via the first U2U relay; and-sending, by at least one candidate U2U relay of the adjacent at least one U2U relay, a response message in response to the request message for relay reselection. According to the invention, the relay reselection efficiency is improved.

Description

Technical Field

[0001] The present invention relates to relaying of side link communication between two user equipments (ie, a source user equipment and a target user equipment), and more particularly to a method for optimizing relay reselection of such side link communication. Background Art

[0002] User-to-user (U2U) relay for 5G New Radio (NR) Proximity Service (ProSe) is an important technology under 3GPP.

[0003] A U2U relay is a user equipment (UE) node that can be used as a relay. When a source UE wants to communicate with a target UE but cannot reach the target UE directly, the source UE can use the U2U relay to pass information and reach the target UE. Unlike conventional base station (BS) to UE communication via the Uu interface, the communication discussed in the present invention is a device-to-device (D2D) sidelink communication via the PC5 interface.

[0004] Conventional sidelink communication from a source UE to a target UE via a U2U relay would potentially involve several steps as follows:

[0005] First, the source UE / target UE requires a relay discovery process to discover UE nodes in their neighborhood. If direct sidelink communication between the source UE and the target UE is possible, no U2U relay is required. However, if the source UE cannot communicate directly with the target UE, the source UE will need to find out (by knowing the node's layer 2 ID) a UE in its vicinity that can act as a U2U relay to reach the target UE.

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

[0007] Finally, once the best relay / path / route is selected, each pair of UE nodes needs to establish a layer 2 communication link and carry the sidelink communication over this link.

[0008] In the case of a side link failure event due to a sudden change in UE mobility or radio propagation conditions (such as deep fading or blocking), the established side link may be interrupted and the source UE requires a U2U relay reselection procedure to find a new U2U relay and re-establish side link communication to the target UE via the new U2U relay node.

[0009] Different proposals for U2U relay discovery, selection and reselection methods are currently proposed, such as the proposals discussed in the 3GPP SA2 group under study item ProSe in 5G system phase 2 for Release 18.

[0010] As discussed above, for sidelink communication between a source UE and a destination UE via a U2U relay, three steps are generally involved during the entire process: relay discovery, relay selection, and signaling for sidelink establishment, followed by communication over the established link.

[0011] In particular, three state-of-the-art relay discovery methods are proposed in 3GPP, which are discussed below.

[0012] The first one is called Relay Discovery Model A. In this model, each U2U relay will actively send periodic announcement information to its nearby UEs to indicate that it can serve as a U2U relay to reach the target UE. The process of Relay Discovery Model A is as follows Figure 1 Shown in.

[0013] like Figure 1 As shown, in step 1 and step 2 of relay discovery model A, the source UE (UE-1 in the figure) and the U2U relay (UE-R in the figure) use a prerequisite process called group member discovery specified in LTE ProSe communication to obtain the layer 2 ID of the corresponding node. In this case, when the U2U relay will send a periodic notification message instead of performing a broadcast that potentially interferes with many UEs, the message will be sent in a multicast manner. U2U relay discovery starts in step 3, and the U2U relay periodically sends a notification message in the following format:

[0014] -type=Announcement

[0015] - Discovery Type = UE-to-UE Relay Discovery

[0016] - Information of the notifier (i.e., the upper layer identifier of the UE-R user)

[0017] - ProSe UE ID of UE-R (i.e., Layer 2 identifier of UE-R)

[0018] - "Target user information" parameter list

[0019] Among them, "target user information" is an upper layer parameter that identifies the target user. In order to support layer 2 communication via stateful U2E relay, "target user information" also includes the layer 2 identifier of the UE of the target user. It can also include parameters that have been collected during group member discovery in step 2.

[0020] Afterwards, in Figure 1In step 4, the source UE (UE-1) communicates with the target UE (UE-2 in the figure) via the U2U relay (UE-R).

[0021] Some variants of relay discovery model A are also proposed in 3GPP. For example, instead of using the group member discovery process in steps 1 and 2, another process called the direct discovery process also specified in LTE ProSe communication can be used to obtain the layer 2 ID. If there is a previous direct communication between UEs, the previously identified layer 2 ID can also be used. In addition, in the notification message format, the relay service code (RCS) is included.

[0022] There is another variation of relay discovery model A, in which there is no prerequisite process such as group member discovery or direct discovery for the U2U relay to obtain the layer 2 ID of the recipient UE for the announcement message. In this case, the periodic announcement message is sent in a broadcast manner. In addition, the relay service code (RCS) is also included in the announcement message format.

[0023] The second relay discovery model proposed in 3GPP is relay discovery model B. In this model, instead of using periodic notification messages, reactive on-demand request messages and response messages are used for relay discovery. The process of relay discovery model B is described in Figure 2 Shown in.

[0024] Same as Model A, in step 1 and step 2 of relay discovery mode B, the source UE and the U2U relay use the prerequisite group member discovery process to obtain the layer 2 ID of the corresponding node. After step 1, UE-1 realizes that the target user is not in direct range on NR PC5. Then, in step 3, U-1 requests potential U2U relays by sending a request message including the following parameters:

[0025] -type=request

[0026] - Discovery Type = UE-to-UE Relay Discovery

[0027] - Discoverer information (i.e., upper layer identifier of UE-1 user)

[0028] - ProSe UE ID of UE-1 (i.e., Layer 2 identifier of UE-1)

[0029] - List of "target user information" parameters.

[0030] Upon receiving the request message, Figure 2 In step 4 of , the UE-R recognizes that it can act as a U2U relay and replies with a response message including the following parameters:

[0031] -Type = Response

[0032] - Discovery Type = UE-to-UE Relay Discovery

[0033] - Discoverer information (i.e., upper layer identifier of the UE-R user)

[0034] - ProSe UE ID of UE-R (i.e., Layer 2 identifier of UE-R)

[0035] - List of "target user information" parameters.

[0036] Afterwards, in Figure 2 In step 5, the source UE (UE-1) communicates with the target UE (UE-2) via the U2U relay (UE-R).

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

[0038] There are some other variants of the relay discovery model without taking into account the prerequisite group membership discovery or direct discovery process or previous direct communication to obtain the layer 2 ID. In this case, the request message is a broadcast message, and when a potential U2U relay receives the request message, depending on its capabilities as a U2U relay, the potential U2U relay will forward the request message by broadcasting the request message in its neighborhood. This process is similar to the conventional ad-hoc on-demand distance vector (AODV) algorithm in mobile ad-hoc networks (MANETs). The target UE can receive several forward request messages from different U2U relays, it can select a U2U relay to send a response message, and the message is forwarded back to the source UE by the selected U2U relay, or it can also send a response message to each U2U relay that forwarded the request message. In the latter case, each U2U relay forwards the response message back to the source UE, and the source UE will make a final selection on the best U2U relay.

[0039] The third relay discovery model proposed in the current 3GPP discussion involves the unification of relay discovery, relay selection and PC5-signaling (PC5-S) processes to reduce signaling overhead. Therefore, the process will start 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 used to initialize the establishment of a layer 2 link between two UE nodes. Since the source UE cannot reach the target UE directly, the U2U relay receiving the DCR message will forward and broadcast the DCR message in its neighborhood using a similar method to AODV described above in the variant of model B.

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

[0041] In this negotiation-based relay reselection model, Figure 3 After establishing a connection between two UEs via relay 1 in step 1, the source UE decides to perform U2U relay reselection, such as Figure 3 As shown in step 2 of . This can be triggered by receiving a relay discovery message from another U2U relay, and the signal quality of this U2U relay is better than the signal quality of the current U2U relay (Relay 1). Alternatively, when it is found that the signal quality with Relay 1 is not good enough, the source UE will initiate a discovery message to find a candidate UE-to-UE relay that can provide a better connection.

[0042] After the source UE identifies a candidate U2U relay, the source UE sends a U2U relay reselection request to the target UE using the connection via relay 1 ( Figure 3 3), and the request message includes a list of candidate U2U relay IDs sorted by the source UE's preference based on, for example, the signal quality of the U2U relay.

[0043] Afterwards, in Figure 3In step 4 of , the target UE decides to change from relay 1 to a new UE-to-UE relay. A new U2U relay is selected from a candidate list included in the reselection request. The decision may be based on the new U2U relay providing the best signal quality and additionally on the order of the candidate U2U relay IDs received from the source UE. If the target UE does not receive a relay discovery message from a candidate U2U relay or is not connected to a candidate U2U relay, the target UE may perform a U2U relay discovery procedure using the candidate U2U relay ID in the discovery message.

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

[0045] Finally, when a new U2U relay (i.e., relay 2) is selected, Figure 6 In step 6 of , a new connection is established between the source UE and the target UE via the new U2U relay.

[0046] However, due to the evolution of radio conditions or side link failure events (which may be caused by sudden changes in UE mobility or radio propagation conditions), when the current relay is no longer working, relay reselection is necessary. In particular, considering the sudden side link failures that are likely to occur for high mobility scenarios such as V2X or high-speed train communications, or considering the rapidly changing channels or complex environments with various blocking effects, the relay reselection proposal in the art as described above is not realistic because it requires negotiation between the source UE and the target UE via the current U2U relay.

[0047] According to the current proposal in 3GPP, when such a sudden sidelink failure occurs, there is no other choice but to redo the relay discovery process from the beginning. However, re-performing the relay selection process is not optimal at all. It takes time to complete the relay discovery process from the beginning, and there will also be service breakdown. Service continuity and QoS continuity cannot be guaranteed using the current solution proposed in 3GPP.

[0048] Even in the art, the method of negotiating between the source UE and the target UE via the current U2U relay can somehow anticipate potential performance degradation through sidelink radio condition monitoring, and then trigger negotiation between the source UE and the target UE when 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 involving rapidly changing radio propagation conditions (e.g., deep fading, obstruction, moving scattering objects), a sudden sidelink failure may occur before the source UE and the target UE negotiate the reselected U2U relay. In this case, the above methods in the art cannot solve the problem, and according to the current proposals in 3GPP, restarting the relay discovery and selection process is inevitable. In addition, the relay reselection criteria proposed in the above methods are based on the sidelink signal quality, which cannot fully reflect application-level requirements such as QoS.

[0049] The present invention aims to solve these problems in the art to optimize relay reselection. Summary of the invention

[0050] In this regard, according to one aspect of the present invention, there is provided a method for optimizing relay reselection for sidelink communications between a source user equipment and a target user equipment, particularly in the context of off-network UE-to-UE communications based on a sidelink PC5 interface, the method comprising:

[0051] -sending, by a first U2U relay, a request message for relay reselection to at least one nearby U2U relay, wherein the sidelink communication is initially established via the first U2U relay; and

[0052] - At least one candidate U2U relay among at least one nearby U2U relay sends a response message in response to the request message to perform relay reselection.

[0053] Such an arrangement is different from prior art proposals for relay reselection, in which the source / target UE restarts the relay discovery process from the beginning or performs relay reselection negotiation between the source UE and the target UE via the current relay. In the present invention, the current relay (i.e., the first U2U relay) initiates the relay reselection process by sending a request message to find a second U2U relay suitable for relay reselection. Therefore, the present invention is more efficient for relay reselection in certain situations such as sudden side link failure events.

[0054] Advantageously, the request message comprises the layer 2 ID of both the source user equipment and the target user equipment. Furthermore, the request message comprises an indication of which node (source, target or relay) the response is to be sent to. In particular, the request message comprises an indication of a reply address among the source user equipment, the target user equipment or the first U2U relay for notifying the source user equipment, the target user equipment or the first U2U relay to which the response message is to be sent of at least one candidate U2U relay that received the request information.

[0055] Advantageously, the request message further includes service-related information related to the service traffic through the first U2U relay.

[0056] Advantageously, the response message comprises a layer 2 ID of at least one candidate U2U relay. In particular, the response message may also comprise service assistance information provided by the candidate U2U reply, the service assistance information comprising the candidate U2U relay's prediction of its performance.

[0057] Advantageously, the service-related information or service assistance information includes any one of end-to-end (E2E) QoS, load of relays, QoS sustainability, and application level information.

[0058] According to one embodiment of the present invention, during the step of sending a response message in response to a request message:

[0059] - a response message is sent to the first U2U relay; or

[0060] - A response message is sent to the source user equipment or the target user equipment.

[0061] According to one embodiment of the present invention, before the step of sending a request message, the following steps are included:

[0062] - establishing a connection between the source user equipment and the target user equipment via the first U2U relay;

[0063] And after the step of sending the response message, including:

[0064] - determining, by the first U2U relay, at least one second U2U relay for relay reselection.

[0065] Advantageously, at least one candidate U2U relay receives the request information and decides to become an applicant for a second U2U relay for relay reselection.

[0066] Advantageously, the method according to the invention further comprises:

[0067] - Making a relay reselection decision, and selecting at least one second U2U relay for relay reselection among at least one candidate U2U relay based on the serving assistance information.

[0068] Advantageously, the step of determining at least one second U2U relay for relay reselection comprises:

[0069] - Determining, directly or indirectly, by the first U2U relay at least one second U2U relay suitable for relaying in place of the first U2U relay or in addition to the first U2U relay.

[0070] Therefore, in addition to enabling a UE relay to directly or indirectly determine a UE relay group suitable for relaying instead of itself or in addition to itself, the present invention proposes a determination process, wherein it may include service assistance information and service related information regarding end-to-end (E2E) QoS, load of the relay, QoS sustainability and application level information. Therefore, when radio conditions change, for example due to mobility, blocking or deep fading, the present invention can guarantee service continuity and QoS continuity / sustainability during relay reselection for communication between two UEs.

[0071] Furthermore, according to another embodiment of the present invention, during the step of sending a request message for relay reselection:

[0072] - If the first U2U relay knows the layer 2 ID of at least one candidate U2U relay, the first U2U relay sends a request message to the at least one candidate U2U relay in a unicast or multicast manner;

[0073] otherwise

[0074] -The first U2U relay sends the request message in a broadcast manner.

[0075] Furthermore, during the step of making a relay reselection decision, a replay reselection decision is made based on at least one of the following metrics:

[0076] - Radio link quality;

[0077] -Service assistance information; and

[0078] - Implementation-specific preferences.

[0079] In addition, according to another embodiment of the present invention, the method of the present invention further comprises:

[0080] - Establishing a new connection between the source user equipment and the target user equipment via the second U2U relay.

[0081] According to another aspect of the present invention, a computer program is provided. The computer program comprises a program code executed by a processor. The program code is suitable for executing the method of the present invention as described above.

[0082] Other features and advantages of the present invention will be discussed in the following exemplary embodiments. Those skilled in the art can clearly understand the content of the present invention and the technical effects obtained based on these exemplary embodiments.

[0083] Other features and advantages of the present invention will appear from the following description with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] [ Figure 1 ]

[0085] Figure 1 A relay discovery model A in the art is shown.

[0086] [ Figure 2 ]

[0087] Figure 2 A relay discovery model B in the art is shown.

[0088] [ Figure 3 ]

[0089] Figure 3 A negotiation-based relay reselection model in the art is shown.

[0090] [ Figure 4 ]

[0091] Figure 4 The U2U relay reselection implementation according to the present invention is shown.

[0092] [ Figure 5 ]

[0093] Figure 5 is a flow chart showing the decision process of sending a request message by the current U2U relay according to the present invention.

[0094] [ Figure 6 ]

[0095] Figure 6 is a flow chart illustrating the decision flow for processing messages according to the present invention.

[0096] [ Figure 7 ]

[0097] Figure 7 An embodiment of U2U relay reselection as an alternative to 2-hop relay according to the present invention is shown.

[0098] [ Figure 8 ]

[0099] Figure 8 An implementation of U2U relay reselection other than itself for a multi-hop relay according to the present invention is shown.

[0100] [ Fig. 9 ]

[0101] Fig. 9 An implementation example of U2U relay reselection with higher layer information is shown. DETAILED DESCRIPTION

[0102] Figure 4 An exemplary embodiment of the relay reselection method according to the present invention is shown, wherein it shows off-network U2U communication based on the side link PC5 interface, wherein the source user equipment (source UE) can be connected to the target user equipment (target UE) via any one of the U2U relays 1 to 3.

[0103] An exemplary method includes the following steps:

[0104] Step 1: Establish a connection between the source UE and the target UE via U2U Relay 1 by using relay discovery, selection and link establishment methods in the art, such as the current 3GPP proposal as described above. Once the layer 2 link is established, traffic is transmitted via U2U Relay 1, which can be a L2 or L3 U2U relay.

[0105] Step 2: U2U relay 1 decides to perform U2U relay reselection. This can be triggered by any of the following situations:

[0106] a. 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, and U2U relay 1 observes a link failure in either the source UE-U2U relay 1 link or the U2U relay 1-target UE link;

[0107] b. U2U Relay 1 monitors the Source UE-U2U Relay 1 link and / or the U2U Relay 1-Target UE link, observing the evolution of the radio link conditions, which may lead to future link failures or the existence of a U2U Relay with a potentially better radio link condition for relaying; and

[0108] c. Periodically or periodically when the link quality is below a given level. In this case, the reselected relay will be kept in the waiting list in case relay reselection discussed later is required.

[0109] Step 3: U2U relay 1 sends a request message for relay reselection to other U2U relays in its vicinity (U2U relay 2 and U2U relay 3 in the figure), the format of which is different from the format in relay discovery model B as described above. The request message includes the layer 2 IDs of both the source UE and the target UE, and optionally includes service-related information related to the service traffic previously conducted through U2U relay 1. The service-related information may be E2E QoS of the sidelink communication from the source UE to the target UE, application-level information about the traffic, QoS sustainability requirements, etc. A detailed discussion of the request message format will be discussed later.

[0110] Furthermore, in step 3, many sub-scenarios may occur, and their implementation will be discussed later.

[0111] Step 4: Among the U2U relays in the vicinity of U2U relay 1, those relays that have received the request message and regard them as candidate U2U relays for relay reselection will send a response message in response to the request message. The format of the response message is different from the format proposed in the relay discovery model B as described above. The response message includes the layer 2 ID of the U2U relay, and other service assistance information that can be used for relay selection. The service assistance information includes, but is not limited to, the prediction of the source-side QoS and target-side QoS of the U2U relay regarding the E2E QoS in the request message, the load of the U2U relay, QoS sustainability, etc. A detailed discussion of the response message format will be discussed later.

[0112] Additionally, in step 4, many sub-scenarios may occur, and their implementation will be discussed later.

[0113] Step 5: Make a relay reselection decision. Depending on how the response message process in step 4 is implemented, the source / target UE or the U2U relay 1 can make this decision. A more detailed discussion will be provided later.

[0114] Step 6: Once a new U2U relay is reselected, a connection between the source UE and the target UE via the new U2U relay will be established. This layer 2 link connection can be initiated by the source UE or the new U2U relay, which will be discussed in more detail later.

[0115] In one exemplary embodiment, a waiting list may be used, and the reselection process as described above may be divided into two parts in terms of time:

[0116] The first part consists of the above Figure 4 After this part, a list of candidate U2U relays is obtained and stored in a waiting list at a selection point, which can be a relay UE, a source UE or a target UE. The list can be updated regularly, i.e., this process part is performed periodically.

[0117] The second part consists of steps 5 and 6 above, i.e., selecting a relay from the waiting list and setting up with the new relay. The criteria for candidate selection are the same as when performing the full selection process in one row.

[0118] Optionally, the relay UE may remember the waiting list even if the selection point is at the source UE or target UE. In this case, when relay reselection has to be performed (e.g., link quality becomes too poor), the relay provides the source UE or target UE with a list of candidate U2U relays from its waiting list. For example, the relay builds response messages from its waiting list as if they had been received from the candidate U2U relays, and provides them to the source UE or target UE on behalf of the candidate U2U relays. Therefore, the source UE or target UE is not affected by the use of the waiting list.

[0119] The advantage of using a waiting list is to improve service continuity. In fact, in the case of a sudden drop in link quality, a new relay is directly selected from the waiting list without first finding a candidate U2U relay among nearby relays.

[0120] The relay may decide to create or update the waiting list according to different criteria (eg periodically, periodically only when radio conditions deteriorate).

[0121] Below, we will discuss in more detail Figure 4 Implementation method of step 3 to step 6.

[0122] -Step 3

[0123] In step 3, the first U2U relay (i.e., U2U relay 1) sends a request message for relay reselection to find a U2U relay (or a group of U2U relays if multi-hop relay is enabled) as its replacement, or find a group of U2U relays in addition to itself (if multi-hop relay is enabled).

[0124] The first aspect of the request message is how U2U relay 1 can know the layer 2 ID of other U2U relays in order to send the request message, such as Figure 5 As shown, where:

[0125] One scenario is that the current U2U relay 1 already knows the layer 2 ID of a potential U2U relay (e.g., a U2U relay near U2U relay 1). This may happen due to, for example, the following situations:

[0126] (1) There is previous side link direct communication / direct discovery / group member discovery between U2U relay 1 and potential U2U relays (see LTE ProSe TS23.303),

[0127] (2) There is a previous relay discovery process (Model A or B or others as described in Section 3.1), and the current U2U relay has discovered other potential U2U relays,

[0128] (3) The layer 2 IDs of other potential U2U relays are provided by the application-level server to the current U2U relay. For example, considering that all U2U relays are infrastructure nodes that provide sidelink relay capabilities for vehicle / train dedicated networks, the application-level server can directly provide each U2U relay with each other's layer 2 ID using application-level signaling. In this case, the current U2U relay can send a request message to the target candidate U2U relay in a unicast or multicast manner.

[0129] Another scenario is that the current U2U relay does not know the layer 2 ID of the potential U2U relay. In this case, the current U2U relay will have two possibilities. Possibility 1, the current U2U relay initiates the group member discovery / direct discovery / direct communication request process to discover the candidate U2U relays in its vicinity and obtain their layer 2 IDs. Possibility 2, the request message is broadcast by the current U2U relay.

[0130] The second aspect of the request message is its format. In contrast to the request message in the relay discovery model B described above, the request message includes the following parameters:

[0131] -type=request

[0132] -Discovery Type = U2U Relay Reselection

[0133] - Discoverer information (i.e., the upper layer identifier of the current U2U relay)

[0134] - ProSe UE ID of the current U2U relay (i.e., Layer 2 ID of the current U2U relay)

[0135] - ProSe UE ID of the source UE (i.e., Layer 2 ID of the source UE)

[0136] - ProSe UE ID of the target UE (i.e., Layer 2 ID of the target UE)

[0137] - (optional) a list of "service related information" parameters

[0138] - (optional) request message forwarding enabled (or not enabled), constraints on request message forwarding

[0139] -Response message recipient indicator (if multi-hop routing is allowed, the possible recipients are the source UE, or the target UE, or the current U2U relay, or the intermediate U2U relay)

[0140] - List of "target user information" parameters.

[0141] In this case, preferably, in the request message, the current U2U relay 1 will provide the receiver with the layer 2 ID of the source UE / target UE / itself and service related information, such as the E2E QoS of the sidelink communication from the source UE to the target UE, application-level information about the service, QoS sustainability requirements, etc. Optionally, the current U2U relay 1 can also indicate whether the receiver of the request message can or cannot forward the message to other candidate U2U relays near the receiver, and if the forwarding of the request is enabled, it also indicates additional constraints on the forwarding of the request message (e.g., the maximum number of hops to be forwarded, etc.).

[0142] -Step 4

[0143] In step 4, the U2U relays that have received the request message and consider that they are the applicant for relay reselection will send a response message.

[0144] The first aspect of the response message is what the other U2U relay will do upon receiving the request message. Figure 6 shown in and with Figure 5 This is related to the scenario of the request message described in .

[0145] like Figure 6 As shown, if the request message is unicast / multicast (which means that the layer 2 ID of the recipient is indicated), the U2U relay with the layer 2 ID corresponding to the recipient will receive the request message and proceed to the next step (step 5) to see if it (they) can be a candidate U2U relay for relay reselection. If the U2U relay is not the addressed recipient of the unicast / multicast request message, the U2U relay will simply discard the request message.

[0146] Likewise Figure 6 As shown, if the request message is broadcast, the situation is more complicated. The U2U relays that receive the request message broadcast will first decode the message and proceed to the next step (step 5) to see if they can be candidate U2U relays for relay reselection.

[0147] In addition, after decoding and deciding whether the candidate U2U relays should respond, they will also check the request message forwarding part to see if they are authorized to forward the request message in a broadcast manner in their vicinity. If the answer is yes, they will also check the request forwarding constraints and update the field accordingly when they forward the request message. For example, if there is a maximum number of forward hops in the request forward constraint, the U2U relay will decrement the value by 1 when it forwards the request message. In addition, in order to reduce the duplication of forwarding, each U2U relay will only perform a request message broadcast forwarding once for a request message with the same triplet set of source UE / target UE / current U2U relay layer 2ID.

[0148] The second aspect of the response message is how each U2U relay receiving the request message can decide whether it can be an applicant for relay reselection.

[0149] If the request message is a unicast / multicast message dedicated to the received U2U relay, or the request message is a multicast 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. Using the layer 2 IDs of the source UE and the target UE, the U2U relay can use the direct discovery process / direct communication request (see LTE ProSeTS23.303) to verify whether it can have a direct communication link with the source UE and the target UE. In addition, if direct communication is possible, using the service-related information received in the request message, the U2U relay can also predict and generate service assistance information about potential direct communication links. Service assistance information can be used for relay selection. For example, assume that the E2E QoS of the service business is included in the request message. In this case, the U2U relay can predict the source side QoS and the target side QoS based on the feedback of the direct discovery process / direct communication request for the direct communication link quality (as an example, signal strength) and the pre-configured lookup table of the QoS profile for QoS splitting.

[0150] In the case that the candidate U2U relay performs relay discovery in Model A as described above, this indicates that each candidate U2U relay will periodically broadcast an announcement message to let other UEs in its vicinity know that it may be a U2U relay, such a process may also improve relay reselection.

[0151] In this case, the source UE Layer 2 ID and the target UE Layer 2 ID are not necessary for the candidate U2U relay, because the source UE and the target UE can obtain their Layer 2 IDs during Model A advertising and establish a Layer 2 link with the candidate U2U relay.

[0152] However, service related information and service assistance information are still useful for the optimization of relay selection. When the current U2U relay sends a request message with service related information, upon receiving such information, the candidate U2U relay in model A can add the service assistance information in its broadcast announcement as a personal performance prediction given the flow / application requirements specified in the service related information. In this way, when the source UE receives the enhanced version of the announcement message during neighborhood sensing, it can make a better reselection choice.

[0153] The third aspect of the response message is to whom the U2U relay should send the response message. The candidate U2U relay can obtain information about the recipient of the response message from the response message recipient indicator field in the request message. The response message recipient indicator field specifies the reply address to which the response message should be sent. Different exemplary implementations are listed below:

[0154] - The response message is sent to the original U2U relay (U2U relay 1, the relay that originally sent the request message). In this case, the original U2U relay may receive multiple response messages from different candidate U2U relays.

[0155] - A response message is sent to the source / target UE. In this case, the source / target UE may receive multiple response messages from different candidate U2U relays.

[0156] - If the request message is a broadcast request forwarded by an intermediate U2U relay, the candidate U2U relay will send a response message to the intermediate U2U relay, and the response message will go back until it reaches the U2U relay that originally sent the request broadcast.

[0157] The fourth aspect of the response message is its format. Response message format. Compared with the response message in the relay discovery model B described above, the response message includes the following parameters:

[0158] -Type = Response

[0159] -Discovery Type = U2U Relay Reselection

[0160] - Discoverer information (i.e., upper layer identifier of the candidate U2U relay)

[0161] - ProSe UE ID of the candidate U2U relay (i.e., the layer 2 identifier of the candidate U2U relay)

[0162] - List of "Target User Information" parameters

[0163] - (optional) list of "service auxiliary information" parameters.

[0164] In the response message, the candidate U2U relay may provide service assistance information, such as its QoS split expectations regarding E2E QoS (i.e., source-side QoS and target-side QoS), the load of the candidate U2U relay, QoS sustainability, etc. This service assistance information may be used for relay reselection.

[0165] -Step 5

[0166] In step 5, the relay reselection decision may be made by the source UE, the target UE, or the original U2U relay, depending on to whom the response message is sent. The receiving entity of the response message may receive multiple messages from different candidate U2U relays, and it may make a final decision based on: (1) wireless link quality (e.g., signal strength), (2) the service assistance information described previously, (3) implementation-specific preferences (such as preference for routes with fewer hops if multiple hops are considered, or preference for U2U relays in a specific geographic location area, etc.), or (4) a combination of these metrics.

[0167] -Step 6

[0168] In step 6, the layer 2 link establishment procedure may be initiated by different entities depending on to whom the response message is sent and who is making the final decision regarding relay reselection.

[0169] If the original U2U relay decides to relay reselection, it will indicate the decision to the reselected U2U relay, and the U2U relay will initiate 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 on relay reselection, it will be the source / target UE that 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 will be from the source (target) UE to the reselected U2U relay, and the reselected U2U relay will initiate a second direct communication request from itself to the target (source) UE.

[0170] Furthermore, in the context of the present invention, the original first U2U relay 1 may directly or indirectly determine a group candidate U2U relay that is suitable for relaying instead of or in addition to itself.

[0171] In the case of relaying instead of the current U2U relay, only 2-hop U2U relay (source UE-U2U relay-target UE) is considered. Figure 7 As shown, after relay reselection, the first U2U relay 1 connected to the source UE and the target UE is replaced by the U2U relay 2.

[0172] In the case of relaying in place of the current U2U relay, an optimized relay other than itself is found, which is a multi-hop U2U relay, such as Figure 8 shown.

[0173] exist Figure 8 In the exemplary embodiment of , the current U2U relay 1 will initiate a request message to find a group of candidate U2U relays (relay 2 to relay 4) other than itself. Figure 8In , 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 relay selection as an alternative lies in the service related information and service assistance information.

[0174] Consider for example (without loss of generality) QoS information as service-related / auxiliary information, consider Figure 8 In the scenario shown, the current relay node will send a request message to find an additional U2U relay, and the service-related information included in the request message is not an E2E QoS requirement as in the case of finding a replacement U2U relay. In this scenario, the service-related information is the target UE-side QoS that the current U2U relay negotiates with the target UE during side link communication before relay reselection. Upon receiving the request message, each candidate U2U relay can anticipate its performance by providing QoS splitting for its relay node-side QoS on the link to the current U2U relay and providing QoS splitting for its target UE-side QoS on the link to the target UE. The splitting is based on the input of the target UE-side QoS received in the request message. After performing the QoS splitting and including it in the service assistance information of the response message, each U2U candidate will have to send a response message to the current U2U relay that initiated the request. The current U2U relay node can select the optimal add node based on the service assistance information when receiving multiple copies of the response message from multiple candidate U2U relays.

[0175] Optionally, in the case of multiple additional hop U2U relays (e.g. Figure 8 The U2U relay 2 in will relay as an additional U2U relay, and the additional U2U relay 2 will relay to the target UE), performing the previously described process in a linked manner (the newly selected additional U2U relay 2 will repeat the operations already performed by the relay node to find its additional successor U2U relay node).

[0176] Next, service-related information and service assistance information will be discussed in detail. In particular, several exemplary embodiments will be discussed regarding how service-related information provided from a current U2U relay and service assistance information provided by a candidate U2U relay may be used to optimize relay reselection.

[0177] The first embodiment relates to U2U relay reselection with QoS expectations. In this embodiment, the current U2U relay initiates a request message as described in step 3 of the present invention. The service-related information included in the request message is the E2E QoS of the current service side link flow. More precisely, the original PQI (PC5 QoS identifier) ​​and the associated QoS profile and parameters are service-related 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. They are sent from the source UE to the current U2U relay during the layer 2 link establishment / modification between the two nodes, so the information is available at the current U2U relay when the request message is sent.

[0178] For example, in one specific embodiment, the current U2U relay will send a request message including service related information as follows:

[0179] PQI:23,GFBR:1Mbps.

[0180] A candidate U2U relay (e.g., Relay 2) can decode the request message to obtain the above service-related information, the layer 2 ID of the source UE, and the target UE. Relay 2 can use the layer 2 ID to send a DCR to the source / target UE to verify whether it can establish a layer 2 link with the source UE and the target UE. Upon receiving the DCR, the source UE and the target UE can respond with "Direct Communication Acceptance" to confirm that the side link between Relay 2 and the source / target UE is available. When Relay 2 receives "Direct Communication Acceptance", it can use the signal level of the received confirmation to roughly estimate the side link quality. In addition, Relay 2 will (1) be pre-configured, or (2) when within the coverage of the cellular base station, be configured by the cellular base station with a lookup table of supported QoS profiles for relevant source-side PC5 QoS parameters and relevant target-side PC5 QoS parameters.

[0181] Assume that the pre-configured lookup table of supported QoS profiles for relevant source-side PC5 QoS parameters at Relay 2 is as follows:

[0182] PQI Source Type Priority PDB PER … … … … … 21 GBR 3 20ms 10^-4 22 GBR 4 50ms 10^-2 26 GBR 3 50ms 10^-4 28 GBR 3 70ms 10^-4 … … … … …

[0183] According to E2E QoS service related information:

[0184] PQI:23,GFBR:1Mbps.

[0185] The source-side PC5 QoS that can potentially satisfy the above E2E QoS is the lines of PQI=21, 26, 28. This is because the line PQI=22 has too high a PER.

[0186] It is assumed that Relay 2 will have a similar table of target side PC5 QoS and it will perform the same method to estimate the sidelink capacity of the sidelink between Relay 2 and the target UE. For illustration purposes, it is assumed that the target side PC5 QoS retained is: PQI=21,26,28.

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

[0188] Assuming that the received signal level of the 'direct communication acceptance' 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 side link capacity of the side link on the source UE side as C_s=log(1+SINR_t). The GFBR of the PC5 QoS parameters on the source / target side can be roughly estimated as C_s*BW (C_t*BW on the target side, BW is the system bandwidth).

[0189] Finally, in the response message of Relay 2, it will include the service assistance information (supported PQI, estimated GFBR) of the supported source and target side PC5 QoS pairs: (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).

[0190] It is assumed that another candidate U2U relay 3 will perform the same process as relay 2 and send a response message to the source UE with its service assistance information for the supported source and target side PC5 QoS pairs. Upon receiving multiple response messages from different candidate U2U relays, the source UE can make a final decision on relay selection based on the service assistance information. The decision criteria can be completely based on the specific implementation, for example, considering the congestion control parameters at the source UE, and selecting a U2U relay that can provide a properly matched pair of source and target side PC5 QoS splits, for example, selecting relay 2 using the pair (source side: PQI=26, GFBR=xx1, target side: PQI=26, GFBR=yy1). Alternatively, if the application is actually very sensitive to delay, the source UE can reserve some margin for delay, for example, the source UE can select relay 2 with the pair (source side: PQI=21, GFBR=xx2, target side: PQI=21, GFBR=yy2), which will have an estimated E2E PDB of 40ms as delay requirement compared to the E2E QoS requirement of 100ms. Alternatively, once the delay and PER constraints are met, the source UE may prefer a combination with a better GFBR.

[0191] Once relay reselection is decided, a layer 2 link establishment procedure between the source UE and the reselected relay and between the relay and the target UE may be established, and the corresponding QoS may be negotiated.

[0192] Another embodiment relates to U2U relay reselection with QoS sustainability. In this embodiment, QoS sustainability is a parameter that defines the confidence to provide a given QoS level over a period of time. For example, QoS sustainability can be (low, medium, high), which can be calculated based on, for example, node mobility, load prediction, battery power (power consumption).

[0193] For example, in one specific embodiment, the current U2U relay will send a request message including service related information as follows:

[0194] PQI:23,GFBR:1Mbps.

[0195] For a candidate U2U relay, it may reply with a response message including the following service assistance information:

[0196] (Source side: PQI=26, GFBR=x1, QoS sustainability: medium, target side: PQI=26, GFBR=y1, QoS sustainability: high).

[0197] Another candidate U2U relay may reply with the following service assistance information:

[0198] (Source side: PQI=21, GFBR=x1, QoS sustainability: low, target side: PQI=21, GFBR=y1, QoS sustainability: low).

[0199] In this case, in order to have better QoS sustainability, the source UE may select the first U2U relay candidate.

[0200] Yet another embodiment relates to U2U relay reselection with high-layer information. In this embodiment, it is assumed that the U2U relay is a road side unit (RSU) deployed along a railway that is not a public railway communication network, such as Fig. 9 shown.

[0201] In this embodiment, all U2U relays (RSUs) are fixed deployments with known locations in advance. It is assumed that all U2U relays subscribe to a service group for performing U2U ProSe relaying, and their layer 2 IDs are propagated among all members of the group in advance. That is, each RSU knows exactly the layer 2 IDs of other RSUs in its vicinity, and also knows how to reach distant RSUs via multi-hop routing.

[0202] In this embodiment, the current U2U relay RSU3 initiates a request message as described in step 3. The current U2U relay RSU3 can predict the next relay to serve the target UE through high-level information such as the current position of the target UE and the speed information of the target UE and the position of the candidate U2U relay (RSU2). The service-related information included in the request message may be the current position of the target UE train (if the current U2U relay RSU is able to predict or obtain such information), or a kind of prediction information about the time when the target UE will be near RSU2. The service-related information may also include the last data packet relayed from RSU3 to the target UE, in which case, when RSU2 is reselected to replace RSU3, it can accurately use the data that was not successfully sent by RSU3 due to the sidelink switching to start service relay.

[0203] In the service assistance information sent from the candidate RSU2 to the source UE (RSU1), an estimate of the service time of RSU2 as a U2U relay may be included. In this way, upon receiving this information, the source UE (RSU1) can optimize its buffer and caching mechanism for relaying.

[0204] In view of the above, in the present invention, a method for optimizing relay reselection for communication between two UEs in the context of off-network UE-to-UE communication via a side link PC5 interface is proposed. After establishing a connection between a source UE and a target UE via a first U2U relay, the current first U2U relay knows the E2E QoS requirements of the current service flow, because it is the U2U relay that is responsible for splitting the E2E QoS into source-side QoS and target-side QoS. In the event of a sudden side link failure, the source UE and the target UE do not have sufficient time to negotiate relay reselection, but let the source UE perform the relay discovery and selection process again. In the present invention, the current U2U relay directly or indirectly determines a group U2U relay suitable for relaying in place of itself or in addition to itself. In this way, no negotiation is required between the source UE and the target UE, which is superior to the relay reselection method based on source-target UE negotiation during a sudden link failure. In addition, since the first U2U relay is a relay for relaying communication, it has first-hand information about the application flow between the source UE and the target UE. Thus, when having the first U2U relay directly or indirectly determine a group U2U relay suitable for relaying in place of or in addition to itself, such stream / application service related information may be considered for a better decision. In addition, as described above, the determination process may include service assistance information provided by the candidate U2U relays, which is each candidate UE's prediction of its performance if the candidate UE is selected based on service related information about the stream / application requirements.

[0205] In addition, it is known to those skilled in the art that the above examples according to the present invention can be implemented in many ways, such as program instructions executed by a processor, software modules, microcodes, computer program products on computer readable media, logic circuits, application specific integrated circuits, firmware, etc. The embodiments of the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment containing both hardware elements and software elements. In a preferred embodiment, the present invention is implemented in software, which includes but is not limited to firmware, resident software, microcodes, etc.

[0206] In addition, embodiments of the present invention may take the form of a computer program product accessible from a computer-usable medium or a computer-readable medium, which provides a program code used by a computer, a processing device, or any instruction execution system or used in combination with it. For the purposes of this specification, a computer-usable medium or a computer-readable medium may be any device that can contain, store, communicate, or transmit a program for use by an instruction execution system, a device, or a device or used in combination with it. The medium may be an electronic, magnetic, optical, or semiconductor system (or device or device). Examples of computer-readable media include, but are not limited to, semiconductor or solid-state memory, magnetic tape, removable computer disk, RAM, read-only memory (ROM), hard disk, optical disk, etc. Current examples of optical disks include compact disk read-only memory (CD-ROM), compact disk read / write (CD-R / W) and DVD.

[0207] The embodiments described above are illustrative of the present invention. Various modifications may be made to them without departing from the scope of the present invention as derived from the appended claims.

Claims

1. A method for optimizing relay reselection for sidelink communication between a source user equipment and a target user equipment, the method comprising the following steps: -sending, by the first U2U relay, a request message for relay reselection to at least one nearby U2U relay, wherein the sidelink communication is initially established via the first U2U relay; and - At least one candidate U2U relay among the at least one nearby U2U relay sends a response message in response to the request message to perform relay reselection.

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

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

4. The method according to claim 1, wherein: The request message includes service-related information related to a service business performed through the first U2U relay.

5. The method according to claim 4, wherein: Sending a response message in response to the request message is based on the service related information.

6. The method according to claim 1, wherein: The response message includes the layer 2 ID of the at least one candidate U2U relay.

7. The method according to claim 1, wherein: The response message includes service assistance information provided by the candidate U2U relay, and the service assistance information includes the candidate U2U relay's prediction of its performance.

8. The method according to claim 4 or 7, wherein: The service-related information or the service auxiliary information includes end-to-end (E2E) QoS, load of relays, QoS sustainability or application-level information.

9. The method according to claim 1, wherein: During the step of sending a response message in response to said request message: - the response message is sent to the first U2U relay; or - The response message is sent to the source user equipment or the target user equipment.

10. The method according to claim 1, wherein: Before the step of sending the request message, the method comprises the following steps: - establishing a connection between the source user equipment and the target user equipment via the first U2U relay; And wherein, after the step of sending the response message, the method comprises the following steps: - determining, by said first U2U relay, at least one second U2U relay for relay reselection.

11. The method according to claim 10, wherein: The at least one candidate U2U relay receives the request information and decides to become an applicant for the second U2U relay for the relay reselection.

12. The method according to claim 7 or 10, wherein: The method further comprises the following steps: - Making a relay reselection decision, and selecting at least one second U2U relay for the relay reselection among the at least one candidate U2U relay based on serving assistance information.

13. The method according to claim 10, wherein: The step of determining at least one second U2U relay for relay reselection comprises: - Determining, directly or indirectly, by the first U2U relay, the at least one second U2U relay suitable for relaying instead of or in addition to the first U2U relay.

14. The method according to claim 10, wherein: The step of determining at least one second U2U relay for relay reselection comprises: The first U2U relay may decide to perform U2U relay reselection periodically or upon detecting a side link failure event or an evolution of a radio link condition.

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

Images