Traffic control method and device

Abstract

The present application relates to a traffic control method and device, which is applied to the roadside end, and the method includes: sending a payment inquiry message to a vehicle with a first power, the payment inquiry message is used to request the payment voucher information of a vehicle that has completed the payment but has not passed the gate, the payment is to pay the fee for passing the gate, the first power is less than the second power used to send the payment interaction message, the payment interaction message is used to collect the fee from the vehicle; receiving a payment response message fed back by the vehicle in response to the payment inquiry message, the payment response message includes the payment voucher information; generating a traffic control signal according to the payment response message, the traffic control signal is used to control the gate to release the vehicle. The traffic control method and device provided in the embodiment of the present application can realize reliable and efficient non-free flow payment based on V2X technology.

Description

Technical Field

[0001] The present application relates to the field of vehicle networking, and in particular to a traffic control method and device. Background Art

[0002] Road payment refers to the process of receiving toll information issued by the roadside end and completing the payment business through vehicle-road interaction when the vehicle travels to the toll area such as the bridge or highway. In actual application, the vehicle can be equipped with an on-board unit (OBU), and the toll area can be deployed with a road side unit (RSU) connected to the toll system. When the vehicle enters the toll area, the on-board unit and the road side unit complete mutual identity authentication and can automatically perform the payment operation.

[0003] Current road payment is mainly based on Electronic Toll Collection (ETC) technology. However, the reliability of ETC technology is relatively low, and it is prone to problems such as recognition errors when the on-board unit is near multiple roadside units. At the same time, ETC technology currently supports integrated circuit card (ICC) payment, which is incompatible with QR code and third-party electronic payment, affecting the payment experience. In addition, the communication range of ETC technology is small, and usually it can only interact one-to-one with one vehicle within the communication range, affecting the traffic efficiency of vehicles.

[0004] Vehicle to Everything (V2X) technology has the characteristics of long communication distance, high communication reliability, and support for simultaneous interaction with multiple vehicles. Road payment based on V2X technology can effectively improve reliability, payment efficiency, and vehicle traffic efficiency.

[0005] Road payment scenarios can be divided into free-flow payment and non-free-flow payment. In the free-flow payment scenario, vehicles complete imperceptible road payments while driving without having to slow down or stop at toll stations. In the non-free-flow payment scenario, a control lever is set at the gate of the toll station. When the vehicle drives to the toll station, it needs to slow down or stop and wait for the control lever to be lifted before passing. At present, road payment based on V2X technology can be deployed in free-flow payment scenarios. When road payment based on V2X technology is applied to non-free-flow payment scenarios, due to the long communication distance and the presence of multiple vehicles with different transaction status within the communication range, it is easy for the roadside end to fail to accurately lift the lever for vehicles that have completed payment. Summary of the invention

[0006] In view of this, a traffic control method and device are proposed, which can realize reliable and efficient non-free flow payment based on V2X technology.

[0007] In the first aspect, an embodiment of the present application provides a traffic control method, which is applied to a roadside end, and the method includes: sending a payment inquiry message to a vehicle at a first power, the payment inquiry message is used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, the payment is the payment of a fee for passing through the gate, the first power is less than a second power used to send a payment interaction message, and the payment interaction message is used to collect the fee from the vehicle; receiving a payment response message fed back by the vehicle in response to the payment inquiry message, the payment response message including the payment voucher information; generating a traffic control signal according to the payment response message, and the traffic control signal is used to control the gate to release the vehicle.

[0008] In an embodiment of the present application, the payment process is completed through a payment interaction message with high power, so that the vehicle can complete the payment when it is far away from the gate. The payment completion time is much earlier than the time it takes for the vehicle to travel to the gate. The release confirmation is performed through a payment inquiry message with low power. When the paid vehicle further travels to a position closer to the gate, the roadside can confirm that the vehicle has paid, so that the gate releases the paid vehicle and avoids releasing other vehicles that have not paid or vehicles whose payment status has not been confirmed. This not only ensures the vehicle traffic efficiency, but also improves the accuracy of vehicle release, and realizes reliable and efficient non-free flow payment based on V2X technology.

[0009] According to the first aspect, in a first possible implementation of the traffic control method, the payment voucher information is a first charging voucher received by the vehicle after paying the fee;

[0010] Before receiving the payment response message, the method further includes: saving a second charging voucher;

[0011] The generating of the access control signal according to the payment response message includes: generating the access control signal based on a judgment result that the first charging voucher is consistent with the second charging voucher.

[0012] In an embodiment of the present application, by performing a consistency check between the charging voucher saved before receiving the payment response and the charging voucher obtained when the payment response message is received, it can be determined whether the vehicle currently waiting to pass through the gate has completed the payment, thereby accurately determining whether to release the vehicle.

[0013] According to the first aspect, in a second possible implementation of the access control method, the payment voucher information is a first vehicle identification code;

[0014] Before receiving the payment response message, the method further includes: saving a second vehicle identification code;

[0015] The generating of the access control signal according to the payment response message includes: generating the access control signal based on a judgment result that the first vehicle identification code is consistent with the second vehicle identification code.

[0016] In an embodiment of the present application, by performing a consistency check between the vehicle identification code saved before receiving the payment response and the vehicle identification code obtained when the payment response message is received, it can be determined whether the vehicle currently waiting to pass through the gate has completed the payment, thereby accurately determining whether to release the vehicle.

[0017] According to the first aspect, or any possible implementation of the first aspect above, in a third possible implementation of the traffic control method, the payment inquiry message includes at least one of a roadside equipment identification, a toll station identification, a gate identification or a random code.

[0018] According to the first aspect, or the first possible implementation manner or the second possible implementation manner of the first aspect, in a fourth possible implementation manner of the traffic control method, the payment inquiry message includes a random code, and the payment response message includes the random code.

[0019] In this way, false payment response messages sent by the on-board unit can be identified, thereby improving reliability.

[0020] According to the first aspect, or any possible implementation of the first aspect above, in a fifth possible implementation of the traffic control method, after generating the traffic control signal, the method further includes: sending a release confirmation message to the vehicle.

[0021] In this way, the on-board unit in the vehicle can stop sending the payment response message, thereby reducing resource consumption.

[0022] According to the first aspect, or any possible implementation of the first aspect above, in a sixth possible implementation of the traffic control method, the payment inquiry message is a broadcast message sent periodically.

[0023] In this way, after a vehicle enters the communication range of the payment inquiry message, it can communicate with the roadside end as soon as possible, thereby improving traffic efficiency.

[0024] According to a sixth possible implementation manner of the first aspect, in a seventh possible implementation manner of the traffic control method, a sending period of the payment inquiry message is determined according to a road speed limit or a traffic volume.

[0025] In this way, resource consumption and traffic efficiency can be balanced.

[0026] According to the first aspect, or any possible implementation manner of the first aspect, in an eighth possible implementation manner of the traffic control method, the method further includes:

[0027] The payment interaction message is sent to the vehicle at the second power, and the payment interaction message and the payment inquiry message are sent in a frequency-division or time-division manner.

[0028] In this way, a single roadside unit can send both payment interaction messages and payment inquiry messages.

[0029] According to the first aspect, or any possible implementation of the first aspect above, in a ninth possible implementation of the traffic control method, the roadside end includes:

[0030] A roadside unit for sending the payment inquiry message and sending the payment interaction message;

[0031] or,

[0032] A roadside system comprising a first roadside unit for sending the payment inquiry message and a second roadside unit for sending the payment interaction message;

[0033] or,

[0034] The first roadside unit in the roadside system is used to send the payment inquiry message.

[0035] In the second aspect, an embodiment of the present application provides a traffic control method, which is applied to a vehicle-mounted unit, and the method includes: receiving a payment inquiry message from a roadside end, the payment inquiry message is used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, the payment is the fee paid for passing through the gate; sending a payment response message to the roadside end according to the payment inquiry message, and the payment response message includes the payment voucher information.

[0036] In an embodiment of the present application, the inquiry process is completed in response to a payment inquiry message with lower power, so that vehicles that have completed payment can pass through the gate smoothly when they drive to a position closer to the gate, while vehicles that have not completed payment cannot pass through the gate when they drive to a position closer to the gate. This not only ensures the vehicle's passage efficiency, but also improves the accuracy of vehicle release, thereby realizing reliable and efficient non-free flow payment based on V2X technology.

[0037] According to the second aspect, in a first possible implementation of the traffic control method, the method further includes: receiving a charging voucher after the vehicle pays the fee; the payment voucher information is the charging voucher.

[0038] According to the second aspect, in a second possible implementation of the traffic control method, the payment voucher information is a vehicle identification code of the vehicle; the method further includes: after the vehicle pays the fee, sending the vehicle identification code to the roadside end.

[0039] According to the second aspect, or any possible implementation of the second aspect above, in a third possible implementation of the traffic control method, the payment inquiry message includes at least one of a roadside equipment identification, a toll station identification, a gate identification or a random code.

[0040] According to the second aspect, or the first possible implementation manner or the second possible implementation manner of the second aspect, in a fourth possible implementation manner of the access control method, the payment inquiry message includes a random code, and the payment response message includes the random code. In this way, reliability can be improved.

[0041] According to the second aspect, or any possible implementation manner of the second aspect above, in a fifth possible implementation manner of the traffic control method, sending the payment response message is repeatedly sending the payment response message multiple times, and the method further includes:

[0042] Receive a release confirmation message from the roadside terminal;

[0043] Stop sending the payment response message according to the release confirmation message.

[0044] In a third aspect, an embodiment of the present application provides a traffic control device, which is applied to a roadside end, and includes:

[0045] a sending module, configured to send a payment inquiry message to a vehicle at a first power, wherein the payment inquiry message is used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, wherein the payment is to pay a fee for passing through the gate, and the first power is less than a second power used to send a payment interaction message, wherein the payment interaction message is used to collect the fee from the vehicle;

[0046] A receiving module, configured to receive a payment response message fed back by the vehicle in response to the payment inquiry message sent by the sending module, wherein the payment response message includes the payment voucher information;

[0047] The processing module is used to generate a passage control signal according to the payment response message received by the receiving module, and the passage control signal is used to control the gate to release the vehicle.

[0048] According to the third aspect, in a first possible implementation of the traffic control device, the payment voucher information is a first charging voucher received by the vehicle after paying the fee;

[0049] The device further comprises: a storage module, configured to store the second charging voucher;

[0050] The processing module is further used to generate a passage control signal based on a judgment result that the first charging voucher is consistent with the second charging voucher.

[0051] According to the third aspect, in a second possible implementation of the traffic control device, the payment voucher information is a first vehicle identification code;

[0052] The device further comprises: a storage module, configured to store the second vehicle identification code;

[0053] The processing module is further used to generate a passage control signal based on a judgment result that the first vehicle identification code is consistent with the second vehicle identification code.

[0054] According to the third aspect, or any possible implementation of the third aspect above, in a third possible implementation of the traffic control device, the payment inquiry message includes at least one of a roadside equipment identification, a toll station identification, a gate identification or a random code.

[0055] According to the third aspect, or the first possible implementation manner or the second possible implementation manner of the third aspect, in a fourth possible implementation manner of the traffic control device, the payment inquiry message includes a random code, and the payment response message includes the random code.

[0056] According to the third aspect, or any possible implementation of the third aspect, in a fifth possible implementation of the traffic control device, the sending module is further used to send a release confirmation message to the vehicle.

[0057] According to the third aspect, or any possible implementation of the third aspect, in a sixth possible implementation of the traffic control device, the payment inquiry message is a broadcast message that is sent periodically.

[0058] According to a sixth possible implementation manner of the third aspect, in a seventh possible implementation manner of the traffic control device, a sending period of the payment inquiry message is determined according to a road speed limit or a traffic volume.

[0059] According to the third aspect, or any possible implementation of the third aspect above, in an eighth possible implementation of the traffic control device, the sending module is also used to send the payment interaction message to the vehicle at the second power, and the payment interaction message and the payment inquiry message are sent in a frequency-divided manner or a time-divided manner.

[0060] According to the third aspect, or any possible implementation of the third aspect, in a ninth possible implementation of the traffic control method, the roadside end includes:

[0061] A roadside unit for sending the payment inquiry message and sending the payment interaction message;

[0062] or,

[0063] A roadside system comprising a first roadside unit for sending the payment inquiry message and a second roadside unit for sending the payment interaction message;

[0064] or,

[0065] The first roadside unit in the roadside system is used to send the payment inquiry message.

[0066] In a fourth aspect, an embodiment of the present application provides a traffic control device, which is applied to a vehicle-mounted unit, and includes:

[0067] A receiving module, used to receive a payment inquiry message from a roadside end, wherein the payment inquiry message is used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, wherein the payment is a fee paid for passing through the gate;

[0068] The sending module is used to send a payment response message to the roadside end according to the payment inquiry message received by the receiving module, and the payment response message includes the payment voucher information.

[0069] According to the fourth aspect, in a first possible implementation of the traffic control device, the receiving module is further used to receive a charging voucher after the vehicle pays the fee; the payment voucher information is the charging voucher.

[0070] According to the fourth aspect, in a second possible implementation of the traffic control device, the payment voucher information is a vehicle identification code of the vehicle; the sending module is also used to send the vehicle identification code to the roadside end after the vehicle pays the fee.

[0071] According to the fourth aspect, or any possible implementation of the fourth aspect above, in a third possible implementation of the traffic control device, the payment inquiry message includes at least one of a roadside equipment identification, a toll station identification, a gate identification or a random code.

[0072] According to the fourth aspect, or the first possible implementation manner or the second possible implementation manner of the fourth aspect, in a fourth possible implementation manner of the traffic control device, the payment inquiry message includes a random code, and the payment response message includes the random code.

[0073] According to the fourth aspect, or any possible implementation of the fourth aspect, in a fifth possible implementation of the traffic control device, the sending of the payment response message is to repeatedly send the payment response message multiple times, and the receiving module is further used to receive a release confirmation message from the roadside end;

[0074] The sending module is further used to stop sending the payment response message according to the release confirmation message.

[0075] In a fifth aspect, an embodiment of the present application provides a traffic control device, which can execute one or more of the traffic control methods of the above-mentioned first aspect or multiple possible implementation methods of the first aspect.

[0076] In a sixth aspect, an embodiment of the present application provides a traffic control device, which can execute one or more of the traffic control methods of the above-mentioned second aspect or multiple possible implementation methods of the second aspect.

[0077] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the above-mentioned first aspect or one or several of the multiple possible implementations of the first aspect, or execute the above-mentioned second aspect or one or several of the multiple possible implementations of the second aspect.

[0078] In an eighth aspect, an embodiment of the present application provides a computer program product, comprising a computer-readable code, which, when executed in a traffic control device, enables the traffic control device to execute the traffic control method of the first aspect or one or several of the multiple possible implementations of the first aspect, or to execute the traffic control method of the second aspect or one or several of the multiple possible implementations of the second aspect.

[0079] These and other aspects of the present application will become more apparent from the following description of the embodiment(s). BRIEF DESCRIPTION OF THE DRAWINGS

[0080] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features, and aspects of the present application and, together with the description, serve to explain the principles of the present application.

[0081] Figure 1a An exemplary schematic diagram of an open non-free flow payment scenario is shown;

[0082] Figure 1b An exemplary schematic diagram of a regional non-free flow payment scenario is shown;

[0083] Figure 1c An exemplary schematic diagram of a regional non-free flow payment scenario is shown;

[0084] Figure 2a A schematic diagram showing the communication range of a roadside unit;

[0085] Figure 2b A schematic diagram of a scenario of implementing non-free flow payment based on V2X technology in the related art is shown;

[0086] Figure 2c A schematic diagram of a scenario of implementing non-free flow payment based on V2X technology in the related art is shown;

[0087] Figure 3a A schematic diagram showing the communication range of a V2X message sent by a roadside terminal in an embodiment of the present application is shown;

[0088] Figure 3b A schematic diagram showing the transmission of a payment inquiry message and a payment interaction message in the frequency domain;

[0089] Figure 3c to Figure 3g Schematic diagrams showing exemplary transmission of a payment inquiry message and a payment interaction message in the time domain respectively;

[0090] Figure 4a A schematic diagram showing the architecture of a traffic control system according to an embodiment of the present application;

[0091] Figure 4b A schematic diagram showing the architecture of a traffic control system according to an embodiment of the present application;

[0092] Figure 4c A schematic diagram showing the architecture of a traffic control system according to an embodiment of the present application;

[0093] Figure 5a A schematic diagram of the structure of an electronic device is shown;

[0094] Figure 5b A schematic diagram showing the structure of a chip according to an embodiment of the present application is shown;

[0095] Figure 6An interactive flow chart of a traffic control method provided by an embodiment of the present application is shown;

[0096] Figure 7 An interactive flow chart of a traffic control method provided by an embodiment of the present application is shown;

[0097] Figure 8 An interactive flow chart of a traffic control method provided by an embodiment of the present application is shown;

[0098] Fig. 9 A schematic diagram showing the structure of a traffic control device provided in an embodiment of the present application is shown;

[0099] Fig.10 A schematic diagram of the structure of a traffic control device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0100] Various exemplary embodiments, features and aspects of the present application will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0101] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0102] In addition, in order to better illustrate the present application, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present application can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter of the present application.

[0103] In the non-free flow payment scenario, a control lever is set at the gate of each lane of the toll station. When the control lever is raised, it indicates that the gate releases the vehicle and the vehicle can pass through the toll station. Non-free flow payment scenarios can include open non-free flow payment scenarios (such as passing roads, crossing bridges, etc.) and regional non-free flow payment scenarios (such as highway sections, parking lots, etc.). Figure 1a , Figure 1b and Figure 1c Schematic diagrams of application scenarios of embodiments of the present application are respectively shown.

[0104] Figure 1a An exemplary schematic diagram of an open non-free flow payment scenario is shown. Figure 1aAs shown, the toll station is set at the exit of the toll road section. After the roadside unit at the toll station confirms that the vehicle has completed payment, it controls the gate to release the vehicle (i.e., triggers the lifting operation of the barrier), allowing the vehicle to leave the toll road section. In practice, the toll station can also be set at the entrance of the toll road section (not shown), or other locations in the toll road section (for example, 5 km away from the entrance, 1 / 2 of the toll road section, etc., not shown).

[0105] Figure 1b An exemplary schematic diagram of a regional non-free flow payment scenario is shown. Figure 1b As shown, toll stations are set at the entrance and exit of the toll road section. At the toll station at the entrance, after the roadside unit confirms that the vehicle has completed payment (usually the payment fee at the entrance is 0), it controls the gate to release the vehicle and allow the vehicle to enter the toll road section. At the toll station at the exit, after the roadside unit confirms that the vehicle has completed payment, it controls the gate to release the vehicle and allow the vehicle to leave the toll road section.

[0106] Figure 1c An exemplary schematic diagram of a regional non-free flow payment scenario is shown. Figure 1c As shown, toll stations are set at the entrance and exit of the toll parking lot. At the toll station at the entrance, after the roadside unit confirms that the vehicle has completed payment (usually the payment fee at the entrance is 0), it controls the gate to release the vehicle and allow the vehicle to enter the parking lot. At the toll station at the exit, after the roadside unit confirms that the vehicle has completed payment, it controls the gate to release the vehicle and allow the vehicle to leave the parking lot.

[0107] The traffic control method provided in the embodiment of the present application can also be applied to other non-free flow payment scenarios, such as passing through a tunnel, taking a ferry, etc., without limitation compared to the present application.

[0108] Vehicle to Everything (V2X) technology has the characteristics of long communication distance, high communication reliability, and support for interaction with multiple vehicles at the same time. Therefore, in non-free flow payment based on V2X technology, the transaction status of multiple vehicles within the communication range of a road side unit (RSU) may be different (for example, some vehicles have completed payment, some vehicles are in the process of payment but have not yet completed payment, and some vehicles have failed to pay, etc.). At this time, the road side unit has the problem of being unable to accurately trigger the lifting operation because it cannot distinguish the transaction status of vehicles waiting to pass at the gate. Figure 2a A schematic diagram showing the communication range of the roadside unit is shown. Figure 2aAs shown in the figure, at the toll station at the exit of the toll road section, there are three vehicles within the communication range of the roadside unit, namely vehicle 1, vehicle 2 and vehicle 3. Among them, vehicle 1 has completed payment, vehicle 2 has failed to pay, and vehicle 3 is paying and has not yet completed payment (i.e., paying). When vehicle 3 drives to the gate of the toll station, the roadside unit cannot accurately trigger the lifting operation because it cannot distinguish whether the vehicle waiting to pass in front of the control lever is vehicle 1, vehicle 2 or vehicle 3.

[0109] In the related technology, one method is to realize non-free flow payment by combining V2X technology with cameras. The roadside unit and the camera are connected to the backend server of the toll station. Before the vehicle drives to the control lever at the gate, the payment process is completed with the roadside unit through V2X technology, and the vehicle information is recorded in the backend server. When the vehicle drives to the control lever at the gate, the camera takes a picture of the vehicle's license plate and identifies the license plate number. The backend server queries and verifies the identified license plate number based on the recorded vehicle information. When it is confirmed that the vehicle in front of the current camera has completed the payment, the barrier is lifted to allow it to pass. Figure 2b The following is a schematic diagram showing a scenario of implementing non-free flow payment based on V2X technology in related technologies. Figure 1b , Figure 2b Cameras have been added to the toll booths at the entrance and exit. Figure 2b As shown in the figure, at the toll station at the entrance, there are two vehicles within the communication range of the roadside unit, namely vehicle 4 and vehicle 5. Currently, both vehicle 4 and vehicle 5 have completed payment. When vehicle 4 drives to the toll station at the entrance, the camera at the toll station takes a picture of the license plate of vehicle 4 and recognizes the license plate number of vehicle 4, and uploads the license plate number of vehicle 4 to the backend server. The backend server confirms that vehicle 4 has completed payment based on the recorded vehicle information and lifts the barrier to let it pass. Afterwards, vehicle 3 drives to the toll station at the entrance, and the backend server also confirms that vehicle 3 has completed payment and lifts the barrier to let it pass. As shown in the figure, Figure 2b As shown, at the toll station at the exit, there are three vehicles within the communication range of the roadside unit, namely vehicle 1, vehicle 2 and vehicle 3. Currently, vehicle 1 has completed payment, vehicle 2 has failed to pay, and vehicle 3 is paying and has not yet completed payment. When vehicle 3 drives to the toll station at the exit, the background server confirms that vehicle 3 has not completed payment and will not allow it to pass. After waiting for vehicle 3 to complete payment, the background server will lift the barrier to allow it to pass. Afterwards, vehicle 2 drives to the toll station at the exit, and the background server confirms that vehicle 2 has not completed payment and will not allow it to pass. After waiting for vehicle 2 to complete payment, the background server will lift the barrier to allow it to pass. Afterwards, vehicle 1 drives to the toll station at the exit, and the background server confirms that vehicle 3 has completed payment and lifts the barrier to allow it to pass.

[0110] This method relies heavily on the camera's recognition of the license plate number. At night or in foggy conditions, the camera's correct recognition rate of the license plate will be reduced, which will have a certain impact on the reliability and effectiveness of the system. At the same time, this method requires two types of equipment, the V2X system and the camera, which increases the complexity of system integration and deployment costs.

[0111] In the related art, another way is to realize non-free flow payment by combining V2X technology with vehicle positioning technology. Before the vehicle drives to the control pole, it completes the payment process with the roadside unit through V2X, and the vehicle information is recorded in the background server. After the vehicle completes the payment, it continues to send the real-time location information of the vehicle to the roadside unit through V2X technology. The roadside unit identifies the distance between the vehicle and the control pole at the gate of the toll station based on the real-time location information sent by the vehicle. If the vehicle drives to the position of the control pole (for example, the distance between the vehicle and the control pole is less than 1 meter), and it is confirmed according to the records of the background server that the vehicle has completed the payment, the roadside unit can trigger the lifting operation of the pole and release the vehicle. If the vehicle drives to the position of the control pole, and it is confirmed according to the records of the background server that the vehicle has not completed the payment, the roadside unit will not trigger the lifting operation of the pole and will not release the vehicle. Figure 2c A schematic diagram of a scenario for implementing non-free flow payment based on V2X technology in related technologies is shown. Figure 2c As shown in the figure, at the toll station at the entrance, there are two vehicles within the communication range of the roadside unit, namely vehicle 4 and vehicle 5. After vehicle 4 and vehicle 5 have completed payment, they continue to send real-time location information to the roadside unit. When the roadside unit determines that vehicle 4 has driven to the control lever of the toll station at the entrance, it confirms that vehicle 4 has completed payment through the information recorded by the background server, triggering the lifting operation. Figure 2c As shown in the figure, at the toll station at the exit, there are three vehicles within the communication range of the roadside unit, namely vehicle 1, vehicle 2 and vehicle 3. Vehicle 1 has completed payment, vehicle 2 has failed to pay, and vehicle 3 is paying but has not yet completed payment. Since vehicle 3 has not yet completed payment, when vehicle 3 drives to the control lever of the toll station at the exit, the roadside unit will not trigger the lifting operation, and vehicle 3 cannot pass.

[0112] This method relies heavily on the accuracy of the vehicle's navigation and positioning system and the strength of the Global Navigation Satellite System (GNSS) signal. When the vehicle's navigation and positioning equipment is not accurate enough or the GNSS signal is weak, the distance between the vehicle and the control pole cannot be accurately determined, resulting in an error in the pole lifting judgment. At toll booths, gas stations, or some urban scenes, the GNSS signal is very weak due to the obstruction of buildings. Even if the vehicle is equipped with a high-precision navigation and positioning device, it may not be able to search for four satellites for positioning.

[0113] The embodiment of the present application provides a traffic control method, which can accurately identify whether the vehicle to be passed in front of the control lever at the gate has paid the fee without adding cameras or relying on positioning equipment, so as to accurately control the control lever and achieve accurate release of the vehicle, thereby realizing reliable and efficient non-free flow payment based on V2X technology.

[0114] In the traffic control method provided in the embodiment of the present application, the roadside end sends at least two types of V2X messages to the vehicle, which are respectively divided into: payment interaction message and payment inquiry message. There are at least two interaction processes between the roadside end and the vehicle, namely: payment process and inquiry process. In the payment process, the V2X message sent by the roadside end to the vehicle can be called a payment interaction message. In the inquiry process, the V2X message sent by the roadside end to the vehicle can be called a payment inquiry message.

[0115] Among them, payment is to pay the fee for passing through the gate, the payment interaction message can be used to collect fees from the vehicle, and the payment inquiry message can be used to request payment voucher information of vehicles that have completed payment but have not passed through the gate. In the embodiment of the present application, the message fed back by the vehicle in response to the payment interaction message can be called an interaction response message, and the message fed back by the vehicle in response to the payment inquiry message can be called a payment response message. The payment response message includes the payment voucher information requested by the payment inquiry message.

[0116] In implementation, the roadside sends a payment inquiry message to the vehicle at a first power and sends a payment interaction message to the vehicle at a second power, and the first power is less than the second power. Since the communication range of the V2X message is positively correlated with its transmission power, that is, the greater the transmission power of the V2X message, the greater the communication range of the V2X message; the smaller the transmission power of the V2X message, the smaller the communication range of the V2X message. Therefore, the communication range of the payment inquiry message is smaller than the communication range of the payment interaction message.

[0117] Figure 3a FIG. 1 is a schematic diagram showing the communication range of a V2X message sent by a roadside terminal in an embodiment of the present application. Figure 3aAs shown, the communication range of the payment inquiry message is smaller than the communication range of the payment interaction message. In one example, the coverage radius of the payment inquiry message can be in the range of [5m, 10m], and the coverage radius of the payment interaction message can be in the range of [200m, 300m]. It can be seen that the communication range of the payment inquiry message can usually accommodate one vehicle, and the roadside end only interacts with one vehicle close to the gate control lever by sending the payment inquiry message to ensure the accuracy of releasing the vehicle; the communication range of the payment interaction message can usually accommodate multiple vehicles, and the roadside end can interact with multiple vehicles within the communication range of the payment interaction message at the same time through the payment interaction message to improve the payment efficiency.

[0118] In implementation, the transmission power of the V2X message can be configured and controlled by high-level parameters. According to the technical requirements for roadside equipment of the vehicle network wireless communication technology based on the Long Term Evolution-Vehicle to Everything (LTE-V2X) technology, it can be determined that the maximum transmission power of the roadside unit at the roadside end in the current V2X technology is 23dBm. Therefore, in the embodiment of the present application, the maximum value of the transmission power (ie, the second power) of the payment interaction message can be set to 23dBm. Based on the 3GPP TS36.101 protocol standard, it can be determined that the minimum value of the transmission power (ie, the second power) of the payment interaction message can be set to -30dBm. That is to say, in the embodiment of the present application, the power adjustment range of the payment interaction message (ie, the adjustment range of the second power) can be configured to [-30dBm, 23dBm].

[0119] In implementation, the transmission power (i.e., the first power) of the payment inquiry message can be determined according to the transmission power of the roadside unit at the roadside end, the transmission antenna gain of the roadside unit, the receiving antenna gain of the roadside unit, the receiver sensitivity of the vehicle-mounted unit, and the preset lifting pole recognition distance. For example, the transmission power of the payment inquiry message can be -85dBm or -75dbm, etc.

[0120] In an example, the transmission power of the payment inquiry message can be obtained by formula (1).

[0121] Pt=Sr+PL(d)-Gt-Gr Formula (I)

[0122] Among them, Pt represents the transmission power of the payment inquiry message, in dBm; Sr represents the receiver sensitivity of the on-board unit, in dBm, PL(d) represents the path loss at a distance of d, in dB, where d represents the preset lifting pole identification distance; Gt represents the transmitting antenna gain of the roadside unit, in dB; Gr represents the receiving antenna gain of the roadside unit, in dB. Sr, PL(d), Gt and Gr can be obtained through actual measurement, and d can be determined according to the position of the roadside unit and the control pole. It should be noted that in actual situations, factors such as cable loss need to be considered, and the actual transmission power of the payment inquiry message can be slightly larger than the transmission power obtained by formula (I).

[0123] The traffic control method provided in the embodiment of the present application can be divided into two scenarios based on the roadside equipment involved in the roadside end. In scenario one, the payment inquiry message and the payment interaction message are sent by a single roadside equipment, so that the payment process and the inquiry process are completed by a single roadside equipment. In scenario two, the payment inquiry message and the payment interaction message are sent by two different roadside equipment, so that the payment process and the inquiry process are completed by two roadside equipment systems. In a possible implementation of scenario two, the roadside end provided in the embodiment of the present application may be a roadside system including two roadside equipment, and the two roadside equipment in the roadside system respectively send payment inquiry messages and payment interaction messages, and then collaborate to complete the payment process and the inquiry process. In another possible implementation of scenario two, the roadside end provided in the embodiment of the present application may be a roadside equipment used to send payment inquiry messages in the above-mentioned roadside system.

[0124] The following is a detailed description of scenario 1. In scenario 1, the payment inquiry message and the payment interaction message are sent by the same roadside device, that is, the roadside device sends the payment inquiry message to the vehicle at a first power and sends the payment interaction message to the vehicle at a second power. Figure 4a The schematic diagram of the architecture of the traffic control system of the embodiment of the present application is shown. Figure 4a As shown, the traffic control system may include a first roadside unit 11, a vehicle-mounted unit 12, and a toll collection system 13. The first roadside unit 11 is a roadside device, and the vehicle-mounted unit 12 is a device in a vehicle. The roadside terminal provided in the embodiment of the present application may be the first roadside unit 11.

[0125] like Figure 4aAs shown, the first roadside unit 11 can send a payment interaction message to the vehicle-mounted unit 12 at the second power, and interact with the toll collection system 13 according to the interaction response message returned by the vehicle-mounted unit 12, and locally record the payment voucher information of the vehicle that has completed the payment. The first roadside unit 11 can also send a payment inquiry message to the vehicle-mounted unit 12 at the first power, and determine whether to control the gate to release the vehicle according to the payment response message returned by the vehicle-mounted unit 12 and the payment voucher information recorded locally.

[0126] In implementation, the payment inquiry message and the payment interaction message may be periodically sent broadcast messages. That is, the first roadside unit 11 may periodically broadcast the payment inquiry message and the payment interaction message so that the vehicle-mounted unit 12 can detect the signal in time and interact.

[0127] In an embodiment of the present application, the payment inquiry message and the payment interaction message are sent in frequency or time division to enable a single roadside unit to send the payment inquiry message and the payment interaction message.

[0128] In a possible implementation, in an embodiment of the present application, the sending channel and the sending interval of the payment inquiry message and the payment interaction message are designed as follows.

[0129] In the frequency domain, the transmission channel of the roadside unit is different from that of the vehicle-mounted unit, and the signal reception of the roadside unit and the vehicle-mounted unit is within the entire working frequency band. Therefore, in the embodiment of the present application, the payment inquiry message and the payment interaction message are both sent on the same specified roadside unit channel. Figure 3b FIG. 2 shows a schematic diagram of sending a payment inquiry message and a payment interaction message in the frequency domain. Figure 3b As shown, in one example, the payment inquiry message and the payment interaction message can be sent in a channel with a frequency of 5915 MHz to 5925 MHz. Of course, the payment inquiry message and the payment interaction message can also be sent in channels of other frequencies, which is not limited in this application.

[0130] In the time domain, the power of the V2X message can be adjusted according to the time slot of the subframe 1ms, that is, the power of the V2X message can be changed every 1ms, and the sending time interval of the payment inquiry message and the payment interaction message can be adjusted based on 1ms. The roadside unit can send the payment inquiry message and the payment interaction message at the same period, or at different periods. The roadside unit can send the payment inquiry message and the payment interaction message at equal intervals, or at different intervals.

[0131] Figure 3c to Figure 3g Schematic diagrams showing exemplary transmission of a payment inquiry message and a payment interaction message in the time domain are shown respectively. Figure 3c As shown in the figure, the sending interval of the payment inquiry message and the payment interaction message is 1ms, and the sending period of the payment inquiry message and the payment interaction message is 100ms. It can be seen that the roadside equipment can adjust the transmission power at intervals of 1ms, and the sending period of the payment inquiry message and the payment interaction message can be the same. Figure 3d As shown in the figure, the sending interval of the payment inquiry message and the payment interaction message is 50ms, and the sending period of the payment inquiry message and the payment interaction message is 100ms. It can be seen that the roadside equipment can adjust the transmission power at intervals of 50ms, and the sending period of the payment inquiry message and the payment interaction message can be the same. Figure 3e As shown in the figure, the sending interval of the payment inquiry message and the payment interaction message is 50ms, and the sending period of the payment inquiry message and the payment interaction message is 200ms. It can be seen that the roadside equipment can adjust the transmission power at intervals of 100ms, and the sending period of the payment inquiry message and the payment interaction message can be the same. Figure 3f As shown in the figure, the minimum interval between payment interaction messages and payment inquiry messages is 100ms, the interval between payment interaction messages is 100ms and 200ms, and the interval between payment inquiry messages is 300ms. It can be seen that the sending period of payment interaction messages is variable. After sending two payment interaction messages in succession, a payment inquiry message is sent. The sending period of payment interaction messages can be different from that of payment inquiry messages. Figure 3g As shown, the minimum sending interval between the payment interaction message and the payment inquiry message is 100ms, the sending interval between the payment interaction messages is 300ms, and the sending interval between the payment inquiry messages is 100ms and 200ms. It can be seen that the sending period of the payment inquiry message is variable. After sending one payment interaction message, two payment inquiry messages are sent. The sending period of the payment interaction message can be different from the sending period of the payment inquiry message.

[0132] Scenario 2 is described in detail below. In one possible implementation of Scenario 2, the roadside end may be a roadside system including two roadside devices, in which one roadside device sends a payment inquiry message to the vehicle at a first power, and the other roadside device sends a payment interaction message to the vehicle at a second power. In another possible implementation of Scenario 2, the roadside end may be a roadside device in the above-mentioned roadside system for sending a payment inquiry message.

[0133] In one example, Figure 4b The schematic diagram of the architecture of the traffic control system of the embodiment of the present application is shown. Figure 4bAs shown, the traffic control system may include a first roadside unit 11, a vehicle-mounted unit 12, a toll collection system 13, and a second roadside unit 14. The first roadside unit 11 and the second roadside unit 14 are roadside devices, and the vehicle-mounted unit 12 is a device in the vehicle. The first roadside unit 11 is used to send payment inquiry messages, and the second roadside unit 14 is used to send payment interaction messages. The first roadside unit 11 and the second roadside unit 14 constitute a roadside system. The roadside end provided in the embodiment of the present application may be a roadside system composed of the first roadside unit 11 and the second roadside unit 14, or may be the first roadside unit.

[0134] like Figure 4b As shown, the second roadside unit 14 can send a payment interaction message to the vehicle-mounted unit 12 at the second power, and interact with the toll collection system 13 according to the interaction response message returned by the vehicle-mounted unit 12, and locally record the payment voucher information of the vehicle that has completed the payment. The first roadside unit 11 can send a payment inquiry message to the vehicle-mounted unit 12 at the first power, and determine whether to control the gate to release the vehicle according to the payment response message returned by the vehicle-mounted unit 12 and the payment voucher information recorded by the second roadside unit 14.

[0135] In yet another example, Figure 4c The schematic diagram of the architecture of the traffic control system of the embodiment of the present application is shown. Figure 4c As shown, the traffic control system may include a first roadside unit 11, a vehicle-mounted unit 12, a toll collection system 13, a second roadside unit 14, and a server 15. The second roadside unit 14 may send a payment interaction message to the vehicle-mounted unit 12 at a second power, and interact with the toll collection system 13 according to the interaction response message returned by the vehicle-mounted unit 12, and record the payment voucher information of the vehicle that has completed the payment in the server 15. The first roadside unit 11 may send a payment inquiry message to the vehicle-mounted unit 12 at a first power, and determine whether to control the gate to release the vehicle according to the payment response message returned by the vehicle-mounted unit 12 and the payment voucher information recorded by the server 15.

[0136] It should be noted that when the payment inquiry message and the payment interaction message are sent by different roadside devices, the sending channel and sending cycle of the payment inquiry message and the payment interaction message can be set as needed, and this application does not impose any restrictions.

[0137] Figure 5a The roadside equipment, the equipment in the vehicle, the first roadside unit, the second roadside unit, the vehicle-mounted unit and the server in the embodiment of the present application can all be composed of Figure 5a The electronic device shown is implemented, for example Figure 4c The first roadside unit 11, the vehicle-mounted unit 12, the second roadside unit 14 and the server 15 are shown. Figure 5aAs shown, the electronic device may include: at least one processor 3101 , a communication line 3102 , a memory 3103 and at least one communication interface 3104 .

[0138] Processor 3101 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0139] The communication link 3102 may include a pathway for transmitting information between the above-mentioned components.

[0140] The communication interface 3104 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, RAN, wireless local area networks (WLAN), etc.

[0141] The memory 3103 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited to this. The memory can be independent and connected to the processor through a communication line 3102. The memory can also be integrated with the processor. The memory provided in the embodiment of the present application can generally have non-volatility. Among them, the memory 3103 is used to store the computer execution instructions for executing the scheme of the present application, and the execution is controlled by the processor 3101. The processor 3101 is used to execute the computer-executable instructions stored in the memory 3103, thereby implementing the method provided in the above embodiments of the present application.

[0142] Optionally, the computer-executable instructions in the embodiments of the present application may also be referred to as application code, which is not specifically limited in the embodiments of the present application.

[0143] In a specific implementation, as an embodiment, the processor 3101 may include one or more CPUs, such as Figure 5a CPU0 and CPU1 in.

[0144] In a specific implementation, as an embodiment, the electronic device may include multiple processors, such as Figure 5a 3101 and processor 3107 in the embodiment. Each of these processors may be a single-CPU processor or a multi-CPU processor. The processor here may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0145] In a specific implementation, as an embodiment, the electronic device may further include an output device 3105 and an input device 3106. The output device 3105 communicates with the processor 3101 and may display information in a variety of ways. For example, the output device 3105 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 3106 communicates with the processor 3101 and may receive user input in a variety of ways. For example, the input device 3106 may be a mouse, a keyboard, a touch screen device, or a sensor device.

[0146] Figure 5b FIG. 2 shows a schematic diagram of the structure of a chip according to an embodiment of the present application. Figure 5b As shown, Figure 5b The chip shown may be a general-purpose processor or a special-purpose processor. The chip includes a processor 3201 .

[0147] Optionally, the chip also includes a transceiver 3202, which is used to accept the control of the processor 3201 and to support the electronic device to execute the above technical solution.

[0148] Optional, Figure 5b The chip shown may also include: a storage medium 3203 .

[0149] It should be noted that Figure 5bThe chip shown can be implemented using the following circuits or devices: one or more field programmable gate arrays (FPGAs), programmable logic devices (PLDs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits that can perform the various functions described throughout this application.

[0150] Figure 6 The interactive flow chart of the traffic control method provided by the embodiment of the present application is shown. The method can be applied to non-free flow charging scenarios, such as Figure 1a , Figure 1b or Figure 1c This method can be applied to the scenarios shown in Figure 4a The access control system shown in Figure 1 is Figure 6 As shown, the method may include:

[0151] Step S601: The first roadside unit at the roadside end sends a payment interaction message to the vehicle at a second power.

[0152] The payment interaction message is used to charge the vehicle for passing through the gate.

[0153] The first roadside unit may periodically send a payment interaction message. The sending period of the payment interaction message may be set as required. In a possible implementation, the sending period of the payment interaction message may be determined according to the road speed limit or the traffic volume. When the road speed limit is low or the traffic volume is low, a larger sending period may be set for the payment interaction message. When the road speed limit is high or the traffic volume is high, a smaller sending period may be set for the payment interaction message. When the road speed limit is low, the vehicle traffic rate is relatively low, the vehicle traffic volume is relatively low, and at this time, there are fewer vehicles that need to pay. Therefore, in order to reduce the energy consumption of the first roadside unit, a larger sending period may be set for the payment interaction message. When the road speed limit is high, the vehicle traffic rate is relatively high (such as a highway), the vehicle traffic volume is relatively high (such as a main road in a city), and at this time, there are more vehicles that need to pay. Therefore, in order to improve the payment efficiency, a smaller sending period may be set for the payment interaction message. In addition, when the communication range of the payment interaction message is large, there may be more vehicles that need to pay. At this time, a smaller sending period may also be set for the payment interaction message. When the communication range of the payment interaction message is small, there may be fewer vehicles that need to pay. In this case, a larger sending period can be set for the payment interaction message. The sending period of the payment interaction message is variable (e.g. Figure 3f shown).

[0154] During implementation, the first roadside unit can broadcast the payment interaction message, so that all vehicles entering the payment interaction message communication range can receive the payment interaction message and enter the payment process, which is conducive to improving payment efficiency.

[0155] In one example, the payment interaction message may include information such as the identification of the first roadside unit.

[0156] Step S602: In response to the payment interaction message sent by the first roadside unit, the on-board unit in the vehicle returns an interaction response message including a vehicle identification code to the first roadside unit.

[0157] After the vehicle enters the communication range of the payment interaction message sent by the first roadside unit, its onboard unit can receive the payment interaction message. In response to the received payment interaction message, the onboard unit in the vehicle can obtain the vehicle identification code and send the vehicle identification code to the first roadside unit through an interactive response message, so that the first roadside unit can enter the payment process of the vehicle. In one example, the vehicle identification code includes but is not limited to the vehicle identification (VID) or license plate number.

[0158] Step S603: The first roadside unit at the roadside end obtains transaction information according to the vehicle identification code in the received interactive response message.

[0159] In implementation, after receiving the interactive response message, the first roadside unit can obtain the vehicle identification code from the interactive response message, and interact with the charging system based on the vehicle identification code to obtain transaction information. In one example, the transaction information may include information such as bills, charging details and vehicle identification codes.

[0160] Step S604: the first roadside unit at the roadside end returns the transaction information to the on-board unit in the vehicle.

[0161] After the first roadside unit obtains the transaction information, it returns the transaction information to the vehicle-mounted unit. In a possible implementation, when the first roadside unit returns the transaction information to the vehicle-mounted unit, it may also return at least one of the roadside equipment identifier (e.g., the number of the first roadside unit, etc.), the toll station identifier (e.g., the number of the toll station, etc.), the gate identifier (e.g., the gate number, or the number of the control lever at the gate, etc.), or the random code corresponding to the first roadside unit.

[0162] Step S605: the on-board unit in the vehicle pays the fee according to the received transaction information.

[0163] The on-board unit in the vehicle can deduct money or make accounting operations based on the received transaction information to complete the payment.

[0164] Step S606: After the payment is completed, the on-board unit in the vehicle sends a payment completion message including payment voucher information to the first roadside unit.

[0165] The payment completion message can be used to prove that the vehicle has completed the payment (including that a deduction operation has been performed or an accounting operation has been performed, etc.).

[0166] Step S607, the first roadside unit at the roadside end confirms whether the payment is completed based on the payment voucher information in the received payment completion message, and if the payment is completed, saves the payment voucher information locally.

[0167] The first roadside unit verifies the authenticity of the payment voucher information in the payment completion message. If the verification is successful, the first roadside unit can assume that the vehicle has completed the payment. At this time, the first roadside unit saves the payment voucher information locally for subsequent query.

[0168] In a possible implementation, the first roadside unit may save the second charging voucher or the second vehicle identification code as payment voucher information. In the embodiment of the present application, the first charging voucher may represent the charging voucher received by the first roadside unit after the vehicle has paid the fee (i.e., the charging voucher in the payment response message fed back by the vehicle in response to the payment inquiry message, corresponding to the charging voucher obtained when executing step S612), and the second charging voucher may be used to represent the charging voucher saved by the first roadside unit before receiving the payment response message (corresponding to before executing step S612). The first vehicle identification code may represent the vehicle identification code received by the first roadside unit after the vehicle has paid the fee (i.e., the vehicle identification code in the payment response message fed back by the vehicle in response to the payment inquiry message, corresponding to the vehicle identification code obtained when executing step S612), and the second vehicle identification code may be used to represent the vehicle identification code saved by the first roadside unit before receiving the payment response message (corresponding to before executing step S612).

[0169] In one example, the vehicle identification code (the first vehicle identification code and the second vehicle identification code) includes but is not limited to a VID or a license plate number. The charging voucher (the first charging voucher and the second charging voucher) may include a vehicle identification code and at least one of a roadside equipment identification, a charging station identification, and a gate identification.

[0170] Step S608: The first roadside unit at the roadside end sends a payment inquiry message to the vehicle at a first power.

[0171] The payment inquiry message is used to request payment voucher information of a vehicle that has completed payment but has not passed through the gate. In one example, the payment voucher information may be a charging voucher or a vehicle identification code.

[0172] The first roadside unit may periodically send payment inquiry messages. The sending period of the payment inquiry message may be set as needed. In one possible implementation, the sending period of the payment inquiry message may be determined based on the road speed limit or the traffic volume. In the case where the road speed limit is high (e.g., a highway) or the traffic volume is high (e.g., a main road in a city), a smaller sending period may be set for the payment inquiry message. In the case where the road speed limit is low or the traffic volume is low, a larger sending period may be set for the payment inquiry message. The sending period of the payment inquiry message is variable (e.g., Figure 3g shown).

[0173] It should be noted that the payment inquiry message in this step is sent periodically and has no order relationship with the sending order of the payment interaction message in step S601. It is just that when the vehicle is close to the gate, its on-board unit can receive the payment inquiry message and then execute the subsequent step S609. The sending interval between the payment inquiry message in this step and the payment interaction message in step S601 can be set as needed, and the minimum adjustment interval can be 1ms, which is not limited by this application.

[0174] During implementation, the first roadside unit can broadcast a payment inquiry message. Since the communication range of the payment inquiry message is small, although the first roadside unit broadcasts the payment inquiry message, only one vehicle receives the payment inquiry message, that is, only one vehicle can enter the inquiry process, which is conducive to precise control of vehicle passage.

[0175] In a possible implementation, the payment inquiry message may include at least one of a roadside device identifier, a toll booth identifier, a gate identifier, or a random code, wherein the random code is used to identify a fake payment response message sent by the vehicle-mounted unit.

[0176] Step S609, in response to the payment inquiry message sent by the first roadside unit, the on-board unit in the vehicle obtains the payment voucher information.

[0177] After the vehicle enters the communication range of the payment inquiry message sent by the first roadside unit, its onboard unit can receive the payment inquiry message. In response to the received payment inquiry message, the onboard unit in the vehicle can obtain the payment voucher information and send the payment voucher information to the first roadside unit through a payment response message.

[0178] Step S610: the on-board unit in the vehicle generates a payment response message including payment voucher information.

[0179] Step S611: The on-board unit in the vehicle returns a payment response message to the first roadside unit.

[0180] In a possible implementation, when the received payment inquiry message includes a random code, the returned payment response message includes the same random code to improve reliability.

[0181] Step S612: The first roadside unit at the roadside end obtains payment voucher information from the received payment response message.

[0182] In a possible implementation, the payment voucher information obtained by the first roadside unit from the payment response message includes a vehicle identification code or a charging voucher. In order to distinguish it from the vehicle identification code (i.e., the second vehicle identification code) or the charging voucher (i.e., the second charging voucher) saved by the first roadside unit before the current moment, in the embodiment of the present application, the vehicle identification code obtained by the first roadside unit from the payment response message is recorded as the first vehicle identification code, and the charging voucher obtained by the first roadside unit from the payment response message is recorded as the first charging voucher.

[0183] Step S613: The first roadside unit at the roadside end generates a traffic control signal based on the payment voucher information obtained from the payment response message and the payment voucher information stored locally.

[0184] The traffic control signal is used to control the gate to release vehicles. The payment voucher information obtained from the payment response message includes the first charging voucher or the first vehicle identification code.

[0185] In one possible implementation, the payment voucher information obtained by the first roadside unit from the payment response message is the first charging voucher, and the payment voucher information locally stored by the first roadside unit is the second charging voucher. Step S612 may include: generating a traffic control signal based on the judgment result that the first charging voucher is consistent with the second charging voucher.

[0186] If the first charging voucher is consistent with the second charging voucher, it indicates that the vehicle to be passed through the gate has completed the payment, so a pass control signal can be generated to control the gate to release the vehicle. If the first charging voucher is inconsistent with the second charging voucher, it indicates that the vehicle to be passed through the gate has not paid or the payment status has not been confirmed, and no gate control signal will be generated to release the vehicle.

[0187] In one possible implementation, the payment voucher information obtained by the second roadside unit from the payment response message is the first vehicle identification code, and the payment voucher information locally stored by the second roadside unit is the second vehicle identification code. Step S612 may include: generating a traffic control signal based on the judgment result that the first vehicle identification code is consistent with the second vehicle identification code.

[0188] When the first vehicle identification code and the second vehicle identification code are consistent, it indicates that the vehicle to be passed through the gate has completed payment, so a pass control signal can be generated to control the gate to release the vehicle. When the first vehicle identification code and the second vehicle identification code are inconsistent, it indicates that the vehicle to be passed through the gate has not paid or the payment status has not been confirmed, and no control gate will be generated to release the vehicle.

[0189] During implementation, the first roadside unit may send a traffic control signal to a control lever at the gate, causing the control lever to perform a lifting operation, thereby releasing the vehicle from the gate.

[0190] In a possible implementation, in step S611, the vehicle-mounted unit may repeatedly send the payment response message multiple times to improve reliability. After the first roadside unit at the roadside end generates the traffic control signal, the first roadside unit may also send a release confirmation message to the vehicle. After receiving the release confirmation message from the roadside end, the vehicle-mounted unit may stop sending the payment response message according to the release confirmation message.

[0191] In an embodiment of the present application, the payment process is completed through a payment interaction message with high power, so that the vehicle can complete the payment at a location far away from the gate, and the payment completion time is much earlier than the time it takes for the vehicle to travel to the gate. The release confirmation is performed through a payment inquiry message with low power. When the paid vehicle further travels to a location closer to the gate, the roadside can confirm that the vehicle has paid, so that the gate releases the paid vehicle and avoids releasing other vehicles that have not paid or vehicles whose payment status has not been confirmed. This not only ensures the vehicle traffic efficiency, but also improves the accuracy of vehicle release, and realizes reliable and efficient non-free flow payment based on V2X technology.

[0192] Figure 7 The interactive flow chart of the traffic control method provided by the embodiment of the present application is shown. The method can be applied to non-free flow payment scenarios, such as Figure 1a , Figure 1b or Figure 1c This method can be applied to the scenarios shown in Figure 4b The access control system shown in Figure 1 is Figure 7 As shown, the method may include:

[0193] Step S701: The second roadside unit at the roadside end sends a payment interaction message to the vehicle at a second power.

[0194] Step S702: In response to the payment interaction message sent by the second roadside unit, the on-board unit in the vehicle returns an interaction response message including a vehicle identification code to the second roadside unit.

[0195] Step S703: The second roadside unit at the roadside end obtains transaction information according to the vehicle identification code in the received interactive response message.

[0196] Step S704: The second roadside unit at the roadside end returns the transaction information to the on-board unit in the vehicle.

[0197] Step S705: The on-board unit in the vehicle pays the fee according to the received transaction information.

[0198] Step S706, after the payment is completed, the on-board unit in the vehicle sends a payment completion message including payment voucher information to the second roadside unit.

[0199] Step S707: The second roadside unit at the roadside end confirms whether the payment is completed based on the payment voucher information in the received payment completion message, and if the payment is completed, saves the payment voucher information locally.

[0200] Steps S701 to S707 may refer to steps S601 to S607 and will not be described in detail here.

[0201] Step S708: The first roadside unit at the roadside end sends a payment inquiry message to the vehicle at a first power.

[0202] Step S709, in response to the payment inquiry message sent by the first roadside unit, the on-board unit in the vehicle obtains the payment voucher information.

[0203] Step S710: the on-board unit in the vehicle generates a payment response message including payment voucher information.

[0204] Step S711: The on-board unit in the vehicle returns a payment response message to the first roadside unit.

[0205] Steps S708 to S711 may refer to steps S608 to S611 and will not be described in detail here.

[0206] Step S712: The first roadside unit at the roadside end obtains payment voucher information from the received payment response message.

[0207] Step S713: The first roadside unit at the roadside end generates a traffic control signal based on the payment voucher information obtained from the payment response message and the payment voucher information stored in the second roadside unit.

[0208] In a possible implementation, the payment voucher information obtained by the first roadside unit from the payment response message is the first charging voucher, and the payment voucher information locally stored by the second roadside unit is the second charging voucher. The first roadside unit can send a search request to the second roadside unit, and the search request may include the first charging voucher. After receiving the search request, the second roadside unit searches for a second charging voucher that is consistent with the first charging voucher. If a consistent second charging voucher is found, the second roadside unit sends a notification of finding to the first roadside unit; otherwise, the second roadside unit sends a notification of not finding to the first roadside unit. After receiving the notification of finding sent by the second roadside unit, the first roadside unit can determine that the first charging voucher is consistent with the second charging voucher, and then generate a traffic control signal.

[0209] In a possible implementation, the payment voucher information obtained by the first roadside unit from the payment response message is the first vehicle identification code, and the payment voucher information locally stored by the second roadside unit is the second vehicle identification code. The first roadside unit can send a search request to the second roadside unit, and the search request may include the first vehicle identification code. After receiving the search request, the second roadside unit searches for a second vehicle identification code that is consistent with the first vehicle identification code. If a consistent second vehicle identification code is found, the second roadside unit sends a notification of finding to the first roadside unit; otherwise, the second roadside unit sends a notification of not finding to the first roadside unit. After receiving the notification of finding sent by the second roadside unit, the first roadside unit can determine that the first vehicle identification code is consistent with the second vehicle identification code, and then generate a traffic control signal.

[0210] During implementation, the first roadside unit may send a traffic control signal to a control lever at the gate, causing the control lever to perform a lifting operation, thereby releasing the vehicle from the gate.

[0211] In a possible implementation, in step S611, the vehicle-mounted unit may repeatedly send the payment response message multiple times to improve reliability. After the first roadside unit at the roadside end generates the traffic control signal, the first roadside unit may also send a release confirmation message to the vehicle. After receiving the release confirmation message from the roadside end, the vehicle-mounted unit may stop sending the payment response message according to the release confirmation message.

[0212] In an embodiment of the present application, the payment process is completed through a payment interaction message with high power, so that the vehicle can complete the payment when it is far away from the gate. The payment completion time is much earlier than the time it takes for the vehicle to travel to the gate. The release confirmation is performed through a payment inquiry message with low power. When the paid vehicle further travels to a position closer to the gate, the roadside can confirm that the vehicle has paid, so that the gate releases the paid vehicle and avoids releasing other vehicles that have not paid or vehicles whose payment status has not been confirmed. This not only ensures the vehicle traffic efficiency, but also improves the accuracy of vehicle release, and realizes reliable and efficient non-free flow payment based on V2X technology.

[0213] Figure 8 The interactive flow chart of the traffic control method provided by the embodiment of the present application is shown. The method can be applied to non-free flow payment scenarios, such as Figure 1a , Figure 1b or Figure 1c This method can be applied to the scenarios shown in Figure 4c The access control system shown in Figure 1 is Figure 8 As shown, the method may include:

[0214] Step S801: The second roadside unit at the roadside end sends a payment interaction message to the vehicle at a second power.

[0215] Step S802: In response to the payment interaction message sent by the second roadside unit, the on-board unit in the vehicle returns an interaction response message including a vehicle identification code to the second roadside unit.

[0216] Step S803: The second roadside unit at the roadside end obtains transaction information according to the vehicle identification code in the received interactive response message.

[0217] Step S804: The second roadside unit at the roadside end returns the transaction information to the on-board unit in the vehicle.

[0218] Step S805: The on-board unit in the vehicle pays the fee according to the received transaction information.

[0219] Step S806: After the payment is completed, the on-board unit in the vehicle sends a payment completion message including payment voucher information to the second roadside unit.

[0220] Step S807: The second roadside unit at the roadside end confirms whether the payment is completed based on the payment voucher information in the received payment completion message.

[0221] Steps S801 to S807 may refer to steps S601 to S607 and will not be described in detail here.

[0222] Step S808: When the payment is confirmed to be completed, the second roadside unit at the roadside end sends the payment voucher information in the payment completion message to the server.

[0223] Step S809: The server saves the received payment voucher information locally.

[0224] Step S810: The first roadside unit at the roadside end sends a payment inquiry message to the vehicle at a first power.

[0225] Step S811, in response to the payment inquiry message sent by the first roadside unit, the on-board unit in the vehicle obtains the payment voucher information.

[0226] Step S812: The on-board unit in the vehicle generates a payment response message including payment voucher information.

[0227] Step S813: The on-board unit in the vehicle returns a payment response message to the first roadside unit.

[0228] Steps S810 to S813 may refer to steps S608 to S611.

[0229] Step S814: The first roadside unit at the roadside end obtains payment voucher information from the received payment response message.

[0230] Step S815: The first roadside unit at the roadside end generates a traffic control signal based on the payment voucher information obtained from the payment response message and the payment voucher information stored in the server.

[0231] In a possible implementation, the payment voucher information obtained by the first roadside unit from the payment response message is the first charging voucher, and the payment voucher information locally stored by the server is the second charging voucher. The first roadside unit can send a search request to the server, and the search request can include the first charging voucher. After receiving the search request, the server searches for a second charging voucher that is consistent with the first charging voucher. If a consistent second charging voucher is found, the server sends a notification of finding to the first roadside unit; otherwise, the server sends a notification of not finding to the first roadside unit. After receiving the notification of finding sent by the server, the first roadside unit can determine that the first charging voucher is consistent with the second charging voucher, and then generate a traffic control signal.

[0232] In a possible implementation, the payment voucher information obtained by the first roadside unit from the payment response message is the first vehicle identification code, and the payment voucher information locally stored by the server is the second vehicle identification code. The first roadside unit can send a search request to the server, and the search request may include the first vehicle identification code. After receiving the search request, the server searches for a second vehicle identification code that is consistent with the first vehicle identification code. If a consistent second vehicle identification code is found, the server sends a notification of finding to the first roadside unit; otherwise, the server sends a notification of not finding to the first roadside unit. After receiving the notification of finding sent by the server, the first roadside unit can determine that the first vehicle identification code is consistent with the second vehicle identification code, and then generate a traffic control signal.

[0233] During implementation, the first roadside unit may send a traffic control signal to a control lever at the gate, causing the control lever to perform a lifting operation, thereby releasing the vehicle from the gate.

[0234] In a possible implementation, in step S611, the vehicle-mounted unit may repeatedly send the payment response message multiple times to improve reliability. After the first roadside unit at the roadside end generates the traffic control signal, the first roadside unit may also send a release confirmation message to the vehicle. After receiving the release confirmation message from the roadside end, the vehicle-mounted unit may stop sending the payment response message according to the release confirmation message.

[0235] In an embodiment of the present application, the payment process is completed through a payment interaction message with high power, so that the vehicle can complete the payment when it is far away from the gate. The payment completion time is much earlier than the time it takes for the vehicle to travel to the gate. The release confirmation is performed through a payment inquiry message with low power. When the paid vehicle further travels to a position closer to the gate, the roadside can confirm that the vehicle has paid, so that the gate releases the paid vehicle and avoids releasing other vehicles that have not paid or vehicles whose payment status has not been confirmed. This not only ensures the vehicle traffic efficiency, but also improves the accuracy of vehicle release, and realizes reliable and efficient non-free flow payment based on V2X technology.

[0236] Fig. 9 The schematic diagram of the structure of the traffic control device provided in the embodiment of the present application is shown. The device can be applied to the roadside equipment at the roadside end, for example Figure 4a , Figure 4b and Figure 4c The first roadside unit 11 shown. Fig. 9 As shown, the device 900 includes:

[0237] The sending module 901 is used to send a payment inquiry message to the vehicle at a first power, and the payment inquiry message is used to request the payment voucher information of the vehicle that has completed the payment but has not passed through the gate. The payment is the fee paid for passing through the gate. The first power is less than the second power used to send the payment interaction message, and the payment interaction message is used to collect the fee from the vehicle.

[0238] The receiving module 902 is used to receive a payment response message fed back by the vehicle in response to the payment inquiry message sent by the sending module 901, wherein the payment response message includes the payment voucher information.

[0239] The processing module 903 is used to generate a traffic control signal according to the payment response message received by the receiving module 902, and the traffic control signal is used to control the gate to release the vehicle.

[0240] In one possible implementation, the payment voucher information is the first charging voucher received by the vehicle after paying the fee; the device also includes: a saving module for saving a second charging voucher; the processing module is also used to: generate a traffic control signal based on the judgment result that the first charging voucher is consistent with the second charging voucher.

[0241] In a possible implementation, the payment voucher information is a first vehicle identification code; the device also includes: a storage module for storing a second vehicle identification code; the processing module is also used to: generate a traffic control signal based on a judgment result that the first vehicle identification code is consistent with the second vehicle identification code.

[0242] In a possible implementation, the payment inquiry message includes at least one of a roadside equipment identifier, a toll booth identifier, a gate identifier, or a random code.

[0243] In a possible implementation manner, the payment inquiry message includes a random code, and the payment response message includes the random code.

[0244] In a possible implementation, the sending module is further configured to send a release confirmation message to the vehicle.

[0245] In a possible implementation, the payment inquiry message is a broadcast message sent periodically.

[0246] In a possible implementation, the sending cycle of the payment inquiry message is determined according to the road speed limit or traffic volume.

[0247] In a possible implementation, the sending module is further used to send the payment interaction message to the vehicle at the second power, and the payment interaction message and the payment inquiry message are sent in a frequency-division or time-division manner.

[0248] In a possible implementation, the roadside end includes:

[0249] A roadside unit for sending the payment inquiry message and sending the payment interaction message;

[0250] or,

[0251] A roadside system comprising a first roadside unit for sending the payment inquiry message and a second roadside unit for sending the payment interaction message;

[0252] or,

[0253] The first roadside unit in the roadside system is used to send the payment inquiry message.

[0254] In an embodiment of the present application, the payment process is completed through a payment interaction message with high power, so that the vehicle can complete the payment when it is far away from the gate. The payment completion time is much earlier than the time it takes for the vehicle to travel to the gate. The release confirmation is performed through a payment inquiry message with low power. When the paid vehicle further travels to a position closer to the gate, the roadside can confirm that the vehicle has paid, so that the gate releases the paid vehicle and avoids releasing other vehicles that have not paid or vehicles whose payment status has not been confirmed. This not only ensures the vehicle traffic efficiency, but also improves the accuracy of vehicle release, and realizes reliable and efficient non-free flow payment based on V2X technology.

[0255] Fig.10 The schematic diagram of the structure of the traffic control device provided in the embodiment of the present application is shown. The device can be applied to equipment in a vehicle, for example Figure 4a , Figure 4b and Figure 4c The vehicle-mounted unit 12 shown. Fig.10 As shown, the device 1000 includes:

[0256] The receiving module 1001 is used to receive a payment inquiry message from the roadside end, wherein the payment inquiry message is used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, wherein the payment is the fee paid for passing through the gate.

[0257] The sending module 1002 is used to send a payment response message to the roadside end according to the payment inquiry message received by the receiving module 1001, and the payment response message includes the payment voucher information.

[0258] In a possible implementation, the receiving module is further used to receive a charging voucher after the vehicle pays the fee; the payment voucher information is the charging voucher.

[0259] In a possible implementation, the payment voucher information is a vehicle identification code of the vehicle; the sending module is further used to send the vehicle identification code to the roadside end after the vehicle pays the fee.

[0260] In a possible implementation, the payment inquiry message includes at least one of a roadside equipment identifier, a toll booth identifier, a gate identifier, or a random code.

[0261] In a possible implementation manner, the payment inquiry message includes a random code, and the payment response message includes the random code.

[0262] In a possible implementation, the sending of the payment response message is to repeatedly send the payment response message multiple times, and the receiving module is also used to receive a release confirmation message from the roadside end; the sending module is also used to stop sending the payment response message according to the release confirmation message.

[0263] In an embodiment of the present application, the inquiry process is completed in response to a payment inquiry message with lower power, so that vehicles that have completed payment can pass through the gate smoothly when they drive to a position closer to the gate, while vehicles that have not completed payment cannot pass through the gate when they drive to a position closer to the gate. This not only ensures the vehicle traffic efficiency, but also improves the accuracy of vehicle release, and realizes reliable and efficient non-free flow payment based on V2X technology.

[0264] An embodiment of the present application provides a traffic control device, comprising: a processor and a memory for storing processor executable instructions; wherein the processor is configured to implement the above method when executing the instructions.

[0265] An embodiment of the present application provides a chip, comprising: a processor and a memory for storing processor-executable instructions; wherein the processor is configured to implement the above method when executing the instructions.

[0266] An embodiment of the present application provides a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the above method is implemented.

[0267] An embodiment of the present application provides a computer program product, including a computer-readable code. When the computer-readable code is executed in a traffic control device, the traffic control device is enabled to execute the above method.

[0268] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, (but not limited to) an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a protruding structure in a groove on which instructions are stored, and any suitable combination thereof.

[0269] The computer-readable program instructions or codes described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0270] The computer program instructions for performing the operation of the present application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, by utilizing the state information of computer-readable program instructions to personalize an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA), the electronic circuit can execute the computer-readable program instructions to implement various aspects of the present application.

[0271] Various aspects of the present application are described herein with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0272] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0273] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0274] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the device, system, method and computer program product according to multiple embodiments of the present application. In this regard, each square frame in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of the module, program segment or instruction includes one or more executable instructions for realizing the logical function of the specification. In some alternative implementations, the functions marked in the square frame can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square frames can actually be executed substantially in parallel, and they can also be executed in reverse order sometimes, depending on the functions involved.

[0275] It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented by hardware (such as a circuit or ASIC (Application Specific Integrated Circuit)) that performs the corresponding function or action, or can be implemented by a combination of hardware and software, such as firmware.

[0276] Although the present invention is described herein in conjunction with various embodiments, in the process of implementing the claimed invention, those skilled in the art may understand and implement other variations of the disclosed embodiments by viewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "one" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0277] The embodiments of the present application have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A traffic control method, characterized in that: The method is applied to a roadside end, and the method comprises: Sending a payment inquiry message to a vehicle at a first power, the payment inquiry message being used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, the payment being the payment of a fee for passing through the gate, the first power being less than a second power used to send a payment interaction message, the payment interaction message being used to charge the fee from the vehicle; the communication range of the payment inquiry message being less than the communication range of the payment interaction message; receiving a payment response message fed back by the vehicle in response to the payment inquiry message, wherein the payment response message includes the payment voucher information; A passage control signal is generated according to the payment response message, and the passage control signal is used to control the gate to release the vehicle.

2. The method according to claim 1, characterized in that The payment voucher information is the first charging voucher received by the vehicle after paying the fee; Before receiving the payment response message, the method further includes: saving a second charging voucher; The generating of the access control signal according to the payment response message includes: generating the access control signal based on a judgment result that the first charging voucher is consistent with the second charging voucher.

3. The method according to claim 1, characterized in that The payment voucher information is the first vehicle identification code; Before receiving the payment response message, the method further includes: saving a second vehicle identification code; The generating of the access control signal according to the payment response message includes: generating the access control signal based on a judgment result that the first vehicle identification code is consistent with the second vehicle identification code.

4. The method according to any one of claims 1 to 3, characterized in that: The payment inquiry message includes at least one of a roadside equipment identification, a toll booth identification, a gate identification or a random code.

5. The method according to any one of claims 1 to 3, characterized in that: The payment inquiry message includes a random code, and the payment response message includes the random code.

6. The method according to any one of claims 1 to 3, characterized in that: After generating the traffic control signal, the method further includes: sending a release confirmation message to the vehicle.

7. The method according to any one of claims 1 to 3, characterized in that: The payment inquiry message is a broadcast message sent periodically.

8. The method according to claim 7, characterized in that The sending cycle of the payment inquiry message is determined according to the road speed limit or traffic volume.

9. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The payment interaction message is sent to the vehicle at the second power, and the payment interaction message and the payment inquiry message are sent in a frequency-division or time-division manner.

10. A traffic control method, characterized in that: The method is applied to a vehicle-mounted unit, and the method comprises: receiving a payment inquiry message from a roadside end, the payment inquiry message being used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, the payment being the payment of a fee for passing through the gate; wherein the sending power corresponding to the payment inquiry message is less than the sending power corresponding to the payment interaction message, the payment interaction message being a message sent by the roadside end for collecting a fee for passing through the gate; and the communication range of the payment inquiry message being less than the communication range of the payment interaction message; A payment response message is sent to the roadside end according to the payment inquiry message, wherein the payment response message includes the payment voucher information.

11. The method according to claim 10, characterized in that The method further includes: receiving a charging voucher after the vehicle has paid the fee; the payment voucher information is the charging voucher.

12. The method according to claim 10, characterized in that The payment voucher information is the vehicle identification code of the vehicle; the method further includes: after the vehicle pays the fee, sending the vehicle identification code to the roadside end.

13. The method according to any one of claims 10 to 12, characterized in that: The payment inquiry message includes at least one of a roadside equipment identification, a toll booth identification, a gate identification or a random code.

14. The method according to any one of claims 10 to 12, characterized in that: The payment inquiry message includes a random code, and the payment response message includes the random code.

15. The method according to any one of claims 10 to 12, characterized in that: The sending of the payment response message is to repeatedly send the payment response message multiple times, and the method further includes: Receive a release confirmation message from the roadside terminal; Stop sending the payment response message according to the release confirmation message.

16. A traffic control device, characterized in that: The device is applied to the roadside end, and the device comprises: a sending module, configured to send a payment inquiry message to a vehicle at a first power, wherein the payment inquiry message is used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, wherein the payment is the payment of a fee for passing through the gate, wherein the first power is less than a second power used to send a payment interaction message, wherein the payment interaction message is used to collect the fee from the vehicle; and wherein a communication range of the payment inquiry message is less than a communication range of the payment interaction message; A receiving module, configured to receive a payment response message fed back by the vehicle in response to the payment inquiry message sent by the sending module, wherein the payment response message includes the payment voucher information; The processing module is used to generate a passage control signal according to the payment response message received by the receiving module, and the passage control signal is used to control the gate to release the vehicle.

17. A traffic control device, characterized in that: The device is applied to a vehicle-mounted unit, and comprises: A receiving module, used for receiving a payment inquiry message from a roadside end, wherein the payment inquiry message is used to request payment voucher information of a vehicle that has completed the payment but has not passed through the gate, wherein the payment is the payment of a fee for passing through the gate; wherein the sending power corresponding to the payment inquiry message is smaller than the sending power corresponding to the payment interaction message, wherein the payment interaction message is a message sent by the roadside end for collecting fees for passing through the gate; and the communication range of the payment inquiry message is smaller than the communication range of the payment interaction message; The sending module is used to send a payment response message to the roadside end according to the payment inquiry message received by the receiving module, and the payment response message includes the payment voucher information.

18. A traffic control device, characterized in that: include: processor; a memory for storing processor-executable instructions; Wherein, the processor is configured to implement the method according to any one of claims 1 to 9 when executing the instructions.

19. A traffic control device, characterized in that: include: processor; a memory for storing processor-executable instructions; Wherein, the processor is configured to implement the method of any one of claims 10-15 when executing the instructions.

20. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 9 is implemented, or the method according to any one of claims 10 to 15 is implemented.

Images