Method for relaying a VRU application server for updating a VRU, and a UE, a VRU application server, and a UE client

Abstract

The present invention relates to a method for relaying a VRU application server 20 for updating vulnerable road users' parameters P1, P2, P3 of a vulnerable road user (VRU) corresponding to a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, the method including: a second user equipment (UE) receiving a first message from the VRU application server, the first message including information related to the VRU parameters of the first UE, the second user equipment (UE) corresponding to a vehicle and present in the V2X communication system; the second user equipment (UE) sending a second message including information related to the VRU parameters to the first user equipment (UE) via device-to-device communication; and the second user equipment (UE) receiving a third message from the first user equipment (UE) including information related to values ​​of the VRU parameters of the first user equipment (UE).

Description

Technical Field

[0001] The present invention generally relates to the area of device-to-device electrical communication systems, and more particularly to a method for avoiding vulnerable road users.

Background Art

[0002] In these methods, a vulnerable road user (VRU) broadcasts a VRU Awareness Message (VAM) that includes the VRU position, the VRU speed, and various VRU-related information. Vehicles within the coverage area of the VRU receive the VAM message, detect the VRU, and evaluate the risk of a collision related to the VRU. To implement such a method, it is necessary for the VRU and the vehicle to receive specific information from an application server. For example, the application server transmits resource planning to the vehicle and the VRU, and notifies those vehicles and VRUs of the radio resources used to broadcast the VAM. This specific information requires the VRU to update parameters related to the VRU avoidance method and the application server to update the status of the VRU. If the value of the VRU parameter does not correspond to the value of these parameters of the VRU status of the application server, the VRU avoidance method cannot be correctly executed.

[0003] More precisely, in the VRU avoidance method, the VRU broadcasts a VAM received by an application server. The VAM includes the current position of the VRU, the speed of the VRU, and other VRU-related information such as the type of the VRU (e.g., pedestrian or bicycle). Thereafter, the application server determines or updates the VRU status. That is, the application server updates the value of the parameter of the VRU status. These parameters include, for example, the following. - A parameter corresponding to the identification of the VRU, - A parameter indicating the VAM reporting periodicity, - Synchronization information, - Radio resource planning for VAM transmission, - Others.

[0004] The application server can send new values of the VRU parameters to the VRU according to the updated VRU status. For example, the application server may change the radio resources reserved for sending the ID or VAM. When these parameters are changed, the application server sends their new values to the VRU.

[0005] The application server sends certain information related to the new VRU status to the vehicle. By sending this information to the vehicle, the vehicle can decode the radio resources used by the VRU to send the VAM, and thus can discover the VRU. Based on the information received by the VAM, the vehicle can evaluate the risk of collision with the VRU.

[0006] The values of the VRU parameters (values on the VRU side) should correspond to the values of these parameters of the VRU status (values stored on the application server side). Otherwise, the application server will send information related to incorrect VRU status to the vehicle. Therefore, the vehicle cannot implement the VRU avoidance method. The VRU avoidance method therefore requires the VRU to maintain connectivity with this application server. However, maintaining such connectivity can be difficult, especially when the VRU is moving.

Summary of the Invention

Problems to be Solved by the Invention

[0007] The present invention aims to improve the above situation.

Means for Solving the Problems

[0008] Therefore, the present invention is a method of relaying a VRU application server that updates traffic vulnerable user (VRU) parameters of a traffic vulnerable user corresponding to a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, wherein a second UE receives a first message including information related to the VRU parameters of the first UE, the information being generated by an application server based on the VRU status of the first UE, and the second UE corresponding to a vehicle and existing in the V2X communication system, the second UE transmits a second message including information related to the VRU parameters to the first UE via device-to-device communication, and the second UE receives a third message including information related to the value of the VRU parameters of the first UE from the first UE, relating to a method.

[0009] Therefore, when connectivity cannot be maintained between the first UE (corresponding to the VRU) and the application server, the application server is relayed by a second UE (which may similarly be a VRU corresponding to a vehicle). That is, the second UE can execute at least a part of the services executed by the application server during the time when the application server and the first UE cannot exchange data. For example, based on information related to the value of the VRU parameter, the second UE can also hold the VRU status of the updated VRU, or can transmit this information to an application server that can hold the VRU status of the updated VRU. More specifically, when the information related to the value of the VRU parameter indicates a value different from the value of the parameter of the VRU status, the VRU status is not the latest, and the second UE, i.e., the application server, can update the value of the parameter in the VRU status. When the information related to the value of the VRU parameter indicates the same value as the value of the parameter of the VRU status (or when it is simply confirmed that the value has been updated according to the information of the second message), the VRU status is the latest, and for the VRU status, no specific operation needs to be performed by the second UE, but the second UE may transmit the information related to the value of the VRU to the application server and / or other UEs.

[0010] Therefore, the VRU status held by the application server when the connection with the first UE is maintained is held by the second UE and / or the application server when the application server cannot properly receive the VAM from the first UE (the information is then relayed to the application server via the second UE).

[0011] The second UE can also relay the application server for only some of the statuses, or can relay the application server even for only one parameter. That is, the first message relates to only one VRU parameter of the first UE. However, this first message or another message received by the second UE from the application server may relate to two or more VRU parameters of the first UE, or even to all the parameters of the status.

[0012] More generally, the VRU status can be held by the second UE instead of the application server, and thus the second UE can relay the application server completely, which is advantageous when the connection between the second UE and the application server cannot be maintained. The VRU status can also be held by the application server, and thus the second UE mainly relays the application server in order to send information related to the VRU parameters to the first UE and finally send information related to the values of the VRU parameters to the application server. The VRU status can be held by both the application server and the second UE, and thus in addition to updating the status on the second UE side, the second UE sends information related to the VRU parameters to the first UE and sends information related to the values of the VRU parameters to the application server. In addition to any of these possibilities, another UE can also hold the VRU status, and thus when the second UE holds the status, the application server sends the same message to this another UE as the message sent to the second UE, so that it can be seen by the third UE, and the second UE sends information related to the values of the VRU parameters to the application server to this another UE so that it can be seen by the third UE.

[0013] When the status is maintained by an entity separate from the application server, the first message (or, when the status is maintained by another UE, an equivalent message sent to this other UE) can include information related to other VRU parameters and can ultimately include information related to all VRU parameters of the VRU. This other UE can be regarded as a third UE hereinafter.

[0014] Thus, the present invention avoids slow VRU discovery by other vehicles due to a mismatch of VRU parameters between the VRU and other vehicles, for example, resulting from the unavailability of a connection to the application server. Therefore, when the VRU avoidance method is executed, latency is reduced.

[0015] The VRU avoidance method is construed as any method that enables a vehicle (e.g., corresponding to a second UE or a third UE) to estimate the probability of a collision with the VRU and ultimately alert the driver of the vehicle.

[0016] Vulnerable road users are interpreted as any user of a space shared with motor vehicles (e.g., a road) or a space dedicated to motor vehicles (e.g., a highway), and / or any user of a nearby space (e.g., a sidewalk) that may be subject to a collision with these motor vehicles. Such users include, for example, pedestrians, motorcyclists, cyclists, etc. Vulnerable road users can also be defined, in accordance with the ITS Directive, as all road users without an engine (such as pedestrians and cyclists), motorcyclists and persons with disabilities or reduced mobility and orientation, regardless of the type of vehicle being driven. Vulnerable road users can also be interpreted as those defined in the ETSI report "Intelligent Transport System (ITS); Vulnerable Road Users (VRU) awareness; Part 1: Use Cases definition; Release 2" (ETSI TR 103 300-1 V2.1.1). This report takes into account the user, but also the situation of the user within that environment (see Table 4 of the ETSI report).

[0017] A VRU application server is interpreted as a server that manages and / or provides VRU services (VRU avoidance methods), i.e., services aimed at minimizing collisions between VRUs and other vehicles.

[0018] The vulnerable road user (VRU) parameters are interpreted as parameters with values specific to the VRU obtained by the VRU itself (e.g., speed or position), or parameters with values specific to the VRU obtained by the VRU application server and / or the user equipment (UE) relaying the VRU application server (e.g., the application ID of the VRU). The VRU status (maintained by the VRU application server and / or another UE relaying the VRU application server such as a second UE) includes values specific to each VRU of the VRU parameters. The VRU status is maintained by the VRU application server and / or any UE relaying the VRU application server. That is, the VRU status can be stored and updated by the entity maintaining the VRU status. The VRU status is specific to each VRU. The VRU itself can have a copy of the VRU status. However, the VRU stores at least one value of the parameters of the VRU status.

[0019] Updating such VRU parameters is interpreted as directly changing the values of the parameters related to (or specific to) the VRU in the status and / or on the first UE.

[0020] The VRU corresponding to the user equipment (or the user equipment corresponding to the VRU) is interpreted as the VRU carrying the UE.

[0021] The vehicle-to-everything communication system is interpreted as a computer network in which the vehicle and the roadside unit are communication nodes that enable communication between at least the vehicle UE, the VRU UE, and the VRU application server of this network.

[0022] Information related to VRU parameters is interpreted as any information related to VRU parameters, for example, the value of the parameter in the VRU status (on the application server side), the update value when the application server requests the first UE to update the parameter (on the UE side), the request addressed to the first UE to send the set value when the parameter is set (on the UE side), etc.

[0023] Device-to-device (D2D) communication is interpreted as direct communication between two UEs.

[0024] The transmission of the second message from the second UE to the first UE can be performed after the second UE wirelessly discovers the first UE and establishes a communication channel. For example, the first UE broadcasts the VAM through a specific radio resource, which is decoded by the second UE and results in the reception of the VAM when the second UE and the first UE are close enough to each other.

[0025] The transmission of the third message from the first UE to the second UE can be performed via any type of communication, for example, through device-to-device communication or through a cellular communication network.

[0026] According to one aspect of the present invention, the method further includes the application server determining that the second UE is at a distance less than a threshold from the first UE and / or determining that the second UE will be at a distance less than a threshold from the first UE within a duration less than a predetermined duration.

[0027] Therefore, when the second UE near the first UE is selected, the second UE is more likely to be able to perform D2D communication with the first UE (e.g., after the discovery procedure), and when the second UE is moving towards the first UE, the second UE is more likely to be able to perform D2D communication with the first UE.

[0028] Any method can be used to determine that the second UE is at a distance less than a threshold from the first UE or will be at a distance less than a threshold from the first UE. For example, the application server can use a positioning system (e.g., GPS, Internet geolocation, wireless positioning, etc.), or the application server can infer the position and / or route of the first UE based on prior D2D exchanges between the second UE and other UEs in the network. The position of the first UE can be incorporated into the most recent position reported to the application server through the VAM, and this position can be improved using information regarding the most recent speed of the first UE reported to the VRU application server.

[0029] According to one aspect of the present invention, the method further includes the second UE transmitting a fifth message including information related to the above value of the VRU parameter of the first UE to a third UE corresponding to another vehicle and present in the V2X communication system.

[0030] Therefore, the second UE transmits a message including information related to the value of the VRU parameter based on the information received via the third message. As a result, the third UE can have the most recently updated value of the VRU parameter. Thus, when a third UE corresponding to another vehicle relays the application server as the second UE did, the third UE can update the status or at least the VRU parameter even if the application server has not received information related to the value of the VRU parameter (this may occur when the second UE loses its connection to the application server, for example, when the first UE and the second UE are in a zone where they do not receive sufficient service in the cellular network due to the environment). Thereby, the latency between the time when the second UE receives the third message and the time when the third UE receives the information related to the value of the VRU parameter is also reduced, which is particularly advantageous when the vehicles are traveling in the same direction and a fast update is required to implement the VRU avoidance method.

[0031] The transmission between the second UE and the third UE can be of any type, for example, device-to-device communication (which provides the best reduction in latency) or via a cellular communication network (which also reduces latency since the application server is not processing the information).

[0032] According to one aspect of the present invention, the method further includes the second UE transmitting a fourth message including information related to the above value of the VRU parameter of the first UE to the application server.

[0033] Therefore, the application server can update the status it holds or check for an update of the status it holds. Therefore, when the connection with the first UE resumes, the application server can continue with the normal update procedure based on the most recent update of the VRU status. If the connection with the first UE does not resume, the application server can also relay it by another UE based on the most recently updated status.

[0034] According to one aspect of the present invention, the method further includes the first UE updating the parameter to the above value based on information related to the VRU parameter.

[0035] This is the case where the parameter involved, for example, the VRU ID of the first UE (since this ID is related to the application layer, it is also called the application ID) is managed by the application server, and for example, it may not apply to the parameter corresponding to the position of the VRU. The information related to the VRU parameter can therefore include the value for the first UE to update the parameter. In addition, the information related to the VRU can also include an update command to instruct the VRU (the first UE) to update the VRU parameter according to the value. Alternatively, when the received value refers to a specific VRU parameter, the first UE can be configured to update to this value.

[0036] According to one aspect of the present invention, the method further includes the application server setting the VRU parameter of the VRU status of the first UE to the updated value based on the information related to the above value.

[0037] This is the case where the parameter involved, for example, the parameter corresponding to the position or speed or trajectory of the VRU is managed by the first UE. The information related to this value is transmitted in a third message by the second UE.

[0038] Alternatively or additionally, setting the VRU parameters of the VRU status of the first UE to an updated value based on the information related to the above value can be done by the second UE (or the third UE when the fifth message is sent to the third UE) when the VRU status is held by the second UE. Therefore, sending the fourth message is not necessary. However, the VRU status may be held by several entities, namely at least the application server and the second UE or another UE (e.g., the third UE).

[0039] According to one aspect of the present invention, the information related to the VRU parameters includes the value of the VRU parameters of the VRU status before the update, and the method further includes the first UE comparing the value before the update with the above value of the VRU parameters of the first UE.

[0040] Therefore, the first UE can determine whether the value of the VRU parameters of the VRU status is up-to-date, and if not, the first UE can indicate that in the third message.

[0041] In any case, the third message including the information related to the value of the VRU parameters of the first UE can be sent in the following cases. - When the parameter is managed by the application server: For example, when the first UE has not updated to the value instructed by the application server, the first UE can send the above third message to send the updated value of the VRU parameters or to send only the confirmation that the value has been updated; - When the parameter is managed by the application server: The above third message can be sent for the VRU application server (or the UE relaying the VRU application server) to send the value to which the VRU parameters should be updated.

[0042] According to one aspect of the present invention, when the application server has not received or has not received within a time a sixth message including information related to the VRU parameters of the first UE, the application server further includes transmitting a first message to the second UE and / or the third UE.

[0043] Therefore, the second UE and / or the third UE (i.e., another UE) relays the application server when it is unable to maintain a connection with the first UE. This reduces the data exchanged between the application server and the UE that can relay this application server, and also reduces the data stored by these UEs. However, the relaying of the application server can be permanently implemented to ensure less delay in status updates when the first UE loses its connection with the application server. The sixth message can be any type of message, for example, a broadcast message or a point-to-point message. Losing the connection between the first UE and the application server is interpreted as the application server no longer receiving the sixth message or a message like the sixth message from the first UE. When the sixth message is a broadcast message, the sixth message can be a VRU awareness message (VAM), i.e., a message transmitted by the first UE to broadcast information (e.g., the position of the VRU) to the nearest vehicles and enable those vehicles to execute a VRU avoidance method.

[0044] According to one aspect of the present invention, the VRU parameter is one of the position of the VRU, the speed of the VRU, the moving direction of the VRU, the VRU group ID, the VRU identification information in the network as a user terminal (UE), the VRU application identification information in the application server, or any other information characterizing the VRU group or cluster and / or the VRU application.

[0045] The position, velocity, and direction of movement of the VRU are interpreted as the geographical position, velocity, and movement of the VRU carrying the first UE in the VRU's environment. These values of these VRU parameters can be directly obtained by the first UE, or the first UE can send, in a sixth message, data that, for example, an application server and / or a second UE and / or a third UE can use to obtain these values. Any method can be used to obtain the values of these VRU parameters. For example, these values can be obtained by using a positioning system (such as GPS, Internet geolocation, wireless positioning, etc.), or can be obtained based on prior D2D exchanges between the second UE and other UEs in the network.

[0046] The VRU group ID is interpreted as an ID that identifies a cluster of nearby VRUs within the network deployment area. The group is identified by its size, range, and group head. The group head (one of the VRUs in the cluster) relays information locally to the VRU group members. The group ID can be, for example, an identifier that uniquely identifies the group head in the network. This identifier is shared between the group head and the VRU group members. The group ID can also be defined by an application server to uniquely identify a cluster of VRUs within the deployment.

[0047] The UE identification information (ID) is interpreted as any information that enables an application server and / or a second UE and / or a third UE, and more generally any entity involved in the service, to identify the first UE. This ID is thus involved in identification at the application layer level. This ID is determined by and / or belongs to the application server and / or the UE relaying the application server.

[0048] Other parameters can be related to the identification of VRU applications. In this case, multiple VRU applications can be deployed for VRUs. VRU applications can be related to class information. For example, one application can be used for pedestrians, and another application can be defined for cyclists or motorcyclists.

[0049] According to one aspect of the present invention, device-to-device communication is established based on communication parameters transmitted by an application server.

[0050] Thereby, the second UE can set up a communication channel with the first UE. These communication parameters correspond to, for example, the radio resources used by the first UE to transmit a VAM, and based on this VAM, the second UE discovers the first UE. These communication parameters can be transmitted in a first message.

[0051] A second aspect of the present invention is a user equipment (UE) configured to relay a VRU application server that updates traffic vulnerable user (VRU) parameters of a traffic vulnerable user corresponding to another user equipment (UE) in a vehicle-to-everything (V2X) communication system. This UE corresponds to a vehicle and exists in the V2X communication system. This UE includes a processor and a non-transitory computer-readable medium containing stored instructions, and is provided with when the instructions are executed by the processor, receiving a first message including information related to the VRU parameters of another UE, the information being generated by an application server based on the VRU status of another UE, and transmitting a second message including information related to the VRU parameters to another UE via device-to-device communication, Receiving, via device-to-device communication, from another UE, a third message including information related to values of VRU parameters of the another UE, relates to a user equipment configured to cause the present UE to perform the above.

[0052] A third aspect of the present invention is a method of relaying a VRU application server that updates VRU parameters of a vulnerable road user (VRU) corresponding to a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, wherein the VRU application server transmits a message including information related to VRU parameters of the first UE based on the VRU status of the first UE to at least a second UE, the second UE corresponding to a vehicle and being present in the V2X communication system, the VRU application server receives from at least the second UE another message including information related to values of VRU parameters of the first UE, and relates to a method.

[0053] According to one aspect of the present invention, the method further includes the application server generating information related to VRU parameters of the first UE based on the VRU status of the first UE.

[0054] A fourth aspect of the present invention is a VRU application server configured to relay an application service to a second UE that updates VRU parameters of a vulnerable road user (VRU) corresponding to a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, the UE corresponding to a vehicle and being present in the V2X communication system, the present VRU application server including a processor, a non-transitory computer-readable medium including stored instructions, and comprising the instructions, when executed by the processor, Transmitting at least to a second UE a message including information related to a VRU parameter of a first UE based on a VRU status of the first UE, wherein the second UE corresponds to a vehicle and exists in a V2X communication system, Receiving at least from the second UE another message including information related to a value of a VRU parameter of the first UE, relates to a VRU application server configured to perform the above.

[0055] A fifth aspect of the present invention is a method of relaying a VRU application server that updates a vulnerable road user (VRU) parameter of a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, wherein a first UE receives a message including information related to a VRU parameter of the first UE from a second UE via device-to-device communication, the information being generated by an application server based on a VRU status of the first UE, and the second UE corresponds to a vehicle and exists in a V2X communication system, wherein the first UE transmits another message including information related to a value of a VRU parameter of the first UE to the second UE via device-to-device communication, and relates to a method.

[0056] A sixth aspect of the present invention is a user equipment (UE) client of a vulnerable road user (VRU) application server, the present UE corresponding to a VRU and existing in a V2X communication system, and the present UE includes a processor, a non-transitory computer-readable medium including stored instructions, and is provided with the instructions, when executed by the processor, Receiving, via device - to - device communication, from another UE, a message containing information related to the VRU parameters of this UE, where the above - mentioned information is generated by an application server based on the VRU status of this UE, and the above - mentioned another UE corresponds to a vehicle and exists in a V2X communication system, and This UE transmitting, via device - to - device communication, another message containing information related to the value of the VRU parameters of this UE to another UE, and relates to a UE client that configures this UE to perform the above.

[0057] The seventh aspect of the present invention relates to a computer program product that includes code instructions for executing the above - mentioned method when executed by a processor.

[0058] The present invention is shown by way of example, not limitation, in the figures of the accompanying drawings. In the accompanying drawings, like reference numerals refer to like elements.

Brief Description of the Drawings

[0059]

Figure 1

Figure 2

Figure 3

Modes for Carrying Out the Invention

[0060] Referring to FIG. 1, a V2X communication system implementing an embodiment of the present invention is shown. In FIG. 1, a VRU 1 is shown. The VRU 1 is, in this example, a user in a space (sidewalk) near the space used by a vehicle with an engine, and may eventually use a crosswalk which is a space shared with the vehicle with an engine. Other vehicles with engines are also represented by 2, 3, and 4. These vehicles 2, 3, 4 are using the road and may eventually have a risk of collision with the VRU 1. For example, when the VRU 1 crosses the road on the crosswalk, vehicles 2 and 3 traveling in the direction of the crosswalk may have a risk of collision with the VRU 1. The situations of vehicle 4 and VRU 1 may also present such a risk when vehicle 4 makes a left turn or when the VRU 1 crosses the road without using the crosswalk.

[0061] The VRU avoidance method implemented by the V2X communication system involves a distributed VRU application in a client-server based model. The server part of this application is supported by a VRU application server 20.

[0062] The VRU 1 carries a UE called the first UE. The first UE supports the client 21 part of the VRU application.

[0063] Vehicle 2 carries a UE called the second UE. The second UE also supports the client 22 part of the VRU application. In addition, when the second UE replaces the VRU application server or replicates the functions of the VRU application server, the second UE can support the server 22 part of the VRU application. When the second UE operates as a relay for message transmission and neither replaces the server nor operates as a server, the second UE does not support the server part of the VRU application and operates only as a network endpoint entity when considered as a client.

[0064] Vehicle 3 carries a UE called the third UE. The third UE also supports the client 23 part of the VRU application and can also support the server 23 part of the VRU application as is done using the second UE.

[0065] Vehicle 4 can be the same as other vehicles (and can carry a UE that supports part of the VRU application), but for simplicity, Figure 1 does not show these details.

[0066] Each of these entities (the first UE, the second UE, the third UE, and the VRU application server) can communicate via a network including a V2X communication system or any other communication system. For example, the communications 320, 330 established between vehicles 2, 3 and the VRU application server 20 can be supported by a conventional cellular communication network. For example, a wireless channel can be established between the base station 40 and vehicles 2, 3 to support the communication between vehicles 2, 3 and the VRU application server 20. The communications 320, 330 between vehicles 2, 3 and the VRU application server 20 can also use satellite communication techniques. The communication 310 between VRU1 and the VRU application server 20 can use the same techniques (such as satellite, cellular, etc.) as those used for the communication between vehicles 2, 3 and the VRU application server 20.

[0067] The communication 321 between VRU1 and vehicle 2 is D2D communication. However, part of that exchange (the transmission M3 from the first UE to the second UE) can be done based on another principle, for example, using the same techniques as those used between vehicles 2, 3 and the VRU application server 20. The communication 332 between the two vehicles 2 and 3 can be based on the same techniques (such as D2D communication) as those used between VRU1 and vehicle 2.

[0068] The VRU application server 20 stores the status 50 of VRU1 including the values of VRU parameters (P1, P2, P3, etc.). These VRU parameters are used by VRU1 and vehicles 2, 3, or 4 to execute the VRU avoidance method. For example, P1 can be UE identification information, P2 can be a VRU group ID, and P3 can be the VRU position and speed of the VRU. The status 50 can include the values (V1, V2, and V3) corresponding to VRU1 for each parameter (P1, P2, and P3). When the second UE of vehicle 2 and / or the third UE of vehicle 3 at least partially replace the VRU application server 20, or when at least partially replicating the services provided by the VRU application server 20, servers 22 and / or 23 hold the VRU status 52 and / or 53 of VRU1. That is, those servers 22 and / or 23 store the VRU status and update the VRU status as needed. When the second UE of vehicle 2 and / or the third UE of vehicle 3 neither replace the VRU application server 20 nor replicate the services provided by the VRU application server 20, but only transmit messages between the client 21 of the first UE and the VRU application server 20, the second UE and the third UE may not hold any status of VRU1.

[0069] Referring to FIG. 2, a flowchart representing the steps of an embodiment according to the present invention is shown.

[0070] In step S0, the VRU application server 20 has not received the VAM M6 from the first UE61 that enabled the update of the VRU status 50. For example, a timer is started when the most recent VAM M6 is received from the first UE61, and when this timer expires and no other VAM M6 has been received. Therefore, the connection between the VRU application server 20 and the client 21 supported by the first UE61 is lost.

[0071] If the VRU application server 20 has not received such a VAM M6, it cannot update the VRU status 50, and thus triggers the following steps so that the second UE62 and / or the third UE relays the VRU application server 20. However, this step can be optional, and the second UE62 and / or the third UE can relay the VRU application server 20 independently of receiving the VAM M6 from the first UE61 corresponding to the VRU1, or can relay it in response to the reception. In that case, step S1 or S2 is performed without performing step S0 beforehand.

[0072] The VAM can be a message as described in, for example, ETSI TS 103 300-2 V2.1.1 (2020-05).

[0073] In step S1, the VRU application server 20 determines which vehicle is present or may be present near the VRU1.

[0074] For example, the VRU application server 20 requests the following. - The distance between the VRU1 and the vehicles 2, 3, 4 connected to the VRU service; and / or - The direction in which the vehicles 2, 3, 4 connected to the VRU service are traveling.

[0075] If at least one of the distances is less than the threshold, or if the VRU application server 20 can predict that one of the vehicles 2, 3, 4 will be at a distance less than the threshold based on one of the directions in which the vehicles 2, 3, 4 are traveling, the VRU application server 20 can perform step S2 with the vehicle for which this condition is checked. In the example of FIG. 1, these vehicles are vehicle 2 and vehicle 3.

[0076] Using any known method, it can be determined that one of the vehicles 2, 3, 4 is at a distance less than a threshold from the first UE61, or will be at a distance less than a threshold from the first UE61. For example, the VRU application server 20 can use a positioning system, such as GPS, to track the positions of each of the vehicles 2, 3, 4. The position of the VRU1 used to determine these distances can be the most recent position reported to the VRU application server 20 through the most recent received VAM.

[0077] In step S2, the VRU application server 20 transmits the message M1 to the second UE and / or the third UE through pre-established communications 320 and 330.

[0078] These messages can include the following. - The VRU status held by the VRU application server 20, i.e., the VRU status 50. This is mainly the case when the servers 22 and / or 23 at least partially replace the VRU application server 20, or when at least partially replicating the services provided by the VRU application server 20; and - Communication information (also called communication parameters). This communication information includes the following: ○ Authentication information that enables the servers 22 and 23 to implement the connection procedure to the services of the client 21 or simply secure the transmission of the message M3, and ○ Information regarding specific radio resources that can be used to establish the communication link 321 with the first UE61; - Information related to operations performed by the second UE 62 or the third UE. For example, the VRU application server 20 notifies the second UE 62 or the third UE to replicate the functions of the VRU application server 20. Alternatively, the VRU application server 20 notifies the second UE 62 or the third UE to instruct the client 21 to update one of the VRU parameters 51 to a value provided by the VRU application server 20 (operation 1). Alternatively, the VRU application server 20 can compare the value of the VRU parameter 51 provided in the information related to the operation being performed with the value of this VRU parameter 51 used by the client 21, and if different, notify the second UE 62 or the third UE to instruct the client 21 to transmit this value (operation 2). When the VRU application server 20 instructs the second UE 62 or the third UE to reproduce or replicate the functions of the VRU application server 20, the servers 22 and 23 then operate autonomously from the VRU application server and perform either operation 1 or operation 2 as necessary. Therefore, only the cases of operation 1 and operation 2 are described in detail below.

[0079] In step S3, the first UE 61 and the second UE 62 establish a D2D communication channel therebetween. The D2D communication can be established based on a radio discovery procedure. In fact, based on information regarding radio resources, the second UE 62 can receive and decode specific radio resources on which the first UE 61 can broadcast the VAM. If such a VAM is received by the second UE 62, the second UE 62 can then establish a communication link with the first UE 61 based on authentication information, secure the communication channel between the second UE 62 and the first UE 61, and / or connect the client 21 to the server 22 supported by the second UE 62.

[0080] In step S4, the second UE62, more specifically, the part 22 of the VRU application supported by the second UE62, transmits the message M2 to the first UE61, and further to the client 21 (at the application level) through the D2D communication 321. In fact, when the communication is established between the first UE61 and the second UE62, the second UE62 transmits the message M2.

[0081] In the case of operation 1, the message M2 includes at least one value Viupdate of the VRU parameter Pi (P1 or P3). For example, the VRU application server 20 or the server 22 can reassign the ID of the client 21 (the application ID of VRU1), and thus, Viupdate is a new ID.

[0082] In the case of operation 2, the message M2 includes at least one value Vi or Vi' of the VRU parameter Pi (P1 or P3). For example, the VRU application server 20 or the server 22 can update the position of VRU1. Thus, M2 includes the position Vi or Vi' actually known by the VRU application server 20 or the server 22.

[0083] In step S5.1, the first UE61 updates the value Vi’’51 of the VRU parameter Pi locally stored and used by VRU1 to a new value Viupdate. This corresponds to the case of operation 1.

[0084] In step S5.2, the first UE61 compares the value Vi’’51 of the VRU parameter Pi locally stored and used by VRU1 with the value Vi or Vi' transmitted in M2. This corresponds to the case of operation 2. Thus, the first UE61 determines whether the values Vi or Vi' of the VRU parameters of the VRU status 50, 52, 53 are up-to-date.

[0085] In step S6, the first UE 61 transmits the message M3 to the second UE 62 via the communication 321, that is, via the D2D communication established between the first UE 61 and the second UE 62. Alternatively, M3 can be transmitted through another communication channel, for example, via a conventional cellular phone network.

[0086] When operation 1 is executed, M3 can include confirmation of the update of Vi’’ to Viupdate.

[0087] When operation 2 is executed, if Vi’’ is equal to Vi or Vi’, M3 can include only information indicating such equality. If Vi’’ is different from Vi or Vi’, M3 can include either the value Vi’’, or any information that enables the second UE 62 or the VRU application server 20 to obtain this value Vi’’ (for example, the gap between Vi’’ and Vi or Vi’). Therefore, M3 includes information related to the value Vi’’ to which the VRU parameter Pi of the VRU status should be updated.

[0088] In step S7.1, the second UE 62 (the part 22 of the VRU application supported by the second UE) transmits the message M4 to the VRU application service 20.

[0089] This message M4 includes the information transmitted to the second UE 62 by the first UE 61 in the message M3. For example, M4 can include confirmation of the update of Vi’’ to Viupdate, or information that enables the second UE 62 or the VRU application server 20 to obtain the value Vi’’.

[0090] In step S7.2, the second UE 62 (the part 22 of the VRU application supported by the second UE) transmits the message M5 to the third UE.

[0091] When the third UE replaces the VRU application server 20 or replicates the functions of the VRU application server 20, the message M5 can contain at least the same information as the message M4. Additionally or alternatively, when the second UE 62 replaces the VRU application server 20 or replicates the functions of the VRU application server 20, the server 22 supported by the second UE 62 can send any information transmitted by this server to the clients of the VRU service to the third UE. For example, the server 22 can send information such as the group ID of VRU1, information regarding the radio resources used to establish D2D communication with the first UE 61, etc. to the client 23.

[0092] In step S8, when operation 1 is executed, that is, when the VRU application server 20 or ultimately the server 22 (when the second UE 62 replaces the VRU application server 20 or replicates the functions of the VRU application server 20) instructs the client 21 to update the value of the VRU parameter 51 to the given value Viupdate, the server (20 and / or 22 and / or 23) of the VRU application confirms that the client 21 has updated the parameter Pi51 according to the value Viupdate.

[0093] When operation 2 is executed, that is, when the client 21 notifies the server (20 and / or 22 and / or 23) of the value Vi’’ used by the client, each server (20 and / or 22 and / or 23) of the VRU application updates the status 50, 52, 53 held locally, for example, by replacing the value Vi and / or Vi’ with Vi’’.

[0094] In step S9, the clients (21, 22, 23) and servers (20, 22, 23) of the VRU application can execute a VRU avoidance method as described in ETSI TS 103 300-2 V2.1.1 (2020-05) based on the updated parameters Viupdate and / or Vj''.

[0095] Referring to FIG. 3, a VRU application server 20, a first UE 61, and a second UE 62 are shown.

[0096] The VRU application server 20 includes a network interface (INT_NET) 20.3, one processing module (PROC_AS) 2.1, and a memory unit (MEMO_AS) 20.2. MEMO_AS 20.2 includes a non-volatile unit for retrieving computer programs and a volatile unit for retrieving a VRU status 50 having different VRU parameters P1, P2, P3 of VRU1.

[0097] PROC_UE20.1 is configured to execute at least steps S0, S1, S2, S7.1, S8, and S9.

[0098] INT_NET20.3 is configured to receive and transmit messages M1 and M4 through the network.

[0099] The first UE 61 includes a communication module (COM_UE1) 61.3, one processing module (PROC_UE1) 61.1, and a memory unit (MEMO_UE1) 61.2. MEMO_UE1 61.2 includes a non-volatile unit for retrieving computer programs and a volatile unit for retrieving VRU parameters 51 P1, P2, P3 used by the first UE 61 when implementing the VRU avoidance method.

[0100] PROC_UE61.1 is configured to execute at least steps S3, S4, S5.1, S5.2, S6, and S9.

[0101] COM_UE1 61.3 is configured to receive and transmit messages M2, M3, and M6 through the network.

[0102] The second UE62 includes a communication module (COM_UE2) 62.3, one processing module (PROC_UE2) 62.1, and a memory unit (MEMO_UE2) 62.2. MEMO_UE2 62.2 includes a non-volatile unit for retrieving computer programs and a volatile unit for retrieving VRU parameters 51 P1, P2, and P3 used by the first UE61 when implementing the VRU avoidance method.

[0103] PROC_UE62.1 is configured to execute at least steps S2, S3, S4, S6, S7.1, S7.2, S8, and S9.

[0104] COM_UE1 62.3 is configured to receive and transmit messages M1, M2, M3, M4, and M5 through the network.

Claims

1. A method for relaying a VRU application server that updates traffic vulnerable person parameters of a traffic vulnerable person (VRU) carrying a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, comprising: a second UE receiving, from the VRU application server, a first message including information related to the VRU parameters of the first UE, wherein the information related to the VRU parameters of the first UE is generated by the VRU application server based on the VRU status of the first UE, and the second UE corresponds to a vehicle and is present in the V2X communication system; the second UE transmitting, via device-to-device communication, a second message including the information related to the VRU parameters to a VRU client of the first UE; the second UE receiving, from the first UE, a third message including information related to a value of the VRU parameters of the first UE, wherein based on the information related to the value, the VRU parameters are updated in the VRU status; when the application server has not received or has not received within a time period a sixth message including information related to the VRU parameters of the first UE from the first UE, the application server transmitting the first message to the second UE; A method comprising the above steps.

2. The method according to claim 1, further comprising the application server determining that the second UE is at a distance less than a threshold from the first UE and / or determining that the second UE will be at a distance less than the threshold from the first UE within a duration less than a predetermined duration.

3. The method according to claim 1 or 2, further comprising the second UE transmitting, to a third UE corresponding to another vehicle and present in the V2X communication system, a fifth message including information related to the value of the VRU parameters of the first UE.

4. The method according to any one of claims 1 to 3, further comprising the second UE transmitting, to the application server, a fourth message including information related to the value of the VRU parameters of the first UE.

5. The method according to any one of claims 1 to 4, further comprising: the first UE updating the VRU parameter to the value based on the information related to the VRU parameter.

6. The method according to claim 4, further comprising: the application server setting the VRU parameter of the VRU status of the first UE to an updated value based on the information related to the value.

7. The method according to claim 6, wherein the information related to the VRU parameter includes a value of the VRU parameter of the VRU status before update, and the method further comprises: the first UE comparing the value before update with the value of the VRU parameter of the first UE.

8. The method according to claim 1, wherein the sixth message is a VRU awareness message (VAM).

9. The method according to any one of claims 1 to 8, wherein the VRU parameter is one of a position of the VRU, a speed of the VRU, a VRU group ID, and UE identification information.

10. The method according to any one of claims 1 to 9, wherein the device-to-device communication is established based on communication parameters transmitted by the application server.

11. The method according to claim 10, further comprising: the second UE receiving a VRU awareness message (VAM) from the first UE based on the communication parameters.

12. A user equipment (UE) configured to relay a VRU application server that updates traffic vulnerable user (VRU) parameters of a traffic vulnerable user carrying another user equipment (UE) in a vehicle-to-everything (V2X) communication system, the UE corresponding to a vehicle and existing in the V2X communication system, the UE comprising: a processor; a non-transitory computer-readable medium including stored instructions; and comprising: When executed by the processor, the instructions: receive a first message including information related to the VRU parameter of the another UE, the information being generated by an application server based on the VRU status of the another UE; transmit a second message including the information related to the VRU parameter to a VRU client of the another UE via device-to-device communication; Receiving, from the another UE, a third message including information related to a value of the VRU parameter of the another UE, wherein based on the information related to the value, the VRU parameter is updated in the VRU status; Receiving, from the application server, the first message when the application server has not received or has not received within a time period a sixth message including information related to the VRU parameter of the another UE; A user equipment configured to cause the UE to perform the above. [

13. ] A method for relaying a VRU application server that updates a vulnerable road user (VRU) parameter of a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, The VRU application server transmitting, to at least a second UE, a message including information related to the VRU parameter of the first UE based on the VRU status of the first UE, wherein the second UE corresponds to a vehicle and exists in the V2X communication system, and the information related to the VRU parameter of the first UE is generated by the VRU application server based on the VRU status of the first UE; The VRU application server receiving, from at least the second UE, another message including information related to a value of the VRU parameter of the first UE, wherein based on the information related to the value, the VRU parameter is updated in the VRU status; The application server transmitting the message to the second UE when the application server has not received or has not received within a time period a sixth message including information related to the VRU parameter of the first UE from the first UE; A method comprising the above. [

14. ] A VRU application server configured to relay an application service to a second UE that updates a vulnerable road user (VRU) parameter of a first user equipment (UE) carried by the second UE in a vehicle-to-everything (V2X) communication system, The VRU application server comprising: a processor; A non-transitory computer-readable medium containing stored instructions, comprising, when the instructions are executed by the processor, transmitting at least to the second UE a message including information related to the VRU parameters of the first UE based on the VRU status of the first UE, wherein the second UE corresponds to a vehicle and exists in the V2X communication system, and the information related to the VRU parameters of the first UE is generated by the VRU application server based on the VRU status of the first UE, receiving at least from the second UE another message including information related to the value of the VRU parameters of the first UE, and based on the information related to the value, the VRU parameters are updated in the VRU status, transmitting the message to the second UE when the sixth message including information related to the VRU parameters of the first UE has not been received from the first UE or has not been received within a time limit, configuring the VRU application server to perform the above, a VRU application server.

15. A method for relaying a VRU application server that updates VRU parameters of a vulnerable road user (VRU) carrying a first user equipment (UE) in a vehicle-to-everything (V2X) communication system, the first UE receiving from the second UE via device-to-device communication a second message including information related to the VRU parameters of the first UE, the information being generated by an application server based on the VRU status of the first UE, and the second UE corresponding to a vehicle and existing in the V2X communication system, the first UE transmitting to the second UE via the device-to-device communication a third message including information related to the value of the VRU parameters of the first UE, and based on the information related to the value, the VRU parameters are updated in the VRU status, When the application server has not received or has not received within a time a sixth message including information related to the VRU parameter of the first UE from the first UE, the first UE receives the second message from the second UE, A method comprising. **Claim 16**: A user equipment (UE) client of a vulnerable road user (VRU) application server, the UE being carried by the VRU and present in a vehicle-to-everything (V2X) communication system, the UE client comprising A processor, A non-transitory computer-readable medium including stored instructions, Comprising, When the instructions are executed by the processor, Receiving, via device-to-device communication, from a second UE a second message including information related to a VRU parameter of the UE, the information being generated by an application server based on a VRU status of the UE, the second UE corresponding to a vehicle and being present in the V2X communication system, The UE transmitting, via the device-to-device communication, to the second UE a third message including information related to a value of the VRU parameter of the UE, based on the information related to the value, the VRU parameter being updated in the VRU status, When the application server has not received or has not received within a time a sixth message including information related to the VRU parameter of the UE from the UE, the UE receives the second message from the second UE, A UE client configured to cause the UE to perform. **Claim 17** A computer program product including code instructions that, when executed at least by a processor, perform the method according to any one of claims 1 to 11, 13, and 15.

Images