A method and system for voice broadcasting on highways based on DSRC

Abstract

This invention provides a method and system for highway voice broadcasting based on DSRC (Dynamic Data Recognition). The method, executed by a roadside unit, includes: acquiring event information to be broadcast and sending it to a roadside safety module; encrypting the information to generate encrypted event information and a first message authentication code; broadcasting an information release data frame containing the encrypted event information, the first message authentication code, and a response identifier; the on-board unit using the on-board safety module to verify the first message authentication code, decrypting it to obtain the plaintext event information, and generating a response data frame containing the gantry information and a second message authentication code, and returning it; the roadside unit verifying the second message authentication code to determine the legitimacy of the on-board unit, and simultaneously determining the driving direction based on the gantry information; when the vehicle is traveling in the correct direction and has passed legally, a confirmation broadcast command is sent, and the on-board unit responds and broadcasts the latest event information. This invention achieves accurate, safe, and compatible highway voice broadcasting through two-way security authentication and direction determination.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation technology, and in particular to a method and system for voice broadcasting on highways based on DSRC. Background Technology

[0002] With the widespread adoption of Electronic Toll Collection (ETC) technology on highways and the successful implementation of the project to eliminate provincial toll stations, a new pattern of "one network operation and integrated service" has been formed nationwide, achieving preliminary vehicle-road cooperative information services.

[0003] However, existing technical solutions have significant drawbacks in practical applications. First, the information service is deeply integrated with the ETC transaction function, only reaching vehicles that have installed ETC and activated the transaction function. Many users who haven't installed ETC or don't want to use the transaction function are unable to access official road condition information, creating a service blind spot. Second, information dissemination, as an add-on function to the transaction, is only broadcast intermittently during transaction breaks, potentially interrupting or missing crucial warnings when vehicles are not in a transaction state. Third, the existing broadcast mechanism lacks strong authentication of the information source and encryption protection of the transmitted content, making it vulnerable to attacks using forged information and posing security risks. Fourth, the broadcast method cannot distinguish the direction of vehicle travel; vehicles in oncoming lanes will also receive warnings about accidents ahead, causing false alarms and interference. Fifth, the existing system lacks a mechanism to identify non-broadcasting devices, which may lead to conflicts between broadcasts and the ETC transaction function, affecting the normal operation of toll collection.

[0004] Therefore, there is an urgent need in this field for a voice broadcasting solution that can overcome the limitations of ETC transaction functions and achieve independent information dissemination. This solution should have two-way authentication and encryption protection capabilities for information sources, be able to accurately identify the vehicle's driving direction to avoid false alarms, and be compatible with existing ETC infrastructure without affecting the normal operation of toll collection services. This would solve the problems of limited service coverage, weak security protection, low broadcasting accuracy, and poor system compatibility. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method and system for highway voice broadcasting based on DSRC, in order to solve the problems of limited service coverage, insufficient information broadcasting reliability, weak security protection, lack of direction judgment and poor system compatibility in existing information release schemes based on ETC transactions.

[0006] One aspect of the present invention provides a highway voice broadcasting method based on DSRC, the method being executed by a roadside unit, the method comprising the following steps: The system acquires the event information to be broadcast and sends it to the roadside safety module, which then encrypts the event information, generates encrypted event information, generates a first message authentication code based on the encrypted event information, and returns the result. The broadcast includes the encrypted event information, the first message authentication code, and the response identifier in an information release data frame. After receiving the information release data frame, the vehicle-mounted device verifies the first message authentication code using the vehicle-mounted security module. After successful verification, the encrypted event information is decrypted to obtain the plaintext event information. Based on the plaintext event information and the locally stored route gantry information, the vehicle-mounted device generates a response data frame containing the route gantry information and the corresponding second message authentication code. The system receives the response data frame, extracts the route gantry information and the second message authentication code from the response data frame, verifies the second message authentication code to obtain the legality verification result of the vehicle-mounted device, and simultaneously determines the driving direction of the vehicle where the vehicle-mounted device is located based on the route gantry information. Based on the driving direction and the legality verification result, a comprehensive judgment is made. If the vehicle's driving direction is positive and the legality verification result is passed, the roadside unit sends a confirmation broadcast command to the vehicle-mounted device; otherwise, the confirmation broadcast command is not sent. In response to the confirmation broadcast command, the vehicle-mounted device reads the latest plaintext event information from the vehicle safety module and executes voice broadcast.

[0007] In some embodiments of the present invention, the roadside safety module encrypts the event information and generates the first message authentication code, specifically including: Based on the event publication timestamp, delayed broadcast time, number of beeps, broadcast information type, and plaintext of the event information, the key distribution instruction in the roadside safety module is invoked to distribute the target key and obtain a temporary key. The event information is encrypted using the temporary key to generate the encrypted event information, and the first message authentication code is generated based on the encrypted event information. After the vehicle-mounted safety module verifies the first message authentication code, it decrypts the encrypted event information and writes the decrypted event information in plaintext into the event publication record file in the vehicle-mounted safety module when the preset writing conditions are met, for subsequent broadcasting and retrieval.

[0008] In some embodiments of the present invention, determining the driving direction of the vehicle containing the on-board equipment based on the gantry information specifically includes: Extract at least one set of transit gantry identifiers and corresponding transit times from the response data frame; Based on the preset topological association between the passing gantry identifier and the current roadside unit corresponding gantry, the driving direction of the road segment where the passing gantry identifier corresponds to the gantry is located is determined, and combined with the time sequence relationship between the passing time and the current receiving time, the vehicle is determined to be a forward vehicle or a reverse vehicle. When the determination result is the reverse vehicle, the confirmation broadcast command is prohibited from being sent to the vehicle-mounted equipment to avoid false broadcasts of the reverse vehicle.

[0009] In some embodiments of the present invention, the preset write conditions include: Based on the system information file in the vehicle safety module, determine whether the current time is between the service start date and the service end date; Determine whether the timestamp of this event's publication is greater than the timestamp of the latest record in the event publication log file; The event information will be written in plaintext to the event publication record file only if the current time is within the service period and the publication timestamp of this event is greater than the timestamp of the latest record; Otherwise, the processing failure status is reported in the information processing status field of the response data frame.

[0010] In some embodiments of the present invention, the broadcast includes an information publishing data frame containing the encrypted event information, the first message authentication code, and the response identifier, specifically including: While broadcasting electronic toll collection transactions, the roadside unit intersperses the information release data frames with the transaction broadcast frames. The information release data frame includes a roadside unit identifier, a real-time timestamp, a configuration file identifier, an application identifier, the response identifier, the encrypted event information, and the first message authentication code; The roadside unit periodically sends the information release data frame between the information release start time and the information release end time, and updates the encrypted event information and the first message authentication code according to a preset time interval.

[0011] In some embodiments of the present invention, the response identifier is used to indicate the response strategy of the vehicle-mounted device, the response strategy including at least one of the following: Do not reply to the response data frame; The response data frame must be replied to; And the on-board equipment can autonomously decide whether to reply with the response data frame based on its own status; Specifically, when the response identifier indicates that the vehicle-mounted device must reply to the response data frame, or when the vehicle-mounted device decides to reply to the response data frame autonomously, the vehicle-mounted device generates and sends the response data frame after completing the verification of the first message authentication code and the decryption of the encrypted event information.

[0012] In some embodiments of the present invention, the response data frame includes at least the following: Physical address information of the vehicle-mounted equipment; Device identification information in the system information file; Event processing result information is used to indicate the processing result of the vehicle-mounted device on the information release data frame. The processing result includes successful decryption and successful writing, decryption failure, or writing failure. The second message authentication code is calculated based on preset authentication data; And at least one set of gantry information recorded in chronological order; The roadside unit determines whether the vehicle-mounted device is a legitimate device and whether it has successfully received the event information based on the event processing result information and the second message authentication code.

[0013] In some embodiments of the present invention, the confirmation broadcast instruction includes an event report request field and an application directory identifier field, and may include the current roadside gantry identifier; After receiving the confirmation broadcast instruction, the vehicle-mounted device triggers the reading of the latest written plaintext event information from the vehicle-mounted safety module according to the event report request field, and if the current roadside gantry identifier exists, it associates and stores the current roadside gantry identifier with the locally recorded route gantry information.

[0014] In some embodiments of the present invention, the route gantry information stored locally by the vehicle-mounted device is stored in a preset route gantry information file, which includes physical address information for locking the vehicle-mounted device, total number of records, and multiple historical records. Each of the aforementioned historical records must include at least the gantry identifier and the corresponding transit time; When passing through a gantry, the on-board equipment writes the newly generated gantry identifier and the passing time into the passing gantry information file, and when generating the response data frame, it reads no more than three recent historical records from the passing gantry information file as the passing gantry information.

[0015] On the other hand, the present invention also provides a highway voice broadcasting system based on DSRC, the system comprising: Lane controllers, roadside units, and onboard equipment; The roadside unit has a built-in roadside safety module, and the vehicle-mounted equipment has a built-in vehicle-mounted safety module; The lane controller, the roadside unit, and the on-board equipment cooperate to execute the DSRC-based highway voice broadcasting method as described above.

[0016] The DSRC-based highway voice broadcasting method and system provided by this invention breaks through the traditional limitation of binding information services and toll collection functions by using a dedicated vehicle-mounted device independent of ETC transaction functions. This allows users who have not installed ETC or do not wish to use ETC transaction functions to receive official traffic information, significantly expanding the service coverage.

[0017] In terms of security mechanisms, this invention establishes a complete two-way authentication link between the roadside unit and the vehicle-mounted unit. The roadside unit encrypts event information and generates a first message authentication code via a PSAM card, which is used by the vehicle-mounted equipment to verify the authenticity of the information source. The vehicle-mounted equipment, in turn, uses a second message authentication code for the roadside unit to verify the legitimacy of the equipment. Combined with dynamic key distribution technology, this ensures that the temporary key used in each communication is different, effectively preventing attacks that forge information and meeting the requirements of critical infrastructure for autonomy, controllability, and data security.

[0018] Regarding the accuracy of the broadcast, this invention achieves direction determination through the gantry information reported by the on-board equipment. The roadside unit accurately distinguishes between forward and reverse vehicles based on the topological relationship of the gantry identifiers and the temporal relationship of the transit time, sending confirmation broadcast commands only to forward vehicles. This fundamentally solves the problem of false alarms for oncoming lanes and significantly improves user experience and system reliability.

[0019] Furthermore, this invention, while fully utilizing existing ETC gantry infrastructure, achieves alternating transmission of information dissemination data frames and transaction broadcast frames, and identifies and differentiates non-broadcasting devices to ensure uninterrupted operation of toll collection services. This compatibility design protects existing investments and provides a feasible path for smooth system upgrades, demonstrating significant economic benefits and promotional value.

[0020] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0021] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0022] The accompanying drawings, which are provided to further illustrate the invention and form part of this application, are not intended to limit the scope of the invention.

[0023] Figure 1 This is a flowchart illustrating a DSRC-based highway voice broadcasting method according to an embodiment of the present invention.

[0024] Figure 2 This is a schematic diagram of the ESAM file structure of the vehicle safety module in a DSRC-based highway voice broadcast system according to an embodiment of the present invention.

[0025] Figure 3 This is a schematic diagram of the PSAM file structure of the roadside safety module in a DSRC-based highway voice broadcasting system according to an embodiment of the present invention.

[0026] Figure 4 This is a timing diagram of the normal broadcasting process of the voice broadcasting device in the DSRC-based highway voice broadcasting method according to an embodiment of the present invention.

[0027] Figure 5 This is a timing diagram of the abnormal broadcasting process of the voice broadcasting device in a highway voice broadcasting method based on DSRC according to an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0029] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0030] Existing ETC-based information service technologies have four main drawbacks: 1) Limited service coverage: Information services are deeply integrated with ETC transaction functions, only reaching vehicles that have installed ETC and activated the transaction function. Many users who have not installed ETC or do not wish to use the ETC transaction function cannot obtain official road condition information, creating a service blind spot; 2) Insufficient reliability of information broadcasting: Information dissemination is an additional function of ETC transactions, broadcasting only intermittently between transactions. When vehicles are not in a transaction state, key warnings may be interrupted or missed. Furthermore, existing equipment information prompts are not intuitive, making it difficult for users to accurately grasp real-time road conditions; 3) Weak security mechanisms: Existing broadcasting mechanisms lack strong authentication of information sources and encryption protection of transmitted content, making them vulnerable to attacks from forged information and posing security risks; 4) Lack of directional judgment capability: Broadcasting methods cannot distinguish the direction of vehicle travel. Vehicles in oncoming lanes may also receive warnings of accidents ahead, causing false alarms and interference, weakening users' trust in warning information.

[0031] In view of this, one aspect of the present invention provides a highway voice broadcasting method based on DSRC, the method being executed by a roadside unit, such as... Figure 1 As shown, the method includes the following steps: S101: Obtain the event information to be broadcast and send it to the roadside safety module so that the roadside safety module can encrypt the event information, generate encrypted event information, generate the first message authentication code based on the encrypted event information, and then return it.

[0032] S102: Broadcast an information release data frame containing encrypted event information, a first message authentication code, and a response identifier, so that after receiving the information release data frame, the vehicle-mounted equipment can use the vehicle-mounted security module to verify the first message authentication code; after successful verification, the encrypted event information is decrypted to obtain the plaintext event information, and the vehicle-mounted equipment generates a response data frame containing the gantry information and the corresponding second message authentication code based on the plaintext event information and the locally stored gantry information.

[0033] S103: Receive the response data frame, extract the route gantry information and the second message authentication code from the response data frame; verify the second message authentication code to obtain the legality verification result of the on-board equipment; and determine the driving direction of the vehicle where the on-board equipment is located based on the route gantry information.

[0034] S104: Based on the driving direction and the legality verification result, a comprehensive judgment is made. If the vehicle is driving in the forward direction and the legality verification result is passed, the roadside unit sends a confirmation broadcast command to the vehicle-mounted equipment. Otherwise, no confirmation broadcast command is sent. In response to the confirmation broadcast command, the vehicle-mounted equipment reads the latest event information plaintext from the vehicle-mounted safety module and executes voice broadcast.

[0035] In step S101, the roadside unit first acquires the event information to be broadcast and sends it to the built-in roadside security module. The security module encrypts and authenticates the original plaintext event information to generate encrypted event information and its corresponding message authentication code that can be securely transmitted in public channels, providing a secure and reliable data foundation for subsequent broadcasting.

[0036] Specifically, the roadside unit receives the event information to be broadcast from the lane controller. This event information is organized according to a preset plaintext data format and includes at least the following fields: event publication timestamp, broadcast delay time, number of beeps, broadcast information type, and plaintext event information. The roadside unit then sends this complete event information as data to be encrypted to the roadside safety module.

[0037] The roadside safety module is implemented using a dedicated vehicle-to-infrastructure (V2I) PSAM card. This PSAM card internally stores encryption and authentication keys specifically for event broadcasting. Upon receiving an event message, the PSAM card first performs a key distribution operation using a key distribution command. Based on the distribution factor for the current application scenario, the original key is distributed to a temporary key register, resulting in a temporary key. This process supports multi-level distribution, and the distributed temporary key inherits the attributes and permissions of the original key.

[0038] Subsequently, the PSAM card uses the obtained temporary key to encrypt the event information. The encryption process is completed via an encryption calculation command, whose parameters are set to specific values ​​indicating the ciphertext for information release and the calculation of the authentication code. The data to be calculated is arranged sequentially according to the event release timestamp, broadcast delay time, number of beeps, broadcast information type, and plaintext event information, forming an input data stream. Based on this input data stream and the temporary key, the PSAM card invokes a domestically developed cryptographic algorithm to perform encryption operations, generating encrypted event information.

[0039] While generating encrypted event information, the PSAM card also calculates a tamper-proof message authentication code based on the same encrypted event information. This authentication code is the first message authentication code. The first message authentication code is used by subsequent onboard equipment to verify the legitimacy of the information source and prevent unauthorized roadside equipment from forging information and publishing data frames.

[0040] After completing the encryption and authentication code calculations, the PSAM card returns the encrypted event information and the first message authentication code to the roadside unit. The roadside unit stores these two data points as the core payload of subsequent broadcast information transmission data frames.

[0041] In some embodiments, when acquiring event information, the roadside unit also receives broadcast parameters via information dissemination control instructions. These broadcast parameters include the information dissemination start time, the information dissemination end time, and the broadcast interval. The roadside unit controls the timing and frequency of subsequent broadcast actions based on these parameters.

[0042] In some embodiments, the roadside safety module employs a dynamic key distribution mechanism for encrypting event information. Specifically, based on fields such as the publication timestamp, broadcast delay time, number of beeps, broadcast information type, and plaintext of the event information, the roadside safety module calls a key distribution instruction to generate a temporary key, which is then used to complete encryption and generate the first message authentication code. This dynamic key mechanism ensures that the temporary key used for each event information encryption is different, thereby effectively enhancing the system's resistance to attacks.

[0043] At this point, step S101 completes the secure conversion of the event information from plaintext to ciphertext, generating encrypted event information that can be used for public broadcasting and its corresponding first message authentication code.

[0044] In step S102, the roadside unit broadcasts the encrypted information release data frame to all vehicle-mounted devices within its coverage area, and triggers the vehicle-mounted devices to complete the verification of the information source, decryption of the event information, and generation of response data, thereby establishing a secure communication link between the roadside and the vehicle, realizing the reliable transmission of information from the roadside to the vehicle, and obtaining the identity information and trajectory data of the vehicle-mounted devices, providing a basis for subsequent direction determination and device legitimacy verification.

[0045] Specifically, the roadside unit first encapsulates the encrypted event information and first message authentication code obtained from the roadside safety module, along with a pre-defined response identifier, into an information broadcast data frame. This data frame is organized according to the extended DSRC protocol format and includes fields such as frame start identifier, broadcast MAC address, MAC control field, LLC control field, RSU identifier, UNIX timestamp, configuration file identifier, application identifier, response identifier, encrypted event information, and first message authentication code. The response identifier indicates the response strategy that the on-board equipment should take upon receiving this data frame.

[0046] In some embodiments, the value of the response flag can be no response required, a response is required, or the vehicle-mounted device can decide whether to respond. When the response flag indicates that a response is required or the vehicle-mounted device can decide whether to respond, the vehicle-mounted device generates and sends a response data frame after completing the verification of the first message authentication code and the decryption of the event information.

[0047] The roadside unit alternately sends information release data frames and electronic toll transaction broadcast frames at preset time intervals.

[0048] In some embodiments, the roadside unit periodically performs a broadcast operation between the information release start time and the information release end time, and updates the broadcast content after recalculating the encrypted event information and the first message authentication code according to a preset time interval, so as to ensure the timeliness of the broadcast information.

[0049] Upon receiving an information transmission data frame, the on-board unit first verifies the first message authentication code using its built-in on-board security module. This security module is implemented using an ESAM chip and internally stores the authentication key corresponding to the roadside security module. The verification process confirms the legitimacy of the information source by comparing the locally calculated authentication code with the received first message authentication code. If the verification fails, the on-board unit rejects further processing; if the verification succeeds, it proves that the information transmission data frame originated from a legitimate roadside unit.

[0050] After successful verification, the onboard device invokes the decryption command in the onboard security module to decrypt the encrypted event information. The decryption process uses the temporary key corresponding to the encryption to restore the plaintext event information according to the domestic cryptographic algorithm. This plaintext includes the event publication timestamp, broadcast delay time, number of beeps, broadcast information type, and the plaintext content of the event information.

[0051] In some embodiments, the vehicle-mounted safety module has a pre-set system information file containing device identification information such as service provider code, service start date, service end date, license plate information, and vehicle model. After decrypting the plaintext event information, the vehicle-mounted device also needs to determine whether the current time is within the service validity period and whether the timestamp of the event's publication is greater than the timestamp of the latest record in the event publication record file. Only when both conditions are met will the plaintext event information be written to the event publication record file; otherwise, a processing failure status will be reported through the information processing status field.

[0052] After completing the above verification and decryption, the on-board equipment generates a response data frame based on the plaintext event information and the locally stored route gantry information.

[0053] In some embodiments, the gantry information is stored in a preset gantry information file, which records several gantry identifiers recently passed by the on-board equipment and their corresponding passing times. The on-board equipment reads several recent historical records from this file as the gantry information.

[0054] The response data frame includes at least the physical address information of the on-board unit, the device identity information from the system information file, the event processing result information, a second message authentication code calculated based on preset authentication data, and at least one set of gantry information recorded in chronological order. The second message authentication code is generated by the on-board safety module based on the device identity information and event information, and is used by the roadside unit to verify the legitimacy of the on-board unit. The event processing result information indicates the on-board unit's processing result of the information release data frame, including states such as successful decryption and successful writing, decryption failure, or writing failure. The on-board unit sends the generated response data frame to the roadside unit via the uplink, completing the vehicle-side response phase of this information exchange.

[0055] In some embodiments, the route gantry information stored locally by the on-board unit is recorded cyclically. Each record includes a gantry identifier and the corresponding transit time. When the on-board unit passes an ETC gantry, it automatically writes the newly generated gantry identifier and transit time into this file, and reads the most recent historical records as the route gantry information to be reported when generating a response data frame.

[0056] In other embodiments, the transit gantry information file can store up to seventeen historical records. The gantry identifier is a three-byte hexadecimal code, and the transit time is a four-byte UNIX timestamp. When generating a response data frame, the onboard equipment reads no more than three recent historical records as the reported transit gantry information.

[0057] Thus, step S102 completes the broadcast transmission of information from the roadside to the vehicle, as well as the on-board equipment's verification of the information source, decryption of event information, and generation of response data.

[0058] In step S103, the roadside unit receives the response data frame returned by the vehicle-mounted device, extracts key information from it, completes the legality verification of the vehicle-mounted device and the determination of the vehicle's driving direction, realizes two-way authentication of the vehicle-mounted device, and accurately identifies the vehicle's driving direction, providing a decision basis for whether to trigger a broadcast.

[0059] Specifically, after broadcasting the data frame, the roadside unit listens to the uplink and waits to receive a response data frame from the onboard equipment. The response data frame is organized according to a preset frame format and includes at least the onboard equipment's physical address information, the equipment's identity information from the system information file, event processing result information, a second message authentication code, and at least one set of gantry information recorded in chronological order. Upon receiving the response data frame, the roadside unit first extracts the gantry information and the second message authentication code from the frame.

[0060] The gantry information includes at least one set of gantry identifiers and their corresponding travel times. The roadside unit can reconstruct the driving trajectory of the onboard equipment based on this information.

[0061] The second authentication code is authentication data calculated by the on-board security module based on device identity information and event information. It is used by the roadside unit to verify the legitimacy of the on-board device. The roadside unit compares the received second authentication code with the authentication code calculated locally based on the information reported by the on-board device. If they match, the on-board device is determined to be a legitimate device, and the legitimacy verification is successful; if they do not match, the legitimacy verification is deemed unsuccessful.

[0062] In some embodiments, the roadside unit also refers to the event processing result information in the response data frame. This information indicates the processing result of the on-board device on the information publishing data frame, including states such as successful decryption and successful writing, decryption failure, or writing failure. The roadside unit combines the event processing result information with the second message authentication code to comprehensively determine whether the on-board device is a legitimate device and whether it has successfully received the event information, thereby more comprehensively evaluating the validity of this information interaction.

[0063] While verifying the legitimacy of the on-board equipment, the roadside unit determines the driving direction of the vehicle carrying the on-board equipment based on the information of the passing gantry. The roadside unit obtains information about the gantry it is currently located on, including the gantry identifier and its preset driving direction attribute. Then, it compares the passing gantry identifier reported by the on-board equipment with the current gantry, and determines the driving direction of the vehicle by combining the time relationship between the passing time and the current receiving time.

[0064] In some embodiments, if the gantry corresponding to the route gantry identifier reported by the on-board unit is located upstream of the current gantry, and the route time is earlier than the current reception time, it indicates that the vehicle is traveling from upstream to downstream, and is therefore determined to be a forward-moving vehicle. If the gantry corresponding to the reported route gantry identifier is located downstream of the current gantry, and the route time is earlier than the current reception time, it indicates that the vehicle is traveling from downstream to upstream, and is therefore determined to be a reverse-moving vehicle. The roadside unit accurately distinguishes the vehicle's direction of travel in this way, avoiding false broadcasts of reverse-moving vehicles.

[0065] In other embodiments, the gantry identifier is a three-byte hexadecimal code used to uniquely identify an ETC gantry; the transit time is a four-byte UNIX timestamp that records the time when the on-board equipment passes through the gantry.

[0066] In some embodiments, the gantry information reported by the on-board equipment may include multiple sets of historical records, up to a maximum of three sets. The roadside unit can use multiple sets of records for redundancy verification, such as checking whether the timestamps of each record are increasing and whether the gantry identifier is consistent with the road topology, thereby further confirming the accuracy of the direction determination and identifying any anomalies such as missed gantry readings.

[0067] At this point, step S103 completes the verification of the legality of the on-board equipment and the determination of the vehicle's driving direction.

[0068] In step S104, the roadside unit makes a comprehensive judgment based on the vehicle driving direction and the legality verification results of the on-board equipment obtained in step S103, and decides whether to trigger the on-board equipment to perform voice broadcast based on the judgment result. This establishes a precise and controllable information broadcast triggering mechanism to ensure that only vehicles that are driving in the correct direction and whose equipment is legal can receive the confirmation broadcast instruction, avoid false broadcasts to reverse vehicles or illegal equipment, and provide clear broadcast authorization for the on-board equipment.

[0069] Specifically, after completing the verification and judgment in step S103, the roadside unit obtains two core state variables: one is the legality verification result of the on-board equipment, including two states: pass or fail; the other is the vehicle's driving direction, including two states: forward vehicle or reverse vehicle. The roadside unit uses these two state variables as input parameters for comprehensive decision-making and performs calculations according to the preset decision logic.

[0070] The decision logic is set as follows: the roadside unit determines that the information exchange meets the broadcast conditions only when the vehicle is traveling in the forward direction and the on-board device passes the legality verification. If the conditions are met, the roadside unit generates a confirmation broadcast command and sends the command to the corresponding on-board device via the downlink; if either condition is not met, i.e., the vehicle is traveling in the reverse direction or the device's legality verification fails, the roadside unit does not send a confirmation broadcast command, and the broadcast process terminates.

[0071] In some embodiments, the confirmation broadcast instruction is carried out via a confirmation information publishing data frame. This data frame includes at least an event report request field and an application directory identifier field, and may optionally include a current roadside gantry identifier. The event report request field instructs the on-board equipment to perform the broadcast operation, the application directory identifier field identifies the application type to which the instruction belongs, and the current roadside gantry identifier provides the on-board equipment with current gantry information for associated storage. The confirmation information publishing data frame is sent via unicast, directed only to specific on-board equipment that meets the broadcast conditions, rather than via broadcast, to ensure accurate delivery of the broadcast instruction.

[0072] Upon receiving the confirmation broadcast command, the onboard device first parses the command content and identifies the indication in the event report request field. Then, the onboard device reads the latest written event information plaintext from the event release log file of the onboard safety module. After reading the event information plaintext, the onboard device executes voice broadcast according to the broadcast parameters in the event information.

[0073] The broadcast parameters include broadcast delay time, number of beeps, and broadcast information type. The in-vehicle device first waits for the broadcast delay time, then sounds a beep according to the number of beeps after the delay. Next, it converts the event information into speech based on the broadcast information type. If the broadcast information type is in encoded mode, the in-vehicle device converts the encoded information in the event information into the corresponding fixed template speech; if the broadcast information type is in transparent transmission mode, the in-vehicle device directly converts the GB2312 encoded plaintext in the event information into speech.

[0074] In some embodiments, the event publishing log file adopts a circular fixed-length recording method, which overwrites the oldest historical record each time a new event is written. Therefore, the latest written record is always stored at the beginning of the file, which facilitates fast reading.

[0075] In some embodiments, the in-vehicle device follows preset conflict handling rules when performing voice broadcasts. If the in-vehicle device is in a delayed broadcast waiting state and receives new event information, after the new event information is successfully verified and decrypted, the in-vehicle device cancels the previously unstarted delayed broadcast and only retains the broadcast task corresponding to the new event information. If the in-vehicle device receives new event information while broadcasting, the in-vehicle device does not interrupt the current broadcast, and the new event information is not executed during the current broadcast to avoid continuous interference to the driver.

[0076] In some embodiments, if the broadcast instruction includes the current roadside gantry identifier, the on-board equipment will associate and store the gantry identifier with the locally recorded route gantry information after the broadcast is completed. This will enrich the recorded content of the route gantry information file and provide more complete data support for subsequent direction determination.

[0077] At this point, step S104 completes the entire closed loop from comprehensive decision-making to voice broadcast.

[0078] The present invention will now be described with reference to a specific embodiment: This embodiment will elaborate on the complete technical solution of the DSRC-based highway voice broadcasting method proposed in this invention, specifically from the definitions of information broadcast data frames, information broadcast response data frames, and confirmation information broadcast data frames; the ESAM file structure; the addition of the ESAM application instruction set; the PSAM file structure; the addition of the PSAM application instruction set; the modification of the PC-RSU interface protocol; and the broadcasting process. The above constitutes the specific implementation details of the technical solution of this invention at the data frame format, security module instructions, and system interface levels. The following is the specific technical solution followed in this embodiment: 1. Definition of Information Broadcast Data Frame The definition of the information broadcast data frame is as follows: 1) The encrypted message for information release is calculated from the plaintext message to be released using PSAM; 2) The tamper-resistant MAC of the data frame is used to identify unauthorized roadside equipment and prevent the publication of data frames with forged information. The tamper-resistant MAC is calculated from the broadcast frame Information Delivery using PSAM. 3) In the data frame, InformationDelivery is the encrypted message for information dissemination, and its corresponding plaintext length is no more than 94 bytes.

[0079] 4) Information Delivery plaintext data format: The definition of the information broadcast data frame is as follows: 1) The encrypted message for information release is calculated from the plaintext message to be released using PSAM; 2) The tamper-resistant MAC of the data frame is used to identify unauthorized roadside equipment and prevent the publication of data frames with forged information. The tamper-resistant MAC is calculated from the broadcast frame Information Delivery using PSAM. 3) In the data frame, InformationDelivery is the encrypted message for information dissemination, and its corresponding plaintext length is no more than 94 bytes.

[0080] 4) Information Delivery plaintext data format: 2. Definition of Information Broadcast Response Data Frame The definition of the information broadcast response data frame is as follows: Path information data format The Information ret message indicates whether the information was successfully written to the DF01 / EF01 file. A successful decryption and correct writing result is indicated by 0x00, while other failures are indicated by 0x01. 3. Confirm the definition of the information release data frame. The data frame definition for confirming message release is as follows: 4. ESAM file structure ESAM file structure definition as follows Figure 2 As shown.

[0081] 4.1 System Information File (MF / EF01) 4.2 Event Release Log Files (DF01 / EF01) 4.3 Information document of the gantry passing through (DF01 / EF02) 5. Added ESAM application instruction set 5.1 INTERNAL AUTHENTICATION command 1) Definition and Scope This command applies to OBE-IC and OBE-V2X applications.

[0082] This command provides the ability to authenticate data using a random number sent by the interface device and the relevant key stored within the device itself.

[0083] 2) Command message 3) Command message data field The command report data field contains application-specific authentication data.

[0084] 4) Response message data field The response message data contains relevant authentication data.

[0085] 5) Response message status code 5.2 INFO RELEASE command 1) Definition and Scope This command is applicable to OBE-V2X applications and uses a symmetric domestic cryptographic algorithm. After receiving the information delivery broadcast data frame, the hardware device uses this command to complete the event publication for the OBE-V2X application based on the Information Delivery and tamper-resistant MAC in the information delivery broadcast data frame.

[0086] The hardware device uses the designated keys P1 and P2 (AK) to calculate the authentication code of the encrypted information release message in the information release broadcast data frame. After successful verification, ESAM automatically uses the corresponding EK key to decrypt the data.

[0087] After successful data verification and decryption, the OBE-V2X application checks whether the time of this broadcast (4 bytes UNIXTIME) is between the service start date (bytes 19-22) and service end date (bytes 23-26) in the OBE-V2X application system information file (MF / EF01). If it is between the two, it checks whether the event publication timestamp UNIXtime is greater than the event publication timestamp of the latest record in the event publication record file (DF01 / EF01). If it is greater and there are no other errors, the broadcast information is written to the DF01 / EF01 file, and the hardware device takes the latest record for voice broadcast; otherwise, an error is returned.

[0088] 2) Command message 3) Command message data field The command message data field consists of a 4-byte authentication code and ciphertext for the event information. 4) Response message data field The response message data field does not exist.

[0089] 5) Response message status code 6. PSAM file structure When implementing vehicle-road cooperative applications using OBE-V2X applications with multi-logic-channel ESAM, a dedicated PSAM card for vehicle-road cooperative applications needs to be added to the roadside unit (RSU).

[0090] The vehicle-road cooperative PSAM card is used for vehicle-road cooperative applications such as encrypted broadcast information.

[0091] The file structure is defined as follows: Figure 3 As shown.

[0092] 7. Added ESAM application instruction set 7.1 DELIVERYKEY command This command distributes the specified key to a temporary key register. It only supports distributing keys and does not generate a process key. The distributed key inherits the attributes of the original key.

[0093] command format Response format: 7.2 CIPHER DATA command This command performs the operation of encrypting the input information or calculating the MAC using the corresponding key.

[0094] The execution of this command requires the DELIVERYKEY command as a prerequisite, and the command preceding this command should be the DELIVERYKEY command.

[0095] After calculating the 4-byte authentication code, it is used in the INFO RELEASE command.

[0096] Command format: Response format: 8. PC-RSU interface protocol modification 8.1 Information Release Control Instructions The information dissemination control command enables the RSU to enter or stop the information dissemination broadcasting operation and sets the operating parameters, as detailed below: 8.2 Continue Trading Order The transaction continuation instruction is responded to, and the roadside unit is informed to continue normal electronic toll collection transactions, as described below: 9. Broadcasting Process The voice broadcasting device should only broadcast the content of the most recent roadside unit event. If the voice broadcasting device is in a delayed broadcasting state and receives a new event from a roadside unit, after successful decryption and verification, it should only broadcast the most recent event and cancel the previously incomplete delayed broadcast. During the broadcasting process, if a new event is received, the broadcasting content should not be interrupted, and the new broadcast content should not be broadcast.

[0097] 9.1 Broadcasting Process of Voice Broadcasting Equipment 1) The RSU and the voice broadcasting equipment complete the broadcast content delivery through information release broadcast data frame commands. The response flag is set to 02H. The subsequent normal process timing diagram is as follows. Figure 4 As shown.

[0098] 2) RSU determines the content to send based on C1's EventReleaseType: 1) If EventReleaseType is 03H, the RSU sends a confirmation information release data frame instruction to instruct the voice broadcasting device to release information.

[0099] 2) If EventReleaseType is any other value, RSU will not send any data frames. The corresponding exception flow timing diagram is as follows: Figure 5 As shown.

[0100] In summary, the DSRC-based highway voice broadcasting method and system provided by this invention, through a dedicated on-board unit independent of ETC transaction function, breaks through the traditional limitation of binding information services and toll collection functions, enabling users who have not installed ETC or do not wish to use ETC transaction function to receive official traffic information, thus significantly expanding the service coverage.

[0101] In terms of security mechanisms, this invention establishes a complete two-way authentication link between the roadside unit and the vehicle-mounted unit. The roadside unit encrypts event information and generates a first message authentication code via a PSAM card, which is used by the vehicle-mounted equipment to verify the authenticity of the information source. The vehicle-mounted equipment, in turn, uses a second message authentication code for the roadside unit to verify the legitimacy of the equipment. Combined with dynamic key distribution technology, this ensures that the temporary key used in each communication is different, effectively preventing attacks that forge information and meeting the requirements of critical infrastructure for autonomy, controllability, and data security.

[0102] Regarding the accuracy of the broadcast, this invention achieves direction determination through the gantry information reported by the on-board equipment. The roadside unit accurately distinguishes between forward and reverse vehicles based on the topological relationship of the gantry identifiers and the temporal relationship of the transit time, sending confirmation broadcast commands only to forward vehicles. This fundamentally solves the problem of false alarms for oncoming lanes and significantly improves user experience and system reliability.

[0103] Furthermore, this invention, while fully utilizing existing ETC gantry infrastructure, achieves alternating transmission of information dissemination data frames and transaction broadcast frames, and identifies and differentiates non-broadcasting devices to ensure uninterrupted operation of toll collection services. This compatibility design protects existing investments and provides a feasible path for smooth system upgrades, demonstrating significant economic benefits and promotional value.

[0104] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0105] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0106] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0107] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for highway voice broadcasting based on DSRC, characterized in that, The method is performed by a roadside unit and includes the following steps: The system acquires the event information to be broadcast and sends it to the roadside safety module, which then encrypts the event information, generates encrypted event information, generates a first message authentication code based on the encrypted event information, and returns the result. The broadcast includes the encrypted event information, the first message authentication code, and the response identifier in an information release data frame. After receiving the information release data frame, the vehicle-mounted device verifies the first message authentication code using the vehicle-mounted security module. After successful verification, the encrypted event information is decrypted to obtain the plaintext event information. Based on the plaintext event information and the locally stored route gantry information, the vehicle-mounted device generates a response data frame containing the route gantry information and the corresponding second message authentication code. The system receives the response data frame, extracts the route gantry information and the second message authentication code from the response data frame, verifies the second message authentication code to obtain the legality verification result of the vehicle-mounted device, and simultaneously determines the driving direction of the vehicle where the vehicle-mounted device is located based on the route gantry information. Based on the driving direction and the legality verification result, a comprehensive judgment is made. If the vehicle's driving direction is positive and the legality verification result is passed, the roadside unit sends a confirmation broadcast command to the vehicle-mounted device; otherwise, the confirmation broadcast command is not sent. In response to the confirmation broadcast command, the vehicle-mounted device reads the latest plaintext event information from the vehicle safety module and executes voice broadcast.

2. The highway voice broadcasting method based on DSRC according to claim 1, characterized in that, The roadside safety module encrypts the event information and generates the first message authentication code, specifically including: Based on the event publication timestamp, delayed broadcast time, number of beeps, broadcast information type, and plaintext of the event information, the key distribution instruction in the roadside safety module is invoked to distribute the target key and obtain a temporary key. The event information is encrypted using the temporary key to generate the encrypted event information, and the first message authentication code is generated based on the encrypted event information. After the vehicle-mounted safety module verifies the first message authentication code, it decrypts the encrypted event information and writes the decrypted event information in plaintext into the event publication record file in the vehicle-mounted safety module when the preset writing conditions are met, for subsequent broadcasting and retrieval.

3. The highway voice broadcasting method based on DSRC according to claim 1, characterized in that, Determining the direction of travel of the vehicle containing the on-board equipment based on the gantry information specifically includes: Extract at least one set of transit gantry identifiers and corresponding transit times from the response data frame; Based on the preset topological association between the passing gantry identifier and the current roadside unit corresponding gantry, the driving direction of the road segment where the passing gantry identifier corresponds to the gantry is located is determined, and combined with the time sequence relationship between the passing time and the current receiving time, the vehicle is determined to be a forward vehicle or a reverse vehicle. When the determination result is the reverse vehicle, the confirmation broadcast command is prohibited from being sent to the vehicle-mounted equipment to avoid false broadcasts of the reverse vehicle.

4. The highway voice broadcasting method based on DSRC according to claim 2, characterized in that, The preset write conditions include: Based on the system information file in the vehicle safety module, determine whether the current time is between the service start date and the service end date; Determine whether the timestamp of this event's publication is greater than the timestamp of the latest record in the event publication log file; The event information will be written in plaintext to the event publication record file only if the current time is within the service period and the publication timestamp of this event is greater than the timestamp of the latest record; Otherwise, the processing failure status is reported in the information processing status field of the response data frame.

5. The highway voice broadcasting method based on DSRC according to claim 1, characterized in that, The broadcast includes an information publishing data frame containing the encrypted event information, the first message authentication code, and the response identifier, specifically including: While broadcasting electronic toll collection transactions, the roadside unit intersperses the information release data frames with the transaction broadcast frames. The information release data frame includes a roadside unit identifier, a real-time timestamp, a configuration file identifier, an application identifier, the response identifier, the encrypted event information, and the first message authentication code; The roadside unit periodically sends the information release data frame between the information release start time and the information release end time, and updates the encrypted event information and the first message authentication code according to a preset time interval.

6. The highway voice broadcasting method based on DSRC according to claim 1, characterized in that, The response identifier is used to indicate the response strategy of the on-board equipment, and the response strategy includes at least one of the following: Do not reply to the response data frame; The response data frame must be replied to; And the on-board equipment can autonomously decide whether to reply with the response data frame based on its own status; Specifically, when the response identifier indicates that the vehicle-mounted device must reply to the response data frame, or when the vehicle-mounted device decides to reply to the response data frame autonomously, the vehicle-mounted device generates and sends the response data frame after completing the verification of the first message authentication code and the decryption of the encrypted event information.

7. The highway voice broadcasting method based on DSRC according to claim 1, characterized in that, The response data frame includes at least the following: Physical address information of the vehicle-mounted equipment; Device identification information in the system information file; Event processing result information is used to indicate the processing result of the vehicle-mounted device on the information release data frame. The processing result includes successful decryption and successful writing, decryption failure, or writing failure. The second message authentication code is calculated based on preset authentication data; And at least one set of gantry information recorded in chronological order; The roadside unit determines whether the vehicle-mounted device is a legitimate device and whether it has successfully received the event information based on the event processing result information and the second message authentication code.

8. The highway voice broadcasting method based on DSRC according to claim 1, characterized in that, The confirmation broadcast instruction includes an event report request field and an application directory identifier field, and may include the current roadside gantry identifier; After receiving the confirmation broadcast instruction, the vehicle-mounted device triggers the reading of the latest written plaintext event information from the vehicle-mounted safety module according to the event report request field, and if the current roadside gantry identifier exists, it associates and stores the current roadside gantry identifier with the locally recorded route gantry information.

9. The highway voice broadcasting method based on DSRC according to claim 1, characterized in that, The route gantry information stored locally by the on-board equipment is saved in a preset route gantry information file. The route gantry information file includes physical address information for locking the on-board equipment of this vehicle, total number of records, and multiple historical records. Each of the aforementioned historical records must include at least the gantry identifier and the corresponding transit time; When passing through a gantry, the on-board equipment writes the newly generated gantry identifier and the passing time into the passing gantry information file, and when generating the response data frame, it reads no more than three recent historical records from the passing gantry information file as the passing gantry information.

10. A highway voice broadcasting system based on DSRC, characterized in that, The system includes: Lane controllers, roadside units, and onboard equipment; The roadside unit has a built-in roadside safety module, and the vehicle-mounted equipment has a built-in vehicle-mounted safety module; The lane controller, the roadside unit, and the on-board equipment cooperate with each other to execute the DSRC-based highway voice broadcasting method as described in any one of claims 1 to 9.

Images