Patent Application
20230386337
The present invention generally relates to the domain of device-to-device telecommunication system, and more specifically to vulnerable road user avoidance methods.
In these methods the vulnerable road user (VRU) broadcasts a VRU Awareness Messages (VAM) that includes the VRU position, the VRU speed and various VRU related information. A vehicle in the coverage area of the VRU receives the VAM message, discovers the VRU and evaluates the risk of collision associated with the VRU. To perform such methods it is required that the VRU and the vehicle receive from an application server specific information. For example, the application server transmits resource planning to the vehicle and to the VRU to inform them of the radio resources to be used to broadcast the VAM. This specific information requires the VRU to update the parameters related to the VRU avoidance method and the application server to update the status of the VRU. If the values of the parameters of the VRU do not correspond to the values of these parameters of the VRU status of the application server the VRU avoidance method cannot be correctly performed.
More precisely, in VRU avoidance methods, the VRU broadcast the VAM which is received by the application server. The VAM contains the current position of the VRU, the speed of the VRU and other VRU related information like the type of the VRU (for example, pedestrians or bicycle). Then the application server determines or updates the VRU status. That is, the application server updates the values of the parameters of the VRU status, which comprises for example:
The application server may transmit to the VRU new values of the VRU's parameters according to the updated VRU status. For example, the application server may change an ID or the radio resources reserved for transmitting the VAM. When these parameters are changed, the application server transmits to the VRU their new value.
The application server transmits to the vehicle some information related to the new VRU status. The transmission of this information to the vehicle enables it to decode the radio resources in which the VRU transmits the VAM and therefore to discover the VRU. Based on the information received in the VAM the vehicle can evaluate the risk of collision with the VRU.
The values of the parameters of the VRU (that is the values on the VRU side) should correspond to the values of these parameters of the VRU status (that is the values stored on the side of the application server) otherwise the application server will send to the vehicle information related to an incorrect VRU status. The vehicle will therefore not be able to implement the VRU avoidance method. VRU avoidance methods, thus, require the VRU to maintain connectivity with this application server. However, maintaining such connectivity may be difficult especially when the VRU is moving.
The present invention aims at improving the situation.
To that end, the invention relates to a method to relay a vulnerable road user, VRU, application server for updating a vulnerable road user parameter of a VRU corresponding to a first user equipment, UE, in a vehicle-to-everything, V2X, communication system, comprising:
Therefore, when connectivity cannot be maintained between the first UE (corresponding to the VRU) and the application server is relayed by the second UE (corresponding to a vehicle which may as well be a VRU). That is, the second UE may perform at least part of the service performed by the application server during the time the application server and the first UE cannot exchange data. For example, based on the information related to a value of the VRU parameter, the second UE may maintain the VRU status of the VRU updated or may transmit this information to the application server which may maintain the VRU status of the VRU updated. More specifically, if the information related to a value of the VRU parameter indicates a different value than the value of the parameter of the VRU status, the VRU status is not up to date and the second UE, or the application server, may update the value of the parameter in the VRU status. If the information related to a value of the VRU parameter indicates a value identical to the value of the parameter of the VRU status (or simply confirms that the value has been updated according to the information of the second message), the VRU status is up to date no specific action needs to be taken by the second UE regarding the VRU status, however, the second UE may transmit the information related to the value of the VRU to the application server and/or other UE.
Therefore, the VRU status, which is held by the application server when connection with the first UE is maintained, is held by the second UE and/or by the application server (information is then relayed to the application server via the second UE) when the application server cannot receive the VAM properly from the first UE.
The second UE may relay the application server on only part of the status or even on only one parameter, that is, the first message only concerns one VRU parameter of the first UE. However, this first message or another message received by the second UE from the application server may concern more than one VRU parameter of the first UE or even all the parameters of the status.
More generally, the VRU status may be maintained by the second UE rather than by the application server, thus the second UE fully relays the application server, which is advantageous when the connection between the second UE and the application server cannot be maintained. The VRU status may also be maintained by the application server, thus the second UE mainly relays the application server to transmit the information related to the VRU parameter to the first UE and eventually to transmit the information related to a value of the VRU parameter to the application server. The VRU status may be maintained by both the application server and the second UE, thus, the second UE, in addition to updating the status on its side, transmits the information related to the VRU parameter to the first UE and transmits the information related to a value of the VRU parameter to the application server. In addition to any of these possibilities, another UE may also maintain the VRU status, therefore the application server transmits to this another UE the same message it sends to the second UE when the second UE maintains the status as it will be seen with the third UE and the second UE sends to this another UE the information related to a value of the VRU parameter to the application server as it will also be seen with the third UE.
When the status is maintained by another entity than the application server, the first message (or an equivalent message sent to another UE when it is maintained by this another UE) may include information related to other VRU parameters, eventually all the VRU parameters of the VRU. The another UE may be considered as the third UE in the following.
The invention thus avoids slow VRU discovery by the other vehicles due to VRU parameter mismatch between the VRU and the other vehicles due for example to unavailability of a connection with the application server. Therefore, latency is reduced when performing a VRU avoidance method.
By VRU avoidance method it is understood any method which enables a vehicle (for example corresponding to the second or third UE) to estimate the probability of a collision with the VRU, and eventually to alert the driver of the vehicle.
By vulnerable road user it is understood any user of space shared with motorized vehicles (for example roads) or dedicated to motorized vehicles (for example highways) and/or user of the space near those space (for example sidewalks) that could suffer from a collision with these motorized vehicles. It is for example, pedestrians, motorcycle, bicycle, etc. Vulnerable road user may also be defined according to ITS Directive as all the non-motorized road users (such as pedestrians and cyclists), the motorcyclists and people with disabilities or reduced mobility and orientation whatever vehicle they are driving. Vulnerable road user may also be understood as defined by the ETSI in its 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) which considers the user but also the situation of this user in its environment (see table 4 of the ETSI report).
By VRU application server it is understood the server which manages and/or provides the VRU service (which is an VRU avoidance method), that is, the service which aims at minimizing the conflict between VRUs and the other vehicles.
By vulnerable road user parameter of a VRU it is understood a parameter for which a value specific to the VRU is determined either by the VRU its self (for example, speed or position) or by the VRU application server (for example, application ID of the VRU) and/or by the UE which relays the VRU application server. The VRU status (which is held by the VRU application server and/or by another UE which relays the VRU application server such as the second UE) comprises the values specific to the VRU of each of the parameter of the VRU. The VRU status is held by the VRU application server and/or by any UE which relays the VRU application server. That is, the VRU status is stored and may be updated by the entity which holds the VRU status. The VRU status is specific to each VRU. The VRU itself may have a copy of the VRU status. However, the VRU stores the values of at least one of the parameters of the VRU status.
Updating such VRU parameters is understood as modifying the value of the parameter related (or specific) to the VRU either in the status and/or directly on the first UE.
By VRU corresponding to a user equipment (or a user equipment corresponding to the VRU) it is understood the VRU transporting the UE.
By vehicle-to-everything communication system it is understood a computer networks in which vehicles and roadside units are the communicating nodes enabling at least to perform communications between the UEs of the vehicles, the UEs of the VRUs and the VRU application servers of this network.
By information related to the VRU parameter it is understood any information related to the VRU parameter, for example, the value of that parameter in the VRU status (on the application server side), the value to which the application server requires the first UE to update the parameter (on the UE side), a request intended to the first UE to send the value to which is set the parameter (on the UE side), etc.
By device to device communication (D2D) it is understood a direct communication between two UE.
The transmission of the second message from the second UE to the first UE may be performed after a radio discovery of the first UE by the second UE to establish a communication channel. For example, the first UE broadcasts a VAM through specific radio resources which are decoded by the second UE leading to the reception of the VAM when the second UE and the first UE are close enough to each other.
The transmission of the third message from the first UE to the second UE may be performed via any type of communication, for example, through a device-to-device communication or through a cellular communication network.
According to an aspect of the invention, the method further comprises determining by the application server that the second UE is at a distance from the first UE under a threshold and/or that under a predetermined duration the second UE will be at a distance from the first UE under the threshold.
Therefore, the second UE is more likely to be able to perform the D2D communication with the first UE (for example, after a discovery procedure) when the second UE is chosen near the first UE or will be more likely to be able to perform the D2D communication with the first UE if it is heading towards the first UE.
Any methods can be used to determine that the second UE is at a distance from the first UE under a threshold or that the second UE will be at a distance from the first UE under the threshold. For example, the application server may use a positioning system (for example, GPS, internet geolocation, Radiolocation, etc) or the application server may deduce the position and/or the path of the first UE based on previous D2D exchanges between the second UE and other UEs in the network. The position of the first UE may be assimilated to the last position reported to the application server through the VAM, this position may be improved with the information regarding the last speed of the first UE reported to the VRU application server.
According to an aspect of the invention, the method further comprises transmitting by the second UE to a third UE corresponding to another vehicle and being in the V2X communication system a fifth message including information related to the value of the VRU parameter of the first UE.
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. This enables the third UE to have the last updated value of the VRU parameter and therefore if the third UE, which corresponds to another vehicle, relays the application server as the second UE did he will be able to update the status or at least the VRU parameter even if the application server did not receive the information related to a value of the VRU parameter (which may happen when the second UE lost its connection with the application server, for example, when the first and the second UE are in a zone which is underserved in the cellular network due for example to the environment). This also reduces the latency between the time the second UE receives the third message and the time the third UE receives the information related to the value of the VRU parameter, which is especially advantageous in the vehicles are driving in the same direction requiring fast update to perform the VRU avoidance method.
The transmission between the second UE and the third UE can be of any type, for example, through a device-to-device communication (which offers the best reduction of latency) or through a cellular communication network (which still reduces the latency since the application server does not process the information).
According to an aspect of the invention, the method further comprises transmitting by the second UE to the application server a fourth message including information related to the value of the VRU parameter of the first UE.
Therefore, the application server may update or validate the update of the status that it holds. Thus, when the connection with the first UE returns the application server may proceed with the normal update procedure based on the last updates of the VRU status. If the connection with the first UE does not return, the application server may also be relayed by another UE based on the last updated status.
According to an aspect of the invention, the method further comprises updating by the first UE the parameter to the value based on the information related to the VRU parameter.
This is the case when the parameter involved is managed by the application server, for example, the VRU ID (also called application ID since this ID is related to the application layer) of the first UE, which may not be the case for example with the parameter corresponding to the position of the VRU. The information related to the VRU parameter may therefore include the value to which the first UE updates the parameter. In addition, the information related to the VRU may also include an update command which commands the VRU (the first UE) to update the VRU parameter according to the value. Alternatively, the first UE may be configured to update to the value received when this value refers to specific VRU parameters.
According to an aspect of the invention, the method further comprises setting by the application server the VRU parameter of the VRU status of the first UE to an updated value based on the information related to the value.
This is the case when the parameter involved is managed by the first UE, for example the parameter corresponding to the position or the speed or the trajectory of the VRU. The information related to the value is sent by the second UE in the third message.
Alternatively or in complementary, setting the VRU parameter of the VRU status of the first UE to an updated value based on the information related to the value may be done by the second UE (or by the third UE when the fifth message is sent to it) when the VRU status is held by the second UE. Therefore, the transmission of the fourth message is not necessary. However, the VRU status may be held by several entities, that is, at least by the application server and the second UE or another UE (for example, the third UE).
According to an aspect of the invention, the information related to the VRU parameter comprises a previous to update value of the VRU parameter of the VRU status and further comprising comparing by the first UE the previous to update value with the value of the VRU parameter of the first UE.
Therefore, the first UE may determine if the value of the VRU parameter of the VRU status is up to date or not, if it is not up to date, the first UE may indicate it in the third message.
In any case, the third message including information related to a value of the VRU parameter of the first UE may be sent:
According to an aspect of the invention, the method further comprises transmitting by the application server to the second UE and/or to the third UE, the first message when the application server does not receive or does not receive in time from the first UE a sixth message including information related to the VRU parameter of the first UE.
Therefore, the second UE and/or the third UE (that is, the another UE) relay the application server when the connection with the first UE cannot be maintained. This reduces the data exchanged between the application server and the UEs that may relay it, and reduces the data to be stored by these UEs. However, the relay of the application server may be implemented on a permanent basis to ensure less delay for updating the status when the first UE loses its connection to the application server. The sixth message may be any type of message, for example, a broadcast message or a point-to-point message. By losing connection between the first UE and the application server it is understood that the application server no longer receives the sixth message or message like the sixth message from the first UE. When the sixth message is a broadcast message it may be a VRU Awareness Messages, VAM, that is, the message sent by the first UE to broadcast information (for example, the position of the VRU) to the proximate vehicles to enable them to perform a VRU avoidance method.
According to an aspect of the invention the VRU parameter is one among a position of the VRU, a speed of the VRU, a movement direction of the VRU, a VRU group ID, VRU identification information in the network as user terminal (UE), VRU application identification information in the application server or any other information for charactering the VRU group or cluster and/or the VRU application.
By position, speed and movement direction of the VRU it is understood the geographical position, speed and movement of the VRU which transports the first UE in the environment of the VRU. These values of these VRU parameters may be determined by the first UE directly or the first UE may transmit, for example, in the sixth message, data enabling the application server and/or the second UE and/or the third UE to determine these values. Any methods can be used to determine the values of these VRU parameters. For example, they can be obtained by using a positioning system (for example, GPS, internet geolocation, Radiolocation, etc) or obtained based on previous D2D exchanges between the second UE and other UEs in the network.
By VRU group ID it is understood an ID identifying the cluster of close VRUs in the region of the deployment of the network. The group is identified by its size, range and group head. The group head (one among the VRUs of the cluster) relays information locally to the VRU group members. The group ID may be for example an identifier to identify uniquely the group head in the network. This identifier is shared between the group head and the VRU group members. The group ID may be also defined by the application server to identify uniquely clusters of VRUs in the deployment.
By UE identification information (ID) it is understood any information which enables the application server and/or the second UE and/or the third UE and more generally any entities involved in the service to identify the first UE. This ID is therefore involved in identification at the level of the application layer. This ID is determined and/or attributed by the application server and/or the UE which relays the application server.
Other parameters may be related to the identification of the VRU application. In this case, multiple VRU application can be deployed for the VRUs. The VRU application may be related to the class information. An application may be used for example for pedestrians and another one may be defined for cyclists or motorcyclists.
According to an aspect of the invention the device to device communication is established based on communication parameters transmitted by the application server.
This enables the second UE to set up a communication channel with the first UE. These communication parameters correspond for example to the radio resources that will be used by the first UE to send a VAM based on which the second UE discovers the first UE. These communication parameters may be transmitted in the first message.
A second aspect of the invention concerns a user equipment, UE, configured to relay a vulnerable road user, VRU, application server for updating a vulnerable road user parameter of a VRU corresponding to another user equipment, UE, in a vehicle-to-everything, V2X, communication system, the UE corresponds to a vehicle and is in the V2X communication system, said UE comprises:
A third aspect of the invention concerns a method to relay a vulnerable road user, VRU, application server for updating a vulnerable road user parameter of a VRU corresponding to a first user equipment, UE, in a vehicle-to-everything, V2X, communication system, comprising:
According to an aspect of the invention, the method further comprises generating by the application server the information related to the VRU parameter of the first UE based on a VRU status of the first UE.
A fourth aspect of the invention concerns a vulnerable road user, VRU, application server configured to relay an application service to a second user equipment, UE, for updating a vulnerable road user parameter of a VRU corresponding to a first UE in a vehicle-to-everything, V2X, communication system, the UE corresponds to a vehicle and is in the V2X communication system, said VRU application server comprises:
A fifth aspect of the invention concerns a method to relay a vulnerable road user, VRU, application server for updating a vulnerable road user parameter of a VRU corresponding to a first user equipment, UE, in a vehicle-to-everything, V2X, communication system, comprising:
A sixth aspect of the invention concerns a user equipment, UE, client of a vulnerable road user, VRU, application server, said UE corresponds to a VRU and is in the V2X communication system, said UE comprises:
A seventh aspect of the invention concerns a computer program product comprising code instructions to perform the method as described previously when said instructions are run by a processor.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements.
Referring to
The VRU avoidance method implemented by the V2X communication system involves a distributed VRU application on a client-server based model. A server part of this application is supported by a VRU application server 20.
The VRU 1 carries a UE, named first UE. The first UE supports the client 21 part of the VRU application.
The Vehicle 2 carries a UE, named second UE. The second UE supports also a client 22 part of the VRU application. In addition, the second UE may also support a server 22 part of the VRU application when the second UE replaces or duplicates the functions of the VRU application server. When the second UE acts as a relay for the transmission of messages and not replacing or acting as a server the second UE does not support a server part of the VRU application and only acts like an end point entity of the network when it is considered as a client.
The Vehicle 3 carries a UE, named third UE. The third UE supports also a client 23 part of the VRU application and may also support a server 23 part of the VRU application as it is done with the second UE.
The Vehicle 4 may be identical to the other vehicles (and may carry a UE which supports part of the VRU application), however, for the sake of simplicity
Each of these entities (first UE, second UE, third UE and the VRU application server) may communicate via a network including a V2X communication system or any other communication system. For example, the communications 320, 330 established between the vehicles 2, 3 and the VRU application server 20 may be supported by a classical cellular communication network. For instance, a radio channel may be established between the base station 40 and the vehicles 2, 3 to support the communication between the vehicles 2, 3 and the VRU application server 20. The communications 320, 330 between the vehicles 2, 3 and the VRU application server 20 may as well use a satellite communication technic. The communication 310 between the VRU 1 and the VRU application server 20 may use the same technics as for the communications between the vehicles 2, 3 and the VRU application server 20 (satellite, cellular, etc).
The communication 321 between the VRU 1 and vehicle 2 is a D2D communication. However, part of the exchange (transmitting M3 from the first UE to the second UE) may be performed on another basis, for example, with the same technics used between the vehicles 2, 3 and the VRU application server 20. The communication 332 between the two vehicles 2 and 3 maybe based on the same technics used between the VRU 1 and the vehicle 2 (For example, a D2D communication).
The VRU application server 20 stores a status 50 of the VRU 1 comprising values (P1, P2, P3, etc) of the VRU parameters. These VRU parameters are used by the VRU 1 and by the vehicles 2, 3 or 4 to perform the VRU avoidance method. For example, P1 may be the UE identification information, P2 may be the VRU group ID and P3 may be the VRU position and speed of the VRU. The status 50 may comprise for each parameter (P1, P2 and P3) the values (V1, V2 and V3) corresponding to the VRU 1. When the second UE and/or the third UE of vehicles 2 or 3 at least partly replace or duplicate the service provided by the VRU application server 20, the servers 22 and/or 23 maintain a VRU status 52 and/or 53 of the VRU 1, that is, they store and if needed update the VRU status. When the second UE and/or the third UE of vehicles 2 or 3 do not replace or duplicate the service provided by the VRU application server 20 but only transmit the messages between the client 21 of the first UE and the VRU application server 20, the second UE and third UE may not maintain any status of the VRU 1.
Referring to
At step S0, the VRU application server 20 did not receive a VAM M6 from the first UE 61 which would have enabled it to update the VRU status 50. For example, a timer is started at the reception of the last VAM M6 received from the first UE 61 and no other VAM M6 is received when the timer ends. Thus, the connection between the VRU application server 20 and client 21 supported by the first UE 61 is lost.
In case the VRU application server 20 does not receive such VAM M6 it cannot update the VRU status 50 and therefore triggers the next steps so that the second UE 62 and/or the third UE relay it. However, this step may be optional, and the second UE 62 and/or the third UE may relay the VRU application server independently from the reception or not of a VAM M6 from the first UE 61 which corresponds to the VRU 1. In that case step S1 or S2 is implemented without previously implementing step S0.
The VAM may be for example a message as described in ETSI TS 103 300-2 V2.1.1 (2020 May).
At step S1, the VRU application server 20 determines which vehicles are or will potentially be in the proximity of the VRU 1.
For example, the VRU application server 20 determines:
If at least one of the distances is under a threshold or if one of the directions to which heads the vehicles 2, 3, 4 enables the VRU application server 20 to predict that one of the vehicles 2, 3, 4 will be at a distance under the threshold, the VRU application server 20 may implement step S2 with the vehicles which check this condition, in the example of
Any known method can be used to determine that one of the vehicles 2, 3, 4 is at a distance from the first UE 61 under a threshold or will be at a distance from the first UE 61 under the threshold. For example, the VRU application server 20 may use a positioning system, for example, a GPS, to track the position of each vehicles 2, 3, 4. The position of the VRU 1 used to determine these distances may be the last position reported to the VRU application server 20 through the last VAM received.
At step S2, the VRU application server 20 sends a message M1 to the second UE and/or to the third UE through the communications 320 and 330 previously established.
These messages may comprise:
At step S3, the first UE 61 and second UE 62 establish a D2D communication channel between them. The D2D communication may be established based on a radio discovery procedure. Indeed, based on the information on the radio resources, the second UE 62 may receive and decode the specific radio resources in which the first UE 61 may broadcast a VAM. If such 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 the authentication information either to secure the communication channel between the second UE 62 and the first UE 61 and/or to connect the client 21 to the server 22 supported by the second UE 62.
At step S4, the second UE 62, more specifically the part 22 of the VRU application supported by the second UE 62, sends to the first UE 61 and thus to the client 21 (at an application level) a message M2 through a D2D communication 321. Indeed, once the communication established between the first UE 61 and the second UE 62, the second UE 62 sends a message M2.
In the case of action 1, message M2 contains a value Viupdate of at least one of the VRU parameter Pi (P1 or P3). For example, the VRU application server 20 or the server 22 may reassign the ID of the client 21 (that is the application ID of the VRU 1), Viupdate is thus the new ID.
In the case of action 2, message M2 contains a value Vi or Vi′ of at least one of the VRU parameter Pi (P1 or P3). For example, the VRU application server 20 or the server 22 may update the position of VRU 1. Therefore, M2 contains the position Vi or Vi′ actually known by the VRU application server 20 or by the server 22.
At step S5.1, the first UE 61 updates the value Vi″ of the VRU parameter Pi locally stored 51 and used by VRU 1 to the new value Viupdate. This corresponds to the case of action 1.
At step S5.2, the first UE 61 compares the value Vi″ of the VRU parameter Pi locally stored 51 and used by VRU 1 with the value Vi or Vi′ sent in M2. This corresponds to the case of action 2. Therefore, the first UE 61 determines if the value Vi or Vi′ of the VRU parameter of the VRU status 50, 52, 53 is up to date or not.
At step S6, the first UE 61 sends a message M3 to the second UE 62 via the communication 321, that is, the D2D communication established between the first UE 61 and the second UE 62. Alternatively, M3 may be sent through another communication channel, for example, via a classical cellular phone network.
In case action 1 is performed, M3 may contained a confirmation of the update of Vi″ to Viupdate.
In case action 2 is performed, if Vi″ is equal to Vi or Vi′, then M3 may only contain an information specifying such equality. If Vi″ is different from Vi or Vi′, M3 may comprise either the value Vi″ or any information enabling the second UE 62 or the VRU application server 20 to retrieve said value Vi″ (for example, the gap between Vi″ and Vi or Vi′). Therefore, M3 comprises information related to the value Vi″ to which le VRU parameter Pi of the VRU status should be updated.
At step S7.1, the second UE 62 (the part 22 of the VRU application supported by the second UE) sends a message M4 to the VRU application service 20.
This message M4 contains the information transmitted to the second UE 62 by the first UE 61 in the message M3. For example, M4 may contain a confirmation of the update of Vi″ to Viupdate or information enabling the second UE 62 or the VRU application server 20 to retrieve the value Vi″.
At step S7.2, the second UE 62 (the part 22 of the VRU application supported by the second UE) sends a message M5 to the third UE.
When the third UE replaces or duplicates the functions of the VRU application server 20 the message M5 may contain at least the same information than the message M4. In addition or in complementary, when the second UE 62 replaces or duplicates the functions of the VRU application server 20, the server 22 supported by the second UE 62 may transmit to the third UE any information transmitted to the clients of the VRU service by the servers. For example, the server 22 may transmit to the client 23 the group ID of the VRU 1, the information on the radio resources used to establish a D2D communication with the first UE 61, etc.
At step S8, in the case action 1 is performed, that is, the VRU application server 20 or eventually the server 22 (when the second UE 62 replaces or duplicates the functions of the VRU application server 20) commands the client 21 to update the value of a VRU parameter 51 to the given value Viupdate, the servers (20 and/or 22 and/or 23) of the VRU application validate that the client 21 has updated the parameter Pi 51 according to the value Viupdate.
In the case action 2 is performed, that is, the client 21 informs the servers (20 and/or 22 and/or 23) of the value Vi″ used by it, each server (20 and/or 22 and/or 23) of the VRU application updates the status 50, 52, 53 it locally maintains, for example, by replacing the values Vi and/or Vi′ by Vi″.
At step S9, the clients (21, 22, 23) and servers (20, 22, 23) of the VRU application may perform the VRU avoidance method as described in ETSI TS 103 300-2 V2.1.1 (2020 May) based on the updated parameters Viupdate and/or Vj″.
Referring to
The VRU application server 20 comprises a network interface (INT_NET) one processing module (PROC_AS) 2.1 and a memory unit (MEMO_AS) The MEMO_AS 20.2 comprises a non-volatile unit which retrieves the computer program and a volatile unit which retrieves the VRU status 50 with the different VRU parameter P1, P2, P3 of the VRU 1.
The PROC_UE 20.1 is configured to perform at least the steps S0, S1, S2, S7.1, S8 and S9.
The INT_NET 20.3 is configured to receive and transmit the messages M1 and M4 through the network.
The first UE 61 comprises a communication module (COM_UE1) 61.3, one processing module (PROC_UE1) 61.1 and a memory unit (MEMO_UE1) 61.2. The MEMO_UE161.2 comprises a non-volatile unit which retrieves the computer program and a volatile unit which retrieves the VRU parameters 51 P1, P2, P3 used by the first UE 61 when implementing a VRU avoidance method.
The PROC_UE 61.1 is configured to perform at least the steps S3, S4, S5.1, S5.2, S6 and S9.
The COM_UE161.3 is configured to receive and transmit the messages M2, M3 and M6 through the network.
The second UE 62 comprises a communication module (COM_UE2) 62.3, one processing module (PROC_UE2) 62.1 and a memory unit (MEMO_UE2) 62.2. The MEMO_UE262.2 comprises a non-volatile unit which retrieves the computer program and a volatile unit which retrieves the VRU parameters 51 P1, P2, P3 used by the first UE 61 when implementing a VRU avoidance method.
The PROC_UE 62.1 is configured to perform at least the steps S2, S3, S4, S6, S7.1, S7.2, S8 and S9.
The COM_UE162.3 is configured to receive and transmit the messages M1, M2, M3, M4 and M5 through the network.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20306666.7 | Dec 2020 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/JP2021/025230 | 6/28/2021 | WO |
