A low-power radio frequency receiving method and device based on bidirectional authentication and a medium

Abstract

A low-power radio frequency (RF) receiving method, apparatus, and medium based on two-way authentication are disclosed, relating to the field of wireless communication. In this method, the system switches from a low-power mode to a working mode; if a wake-up challenge code conforming to a preset format is received within a first preset time, the current communication is determined to be in two-way authentication mode, and a random number is extracted; if no wake-up challenge code conforming to the preset format is received within the first preset time, the current communication is determined to be in one-way compatibility mode; after determining that the current communication is in two-way authentication mode, a response code is generated through encryption using a preset key and a random number, and the response code is sent to the transmitter to complete the two-way authentication handshake; after completing the two-way authentication handshake, or after determining that the current communication is in one-way compatibility mode, RF signals are continuously received within a second preset time to obtain control command frames; corresponding control operations are executed according to the control command frames. Implementing this application improves the security of RF communication interaction.

Description

Technical Field

[0001] This application relates to the field of wireless communication, specifically to a low-power radio frequency receiving method, apparatus, and medium based on two-way authentication. Background Technology

[0002] With the rapid development of the automotive aftermarket, intelligent products such as remote start and mobile phone keys are becoming increasingly popular. While adding new functions, these products typically need to be compatible with the original vehicle's 433MHz or 315MHz remote control to maintain user comfort. To respond to remote control commands at any time, existing conventional receiving solutions require the vehicle's RF receiving circuit to remain continuously operational. This results in a static operating current typically as high as 8-12mA, making independent battery power impossible. It must be directly connected to the vehicle battery, increasing installation complexity and cost, and also posing a risk of prolonged battery depletion.

[0003] Currently, to address the high power consumption issue, the industry commonly employs intermittent wake-up monitoring (ERR) technology. This technology significantly reduces average power consumption to the hundreds of microamps level by briefly waking the receiver for a few milliseconds at periodic intervals of hundreds of milliseconds to listen for radio frequency signals, making it possible to power the device with dry cell batteries or button batteries. However, this type of low-power solution based on unidirectional reception has its problems. In terms of security, because it can only receive fixed code or traditional rolling code signals in one direction, it is highly vulnerable to capture and replay attacks, resulting in low security. Summary of the Invention

[0004] This application provides a low-power radio frequency receiving method, apparatus, and medium based on two-way authentication, which improves the security of radio frequency communication interaction.

[0005] The first aspect of this application provides a low-power radio frequency (RF) receiving method based on two-way authentication. The method includes: periodically waking up in a low-power mode and detecting RF signals within a preset listening period; switching from the low-power mode to a working mode when the RF signal meets preset legality requirements and the RF signal strength exceeds a preset strength threshold; receiving a wake-up challenge code containing a random number within a first preset time period; determining that the current communication is a two-way authentication mode and extracting the random number if a wake-up challenge code conforming to a preset format is received within the first preset time period; determining that the current communication is a one-way compatibility mode if no wake-up challenge code conforming to the preset format is received within the first preset time period; generating a response code through encryption using a preset key and the random number, and sending the response code to the transmitter to complete a two-way authentication handshake; continuously receiving RF signals within a second preset time period after completing the two-way authentication handshake or determining that the current communication is a one-way compatibility mode to obtain control command frames; performing corresponding control operations according to the control command frames, and returning to the low-power mode after the control operations are completed.

[0006] By adopting the above technical solution and employing a low-power intermittent listening mode, the vehicle receiver remains in deep sleep most of the time, only being periodically woken up during a preset listening period to detect radio frequency signals, effectively reducing the average power consumption of the receiver. Only when the detected radio frequency signal meets the validity requirements and the signal strength exceeds a threshold will the receiver switch to operating mode to prepare for data reception. This avoids frequent false wake-ups by illegal signals, further saving energy. After confirming the two-way authentication mode, the receiver uses a preset key and a received random number for encryption calculation, generating a response code to send back to the transmitter, completing the two-way handshake authentication and improving communication security. In one-way compatibility mode, the receiver can also adapt to traditional fixed-code transmitters, ensuring good compatibility. Finally, it executes corresponding control operations according to the received control command frame and promptly returns to low-power mode, minimizing energy consumption while reliably completing the remote control function. This technical solution addresses the poor security of existing one-way receiving schemes by introducing a two-way authentication mechanism based on random numbers and pre-set keys, significantly enhancing its resistance to replay attacks. Through a two-way communication design, it enables status interaction between the remote controller and the vehicle, expanding the system's functionality. A dual-mode compatibility mechanism ensures backward compatibility with traditional one-way remote controllers, allowing seamless upgrades to a more secure two-way protocol. Simultaneously, periodic wake-up monitoring in a low-power mode drastically reduces the receiver's average power consumption to the microampere level, enabling battery power. This solution achieves high security, richer functionality, and compatibility with traditional devices while maintaining low power consumption.

[0007] Optionally, receiving a wake-up challenge code containing a random number within a first preset time period specifically includes: starting a challenge code receiving timer and demodulating and decoding the received radio frequency signal to obtain a decoded data frame; detecting whether the decoded data frame contains a preset challenge code frame header identifier; if it is determined that the decoded data frame contains the preset challenge code frame header identifier, then parsing the payload field of the data frame and extracting the random number and transmitter identifier from the payload field; performing a frame verification operation on the data frame, and if the verification passes, determining that a wake-up challenge code conforming to the preset format has been received, and temporarily storing the random number and the transmitter identifier in the receiving buffer; if the challenge code receiving timer times out or the frame verification fails, determining that a wake-up challenge code conforming to the preset format has not been received.

[0008] By adopting the above technical solution, during the process of receiving wake-up challenge codes, the receiving window is precisely controlled by starting a challenge code receiving timer, preventing the receiver from occupying the RF channel for an extended period and affecting the communication of other nodes. By demodulating and decoding the received RF signal and detecting the format characteristics of the decoded data frame, illegal wake-up challenge codes are identified and filtered out early, reducing unnecessary energy consumption. By parsing the payload field of a legitimate wake-up challenge code, random numbers and transmitter identifiers can be accurately extracted, providing necessary key materials for subsequent two-way authentication. Finally, by performing verification operations on the challenge code frame, its integrity and validity are further confirmed, preventing the receiver from being misled by incorrect or forged challenge codes and improving system robustness. Simultaneously, a challenge code receiving timeout mechanism is introduced to prevent the receiver from remaining in a high-power operating mode for an extended period while waiting for a challenge code.

[0009] Optionally, the step of executing the corresponding control operation according to the control instruction frame specifically includes: extracting a main instruction frame and an extended instruction frame from the control instruction frame, wherein the main instruction frame carries a main control instruction, including unlocking the door and starting the vehicle, and the extended instruction frame carries an auxiliary control instruction, including adjusting the air conditioning temperature and opening the windows; decoding the main instruction frame to obtain the operation type and operation parameters of the main control instruction; determining the execution result of the main control instruction based on the operation type, and executing or rejecting the main control instruction based on the execution result; after executing or rejecting the main control instruction, determining the execution result of the extended instruction frame, and executing or rejecting the auxiliary control instruction based on the execution result.

[0010] By employing the above technical solution, main command frames and extended command frames are extracted from control command frames and decoded and processed separately. This allows for flexible combinations of multiple control functions on a single radio frequency channel, improving communication efficiency and control flexibility. Critical control commands such as door unlocking and vehicle start are classified as main control commands, carried by main command frames, and prioritized for reception and processing, improving the system's real-time response capability to core control functions. Auxiliary commands such as air conditioning control and window control are classified as extended commands, carried by extended command frames. This allows for dynamic adjustment of the type and quantity of extended commands according to actual needs without affecting the main control function, increasing control flexibility. Determining and executing different control strategies for main control commands and extended commands effectively avoids conflicts and interference between commands, improving control safety and reliability.

[0011] Optionally, determining the execution result of the main control instruction based on the operation type specifically includes: determining whether the transmitting end has the authority to execute the main control instruction according to the operation type of the main control instruction; if the transmitting end has the authority to execute the main control instruction, then determining to execute the main control instruction and generating an execution result status code; if the transmitting end does not have the authority to execute the main control instruction, then determining to refuse to execute the main control instruction and generating an authority exception status code.

[0012] By adopting the above technical solution and introducing a permission judgment mechanism based on command operation type, different transmitters are granted execution permissions for different types of control commands. This effectively prevents unauthorized transmitters from illegally controlling the vehicle, improving system security. Based on permission judgments, different command execution result status codes are generated and promptly fed back to the transmitter. This helps the transmitter monitor command execution in real time, determine the vehicle's current status, and provide a basis for subsequent human-machine interaction and control decisions. Simultaneously, unauthorized commands that are refused execution are recorded as abnormal events, providing reliable data support for system security auditing and fault diagnosis. This fine-grained permission management and status feedback mechanism ensures system security and controllability while also improving system transparency and diagnostics, facilitating users and administrators to promptly identify and address potential security risks.

[0013] Optionally, after periodically waking up in low-power mode and detecting the radio frequency signal, the method further includes: performing preliminary demodulation on the radio frequency signal to listen for a dynamic wake-up preamble; generating a desired preamble using a preset one-way hash function based on authentication parameters used in historical successful authentication interactions, wherein the authentication parameters are random numbers sent by the transmitter or response codes generated by the vehicle receiver in the historical successful authentication interactions; comparing the dynamic wake-up preamble with the desired preamble; if the match is successful, determining that the radio frequency signal meets the preset legality requirements; if the match fails or the dynamic wake-up preamble is not detected, determining that the radio frequency signal is an invalid wake-up signal and maintaining the low-power mode.

[0014] By adopting the above technical solution and introducing a dynamic wake-up preamble mechanism, the illegal transmitter can be effectively prevented from accidentally waking up the receiver through replay attacks, thus avoiding malicious power consumption of the receiver. After the RF signal is woken up, it is initially demodulated, and any potential dynamic wake-up preamble is extracted. Before entering the formal wake-up challenge authentication process, the legitimacy of the RF signal source is preliminarily screened, significantly reducing unnecessary energy consumption and time overhead at the receiver. Using random numbers or response codes generated during historical authentication processes as seed parameters, a one-time dynamic expected preamble is generated through a one-way hash function, avoiding the risk of the preamble being cracked through long-term use. Through rigorous preamble matching and comparison, illegal wake-up signals that do not meet expectations are identified, and subsequent wake-up processes are promptly blocked, keeping the receiver in a low-power mode and maximizing the conservation of limited battery resources.

[0015] Optionally, after determining that the current communication is in a one-way compatible mode, the method further includes: starting a compatible mode wake-up counter and incrementing the compatible mode wake-up counter each time it is determined to be in a one-way compatible mode; determining whether the count value of the compatible mode wake-up counter reaches a preset count threshold; if the count value does not reach the count threshold, then continuously receiving radio frequency signals; if the count value reaches the count threshold, then entering a temporary high alert state for a preset lock time, in which the control operation is prohibited and an abnormal event log is recorded; if it is determined that the preset lock time has ended, then clearing the compatible mode wake-up counter and restoring the normal working process.

[0016] By adopting the above technical solution, a compatibility mode wake-up counter and a temporary high-alert state mechanism were designed to address the wake-up characteristics of the receiver in one-way compatibility mode. This effectively counters potential wake-up attacks and improves the security and reliability of the receiver. By accumulating the number of consecutive wake-ups of the receiver in one-way mode, a threshold can be determined to promptly detect suspicious high-frequency false wake-ups. Once an abnormal wake-up count is confirmed, a temporary high-alert state is entered, refusing to respond to any wake-up signals for a period of time and prohibiting the execution of control commands, thus isolating the receiver from potential attackers and preventing serious consequences such as vehicle loss of control. Abnormal wake-up events are logged, assisting users and system administrators in post-event analysis and auditing, providing data support for optimizing system configuration and improving defense strategies. After a preset lockout time is reached, the system automatically returns to normal operation, avoiding prolonged service interruptions and impacting user experience.

[0017] Optionally, after continuously receiving radio frequency signals for a second preset time period to obtain control command frames, the method further includes: counting the actual number of control command frames received and comparing the number of control command frames with a preset total number of command frames; if the number of control command frames is lower than the preset total number of command frames, sending a retransmission request to the transmitter, the retransmission request containing the sequence number of the unreceived command frames; if a new received command frame is received by the transmitter within a preset retransmission waiting time, concatenating the new received command frame with the original command frame sequence to obtain a concatenated command frame, and using the concatenated command frame as a new control command frame; if the number of command frames is still lower than the expected total number of command frames after the number of retransmissions reaches a preset retransmission threshold, sending a reception failure notification to the transmitter.

[0018] By employing the above technical solutions, statistical analysis and comparison of the number of received control command frames can promptly detect command frame loss caused by channel interference, transmitter malfunctions, etc., preventing the receiver from making erroneous control decisions based on incomplete command information and improving control reliability. By proactively sending a retransmission request to the transmitter after confirming a missing command frame and explicitly notifying it of the missing frame's sequence number, blind retransmissions by the transmitter can be reduced, improving retransmission efficiency. Utilizing a preset retransmission waiting time prevents the receiver from occupying the receive buffer for extended periods, thus avoiding impacting the reception of subsequent new commands. By aligning the sequence numbers of the retransmitted new command frames with the original command frames and concatenating them, a complete and continuous command sequence can be seamlessly recovered, ensuring control consistency. However, if a complete command frame cannot be obtained after the number of retransmissions exceeds a certain threshold, a timely reception failure notification is sent to the transmitter to avoid unnecessary channel resource consumption and trigger emergency measures at the transmitter, minimizing losses.

[0019] In a second aspect, embodiments of this application provide a low-power radio frequency receiving device based on two-way authentication. The low-power radio frequency receiving device based on two-way authentication includes: one or more processors and a memory; the memory is coupled to the one or more processors and is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the low-power radio frequency receiving device based on two-way authentication to perform the method described in the first aspect and any possible implementation thereof.

[0020] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a low-power radio frequency receiving device based on two-way authentication, cause the low-power radio frequency receiving device based on two-way authentication to perform the method described in the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a low-power radio frequency receiving device based on two-way authentication, cause the low-power radio frequency receiving device based on two-way authentication to perform the method described in the first aspect and any possible implementation thereof.

[0022] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages:

[0023] 1. This technical solution introduces a two-way authentication mechanism in low-power mode. It utilizes random numbers, preset keys, and encryption operations to generate response codes, completing a challenge-response two-way authentication handshake. This effectively prevents replay attacks and illegal signal interference, significantly improving communication security. Simultaneously, by matching and comparing the dynamic wake-up preamble with historical authentication parameters, the accuracy of signal legitimacy detection is further improved, ensuring that the system only responds to trusted signals.

[0024] 2. This technical solution utilizes a two-way communication mechanism to support the parsing of main control commands and extended control commands from radio frequency signals, enabling diverse vehicle control operations such as door unlocking, vehicle start-up, air conditioning adjustment, and window control. Furthermore, through a command frame statistics and retransmission mechanism, the integrity and reliability of control commands are ensured, preventing operational failures due to signal loss or interference, thereby improving user experience and system stability.

[0025] 3. This technical solution employs periodic wake-up monitoring technology, reducing the average power consumption of the receiver to the microampere level, supporting battery power, and extending the device's battery life. Simultaneously, through a dynamic switching design between one-way compatibility mode and two-way authentication mode, backward compatibility with traditional one-way remote controls is ensured. Furthermore, abnormal event logging and a high-alert status enhance the defense against illegal signals, providing flexible support for system security and compatibility. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a low-power radio frequency receiving method based on two-way authentication disclosed in an embodiment of this application;

[0027] Figure 2 This is another schematic diagram of a low-power radio frequency receiving method based on two-way authentication disclosed in an embodiment of this application;

[0028] Figure 3 This is a schematic diagram of a low-power radio frequency receiver based on two-way authentication provided in an embodiment of this application.

[0029] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0030] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0031] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0032] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple system devices refer to two or more system devices, and multiple screen terminals refer to two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0033] This application provides a low-power radio frequency receiving method based on two-way authentication, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a low-power radio frequency (RF) receiving method based on two-way authentication, provided in an embodiment of this application. The method is applied to a device, specifically a vehicle receiver. The vehicle receiver can execute a program for a low-power RF receiving method based on two-way authentication. The method includes steps S101 to S107, as follows:

[0034] Step S101: Within a preset listening period, periodically wake up in low power mode and perform radio frequency signal detection. When the radio frequency signal meets the preset legality requirements and the radio frequency signal strength exceeds the preset strength threshold, switch from low power mode to working mode.

[0035] In step S101, the preset listening period refers to a pre-set time cycle for the system, during which the system performs intermittent wake-up detection. Low-power mode indicates a standby state where the system conserves power, with most circuits in hibernation or off. Radio frequency (RF) signal refers to a radio frequency signal emitted by a transmitting device, such as a smart key. Preset legitimacy requirements represent a set of predetermined rules for preliminary screening of RF signals, such as the preamble or frame format of the signal must conform to regulations. Preset strength threshold refers to a signal power threshold set to filter out invalid signals that are too far away or too weak. Operating mode indicates that the system is fully activated, with the processor and related RF circuits operating at full power for data processing and communication.

[0036] Specifically, the timer inside the vehicle receiver briefly wakes up the RF receiving front-end circuitry according to a preset listening period, such as every 100 milliseconds. Within this brief wake-up window, the vehicle receiver performs RF signal detection, scanning for the presence of RF signals in a specific frequency band. If an RF signal is detected, the vehicle receiver first determines whether the signal strength exceeds a preset strength threshold, such as -85dBm. If the signal strength meets the requirement, the vehicle receiver further analyzes whether the RF signal meets preset validity requirements. Only when both the RF signal strength and validity requirements are met does the vehicle receiver consider this a valid wake-up attempt, immediately activating the internal main processor and the complete communication protocol stack, switching from low-power mode to operating mode to prepare for subsequent data reception. If no signal is detected within the wake-up window, or if the signal does not meet any condition, the vehicle receiver immediately returns to low-power mode, waiting for the next listening period.

[0037] In one possible implementation, after periodically waking up in low-power mode and detecting the radio frequency signal, the method further includes: performing preliminary demodulation of the radio frequency signal to listen for a dynamic wake-up preamble; generating a desired preamble based on the authentication parameters used in historical successful authentication interactions using a preset one-way hash function, where the authentication parameters are random numbers sent by the transmitter or response codes generated by the vehicle receiver in historical successful authentication interactions; comparing the dynamic wake-up preamble with the desired preamble; if the match is successful, determining that the radio frequency signal meets the preset legality requirements; if the match fails or the dynamic wake-up preamble is not detected, determining that the radio frequency signal is an invalid wake-up signal and maintaining the low-power mode.

[0038] Specifically, after the vehicle receiver completes periodic wake-up and detects that the radio frequency signal strength exceeds a preset strength threshold, in order to further distinguish between valid signals sent by legitimate transmitters and possible interference or malicious attack signals, the vehicle receiver needs to execute a signal legitimacy verification mechanism based on a dynamic wake-up preamble. The core idea of ​​this mechanism is to use authentication parameters that have been verified in historical successful authentication interactions to generate an expected preamble through a preset one-way hash function, and then match and compare it with the dynamic wake-up preamble demodulated in the currently received radio frequency signal. This allows for the rapid filtering out of illegal or invalid wake-up signals before formally entering the challenge code reception and authentication handshake process, reducing the power consumption overhead caused by the system responding to invalid signals.

[0039] When the signal strength detection circuit at the vehicle receiver determines that the received signal strength indication value exceeds the preset strength threshold, the main controller does not immediately enter the full operating mode. Instead, it first instructs the RF receiving module to perform preliminary demodulation on the currently received RF signal. This preliminary demodulation operation differs from the subsequent demodulation processing of the complete data frame; its purpose is solely to extract the preamble sequence from the beginning of the RF signal.

[0040] Specifically, after completing carrier synchronization and clock recovery, the RF receiving module begins sampling the bit stream of the received signal. The vehicle receiver predefines the structure format of the dynamic wake-up preamble, which typically includes a fixed-length synchronization field and a dynamic identifier field with variable content. During demodulation, the main controller first checks whether the synchronization field conforms to the preset pattern. If the synchronization field matches successfully, it continues to extract the content of the following dynamic identifier field and temporarily stores this content as the dynamic wake-up preamble in the receiving buffer.

[0041] For example, suppose the total length of the dynamic wake-up preamble is 32 bits, where the first 16 bits are a fixed synchronization field (e.g., 0xAA55) and the last 16 bits are a dynamic identification field. When the RF receiver module detects a continuous 0xAA55 bit sequence during demodulation, it considers the synchronization field to be successfully matched and then extracts the following 16 bits as the dynamic wake-up preamble to be verified.

[0042] After detecting the dynamic wake-up preamble, the vehicle receiver needs to generate a desired preamble for comparison with the dynamic wake-up preamble. The generation of the desired preamble depends on the authentication parameters used in previous successful authentication interactions. The vehicle receiver's state memory maintains a historical authentication parameter record table, which stores the authentication parameters from the most recent successful two-way authentication handshakes. The authentication parameters specifically include two categories: one is the random number sent by the transmitter in previous successful authentication interactions, i.e., the random value carried by the transmitter in the wake-up challenge code; the other is the response code generated by the vehicle receiver itself, i.e., the response code content sent by the vehicle receiver to the transmitter during the two-way authentication handshake.

[0043] The main controller reads the authentication parameters corresponding to the most recent successful authentication interaction from the historical authentication parameter record table. Assume this authentication parameter is the random number R sent by the transmitter in the previous authentication interaction. prev Its value is 0x3A7F29B1. The main controller will use this random number R prev As input, a preset one-way hash function is invoked for computation. The preset one-way hash function can be SHA-256, MD5, or other hash algorithms that meet the requirements of one-wayness and collision resistance. To match the length requirement of the dynamic wake-up preamble, the main controller truncates the hash operation result, retaining only the lower 16 bits as the expected preamble.

[0044] Continuing with the example above, if the lower 16 bits of the 256-bit result obtained after performing a SHA-256 hash operation on the random number 0x3A7F29B1 are 0xC4E7, then 0xC4E7 is the expected preamble generated by the vehicle receiver.

[0045] It is important to note that when a legitimate transmitter sends an RF signal, it will also generate a dynamic wake-up preamble based on the same historical authentication parameters and the same preset one-way hash function. Since both the vehicle receiver and the legitimate transmitter have saved the same authentication parameters after their last successful authentication interaction, and both parties have pre-agreed to use the same hash function and truncation rules, the dynamic wake-up preamble generated by the legitimate transmitter should be completely consistent with the expected preamble generated by the vehicle receiver.

[0046] After generating the expected preamble, the main controller performs a bit-by-bit comparison between the dynamic wake-up preamble temporarily stored in the receive buffer and the expected preamble. If the match is successful, meaning every bit of the dynamic wake-up preamble and the expected preamble are identical, the main controller determines that the currently received RF signal meets the preset legality requirements. At this point, the vehicle receiver determines that the RF signal comes from a legitimate transmitter and immediately switches from low-power mode to operating mode, continuing the subsequent wake-up challenge code reception and two-way authentication handshake process. If the match fails, meaning there is at least one bit difference between the dynamic wake-up preamble and the expected preamble, the main controller determines that the currently received RF signal is an invalid wake-up signal. This invalid wake-up signal may originate from the following situations: random RF interference in the environment, signals emitted by other unrelated devices, or illegal signals from malicious attackers attempting to wake up the vehicle receiver through replay attacks. Regardless of the situation, the vehicle receiver does not respond to this signal but instead shuts down the RF receiving module, and the main controller reduces the core clock frequency back to the lowest operating level, maintaining low-power mode and waiting for the next timer wake-up interrupt. Furthermore, if the vehicle receiver fails to detect a dynamic wake-up preamble that conforms to the preset format during the initial demodulation process, such as a synchronization field detection failure or severe damage to the demodulated data, the radio frequency signal is also determined to be an invalid wake-up signal, and the low-power mode remains unchanged.

[0047] Step S102: After entering the working mode, receive a wake-up challenge code containing a random number within the first preset time.

[0048] In step S102, the first preset time refers to a specific time window set after the vehicle receiver enters the working mode to receive the wake-up challenge code. The wake-up challenge code is a data frame sent by the transmitter to initiate a two-way authentication request and containing key authentication information. The random number is an unpredictable value generated by the transmitter and different for each communication, contained in the wake-up challenge code, used to prevent replay attacks.

[0049] Specifically, after the vehicle receiver switches from low-power mode to operating mode, it immediately starts an internal timer with a period set to a first preset time, such as 50 milliseconds. During this period, the vehicle receiver's radio frequency receiving circuit remains continuously on, focusing on receiving and decoding radio frequency signals from the air. The vehicle receiver expects to receive a complete wake-up challenge code data frame sent by a transmitter supporting two-way authentication within this time window. The payload of this data frame must contain a random number for subsequent authentication procedures.

[0050] In one possible implementation, receiving a wake-up challenge code containing a random number within a first preset time period specifically includes steps S1021-S1025, as follows:

[0051] Step S1021: Start the challenge code receiving timer and demodulate and decode the received radio frequency signal to obtain the decoded data frame.

[0052] In step S1021, the challenge code receiving timer refers to an internal timer used to limit the maximum time for receiving the wake-up challenge code. Demodulation refers to the process of restoring the modulated radio frequency carrier signal to the baseband signal. Decoding refers to converting the baseband signal into a binary digital data stream, i.e., the decoded data frame, according to a predetermined encoding rule, such as Manchester encoding or NRZ encoding. The decoded data frame refers to the original binary data sequence containing structured information such as frame header, payload, and checksum.

[0053] Specifically, upon entering operating mode, the vehicle receiver immediately starts a challenge code reception timer, the set duration of which is the first preset time. Simultaneously, the vehicle receiver's digital signal processing unit begins processing the analog signal received by the RF front-end. First, the signal undergoes mixing, filtering, and amplification before being sent to a demodulator. The demodulator, according to a pre-defined modulation scheme, such as FSK (Frequency Shift Keying), restores the high-frequency signal to baseband level signals representing 0 and 1. Next, the decoder performs clock recovery and data synchronization on the baseband signal, and translates it bit by bit into binary data according to encoding rules, ultimately combining them into a complete data frame structure—the decoded data frame—for subsequent protocol layers to parse.

[0054] Step S1022: Detect whether the decoded data frame contains a preset challenge code frame header identifier.

[0055] In step S1022, the preset challenge code frame header identifier is a fixed and unique bit sequence located at the very beginning of the wake-up challenge code data frame, used to clearly identify that the data frame is a wake-up challenge code.

[0056] Specifically, the vehicle receiving protocol processing unit checks the beginning portion of the decoded data frame obtained in step S1021. The protocol stack precisely compares the first few bits of the data frame with the preset challenge code frame header identifier stored internally. For example, the preset challenge code frame header identifier may be a specific 8-bit sequence, such as 10101010. Only when the beginning bit sequence of the decoded data frame completely matches this preset value will the vehicle receiver consider the data frame to be a valid wake-up challenge code and continue with subsequent processing. If the beginning portion does not match, the decoded data frame will be discarded directly, and the vehicle receiver will continue to wait for a new data frame.

[0057] Step S1023: If it is determined that the decoded data frame contains a preset challenge code frame header identifier, then parse the payload field of the data frame and extract the random number and transmitter identifier from the payload field.

[0058] In step S1023, the payload field refers to the part of the data frame that carries core valid information, distinct from protocol overhead parts such as the frame header, address, and checksum. The transmitter identifier is a code used to uniquely identify the transmitter device, such as the serial number of a smart key.

[0059] Specifically, after confirming the preset challenge code frame header identifier, the protocol processing unit of the vehicle receiver will skip the frame header and locate the payload field according to the preset data frame format definition. The internal structure of the payload field is also predefined; for example, the first 128 bits are random numbers, and the last 32 bits are the transmitter identifier. The processor will precisely copy the corresponding length of bit stream starting from the specified position in the payload field, parse it into random numbers and transmitter identifiers respectively, and temporarily store these two data items in the working register.

[0060] Step S1024: Perform frame verification operation on the data frame. If the verification passes, it is determined that a wake-up challenge code conforming to the preset format has been received, and the random number and the transmitter identifier are temporarily stored in the receiving buffer.

[0061] In step S1024, frame check operation is a technique used to verify whether errors have occurred in data transmission. Commonly used algorithms include Cyclic Redundancy Check (CRC). The receive buffer is a dedicated memory area used to temporarily store valid data that has passed the initial check and is awaiting further processing.

[0062] Specifically, after extracting the payload information, the vehicle receiver performs the same frame check operation as the transmitter on the entire decoded data frame, typically excluding the frame check field itself, using an algorithm such as CRC-16. The calculated result is compared with the frame check field carried at the end of the data frame. If they match perfectly, it means that no bit errors occurred during the data frame transmission, and the check passes. At this point, the vehicle receiver finally confirms that it has received a complete and correct wake-up challenge code that conforms to the preset format. Subsequently, the vehicle receiver formally transfers the random number and transmitter identifier extracted in step S1023 from the temporary working register to the receive buffer for use in the two-way authentication process.

[0063] Step S1025: If the challenge code receiving timer times out or the frame verification fails, it is determined that a wake-up challenge code conforming to the preset format has not been received.

[0064] In step S1025, a challenge code receiving timer timeout means that the timer started in step S1021 failed to complete the success determination in step S1024 before the countdown ended. Frame verification failure means that the checksum calculated in step S1024 is inconsistent with the checksum carried in the data frame.

[0065] Specifically, if the challenge code receiving timer counts down to zero within the entire first preset time and the vehicle receiver fails to receive any data frame containing a correct frame header identifier, or if the received data frame has a correct frame header but the final frame verification operation fails, then the vehicle receiver will determine that the attempt has failed. In either case, whether the timer times out or the frame verification fails, the final result is that a wake-up challenge code conforming to the preset format was not received within the specified time. This determination will trigger the subsequent process to switch to a one-way compatibility mode.

[0066] Step S103: If a wake-up challenge code conforming to a preset format is received within the first preset time, the current communication is determined to be in two-way authentication mode, and a random number is extracted.

[0067] In step S103, the preset format refers to the specific data structure that the wake-up challenge code data frame must follow, including the specifications for the frame header, data length, command identifier, data payload, and checksum. Two-way authentication mode refers to a high-security communication mode where the vehicle receiver and transmitter need to mutually verify each other's identity.

[0068] Specifically, the vehicle receiver successfully receives an RF data frame within a first preset time. The vehicle receiver then parses the data frame, checking if the frame header identifier is a two-way authentication request identifier, if the data length is correct, and if the cyclic redundancy check (CRC) at the frame tail passes the check. If all checks pass, it indicates that the data frame conforms to the preset format of the wake-up challenge code, and the vehicle receiver determines that the current communication has entered two-way authentication mode. After the determination is completed, the vehicle receiver accurately extracts a random number from the data payload area of ​​the wake-up challenge code according to the protocol, and temporarily stores this random number for encryption calculation in step S105.

[0069] Step S104: If a wake-up challenge code conforming to the preset format is not received within the first preset time, the current communication is determined to be in one-way compatibility mode.

[0070] In step S104, the one-way compatibility mode refers to a communication mode set up for compatibility with older or simplified transmitter equipment. In this mode, the vehicle receiver does not perform a two-way authentication handshake, but directly waits to receive control commands.

[0071] Specifically, if the timer started in step S102 counts down to zero within the first preset time and the vehicle receiver still fails to successfully receive and verify any wake-up challenge code that conforms to the preset format, the vehicle receiver determines that the initiator of this communication does not support or has not enabled the two-way authentication function. At this time, the vehicle receiver will mark the current communication process status as one-way compatibility mode, give up waiting for the wake-up challenge code, and directly enter the stage of waiting for subsequent control commands.

[0072] In one possible implementation, after determining that the current communication is in a one-way compatible mode, the method further includes: starting a compatible mode wake-up counter and incrementing the compatible mode wake-up counter each time it is determined to be in a one-way compatible mode; determining whether the count value of the compatible mode wake-up counter has reached a preset counting threshold; if the count value has not reached the counting threshold, continuing to receive radio frequency signals; if the count value has reached the counting threshold, entering a temporary high alert state for a preset lock time, during which control operations are prohibited and abnormal event logs are recorded; if it is determined that the preset lock time has ended, resetting the compatible mode wake-up counter to zero and restoring the normal working process.

[0073] Specifically, to achieve backward compatibility with traditional one-way remote controls, when the vehicle receiver does not receive a wake-up challenge code conforming to a preset format within a first preset time, it determines that the current communication is in one-way compatibility mode and continues to receive subsequent control command frames. However, this compatibility mechanism can be exploited by malicious attackers who can repeatedly trigger the vehicle receiver to enter one-way compatibility mode by continuously sending radio frequency signals that do not contain a valid challenge code, thereby launching a denial-of-service attack or attempting to brute-force the rolling code of a traditional remote control.

[0074] To address the aforementioned security threats, after determining that the current communication is in one-way compatibility mode, the vehicle receiver needs to implement an anomaly detection and temporary locking mechanism based on compatibility mode wake-up counts. The core idea of ​​this mechanism is to count the cumulative number of times the system enters one-way compatibility mode within a certain time window. When this number exceeds a reasonable threshold under normal usage scenarios, it is determined that the system may be under attack or experiencing an anomaly, and then it enters a temporary high-alert state to prevent potential unauthorized control operations.

[0075] When the main controller at the vehicle receiver determines that the current communication is in one-way compatibility mode, it first checks the current state of the compatibility mode wake-up counter. The compatibility mode wake-up counter is a software counter maintained by the main controller, and its count value is stored in a designated register area of ​​the state memory to ensure that the count value is not lost after the vehicle receiver enters low-power mode.

[0076] If the compatibility mode wake-up counter has not yet started, meaning this is the first time entering unidirectional compatibility mode, the main controller performs a counter initialization operation, setting the count value to 1 and simultaneously recording the current time as the start timestamp of the counting cycle. If the compatibility mode wake-up counter is already running, meaning there has been a previous record of entering unidirectional compatibility mode, the main controller first checks whether the time difference between the current time and the start timestamp of the counting cycle exceeds the preset counting cycle duration.

[0077] The preset counting cycle duration is a configurable parameter, typically ranging from 5 to 30 minutes. If the time difference exceeds the counting cycle duration, it indicates that the previous counting cycle has ended. The main controller resets the compatibility mode wake-up counter to zero and uses the current time as the start timestamp of the new counting cycle, subsequently setting the count value to 1. If the time difference does not exceed the counting cycle duration, it indicates that the current period is still within the same counting cycle. The main controller increments the count value of the compatibility mode wake-up counter by one.

[0078] For example, suppose the preset counting period is 10 minutes and the preset counting threshold is 5 times. At 9:00 AM, the vehicle receiver first determines that it has entered one-way compatibility mode, at which point the counter starts with a count value of 1, and the starting timestamp is 9:00 AM. At 9:02 AM, 9:04 AM, and 9:06 AM, the vehicle receiver determines that it has entered one-way compatibility mode three more times. Since these three determinations all occur within 10 minutes after the starting timestamp, the count values ​​accumulate to 2, 3, and 4 respectively.

[0079] After completing the accumulation operation of the compatibility mode wake-up counter, the main controller immediately compares the current count value with the preset counting threshold. The preset counting threshold is a parameter value determined based on the reasonable frequency of user operation of a traditional one-way remote control under normal usage scenarios. Under normal circumstances, the number of times a user uses a traditional remote control consecutively in a short period of time usually does not exceed 3 to 5 times. Therefore, the typical range of the preset counting threshold is 3 to 10 times, and the specific value can be configured according to the vehicle's safety level requirements.

[0080] If the count value does not reach the preset count threshold, the main controller determines that the current one-way compatible mode communication is within the normal usage range, and then continues to perform subsequent operations according to the standard procedure, that is, continuously receiving radio frequency signals to obtain control command frames within the second preset time, and performing corresponding control operations according to the control command frames after receiving them.

[0081] Continuing with the example above, at 9:06 AM, the count value is 4, which is below the preset count threshold of 5. Therefore, the vehicle receiver receives and processes the control command normally. If the count value reaches the preset count threshold, the main controller determines that there may be an abnormal situation or that the system is under attack, and then triggers the vehicle receiver to enter a temporary high-alert state.

[0082] Upon entering a temporary high alert state, the following sequence of operations is performed: First, the current time is recorded as the entry timestamp for the temporary high alert state; second, a new log entry is created in the abnormal event log, which includes an event type identifier (identified as "frequent wake-ups in compatibility mode"), an entry timestamp, the cumulative number of wake-ups within the current counting period, and detailed information on the most recent wake-up events (including the time of each wake-up, received signal strength, demodulated data digest, etc.); third, the temporary high alert state flag is set to active.

[0083] In the temporary high-alert state, the behavior of the vehicle receiver changes significantly. Specifically, while the vehicle receiver still responds to the radio frequency signal wake-up and receives control command frames, it checks the temporary high-alert state flag after decoding the control command frames. If the flag is valid, the main controller prohibits control operations, meaning it does not send any control commands to the body control interface, and the vehicle's door locks, start relays, and other actuators remain in their current state. Simultaneously, the main controller appends details of each prohibited control operation to the abnormal event log, including the prohibited command type, reception time, and source signal characteristics.

[0084] Continuing with the example above, at 9:08 AM, the vehicle receiver again determines that it has entered one-way compatibility mode, and the count value accumulates to 5, reaching the preset count threshold. At this time, the vehicle receiver enters a temporary high-alert state and records the abnormal event log. Assuming the preset lock time is 15 minutes, then between 9:08 AM and 9:23 AM, even if the vehicle receiver receives a valid traditional remote control door opening command, it will not execute the door opening operation, but will instead record the command in the abnormal event log.

[0085] During the temporary high alert state, each time the main controller wakes up from low power mode, in addition to performing the regular RF signal detection process, it will also check whether the time difference between the current moment and the timestamp of entering the temporary high alert state has exceeded the preset lockout time. The preset lockout time is a configurable parameter, typically ranging from 10 minutes to 60 minutes, used to ensure that the system can automatically restore normal function within a reasonable time after a possible attack has ceased.

[0086] If the main controller determines that the time difference between the current moment and the entry timestamp has exceeded the preset lock time, i.e., the preset lock time has ended, then it executes the state recovery operation sequence: First, it clears the count value of the compatibility mode wake-up counter to zero and removes the start timestamp of the counting cycle; Second, it sets the temporary high alert status flag to invalid; Third, it appends a state recovery record to the abnormal event log, indicating the end time of the temporary high alert status and the cumulative number of control operations intercepted during the lock period; Fourth, it restores the normal working process, and subsequent valid control commands will be executed normally.

[0087] Continuing with the example above, after 9:23 AM, when the vehicle receiver is woken up again, the main controller detects that the current time has exceeded the preset lockout timeout. It then performs a state recovery operation, resetting the counter to zero and resuming normal operation. Afterward, if the user sends an open-door command using a traditional remote control, the vehicle receiver will execute the open-door operation normally.

[0088] Step S105: After determining that the current communication is in two-way authentication mode, a response code is generated through encryption operation using a preset key and a random number, and the response code is sent to the transmitter to complete the two-way authentication handshake.

[0089] In step S105, the preset key refers to a piece of secret data securely and uniquely stored within the vehicle receiver and the legitimate transmitter during the vehicle production or key matching stage. Encryption operation refers to the mathematical process of processing random numbers using the preset key to generate an irreversible ciphertext, typically employing a symmetric encryption algorithm such as AES. The response code is the encrypted result generated through encryption operation, used to prove the identity of the vehicle receiver to the transmitter. The two-way authentication handshake refers to the process by which the vehicle receiver and transmitter exchange and verify encrypted information based on random numbers and the preset key to complete mutual identity verification.

[0090] Specifically, after determining in step S103 that the current communication is in two-way authentication mode, the vehicle receiver reads the preset key paired with the current transmitter from its internal secure storage unit. Next, the vehicle receiver invokes its internal encryption algorithm hardware or software, using the random number extracted in step S103 and the read preset key as input, to perform encryption operations and generate a unique response code. After the operation is complete, the vehicle receiver constructs a new radio frequency data frame from the response code and sends this data frame to the transmitter via the radio frequency transmission circuit. Upon receiving the response code, the transmitter performs local verification; if the verification passes, the two-way authentication handshake is complete.

[0091] Step S106: After completing the two-way authentication handshake or determining that the current communication is in one-way compatibility mode, continuously receive radio frequency signals within a second preset time to obtain control command frames.

[0092] In step S106, the second preset time refers to another time window set by the vehicle receiver after the authentication process is completed, in order to wait for receiving specific operation commands from the user. A control command frame refers to a data frame containing the user's specific intent, such as operation commands like unlocking the door or opening the trunk.

[0093] Specifically, the authentication phase ends after the vehicle receiver completes the two-way authentication handshake, or after determining in step S104 that the current communication is in one-way compatibility mode. At this time, the vehicle receiver starts another timer with a second preset duration, such as 200 milliseconds. During this time period, the vehicle receiver's radio frequency receiving circuit remains on, waiting for and receiving control command frames sent from the authenticated transmitter.

[0094] In one possible implementation, after continuously receiving radio frequency signals for a second preset time period to obtain control command frames, the method further includes: counting the actual number of control command frames received and comparing the number of control command frames with a preset total number of command frames; if the number of control command frames is lower than the preset total number of command frames, sending a retransmission request to the transmitter, the retransmission request containing the sequence number of the unreceived command frames; if a new received command frame is received from the transmitter within a preset retransmission waiting time, concatenating the new received command frame with the original command frame sequence to obtain a concatenated command frame, and using the concatenated command frame as a new control command frame; if the number of command frames is still lower than the expected total number of command frames after the number of retransmissions reaches a preset retransmission threshold, sending a reception failure notification to the transmitter.

[0095] Specifically, after the second preset time expires, the main controller at the vehicle receiver first iterates through and counts the data stored in the sliding window receive buffer. During the data reception process, the main controller has numbered and recorded each successfully demodulated and cyclic redundancy check (CRC) data frame, marking the value of its frame sequence number field in the received frame bitmap. The received frame bitmap is a binary vector of the same length as the preset number of command frames, where each bit corresponds to a frame sequence number. A bit value of 1 indicates that the frame with that sequence number has been successfully received, and a bit value of 0 indicates that the frame with that sequence number has not yet been received.

[0096] The main controller performs a bit-counting operation on the received frame bitmap, calculating the total number of bits with a value of 1. This total represents the actual number of control command frames received. Subsequently, the main controller compares this number of control command frames with the preset total number of command frames. The preset total number of command frames is a parameter that the transmitter informs the vehicle receiver during the two-way authentication handshake phase via a wake-up challenge code or response acknowledgment frame, indicating the total number of control command frames the transmitter plans to send in this communication session.

[0097] For example, assuming the preset total number of command frames is 7, the transmitter sequentially sends control command frames numbered 1 to 7. After the second preset time expires, the received frame bitmap status of the vehicle receiver is [1, 1, 0, 1, 1, 0, 1], indicating that frames with sequence numbers 1, 2, 4, 5, and 7 have been successfully received, while frames with sequence numbers 3 and 6 have not been received. At this time, the main controller counts 5 control command frames, which is less than the preset total of 7 command frames.

[0098] If the main controller determines that the number of control command frames is lower than the preset total number of command frames, it initiates a retransmission request process. First, the main controller initializes the retransmission count counter, setting its initial value to 0. Then, the main controller traverses the received frame bitmap, extracts the frame sequence number corresponding to all bits with a value of 0, and arranges these frame sequence numbers in ascending order to form a list of unreceived frame sequence numbers.

[0099] The main controller generates a retransmission request data packet based on the list of unreceived frame sequence numbers. The data structure of the retransmission request includes the following fields: a request frame header identifier field, used to indicate that the frame is a retransmission request type; a session identifier field, used to associate with the current communication session to prevent replay confusion; an unreceived frame count field, indicating the number of frames requested for retransmission; an unreceived frame sequence number field, listing all frame sequence numbers that need to be retransmitted in a compact encoding method; and a frame checksum field, used to ensure the transmission integrity of the retransmission request itself.

[0100] After generating the retransmission request data packet, the main controller activates the miniature RF transmitter module integrated into the vehicle receiver. The miniature RF transmitter module uses the same modulation scheme and transmission parameters as when sending the response code, and transmits the retransmission request data packet to the transmitter within the preset retransmission request transmission time window. After transmission is complete, the main controller shuts down the miniature RF transmitter module and switches the RF receiver module to receive mode, then waits for the transmitter's retransmission response.

[0101] Continuing with the example above, in the retransmission request generated by the vehicle receiver, the number of unreceived frames field has a value of 2, and the sequence number field for unreceived frames is [3, 6], indicating a request for the transmitter to retransmit control commands for frames with sequence numbers 3 and 6. After sending the retransmission request, the main controller starts a retransmission wait timer to begin timing the preset retransmission wait time. The preset retransmission wait time is a parameter that takes into account the transmitter's processing delay and the wireless transmission delay, and its typical value ranges from 50 milliseconds to 200 milliseconds. During the preset retransmission wait time, the RF receiver module continuously listens for retransmission response signals from the transmitter.

[0102] After receiving a retransmission request from the vehicle receiver, the transmitter retrieves the corresponding control command frame from its transmit buffer based on the content of the unreceived frame sequence number field, and retransmits these frames. The vehicle receiver's RF receiving module demodulates and decodes the received signal, and the main controller performs frame sequence number identification and cyclic redundancy check on the decoded data frames.

[0103] If, within the preset retransmission waiting time, the main controller successfully receives the retransmitted new receive command frame from the transmitter, and the new receive command frame passes the verification, the main controller performs a frame sequence splicing operation. Specifically, the main controller inserts the new receive command frame into the corresponding position in the sliding window receive buffer according to the frame sequence number field value, and simultaneously updates the corresponding bit value in the received frame bitmap to 1. After all new receive command frames have been inserted, the main controller rearranges and splices all frames in the sliding window receive buffer according to their frame sequence numbers to obtain the spliced ​​command frame. The main controller uses the spliced ​​command frame as a new control command frame for subsequent command parsing and control operation execution.

[0104] Continuing with the example above, suppose that within the preset retransmission waiting time, the vehicle receiver successfully receives two control commands, frames numbered 3 and 6, retransmitted by the transmitter. The main controller inserts these two frames into positions 3 and 6 of the sliding window receive buffer, updating the received frame bitmap to [1, 1, 1, 1, 1, 1, 1]. Subsequently, the main controller concatenates the seven frames of data in the order of numbers 1 to 7 to obtain a complete concatenated command frame, which is then used as a new control command frame for subsequent processing.

[0105] If a retransmission command frame is not received from the transmitter within the preset retransmission waiting time, or if the received retransmission frame fails verification, the main controller increments the retransmission count counter and determines whether the current retransmission count has reached the preset retransmission threshold. The preset retransmission threshold is a parameter used to limit the number of retransmission attempts, typically ranging from 2 to 5 times, to avoid excessive power consumption and communication delays caused by continuous retransmissions.

[0106] If the number of retransmissions does not reach the preset retransmission threshold, the main controller regenerates the retransmission request and resends it, then re-enters the retransmission waiting state. At this time, the list of unreceived frame sequence numbers in the retransmission request should be recalculated based on the latest received frame bitmap to ensure that only those frames that have not yet been successfully received are requested.

[0107] If, after the number of retransmissions reaches a preset retransmission threshold, the number of control command frames is still lower than the preset total number of command frames (meaning there are still missing frames that cannot be completed), the main controller determines that the reception of this control command frame has ultimately failed. At this point, the main controller generates a reception failure notification data packet, which includes a failure reason code field, a list of final missing frame sequence numbers, and statistical information fields for this session. The main controller sends the reception failure notification to the transmitter via a miniature RF transmitter module to inform the transmitter that this communication has not been successfully completed.

[0108] After sending a reception failure notification, the vehicle receiver's main controller determines its subsequent behavior based on a preset failure handling strategy. If the received control command frames contain enough key frames to perform basic control operations, the main controller can choose to execute some control operations and send partial execution results back to the transmitter. If the received frames are insufficient to support any valid control operations, the main controller discards all received data, records detailed information about this reception failure event in the exception event log, and returns to low-power mode to wait for the next communication session.

[0109] Step S107: Execute the corresponding control operation according to the control instruction frame, and return to the low power mode after the control operation is completed.

[0110] In step S107, the control operation refers to the physical action performed by the vehicle receiver through the vehicle's internal bus, based on the parsed instruction content.

[0111] Specifically, after successfully receiving the control command frame within the second preset time, the vehicle receiver decrypts and verifies the control command frame to confirm the validity and integrity of the command. Then, the vehicle receiver parses the specific content of the command, such as unlocking all doors. The vehicle receiver sends this operation command to the body control unit via the vehicle communication network, such as the CAN bus or LIN bus. After receiving the command, the body control unit drives the door lock motor to perform the unlocking action. After confirming that the control operation has been completed, such as receiving a completion feedback from the body control unit or waiting for a fixed execution time, the vehicle receiver actively disconnects the power supply to high-power components such as the main processor and RF transceiver circuit, returning to the low-power mode in step S101, waiting for the next wake-up event.

[0112] refer to Figure 2 In one possible implementation, a corresponding control operation is performed according to the control command frame, specifically including steps S201-S204, as follows:

[0113] Step S201: Extract the main command frame and extended command frame from the control command frame. The main command frame is used to carry the main control command, which includes unlocking the door and starting the vehicle. The extended command frame is used to carry the auxiliary control command, which includes adjusting the air conditioning temperature and opening the windows.

[0114] In step S201, the main command frame refers to the portion of the control command frame specifically used to transmit commands that have a significant impact on vehicle safety and core functions. The main control command refers to the critical command directly related to vehicle access permissions and driving capabilities. The extended command frame refers to the portion of the control command frame used to transmit non-core function commands that enhance comfort and convenience. The auxiliary control command refers to additional commands that do not directly affect vehicle safety and basic functions.

[0115] Specifically, after receiving a complete sequence of control command frames, the vehicle receiver parses the sequence according to a predefined protocol format. This protocol divides the control command frame into two logical parts or independent physical frames: a main command frame and an extended command frame. The protocol processing unit of the vehicle receiver accurately separates these two parts based on identifiers or fixed data structures within the frame. For example, the first 64 bits of a long control command frame might be defined as the main command frame, carrying main control commands such as unlocking all doors or authorizing engine start; while the following 64 bits are defined as the extended command frame, carrying auxiliary control commands such as setting the air conditioning to 23 degrees Celsius or lowering the driver's side window. The vehicle receiver then sends the separated main command frame and extended command frame to different processing logic.

[0116] Step S202: Decode the main instruction frame to obtain the operation type and operation parameters of the main control instruction.

[0117] In step S202, the operation type refers to the specific action category of the instruction, such as whether it is an unlocking operation or a starting operation. The operation parameters refer to the specific quantification or description of the operation type, such as which door to unlock or the specific conditions for starting the engine.

[0118] Specifically, the vehicle receiver first focuses on the master command frame extracted from step S201. The protocol processing unit decodes the master command frame according to its internal data structure specifications. For example, the first byte of the master command frame may define the operation type, where 0x01 represents door unlocking and 0x02 represents vehicle start. The subsequent one or more bytes define the operation parameters. If the operation type is door unlocking, the operation parameter may be 0xFF, indicating unlocking all doors, or 0x01, indicating unlocking only the driver's side door. By parsing these bits, the vehicle receiver accurately translates the binary master command frame into an operation type and operation parameters that can be understood by the upper-layer application.

[0119] Step S203: Based on the operation type, determine the execution result of the main control instruction, and based on the execution result, execute or refuse to execute the main control instruction.

[0120] In step S203, the execution result refers to the decision made by the vehicle receiver before executing the instruction, based on the current vehicle status and permission policy, i.e., whether to allow execution or refuse execution.

[0121] Specifically, after decoding the operation type and parameters of the main control command, the decision logic unit of the vehicle receiver performs a series of conditional checks. For example, if the operation type is vehicle start, the logic unit checks whether the vehicle is in park (P), whether the brake is engaged, and whether the transmitter identifier used in the previous authentication process has the authority to start the vehicle. Based on these checks, the decision logic unit generates an execution result. If all conditions are met, the execution result is "execution allowed". If any condition is not met, such as the vehicle not being in park, the execution result is "execution denied". Subsequently, the vehicle receiver takes action based on this execution result: if the result is "execution allowed", a start command is sent to the engine control unit via the vehicle network; if the result is "execution denied", no command is sent, and a failed attempt may be recorded.

[0122] In one possible implementation, the execution result of the main control instruction is determined based on the operation type, specifically including steps S2031-S2033, as follows:

[0123] Step S2031: Determine whether the transmitter has the authority to execute the main control command based on the operation type of the main control command.

[0124] In step S2031, permissions refer to the range of functions or sets of operations that are allowed to be invoked for a specific transmitter identifier and are pre-defined within the vehicle.

[0125] Specifically, after decoding the operation type of the master control command, the vehicle receiver retrieves the transmitter identifier obtained during the two-way authentication phase and temporarily stored in the receive buffer. The vehicle receiver compares this transmitter identifier with the permission configuration table stored in its internal non-volatile memory. The permission configuration table details the specific rights possessed by each paired transmitter. For example, the transmitter identifier corresponding to the master key has all permissions, including door unlocking, vehicle start, and air conditioning adjustment, while the transmitter identifier corresponding to the service key may only be granted door unlocking permission. The vehicle receiver verifies whether the corresponding transmitter identifier is marked as allowed in the permission configuration table based on the currently parsed operation type. If the operation type is vehicle start, and the permission configuration table shows that the transmitter identifier has start permission, then the permissions are considered matched.

[0126] Step S2032: If the transmitter has the authority to execute the main control command, then determine to execute the main control command and generate an execution result status code.

[0127] In step S2032, the execution result status code is a specific numerical identifier used to indicate that the main control instruction has passed the permission verification and is allowed to enter the execution stage.

[0128] Specifically, if the vehicle receiver confirms in step S2031 that the transmitter identifier has the necessary permissions to execute the current operation type, the vehicle receiver will decide to execute the main control command. At this time, the vehicle receiver will generate an execution result status code in memory representing a successful verification, for example, assigning the status code the hexadecimal number 0x55. This execution result status code serves as an intermediate variable, used to transmit a permission verification successful signal to subsequent task processing flows, ensuring that only authorized operations can trigger the vehicle's physical actions, thereby maintaining the accuracy of the vehicle's controlled state.

[0129] Step S2033: If the transmitter does not have the authority to execute the main control command, it determines that it will refuse to execute the main control command and generates an authority exception status code.

[0130] In step S2033, the permission exception status code refers to a specific error identifier used to indicate that the current operation violates the permission rules and the instruction has been intercepted.

[0131] Specifically, if the vehicle receiver finds, after searching the permission configuration table, that the current transmitter identifier is not granted the right to execute this type of operation—for example, the transmitter sends a vehicle start command, but the transmitter is only a temporary device without start permission in the system records—the vehicle receiver determines that the permission is denied and therefore refuses to execute the main control command. To record and handle this exception, the vehicle receiver generates a specific permission exception status code, for example, assigned the value 0xAA in hexadecimal. This permission exception status code prevents the command from being sent to the vehicle bus and serves as the basis for subsequent logical judgments, allowing the vehicle receiver to directly skip the command execution stage, effectively preventing illegal operations from threatening vehicle safety.

[0132] Step S204: After executing or rejecting the main control instruction, determine the execution result for the extended instruction frame, and based on the execution result, execute or reject the auxiliary control instruction.

[0133] In step S204, the execution result here is the execution decision for the auxiliary control command.

[0134] Specifically, regardless of whether the main control command in step S203 is executed or rejected, the process continues to process the extended command frame. The vehicle receiver decodes the extended command frame to obtain the operation type and parameters of the auxiliary control command, such as the operation type being air conditioning adjustment and the parameter being 23 degrees Celsius. Next, the decision logic unit determines the execution result for the auxiliary control command. This decision is usually related to the execution result of the main control command. One strategy is to allow the auxiliary control command to be executed only when the main control command is successfully executed. For example, the command to open the window is only executed after the door is successfully unlocked. Another strategy is to have more lenient execution conditions for the auxiliary control command; as long as authentication is successful, it can be executed regardless of whether the main command was successfully executed. The vehicle receiver generates an execution result according to a preset strategy. If the result is "execution allowed," the corresponding command is sent to the air conditioning controller or window controller. If the result is "execution rejected," the auxiliary control command is ignored.

[0135] The following describes a low-power radio frequency receiving device based on two-way authentication from the perspective of hardware processing in an embodiment of this invention. Please refer to [link to relevant documentation]. Figure 3 This is a schematic diagram of a low-power radio frequency receiver based on two-way authentication in an embodiment of this application.

[0136] It should be noted that, Figure 3 The structure of the low-power radio frequency receiver based on two-way authentication shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0137] like Figure 3As shown, a low-power radio frequency receiver based on two-way authentication includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 302 or a program loaded from storage portion 308 into random access memory (RAM) 303, such as performing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for device operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0138] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0139] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0140] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0141] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0142] Specifically, a low-power radio frequency receiving device based on two-way authentication in this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements a low-power radio frequency receiving method based on two-way authentication provided in the above embodiment.

[0143] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the low-power radio frequency receiving device based on two-way authentication described in the above embodiments; or it may exist independently and not assembled into the low-power radio frequency receiving device based on two-way authentication. The storage medium carries one or more computer programs, which, when executed by a processor of the low-power radio frequency receiving device based on two-way authentication, cause the low-power radio frequency receiving device based on two-way authentication to implement the low-power radio frequency receiving method based on two-way authentication for encrypted data transmission based on the Internet of Things provided in the above embodiments.

Claims

1. A low-power radio frequency receiving method based on two-way authentication, characterized in that, The method is applied to a vehicle receiver, and the method includes: Within a preset listening period, the system periodically wakes up in low-power mode and performs radio frequency signal detection. When the radio frequency signal meets the preset legality requirements and the radio frequency signal strength exceeds the preset strength threshold, the system switches from the low-power mode to the working mode. After entering the working mode, a wake-up challenge code containing a random number is received within a first preset time. If a wake-up challenge code conforming to a preset format is received within the first preset time, the current communication is determined to be in two-way authentication mode, and the random number is extracted. If a wake-up challenge code conforming to the preset format is not received within the first preset time, the current communication is determined to be in one-way compatibility mode. After determining that the current communication is the two-way authentication mode, a response code is generated through encryption operation using a preset key and the random number, and the response code is sent to the transmitting end to complete the two-way authentication handshake; After completing the two-way authentication handshake, or after determining that the current communication is the one-way compatible mode, the radio frequency signal is continuously received for a second preset time to obtain control command frames. Execute the corresponding control operation according to the control instruction frame, and return to the low power mode after the control operation is completed; After periodically waking up in low-power mode and detecting radio frequency signals, the method further includes: The radio frequency signal is initially demodulated to listen for the dynamic wake-up preamble; Based on the authentication parameters used in the historical successful authentication interactions, a desired preamble is generated by a preset one-way hash function. The authentication parameters are either random numbers sent by the transmitter or response codes generated by the vehicle receiver in the historical successful authentication interactions. The dynamic wake-up preamble is matched and compared with the expected preamble; If the match is successful, the radio frequency signal is determined to meet the preset legality requirements; If the matching fails or the dynamic wake-up preamble is not detected, the radio frequency signal is determined to be an invalid wake-up signal, and the low-power mode is maintained.

2. The method according to claim 1, characterized in that, Receiving a wake-up challenge code containing a random number within a first preset time period specifically includes: Start the challenge code receiving timer, and demodulate and decode the received radio frequency signal to obtain the decoded data frame; Detect whether the decoded data frame contains a preset challenge code frame header identifier; If it is determined that the decoded data frame contains the preset challenge code frame header identifier, then the payload field of the data frame is parsed, and the random number and transmitter identifier are extracted from the payload field; A frame verification operation is performed on the data frame. If the verification passes, it is determined that a wake-up challenge code conforming to the preset format has been received, and the random number and the transmitter identifier are temporarily stored in the receiving buffer. If the challenge code receiving timer times out or the frame verification fails, it is determined that no wake-up challenge code conforming to the preset format has been received.

3. The method according to claim 1, characterized in that, The execution of the corresponding control operation according to the control instruction frame specifically includes: Extract the main command frame and the extended command frame from the control command frame. The main command frame is used to carry the main control command, which includes unlocking the door and starting the vehicle. The extended command frame is used to carry the auxiliary control command, which includes adjusting the air conditioning temperature and opening the windows. The main instruction frame is decoded to obtain the operation type and operation parameters of the main control instruction; Based on the operation type, determine the execution result of the main control instruction, and based on the execution result, execute or refuse to execute the main control instruction; After executing or rejecting the main control instruction, the execution result for the extended instruction frame is determined, and based on the execution result, the auxiliary control instruction is executed or rejected.

4. The method according to claim 3, characterized in that, Determining the execution result of the main control instruction based on the operation type specifically includes: Based on the operation type of the main control command, determine whether the transmitting end has the authority to execute the main control command; If the transmitting end has the authority to execute the main control command, then it determines to execute the main control command and generates an execution result status code; If the transmitter does not have the authority to execute the main control command, it will refuse to execute the main control command and generate an authority exception status code.

5. The method according to claim 1, characterized in that, After determining that the current communication is in one-way compatibility mode, the method further includes: Start the compatibility mode wake-up counter, and increment the compatibility mode wake-up counter each time it is determined to be in one-way compatibility mode; Determine whether the count value of the compatibility mode wake-up counter has reached a preset count threshold; If the count value does not reach the count threshold, the radio frequency signal is continuously received; If the count value reaches the count threshold, a temporary high alert state with a preset lock time is entered. In the temporary high alert state, the control operation is prohibited and an abnormal event log is recorded. If the preset lock time is determined to have ended, the compatibility mode wake-up counter will be reset to zero and the normal working process will be restored.

6. The method according to claim 1, characterized in that, After continuously receiving radio frequency signals for a second preset time to obtain control command frames, the method further includes: The number of control command frames actually received is counted, and the number of control command frames is compared with the preset total number of command frames; If the number of control command frames is less than the preset total number of command frames, a retransmission request is sent to the transmitting end. The retransmission request includes the sequence number of the unreceived command frames. If a new receive command frame is received from the transmitter within the preset retransmission waiting time, the new receive command frame is concatenated with the original command frame sequence to obtain a concatenated command frame, and the concatenated command frame is used as a new control command frame. If the number of retransmissions reaches the preset retransmission threshold and the number of instruction frames is still lower than the preset total number of instruction frames, a reception failure notification is sent to the transmitting end.

7. A low-power radio frequency receiver based on two-way authentication, characterized in that, The low-power radio frequency receiver based on two-way authentication includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the low-power radio frequency receiver based on two-way authentication to perform the method as described in any one of claims 1-6.

8. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on a low-power radio frequency receiver based on two-way authentication, the low-power radio frequency receiver based on two-way authentication performs the method as described in any one of claims 1-6.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is run on a low-power radio frequency receiver based on two-way authentication, the low-power radio frequency receiver based on two-way authentication performs the method as described in any one of claims 1-6.

Images