An identity updating method and device, and a vehicle networking device

Abstract

The application discloses a kind of identification updating method, device and Internet of Vehicles equipment, it is related to Internet of Vehicles technical field, the method is applied to Internet of Vehicles equipment, the method includes: obtaining service request message, the service request message includes the first information related to the reservation duration of target service;According to the update period of the temporary identifier of vehicle, the first update time of the temporary identifier, determine the second update time of the temporary identifier;Wherein, the time interval between the first update time and the second update time is the update period;Determine the first duration between current time and the second update time;Wherein, the current time is located between the first update time and the second update time;According to the reservation duration and the first duration, determine the update opportunity of the temporary identifier.Such, avoid the problem that the identity of equipment changes due to temporary identifier update, so that service cannot continue to carry out.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an identifier updating method, apparatus and vehicle networking equipment. Background Technology

[0002] In the vehicle-to-everything (V2X) system, after a vehicle activates the V2X function, it periodically sends Basic Safety Messages (BSM). To protect user privacy and prevent tracking, a privacy protection mechanism is designed: (1) A randomly generated identifier is used to represent different vehicles, and this identifier is unrelated to the vehicle's real identity information. (2) The randomly generated identifier needs to change randomly as the anonymous certificate changes. This mechanism can achieve privacy protection for vehicle identity. However, if the identifier also needs to be updated during multiple interactions between the sender and receiver, it will lead to the problem that the two parties cannot determine whether the other party's identity has changed, and the interaction may not be able to continue. Summary of the Invention

[0003] The purpose of this application is to provide an identifier update method, device, and vehicle networking equipment, thereby solving the problem that privacy protection mechanisms in the prior art cause interactive application scenarios to fail to function properly.

[0004] Firstly, in order to achieve the above objectives, embodiments of this application provide an identifier update method applied to vehicle networking devices, the method comprising:

[0005] Obtain a business request message, the business request message including first information related to the reservation duration of the target business;

[0006] The second update time of the temporary identification is determined based on the update cycle of the vehicle's temporary identification and the first update time of the temporary identification; wherein the time interval between the first update time and the second update time is the update cycle;

[0007] Determine a first duration between the current time and the second update time; wherein the current time is located between the first update time and the second update time;

[0008] The timing for updating the temporary identifier is determined based on the reserved duration and the first duration.

[0009] Optionally, determining the update timing of the temporary identifier based on the reserved duration and the first duration includes:

[0010] If the reserved duration is greater than the first duration, the update timing is determined based on the reserved duration and the update cycle; and / or,

[0011] If the reserved duration is less than or equal to the first duration, the update time of the temporary identifier is determined to be the second update time.

[0012] Optionally, when the reserved duration is greater than the first duration, determining the update timing based on the reserved duration and the update cycle includes any one of the following:

[0013] If the reserved time is less than or equal to the update cycle, the timing of this update is determined to be before the target service is triggered, and the time interval between the next adjacent update timing and the current update timing is the update cycle;

[0014] If the reserved time is longer than the update cycle, the current update timing is determined to be before the target service is triggered, and the next adjacent update timing is postponed to the third update time. The time interval between the third update time and the current update timing is greater than or equal to the reserved time.

[0015] If the reserved duration is longer than the update cycle, the update timing is determined to be before the target service is triggered. The time interval between the next adjacent update timing and the current update timing is the update cycle. In this case, at least one message of the target service carries an alternative temporary identifier. The at least one message is a message sent and / or received before the next adjacent update timing.

[0016] Optionally, after the step of determining when to update the temporary identifier, the method further includes:

[0017] If the next adjacent update opportunity occurs during the execution of the target service, and the message of the target service does not carry the alternative temporary identifier, the next adjacent update opportunity is postponed until it arrives.

[0018] Optionally, the method further includes:

[0019] If it is determined that the next adjacent update timing needs to be postponed, the duration of the postponement shall be published in one of the following ways:

[0020] Issue an identifier update instruction message, the identifier update instruction message carrying the duration of the delay;

[0021] The first flag is set, and the setting time is equal to the delay time.

[0022] The second flag is controlled until the time corresponding to the next adjacent update opportunity after the delay.

[0023] Optionally, the method further includes:

[0024] If the time interval between two consecutive updates of the temporary identifier is greater than a first threshold, the temporary identifier is forcibly updated.

[0025] Optionally, the first information includes at least one of the reserved duration and / or the business information of the target service.

[0026] Optionally, the method further includes:

[0027] The reserved duration is determined based on historical data related to the business information.

[0028] Optionally, the business information includes business type and / or category of interaction object.

[0029] Optionally, the method further includes:

[0030] Based on the business type, determine the maximum duration of each interaction step in the target business;

[0031] The reserved duration is determined based on each of the maximum durations.

[0032] Optionally, after the step of determining the reserved duration based on each of the maximum durations, the method further includes:

[0033] The reserved duration is adjusted according to the category of the interactive object.

[0034] Secondly, in order to achieve the above objectives, embodiments of this application provide an identifier updating device applied to a vehicle networking device, the device comprising:

[0035] The acquisition module is used to acquire a business request message, the business request message including first information related to the reservation duration of the target business;

[0036] The first determining module is used to determine the second update time of the temporary identifier based on the update cycle of the vehicle's temporary identifier and the first update time of the temporary identifier; wherein the time interval between the first update time and the second update time is the update cycle;

[0037] The second determining module is used to determine a first duration between the current time and the second update time; wherein the current time is located between the first update time and the second update time;

[0038] The third determining module is used to determine the timing of updating the temporary identifier based on the reserved duration and the first duration.

[0039] Thirdly, in order to achieve the above objectives, embodiments of this application provide a vehicle networking device, including a transceiver, a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the identifier update method as described in the first aspect.

[0040] Fourthly, in order to achieve the above objectives, embodiments of this application provide a readable storage medium having a program or instructions stored thereon, which, when executed by a processor, implement the identifier update method as described in the first aspect.

[0041] The above-mentioned technical solution of this application has at least the following beneficial effects:

[0042] The identifier update method of this application embodiment firstly involves a vehicle-to-everything (V2X) device acquiring a service request message, which includes first information related to the reserved duration of the target service. Secondly, based on the update cycle of the vehicle's temporary identifier and a first update time of the temporary identifier, a second update time of the temporary identifier is determined, wherein the time interval between the first update time and the second update time is the update cycle. Thirdly, a first duration between the current time and the second update time is determined, wherein the current time is located between the first update time and the second update time. Finally, based on the reserved duration and the first duration, the update timing of the temporary identifier is determined. This ensures that the update timing of the temporary identifier does not occur during service execution, thus avoiding situations where the vehicle identity changes during service execution and resolving the problem of service interruption due to temporary identifier updates. Attached Figure Description

[0043] Figure 1 This is a schematic diagram of a collaborative lane-changing scenario;

[0044] Figure 2 This is a schematic diagram of the collaborative lane-changing interaction process;

[0045] Figure 3 This is a flowchart illustrating the identifier update method according to an embodiment of this application;

[0046] Figure 4 This is a schematic diagram illustrating the application of this application's embodiments in a cooperative lane-changing scenario;

[0047] Figure 5 This is a schematic diagram of the identifier updating device according to an embodiment of this application;

[0048] Figure 6This is a schematic diagram of the structure of a vehicle networking device according to an embodiment of this application. Detailed Implementation

[0049] To make the technical problems, technical solutions, and advantages of this application clearer, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments. In the following description, specific details such as particular configurations and components are provided merely to aid in a comprehensive understanding of the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Furthermore, for clarity and brevity, descriptions of known functions and structures have been omitted.

[0050] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0051] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0052] In the embodiments provided in this application, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0053] In describing the embodiments of this application, some concepts used in the following description will first be explained.

[0054] Currently, the application scenarios of vehicle-to-everything (V2X) devices include Phase I and Phase II application scenarios (as shown in Table 1 below). Phase I application scenarios are mostly broadcast, where vehicles or roadside units (RSUs) continuously broadcast their own status information, and other vehicles formulate relevant safety and efficiency strategies based on the received status information. In this case, there is no need for interaction between the sender and receiver. Phase II application scenarios are mostly collaborative scenarios, where vehicles or RSUs need to interact multiple times to complete a collaboration.

[0055]

[0056]

[0057] Table 1 Application List for Phase I and Phase II

[0058] For example, in V2V-based collaborative lane-changing scenarios, such as Figure 1 As shown, when vehicle EV-1 needs to change lanes while driving, vehicle EV-1 sends its driving intention and lane change request to EV-2 in the adjacent lane. Vehicle EV-2 decides whether to give way based on its own situation and feeds back the relevant decision to EV-1. After receiving the decision, EV-1 decides whether to perform the lane change action and informs EV-2 of the result.

[0059] Examples of specific interaction processes are as follows: Figure 2 As shown, in this process, the messages used are Basic Safety Message (BSM) and Vehicle Intention and Request (VIR) messages. The BSM message contains the vehicle's real-time dynamic driving information, and the VIR message contains the vehicle's driving intention and request information. The two messages are associated through a temporary BSM ID, that is, the source ID in the VIR message of EV-1 is the temporary BSM ID, and the destination ID is the temporary BSM ID of EV-2.

[0060] However, to meet privacy protection requirements, pseudonym certificates used to represent vehicle identities need to be replaced periodically. To protect privacy, the continuous use of the same pseudonym certificate should not exceed vCertChangeInterval(300s), except in any of the following circumstances:

[0061] If the current location of the system is less than vCertChangeDistance (2km) from the location when the pseudonym certificate was last changed, the system should continue to use the existing pseudonym certificate.

[0062] If at least one of the critical event flags DE_VehicleEventFlags is set, the system should continue to use the existing pseudonym certificate until all of the above critical event flags are reset.

[0063] When the pseudonym certificate is changed, the BSM temporary ID also needs to be changed.

[0064] return Figure 2For example, after EV-1 sends business flow 1, if EV-1's pseudonym certificate needs to change, its BSM temporary ID also needs to change. Considering the consistency between message sets, the temporary ID in EV-1's VIR message should also change. When EV-2 replies with a response message, since both EV-1's pseudonym certificate and VIR temporary ID have changed, EV-2 cannot recognize EV-1's identity. Therefore, EV-2 cannot determine whether it needs to continue the interaction process with EV-1, and the request process fails.

[0065] In response to the above problems, such as Figure 3 As shown in the figure, this application provides an identifier update method applied to a vehicle networking device, the method including:

[0066] Step 301: Obtain a service request message, the service request message including first information related to the reservation duration of the target service;

[0067] It should be noted that, when the vehicle-to-everything (V2X) device is the sending vehicle, this step can specifically involve obtaining the service request message generated by the V2X device through internal implementation; when the V2X device is the receiving vehicle, this step can specifically involve obtaining the service request message sent by the sending vehicle.

[0068] Step 302: Determine the second update time of the temporary identification based on the update cycle of the vehicle's temporary identification and the first update time of the temporary identification; wherein, the time interval between the first update time and the second update time is the update cycle;

[0069] As mentioned earlier, the temporary identification and pseudonym certificate of the vehicle are updated periodically. Therefore, this step can determine the first update time after the current time (the second update time, the time when the currently used temporary identification is updated) based on the pre-set update cycle and the last update time before the current time (the first update time, i.e. the time when it is updated to the currently used temporary identification).

[0070] Step 303: Determine the first duration between the current time and the second update time; wherein the current time is located between the first update time and the second update time;

[0071] In this step, the first duration is the remaining update duration in the current update cycle;

[0072] Step 304: Determine the timing for updating the temporary identifier based on the reserved duration and the first duration.

[0073] The identifier update method of this application embodiment firstly involves a vehicle-to-everything (V2X) device acquiring a service request message, which includes first information related to the reserved duration of the target service. Secondly, based on the update cycle of the vehicle's temporary identifier and the first update time of the temporary identifier, a second update time of the temporary identifier is determined, wherein the time interval between the first update time and the second update time is the update cycle. Thirdly, a first duration between the current time and the second update time is determined to determine the remaining update duration of the current update cycle, wherein the current time is located between the first update time and the second update time. Finally, based on the reserved duration and the first duration, the update timing of the temporary identifier is determined. This allows the update timing to be set outside the target service execution process, i.e., the temporary identifier update timing is not during service execution. This avoids situations where the vehicle identity changes during service execution, thus solving the problem of service interruption due to temporary identifier updates.

[0074] As an optional implementation, step 304, determining the update timing of the temporary identifier based on the reserved duration and the first duration, includes:

[0075] If the reserved duration is greater than the first duration, the update timing is determined based on the reserved duration and the update cycle; and / or,

[0076] If the reserved duration is less than or equal to the first duration, the update time of the temporary identifier is determined to be the second update time.

[0077] In other words, the update timing can be determined based on the comparison between the reserved duration and the first duration. For example, if the reserved duration is less than or equal to the first duration, it indicates that the temporary identifier will not be updated during the execution of the target service. In this case, the temporary identifier can be updated according to the pre-set update cycle, that is, the first update time after the current time is determined as the second update time. Alternatively, if the reserved duration is longer than the first duration, it indicates that if the temporary identifier is updated according to the existing update cycle, the temporary identifier will be updated during the execution of the target service. Therefore, by postponing the update timing, the update of the temporary identifier during the execution of the target service can be avoided, thus ensuring the smooth execution of the target service.

[0078] It should be noted that an implementation example of this optional method is shown in Example 1 and Example 2 below.

[0079] As a specific implementation, when the reserved duration is greater than the first duration, determining the update timing based on the reserved duration and the update cycle includes any one of the following:

[0080] (1) If the reserved time is less than or equal to the update cycle, the timing of this update is determined to be before the target service is triggered, and the time interval between the next adjacent update timing and the current update timing is the update cycle;

[0081] In this step, if the reserved time (estimated execution time of the target service) is less than or equal to the update cycle, that is, if the interaction of the target service can be completed between two adjacent update times, then the temporary identifier is updated once before the target service starts. That is, the interaction of the target service starts immediately after the temporary identifier is updated. In this way, the interaction of the target service can be completed before the next update of the temporary identifier, avoiding the situation where updating the temporary identifier during the execution of the target service causes the other end to be unable to identify the identity, thus preventing the target service from being carried out.

[0082] (2) If the reserved time is longer than the update cycle, the timing of this update is determined to be before the target service is triggered, and the next adjacent update timing is postponed to the third update time. The time interval between the third update time and the current update timing is greater than or equal to the reserved time.

[0083] In this step, if the reserved time is longer than the update cycle, it means that if the temporary identifier is updated according to the pre-configured update cycle, the temporary identifier will be updated during the execution of the target service no matter when the target service is started. Therefore, the temporary identifier can be updated once before the target service starts, and then the next update time can be postponed. That is, the time interval between the temporary identifier update before the target service starts and the next adjacent temporary identifier update is increased so that the time interval is greater than or equal to the preset time. In this way, it can be ensured that the temporary identifier will not be updated during the execution of the target service, thus avoiding the inability of the target service to proceed normally due to the update of the temporary identifier.

[0084] It should be noted that a specific example of this step is shown in Example 3 below.

[0085] (3) If the reserved duration is longer than the update cycle, the current update timing is determined to be before the target service is triggered, and the time interval between the next adjacent update timing and the current update timing is the update cycle, wherein at least one message of the target service carries an alternative temporary identifier, and the at least one message is a message sent and / or received before the next adjacent update timing.

[0086] It should be noted that a specific example of this step is shown in Example 4 below.

[0087] Similarly, in this step, if the reserved time is longer than the update cycle, it means that if the temporary identifier is updated according to the pre-configured update cycle, the temporary identifier will be updated during the execution of the target service no matter when the target service is started. Therefore, the temporary identifier can be updated once before the target service starts. Then, during the execution of the target service, the currently used temporary identifier and the alternative temporary identifier are carried in at least one interaction message before the next update. The alternative temporary identifier is the temporary identifier after the temporary identifier is updated again. In this way, the other end can clearly understand the correspondence between the current temporary identifier and the updated temporary identifier of this end. In this way, after the temporary update is performed again, the identity of this end can also be determined based on the updated temporary identifier, so that the target service can continue to execute.

[0088] Here, it should be noted that under the conditions of (1) and (2) above, if the actual execution time of the target service is less than the reserved time, the temporary identifier update process can be executed immediately by sending an update command or triggering the reset of the flag bit related to the temporary identifier update.

[0089] Another implementation method is to update the temporary identifier according to the configured update cycle when the reserved duration is longer than the first duration (i.e., without changing the update cycle and update time), and carry the alternative temporary identifier in at least one message before the update time is reached during the execution of the target business.

[0090] Furthermore, as an optional implementation, in step 104, when determining the update of the temporary identifier, the method further includes:

[0091] If the next adjacent update opportunity occurs during the execution of the target service, and the message of the target service does not carry the alternative temporary identifier, the next adjacent update opportunity is postponed until it arrives.

[0092] In other words, if the temporary identifier needs to be updated during the actual execution of the target service, and none of the messages in the target service carry an alternative temporary identifier, if the temporary identifier is updated directly during the execution of the target service, there may be a situation where the peer (another device that interacts with the vehicle network device executing the method of this application embodiment) cannot identify the identity of this end (the vehicle network device executing the method of this application). Therefore, the update time can be postponed again before the update time of the temporary identifier arrives, so that the update time is postponed until after the target service is completed. In this way, the temporary identifier can be updated during the execution of the target service, ensuring that the target service can proceed normally.

[0093] Furthermore, as an optional implementation, after determining the update timing of the temporary identifier in step 104, the method further includes:

[0094] If it is determined that the next adjacent update timing needs to be postponed, the duration of the postponement shall be published in one of the following ways:

[0095] Issue an identifier update instruction message, the identifier update instruction message carrying the duration of the delay;

[0096] The first flag is set, and the setting time is equal to the delay duration; wherein, the first flag can be DE_VehicleEventFlags (data element vehicle event flag);

[0097] The second flag is set until the time corresponding to the next adjacent update opportunity after the delay, wherein the second flag can be a newly added field.

[0098] In other words, in this optional implementation, the duration of the delay for the next adjacent update timing can be communicated by issuing an update instruction, or the duration of the delay can be determined by maintaining the first flag in its set state. This delay duration refers to the time between the time corresponding to the next adjacent update timing determined according to a pre-set update cycle and the time corresponding to the delayed next adjacent update timing. Alternatively, the delay can be achieved by setting the second flag and maintaining its set state until the time corresponding to the delayed next adjacent update timing. When the timing needs to be postponed, the second flag is set and kept in the set state until the time corresponding to the next adjacent update timing after the postponement is reached. At that time, the second flag is reset. In other words, when the second flag is reset, the update process of the temporary flag can be triggered. Thus, the time corresponding to the postponed update timing can be determined based on the duration of the first flag being set and the time corresponding to the next adjacent update timing determined according to the preset update cycle. Alternatively, the postponed update timing can be determined by resetting the second flag. When the time corresponding to the postponed update timing is reached, the update process of the temporary flag is executed.

[0099] Furthermore, as an optional implementation, the method also includes:

[0100] If the time interval between two consecutive updates of the temporary identifier is greater than a first threshold, the temporary identifier is forcibly updated.

[0101] In other words, after several consecutive postponements of the temporary identifier, if the update times of two adjacent temporary identifiers exceed a pre-set first threshold, the temporary identifier can be forcibly updated. That is, regardless of what kind of business interaction is currently in progress, the interaction should be canceled, and the temporary identifier and pseudonym certificate should be forcibly updated. This can prevent someone from maliciously and continuously initiating business interactions, resulting in a long reservation time and causing the update time of the temporary identifier (and pseudonym certificate) to be delayed indefinitely.

[0102] It should be noted that a specific example of this optional implementation is shown in Example 5 below.

[0103] As an optional implementation, the first information includes at least one of the reserved duration and / or the business information of the target service.

[0104] In other words, the service request message can explicitly indicate the reserved time for the target service, i.e., the service request message directly carries the estimated execution time (reserved time) of the target service; and / or, the service request message can implicitly indicate the reserved time for the target service, i.e., the service request message carries the service information of the target service, thereby estimating the reserved time for the target service based on the service information.

[0105] Based on the first information including the reserved duration and / or business information, as an optional implementation, the method further includes:

[0106] The reserved duration is determined based on historical data related to the business information.

[0107] In other words, this optional implementation method can determine the reserved time for the target business based on the estimated or actual duration previously determined for the same type of target business or the same business information, i.e., based on experience.

[0108] As a specific implementation, the business information includes the business type and / or the category of the interaction object. Furthermore, as an optional implementation, the method also includes:

[0109] Based on the business type, determine the maximum duration of each interaction step in the target business;

[0110] The reserved duration is determined based on each of the maximum durations.

[0111] This optional implementation method can specifically determine the interaction steps required by the target business based on the business type, as well as the interaction timeout for each step (the maximum time required for each step is preset).

[0112] Furthermore, as an optional implementation, after the step of determining the reserved duration based on each of the maximum durations, the method further includes:

[0113] The reserved duration is adjusted according to the category of the interactive object.

[0114] Specifically, this optional implementation can determine the execution speed of the interaction object based on its category, and adjust the reserved time for the target business based on the execution speed of the interaction object, so that the reserved time is closer to the actual execution time of the target business. For example, if the interaction object is an RSU, the reserved time can be appropriately shortened so that the reserved time is less than or equal to the preset time; if the interaction object is a vehicle, the reserved time can be appropriately extended so that the reserved time is greater than or equal to the preset time.

[0115] The implementation process of this application embodiment will be described below, taking the vehicle networking device as the requesting vehicle as an example:

[0116] (1) When a vehicle initiates an interactive service request, it sends the information to the identifier update module (there may be no entity, it is just a process). At the same time, it provides the identifier update module with the reserved time, or the business information of the reserved time can be deduced.

[0117] (2) The identifier update module compares the reserved time with the time until the next pseudonym certificate and temporary identifier update, and decides whether to perform the pseudonym certificate and temporary identifier update process.

[0118] (3-1) If the identifier update module decides to perform the pseudonym certificate and temporary identifier update process first, the pseudonym certificate and temporary identifier update process can be triggered directly. The triggering method can be to send an update command directly or to reset the second flag bit.

[0119] (3-2) If the identifier update module decides that the pseudonym certificate and temporary identifier update process can be omitted or needs to be postponed, the pseudonym certificate and temporary identifier update process can be omitted. The length of the postponement can be announced by issuing identifier update instruction information, controlling the first flag position, etc., or by setting the second flag position to the time corresponding to the postponed update time, and the time corresponding to the postponed update time can be announced. Thus, the pseudonym certificate and temporary identifier update process is triggered when the time corresponding to the postponed update time is reached.

[0120] The implementation process of this application embodiment will be described below, taking the vehicle networking device as the collaborating vehicle as an example:

[0121] (1) When a vehicle receives an interactive service request, it also sends the reserved time or the service information from which the reserved time can be derived to the identification update module. The identification update module compares the reserved time with the time until the next identification update and decides whether to perform the identification update process.

[0122] (2-1) If the identifier update module decides that the identifier update process should be performed first, the identifier update process can be triggered directly, or the pseudonym certificate and temporary identifier update process can be triggered by resetting the second flag bit. The response will only be given after the requesting party sends the interactive service request again.

[0123] (2-2) If the identifier update module decides that the update process can be skipped or postponed, the pseudonym certificate and temporary identifier update process can be skipped. The length of the postponement can be announced by issuing identifier update instruction information, controlling the first flag position, etc., or by setting the second flag position to the time corresponding to the postponed update time, and the time corresponding to the postponed update time can be announced. Thus, the pseudonym certificate and temporary identifier update process will be triggered when the time corresponding to the postponed update time is reached.

[0124] It should be noted that the above two examples are illustrated with the identifier update module as the execution subject. Of course, the method of executing the embodiments of this application may not be an entity, but only a program.

[0125] The identifier update method of this application embodiment will be described below with reference to specific scenarios:

[0126] Example 1: Collaborative lane changing scenario, timeout period

[0127] The requesting vehicle HV needs to change lanes and requests cooperation from collaborating vehicles RV1 and RV2 to complete the process. The interaction flow between vehicle HV and RV1 and RV2 is as follows: Figure 4 As shown, the dashed line represents the latest response time; the solid line represents the actual response time.

[0128] For vehicle HV, the maximum time to wait for response messages from RV1 and RV2 (business flow 2) after sending the request is T. intv1 The actual response time is T. res’ -T req Compared to T intv1 Short. Transaction flow 5 marks the end of the entire interaction process. After sending transaction flow 5, the vehicle identifier update process can proceed normally, i.e., T. 0HV =T intv1 +T intv3 .

[0129] For vehicles RV1 and RV2, upon receiving the request, they will send a response message to vehicle HV. After sending the response message (business flow 2), and receiving the confirmation message from vehicle HV (business flow 3), the temporary vehicle identifier update process can proceed normally. The entire process takes T seconds. intv2 That is, T 0RV =T intv2 .

[0130] Therefore, for vehicle HV, after the application layer initiates a cooperative lane change request, it should first trigger the identification management module to make a decision. If the first duration (T) ID )≤Reserved time (T) 0HV If T is not found, then the identifier should be updated first. ID ≥T 0HV If so, then no identifier update is required.

[0131] For vehicles RV1 and RV2, upon receiving a request from vehicle HV, the identifier management module should first be triggered to make a decision. If T ID ≤T 0RV If T ID ≥T 0RVIf so, then no identifier update is required.

[0132] Example 2: During the execution of the current request, a cooperation request is received from another vehicle.

[0133] Vehicle HV triggers a cooperative lane change request and is currently in the interaction process described in Example 1 with RV1 and RV2. If at this time, a cooperative merge request is received from vehicle HV1, requesting vehicle HV to assist in completing the merge.

[0134] Vehicle HV first decides whether to immediately respond to HV1's merging request. If the decision is to respond immediately, the current lane change request is stopped. Then, the sign management module is triggered to compare the remaining sign update time with the maximum timeout of the collaboration process, and then decide whether the sign needs to be updated. After completing the collaborative merging interaction process with HV1, if the previous lane change request still needs to be executed, the process in Example 1 is repeated.

[0135] Example 3: Collaborative lane changing scenario, estimated time, delayed update

[0136] As in Example 1, the requesting vehicle HV needs to change lanes and wants to collaborate with cooperating vehicles RV1 and RV2 to complete the process. The interaction flow between vehicle HV and RV1 and RV2 is as follows: Figure 4 As shown:

[0137] Normally, T intv1 and T intv2 These values ​​are all readily available from standards or the vehicle itself, and can generally be considered stable values. However, T... intv3 This needs to be determined based on the surrounding environment of the vehicle, as it is a changing value.

[0138] For vehicle HV (Hardware Vehicle) scenarios, the total time taken to determine the cooperative lane-changing interaction process should be based on the current environment or empirical values. For example, if there are few surrounding vehicles, T... intv3 It might be a smaller value; if there are many vehicles around, T intv3 The answer is likely to be higher.

[0139] Because of T intv3 This is an estimated time; the actual time taken may differ significantly from this figure. For example:

[0140] If based on the estimated time T ID ≥T 0HV However, during the lane change process, the vehicle was unable to change lanes within the estimated time, resulting in an actual travel time of T... 0HV’ Exceeded T ID If so, the update time for the pseudonym certificate and vehicle identification will be postponed until the entire process is completed.

[0141] Example 4: Collaborative lane changing, estimated time, carrying alternative IDs

[0142] The prerequisites are the same as in Example 3, but the actual cost in T... 0HV’ Exceeded T ID At that time, the pseudonym certificate and vehicle identification are updated according to the established plan. However, the N messages before the update simultaneously carry information about the currently used vehicle identification ID1 and the planned latest vehicle identification ID2, and / or the effective date of vehicle identification ID2. After receiving this message, collaborating vehicles RV1 and RV2 can still identify themselves as the requester even after the vehicle HV identification is changed from ID1 to ID2.

[0143] Example 5: Forced stop after timeout

[0144] The preconditions are the same as in Example 3. After vehicle HV completes service flow 3, it cannot enter service flow 5 because the current environment prevents it from changing lanes for an extended period of time, and the vehicle has not updated its identifier for a period of time T. w If the predetermined limit has been exceeded, the vehicle HV should stop the interaction, send a cancellation request, and then trigger the update of the pseudonym certificate and vehicle identification. Then, it should decide whether and when to trigger the previous lane change request as needed.

[0145] like Figure 5 As shown in the illustration, this application also provides an identifier updating device applied to a vehicle networking device, the device comprising:

[0146] The acquisition module 501 is used to acquire a business request message, the business request message including first information related to the reservation time of the target business;

[0147] The first determining module 502 is used to determine the second update time of the temporary identifier based on the update cycle of the vehicle's temporary identifier and the first update time of the temporary identifier; wherein the time interval between the first update time and the second update time is the update cycle;

[0148] The second determining module 503 is used to determine a first duration between the current time and the second update time; wherein the current time is located between the first update time and the second update time;

[0149] The third determining module 504 is used to determine the update timing of the temporary identifier based on the reserved duration and the first duration.

[0150] Optionally, the third determining module 504 includes:

[0151] The first determining submodule is configured to, when the reserved duration is greater than the first duration, determine the update timing based on the reserved duration and the update cycle; and / or,

[0152] The second determining submodule is used to determine the update time of the temporary identifier as the second update time when the reserved duration is less than or equal to the first duration.

[0153] Optionally, the first determining submodule is specifically used to perform any of the following:

[0154] If the reserved time is less than or equal to the update cycle, the timing of this update is determined to be before the target service is triggered, and the time interval between the next adjacent update timing and the current update timing is the update cycle;

[0155] If the reserved time is longer than the update cycle, the current update timing is determined to be before the target service is triggered, and the next adjacent update timing is postponed to the third update time. The time interval between the third update time and the current update timing is greater than or equal to the reserved time.

[0156] If the reserved duration is longer than the update cycle, the update timing is determined to be before the target service is triggered. The time interval between the next adjacent update timing and the current update timing is the update cycle. In this case, at least one message of the target service carries an alternative temporary identifier. The at least one message is a message sent and / or received before the next adjacent update timing.

[0157] Furthermore, the device also includes:

[0158] The postponement module is used to postpone the next adjacent update opportunity until the next adjacent update opportunity arrives, provided that the next adjacent update opportunity is in the process of executing the target service and the message of the target service does not carry the alternative temporary identifier.

[0159] Furthermore, the device also includes:

[0160] The publishing module is used to publish the duration of the delay for the adjacent next update timing in any of the following ways, if it is determined that the timing needs to be postponed:

[0161] Issue an identifier update instruction message, the identifier update instruction message carrying the duration of the delay;

[0162] The first flag is set, and the setting time is equal to the delay time.

[0163] The second flag is controlled until the time corresponding to the next adjacent update opportunity after the delay.

[0164] Furthermore, the device also includes:

[0165] The forced update module is used to force an update of the temporary identifier when the time interval between two adjacent update events of the temporary identifier is determined to be greater than a first threshold.

[0166] Optionally, the first information includes at least one of the reserved duration and / or the business information of the target service.

[0167] Furthermore, the device also includes:

[0168] The fourth determining module is used to determine the reserved duration based on historical data related to the business information.

[0169] Optionally, the business information includes business type and / or category of interaction object.

[0170] Furthermore, the device also includes:

[0171] The fifth determining module is used to determine the maximum duration of each interaction step in the target business based on the business type.

[0172] The sixth determining module is used to determine the reserved duration based on each of the maximum durations.

[0173] Furthermore, the device also includes:

[0174] An adjustment module is used to adjust the reserved duration based on the category of the interactive object.

[0175] It should be noted that the identifier updating device provided in this application embodiment can implement all the method steps implemented in the above identifier updating method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0176] like Figure 6 As shown, this application embodiment also provides a vehicle networking device, including a transceiver 610, a memory 620, a processor 600, and a computer program stored on the memory 620 and running on the processor 600. When the processor 600 executes the computer program, it implements the various processes of the identification update method embodiment described above and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0177] The transceiver 610 is used to receive and send data under the control of the processor 600.

[0178] Among them, Figure 6 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 600 and memory represented by memory 620 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 610 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. For different user equipment, the user interface 1030 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0179] The processor 600 is responsible for managing the bus architecture and general processing, while the memory 620 can store the data used by the processor 600 when performing operations.

[0180] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a computer program instructing the relevant hardware to implement them. The computer program includes instructions to perform some or all of the steps of the above methods; and the computer program can be stored in a readable storage medium, which can be any form of storage medium.

[0181] In addition, this application also provides a computer-readable storage medium storing a program. When executed by a processor, this program implements the various processes of the identifier update method embodiment described above and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0182] Furthermore, it should be noted that in the apparatus and method of this application, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of this application. Moreover, the steps performing the above series of processes can naturally be executed in the order described or in chronological order, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of this application can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve by using their basic programming skills after reading the description of this application.

[0183] Therefore, the object of this application can also be achieved by running a program or a set of programs on any computing device. The computing device can be a known general-purpose device. Therefore, the object of this application can also be achieved simply by providing a program product containing program code implementing the method or apparatus. That is, such a program product also constitutes this application, and a storage medium storing such a program product also constitutes this application. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future.

[0184] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0185] The above description is the preferred embodiment of this application. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for updating an identifier, characterized in that, Applied to vehicle networking devices, the method includes: Obtain a business request message, the business request message including first information related to the reservation duration of the target business; The second update time of the temporary identification is determined based on the update cycle of the vehicle's temporary identification and the first update time of the temporary identification; wherein the time interval between the first update time and the second update time is the update cycle; Determine a first duration between the current time and the second update time; wherein the current time is located between the first update time and the second update time; Based on the reserved duration and the first duration, the timing for updating the temporary identifier is determined; including: If the reserved duration is greater than the first duration, the update timing is determined based on the reserved duration and the update cycle; and / or, If the reserved duration is less than or equal to the first duration, the update time of the temporary identifier is determined to be the second update time; Wherein, when the reserved duration is greater than the first duration, determining the update timing based on the reserved duration and the update cycle includes any one of the following: If the reserved time is less than or equal to the update cycle, the timing of this update is determined to be before the target service is triggered, and the time interval between the next adjacent update timing and the current update timing is the update cycle; If the reserved time is longer than the update cycle, the current update timing is determined to be before the target service is triggered, and the next adjacent update timing is postponed to the third update time. The time interval between the third update time and the current update timing is greater than or equal to the reserved time.

2. The method according to claim 1, characterized in that, When the reserved duration is greater than the first duration, determining the update timing based on the reserved duration and the update cycle includes: If the reserved duration is longer than the update cycle, the update timing is determined to be before the target service is triggered. The time interval between the next adjacent update timing and the current update timing is the update cycle. In this case, at least one message of the target service carries an alternative temporary identifier. The at least one message is a message sent and / or received before the next adjacent update timing.

3. The method according to claim 2, characterized in that, After the step of determining the update timing of the temporary identifier, the method further includes: If the next adjacent update opportunity occurs during the execution of the target service, and the message of the target service does not carry the alternative temporary identifier, the next adjacent update opportunity is postponed until it arrives.

4. The method according to claim 2 or 3, characterized in that, The method further includes: If it is determined that the next adjacent update timing needs to be postponed, the duration of the postponement shall be published in one of the following ways: Issue an identifier update instruction message, the identifier update instruction message carrying the duration of the delay; The first flag is set, and the set time is equal to the delay duration. The second flag is controlled until the time corresponding to the next adjacent update opportunity after the delay.

5. The method according to claim 1, characterized in that, The method further includes: If the time interval between two consecutive updates of the temporary identifier is greater than a first threshold, the temporary identifier is forcibly updated.

6. The method according to claim 1, characterized in that, The first information includes at least one of the reserved duration and / or the business information of the target service.

7. The method according to claim 6, characterized in that, The method further includes: The reserved duration is determined based on historical data related to the business information.

8. The method according to claim 7, characterized in that, The business information includes the business type and / or the category of the interaction object.

9. The method according to claim 8, characterized in that, The method further includes: Based on the business type, determine the maximum duration of each interaction step in the target business; The reserved duration is determined based on each of the maximum durations.

10. The method according to claim 9, characterized in that, After the step of determining the reserved duration based on each of the maximum durations, the method further includes: The reserved duration is adjusted according to the category of the interactive object.

11. An identifier updating device, characterized in that, The device, used in vehicle networking equipment, includes: The acquisition module is used to acquire a business request message, the business request message including first information related to the reservation duration of the target business; The first determining module is used to determine the second update time of the temporary identifier based on the update cycle of the vehicle's temporary identifier and the first update time of the temporary identifier; wherein the time interval between the first update time and the second update time is the update cycle; The second determining module is used to determine a first duration between the current time and the second update time; wherein the current time is located between the first update time and the second update time; The third determining module is used to determine the timing of updating the temporary identifier based on the reserved duration and the first duration; The third determining module includes: The first determining submodule is configured to, when the reserved duration is greater than the first duration, determine the update timing based on the reserved duration and the update cycle; and / or, The second determining submodule is used to determine the update time of the temporary identifier as the second update time when the reserved duration is less than or equal to the first duration. Specifically, the first determining submodule is used to perform any one of the following: If the reserved time is less than or equal to the update cycle, the timing of this update is determined to be before the target service is triggered, and the time interval between the next adjacent update timing and the current update timing is the update cycle; If the reserved time is longer than the update cycle, the current update timing is determined to be before the target service is triggered, and the next adjacent update timing is postponed to the third update time. The time interval between the third update time and the current update timing is greater than or equal to the reserved time.

12. A vehicle networking device, comprising a transceiver, a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the identifier update method as described in any one of claims 1 to 10.

13. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the identifier update method as described in any one of claims 1 to 10.

Images