A method, system and vehicle for remote wake-up of vehicle-mounted terminal

Abstract

This application relates to the field of intelligent connected vehicle technology, specifically providing a method, system, and vehicle for remote wake-up of an in-vehicle terminal. In this application, a remote service platform sends connection and wake-up commands to the in-vehicle terminal. Remote wake-up of the in-vehicle terminal is achieved based on the interaction between the remote service platform and the vehicle, avoiding the uncertainty of operation response latency (i.e., time delay) inherent in SMS methods, thus solving the problems of long latency and low security. Simultaneously, by controlling the start / stop of the in-vehicle terminal's listening port, it effectively avoids erroneous opening of the listening port in invalid states such as the in-vehicle terminal being in deep sleep or already awakened. This significantly reduces power consumption and communication resource usage in unnecessary scenarios, while also reducing the risk of abnormal startup of the in-vehicle terminal due to false wake-ups, improving the accuracy and security of remote wake-up.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, specifically to a method, system, and vehicle for remotely waking up an in-vehicle terminal. Background Technology

[0002] With the increasing popularity of intelligent connected vehicles, remote control services (such as remote start, air conditioning pre-cooling, and door locking / unlocking) are appearing in more and more models. To reduce the vehicle's static power consumption and prevent battery depletion, the on-board terminal enters a sleep mode after the vehicle is turned off. Therefore, before executing remote control commands, the primary issue to be addressed is how to reliably wake up the on-board terminal from its sleep state.

[0003] Existing technologies typically use SMS to remotely wake up the vehicle's onboard terminal while it is in sleep mode. However, SMS is expensive, has uncertain response times (i.e., time delays), and is not very secure, thus reducing the success rate of remote wake-up. Summary of the Invention

[0004] In view of this, this application aims to provide a method, system and vehicle for remotely waking up an in-vehicle terminal, so as to solve the problem of how to reliably wake up an in-vehicle terminal in a dormant state in traditional related technologies.

[0005] The first aspect of this application provides a method for remotely waking up a vehicle-mounted terminal. The vehicle-mounted terminal includes a power management module, a digital wake-up module, and a listening port. The power management module manages the operating state of the vehicle-mounted terminal, which includes a shallow sleep state and a non-shallow sleep state. The method is applied to the digital wake-up module and includes: Obtain the current working status of the vehicle terminal; When the current working state meets the preset wake-up conditions, the listening port is activated to receive connection and wake-up commands from the remote service platform through the listening port to wake up the vehicle terminal; If the current working state does not meet the preset wake-up conditions, the listening port is closed. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

[0006] In this application, the current working state of the vehicle terminal is obtained. If the current working state meets the preset wake-up conditions, a listening port is activated to receive connection and wake-up commands from the remote service platform to wake up the vehicle terminal. If the current working state does not meet the preset wake-up conditions, the listening port is closed. The preset wake-up conditions include the vehicle terminal being in a shallow sleep state and the absence of a preset wake-up source. Thus, by sending connection and wake-up commands to the vehicle terminal through the remote service platform, remote wake-up of the vehicle terminal is achieved based on the interaction between the remote service platform and the vehicle terminal. This avoids the uncertainty of operation response latency (i.e., time delay) inherent in SMS methods, solving the problems of long latency and low security. Simultaneously, by controlling the start and stop of the vehicle terminal's listening port, erroneous activation of the listening port in invalid states such as deep sleep or already awakened is effectively avoided. This significantly reduces power consumption and communication resource usage in unnecessary scenarios, while also reducing the risk of abnormal vehicle terminal startup due to false wake-ups, improving the accuracy and security of remote wake-up.

[0007] In one possible implementation of this application, waking up the vehicle terminal by receiving connection and wake-up commands from a remote service platform through the listening port includes: The system receives connection requests sent by the remote service platform through the listening port, and establishes a connection with the remote service platform after verifying the connection request. The system receives a wake-up command sent by the remote service platform and wakes up the vehicle terminal after verifying the wake-up command.

[0008] In this implementation, firstly, connection requests are verified during the connection establishment phase, filtering out a large number of invalid probe requests or illegal scans at the source, thus preventing the vehicle terminal from consuming unnecessary communication and computing resources when responding to connections. Subsequently, a verification mechanism is introduced in the wake-up command phase to ensure that only commands from legitimate platforms and that have not been tampered with can trigger terminal wake-up. Connection verification reduces the computational overhead of deep signature verification, while command verification ensures the unforgeability of the wake-up action. The combination of these two mechanisms allows the terminal to maintain extremely low power consumption in a shallow sleep state while resisting replay attacks and man-in-the-middle attacks. This effectively solves the problems of excessive power consumption and susceptibility to malicious exploitation in the traditional always-on listening mode, achieving a balance between secure wake-up and energy saving.

[0009] In one possible implementation of this application, establishing a connection with the remote service platform after the connection request passes verification includes: If the number of connection requests is less than or equal to a preset number, and the connection duration is less than or equal to a preset duration, then a connection is established with the remote service platform.

[0010] In this implementation, limiting the number of connection requests to less than or equal to a preset value effectively suppresses the impact of high-frequency concurrent connections or distributed denial-of-service (DDoS) anomalies on the vehicle terminal, preventing the terminal from becoming blocked or crashing due to frequent handling of invalid connections. Introducing a connection duration threshold as a secondary judgment criterion identifies and filters out half-open connections caused by network packet loss, ACK delays, or man-in-the-middle interference, preventing terminal resources from being occupied by dangling connections for extended periods. The joint verification of these two conditions achieves a collaborative filtering effect: quantity control reduces traffic pressure broadly, while duration control cleans up abnormal states deeply. Together, they ensure that connections are established only when the request is reasonable and communication is smooth. This not only improves the terminal's adaptability to complex network environments but also fundamentally avoids wake-up failures or system deadlocks caused by connection problems or abnormal lingering.

[0011] In one possible implementation of this application, waking up the vehicle terminal after the wake-up command verification passes includes: Determine whether the data volume of the wake-up command message meets the preset conditions; If the amount of data in the wake-up command message meets the preset conditions, the signature of the wake-up command is verified using a pre-stored digital wake-up key. After the signature verification is passed, the start character of the wake-up command message information is verified. After the initial character verification passes, the timestamp of the message information is verified. After the timestamp verification is passed, the vehicle identification number of the message information is verified. After the vehicle identification code is verified, the block check character of the message information is verified. After the block verification character passes the verification, it is determined that the wake-up command has passed the verification, and the power management module is used to wake up the vehicle terminal.

[0012] In this implementation, the wake-up command verification is broken down into a six-level progressive verification system: data volume, signature, start character, timestamp, vehicle identification code, and block check character. Among them, data volume verification, as a pre-checkpoint, can quickly filter abnormally long packets (such as empty packets or excessively long overflow packets), preventing invalid data from entering subsequent complex calculations and reducing resource consumption; digital signature verification verifies the legitimacy of the command source based on a pre-stored key, preventing forged commands from intruding; start character verification ensures that the message format is compliant and blocks interference from unexpected protocols; timestamp verification defends against replay attacks through timeliness judgment, ensuring the freshness of the command; vehicle identification code verification realizes the unique binding between the command and the vehicle; and block check character verification ensures the integrity of message transmission, preventing data from being tampered with or lost in the link.

[0013] In this verification method, factors such as data volume and starting character serve as rapid filtering mechanisms, reducing the computational overhead of deep verification. Signatures, vehicle identification numbers, and timestamps ensure that only fully compliant, legal, complete, and fresh instructions can trigger wake-up. This allows the terminal to maintain only lightweight listening in a shallow sleep state, executing verification sequentially upon receiving instructions. This avoids the energy consumption of deep processing and ensures the non-repudiation, non-forgeability, and integrity of the wake-up action through a multi-level logical closed loop, significantly improving the anti-attack capability of vehicle-to-cloud communication.

[0014] In one possible implementation of this application, after receiving a connection request sent by a remote service platform through the listening port, the method further includes: If the address information corresponding to the connection request is in a pre-built blocking list, the connection with the remote service platform is refused. The pre-built blocking list is dynamically updated, and the dynamic update includes determining whether to add the address information of the remote service platform to the blocking list based on whether the connection request is verified and whether the wake-up command is verified.

[0015] This implementation introduces a dynamic blocking list mechanism based on verification results, achieving adaptive isolation of abnormal sources while ensuring communication security. Since the blocking process occurs before connection establishment, the terminal does not need to consume resources to process handshake requests from marked malicious sources, thus cutting off the intrusion path of invalid or malicious traffic at the source. Simultaneously, it transforms the original passive response security strategy into proactive interception, significantly reducing the probability of interruption and processing overhead during shallow sleep states.

[0016] A second aspect of this application also provides a method for remotely waking up a vehicle-mounted terminal, applied to a remote service platform, the method comprising: A connection and wake-up command is sent to the vehicle terminal to wake it up. The vehicle terminal includes a power management module, a digital wake-up module, and a listening port. The power management module manages the working state of the vehicle terminal, which includes a shallow sleep state and a non-shallow sleep state. The digital wake-up module activates the listening port to receive connection and wake-up commands when the current working state of the vehicle terminal meets preset wake-up conditions, and deactivates the listening port when the current working state of the vehicle terminal does not meet the preset wake-up conditions. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

[0017] In one possible implementation of this application, sending a connection and wake-up command to the vehicle terminal to wake up the vehicle terminal includes: When it is determined that the vehicle terminal has remote wake-up capability, the address information of the vehicle terminal when it is registered based on the dedicated network is obtained; Based on the address information, a connection request is sent to the vehicle terminal to establish a connection with the vehicle terminal; A wake-up command is sent to the vehicle terminal to wake it up.

[0018] In this implementation, the terminal's remote wake-up capability is confirmed before sending the connection request, which avoids sending invalid commands to terminals without this function or devices in an unwakeable state, reducing message redundancy on the network side from the source. Furthermore, by obtaining the address information registered on the dedicated network, public network transmission costs are avoided while improving reliability. Thus, this feature not only solves the problem of low success rate of traditional blind wake-up commands in complex network environments, but also achieves a dual improvement in wake-up success rate and network communication efficiency at the overall solution level, making the remote wake-up process both accurate and stable.

[0019] In one possible implementation of this application, the method further includes: Receive a login request sent by the woken-up vehicle terminal, the login request carrying a digital wake-up capability bit; Upon successful login, disconnect from the vehicle terminal.

[0020] In this implementation, the vehicle terminal reports its wake-up capability status upon login, enabling the remote service platform to accurately identify the terminal's current wake-up source and capability level. This avoids repeated wake-ups or invalid interactions caused by inconsistent status, ensuring the relevance and effectiveness of subsequent processes. Furthermore, the connection is terminated after successful login, so that the terminal does not need to bear the additional power consumption of maintaining the link's heartbeat and keep-alive functions after completing the wake-up confirmation.

[0021] A third aspect of this application also provides a vehicle-mounted terminal remote wake-up system, the system comprising: The vehicle-mounted terminal includes a power management module, a digital wake-up module, and a listening port. The digital wake-up module is used to execute the vehicle-mounted terminal remote wake-up method as described in the first aspect and the first aspect. A remote service platform for performing methods such as the second aspect and the remote wake-up method for vehicle terminals.

[0022] A fourth aspect of this application also provides a vehicle, the vehicle including an in-vehicle terminal, the in-vehicle terminal including a power management module, a digital wake-up module and a listening port, the digital wake-up module being used to perform the in-vehicle terminal remote wake-up method as described in the first aspect and the first aspect.

[0023] The fifth aspect of this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform the vehicle terminal remote wake-up method of the first aspect or the vehicle terminal remote wake-up method of the second aspect.

[0024] The sixth aspect of this application provides a computer storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the vehicle terminal remote wake-up method of the first aspect or to perform the vehicle terminal remote wake-up method of the second aspect.

[0025] The seventh aspect of this application provides a computer program product, comprising: a computer program that, when executed by a processor, implements the vehicle terminal remote wake-up method of the first aspect or performs the vehicle terminal remote wake-up method of the second aspect. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 Schematic diagram of the structure of the vehicle terminal remote wake-up system provided in the embodiments of this application Figure 1 .

[0028] Figure 2 A flowchart illustrating the remote wake-up method for an in-vehicle terminal provided in this application embodiment. Figure 1 .

[0029] Figure 3 A flowchart illustrating the remote wake-up method for an in-vehicle terminal provided in this application embodiment. Figure 2 .

[0030] Figure 4 This is a flowchart illustrating the key acquisition method provided in an embodiment of this application.

[0031] Figure 5 Schematic diagram of the structure of the vehicle terminal remote wake-up system provided in the embodiments of this application Figure 2 .

[0032] Figure 6A schematic diagram of the workflow of the vehicle terminal remote wake-up system provided in this application embodiment. Figure 1 .

[0033] Figure 7 A schematic diagram of the workflow of the vehicle terminal remote wake-up system provided in this application embodiment. Figure 2 .

[0034] Figure 8 Schematic diagram of the structure of the vehicle terminal remote wake-up device provided in the embodiments of this application Figure 1 .

[0035] Figure 9 Schematic diagram of the structure of the vehicle terminal remote wake-up device provided in the embodiments of this application Figure 2 .

[0036] Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0037] The technical solutions of the embodiments of this application 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. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0038] In practical applications, to reduce the vehicle's static power consumption and prevent battery depletion, the vehicle terminal enters a sleep mode after the vehicle is turned off. When various remote control commands need to be executed, the vehicle terminal must first be remotely woken up to activate the vehicle.

[0039] Existing technologies typically use SMS to remotely wake up a vehicle from sleep mode. However, SMS methods suffer from uncertainties in response time (i.e., time delay), and the long delays and low security reduce the success rate of remote wake-up.

[0040] Therefore, to avoid the uncertainty of operation response latency (i.e., time delay) inherent in SMS-based methods and to address the issues of long latency and low security, related technologies have attempted to introduce wake-up schemes based on data networks. For example, by configuring a fixed network address for the vehicle terminal, it can maintain network listening capability in sleep mode to receive wake-up commands from remote platforms. While this method reduces costs and improves response speed to some extent, it still presents a trade-off between energy consumption and accessibility. If the network listening port remains continuously open, it can lead to excessive sleep current, posing a risk of power depletion for the entire vehicle; conversely, if the port is completely closed, the remote service platform cannot establish a connection with the vehicle.

[0041] Therefore, this application provides a vehicle-mounted terminal remote wake-up system, such as... Figure 1 As shown, the system includes: vehicle terminal 101 and remote service platform 102. The vehicle terminal 101 includes a power management module 111, a digital wake-up module 112 and a listening port 113. The digital wake-up module 112 enables the remote service platform 102 to remotely wake up the vehicle terminal 101 by starting and stopping the listening port 113.

[0042] In this embodiment, the remote service platform 102 can be a Telematics Service Provider (TSP). In practical applications, the TSP plays a central role in the Internet of Vehicles (IoV), connecting hardware, software, and vehicle manufacturers. The main functions of the TSP are to provide IoV services such as issuing remote control commands, monitoring vehicle status, and performing data analysis.

[0043] In this embodiment, the vehicle terminal 101 can be a vehicle communication terminal (Telematics Box, T-BOX). As the communication core of the vehicle system, the vehicle terminal is responsible for data interaction between the vehicle and the remote service platform, and supports functions such as 4G / 5G cellular network, GPS positioning, and CAN bus communication.

[0044] Based on the aforementioned vehicle-mounted terminal remote wake-up system, this application provides a method for remotely waking up a vehicle-mounted terminal. The vehicle-mounted terminal includes a power management module, a digital wake-up module, and a listening port. The power management module manages the operating state of the vehicle-mounted terminal, which includes a shallow sleep state and a non-shallow sleep state. The method is applied to the digital wake-up module. Figure 2 This is a schematic flowchart illustrating a remote wake-up method for a vehicle-mounted terminal provided in an embodiment of this application. The method includes: Step 201: Obtain the current working status of the vehicle terminal.

[0045] Specifically, as an intelligent terminal device in a vehicle, the in-vehicle terminal's operation partially depends on the vehicle's power supply. Therefore, as the operating state of the vehicle's battery changes, the in-vehicle terminal's operating state also changes. To manage the in-vehicle terminal's operating state, a power management module is installed. This power management module can manage the in-vehicle terminal's operating state based on the vehicle's battery's operating state. For example, after the vehicle is turned off, the power management module switches the in-vehicle terminal's operating state to a sleep state.

[0046] Meanwhile, the vehicle-mounted terminal is also equipped with a digital wake-up module and a monitoring port, enabling it to be woken from sleep mode under the remote control of a remote service platform. The digital wake-up module manages the start / stop of the monitoring port by determining the current operating status of the vehicle-mounted terminal. Specifically, the digital wake-up module can obtain the current operating status of the vehicle-mounted terminal from the power management module. The power management module can also notify the digital wake-up module of its current operating status. For example, when the vehicle is turned off, the power management module switches the vehicle-mounted terminal into a shallow sleep state and then sends a status change notification to the digital wake-up module. Using this method, the digital wake-up module can promptly detect changes in the vehicle-mounted terminal's status, providing accurate information for subsequent monitoring port start / stop decisions.

[0047] In addition, the current operating status of the vehicle terminal can be obtained in other ways. For example, the digital wake-up module can periodically query the power management module through polling; or it can passively receive notifications when the status changes through an interrupt mechanism. These methods all enable the digital wake-up module to obtain real-time status information of the vehicle terminal.

[0048] In this application, the current operating state can be understood as the operating mode of the vehicle terminal at a certain moment, which includes at least a shallow sleep state and a non-shallow sleep state. The shallow sleep state indicates a low-power state where the power consumption is lower than the preset power consumption when the vehicle is parked. In this state, the vehicle terminal disables some service functions but maintains cellular network connectivity, allowing for rapid response to wake-up requests. Specifically, after the vehicle is turned off and locked (typically after 30 minutes to 1 hour without any wake-up events), the Electronic Control Unit (ECU) and T-Box actively disable unnecessary modules (such as the central control screen, ambient lighting, and high-power sensors), but retain some circuit power for listening for wake-up signals. Furthermore, the non-shallow sleep state includes at least a deep sleep state and a normal operating state. The deep sleep state is usually automatically triggered when the vehicle is parked for a long time (several hours to several days) or when the battery voltage is low; in this case, the remote control function is disabled, requiring manual vehicle starting or physical key activation to restore full functionality. The normal operating state indicates that the vehicle terminal functions normally and does not require waking up.

[0049] It should be noted that accurately obtaining the current operating status of the vehicle terminal provides a necessary prerequisite for subsequent determination of whether the preset wake-up conditions are met. Only based on accurate status information can we ensure that the start and stop operations of the monitoring port are precisely matched with actual needs, avoiding extra power consumption caused by starting monitoring at inappropriate times, or missing the wake-up request due to failure to start monitoring in time when it is needed.

[0050] Step 202: If the current working state meets the preset wake-up conditions, start the listening port to receive the connection and wake-up command from the remote service platform through the listening port to wake up the vehicle terminal.

[0051] Specifically, after acquiring the current operating state of the vehicle terminal, the digital wake-up module compares the current operating state with preset wake-up conditions. In this embodiment, the preset wake-up conditions include the vehicle terminal being in a shallow sleep state and the absence of a preset wake-up source. If the current operating state simultaneously meets both of these sub-conditions, it is determined that the preset wake-up conditions are met, and the digital wake-up module starts listening to the port.

[0052] Specifically, the digital wake-up module first determines whether the vehicle terminal is in a shallow sleep state. If so, it further checks whether a preset wake-up source exists. A preset wake-up source can be a running service or event that actively wakes the vehicle terminal from sleep. For example, preset wake-up sources may include remote wake-up commands (TCP connections or SMS messages from a remote service platform), local physical events (such as door unlocking, key proximity, or pressing the start button), timed wake-up (the expiration of a timer within the vehicle terminal), and service requests (such as upgrade tasks or remote diagnostic commands). If no such wake-up source exists, the condition of no preset wake-up source is met. When both the shallow sleep state and the absence of a preset wake-up source are met, the digital wake-up module starts listening on the port and passively listens for connection requests from the remote service platform.

[0053] In practical applications, the specific means to implement the above-mentioned function of starting the listening port can include: At the software level, the digital wake-up module calls the socket interface provided by the operating system to create a TCP socket, bind it to the specified port, and call the listen function to enter the listening state; at the same time, it registers a connection event callback function so that it can handle connection requests in a timely manner. At the hardware level, the cellular network module maintains power supply to keep the private network online, so that the listening port is in an available state.

[0054] After the listening port of the vehicle terminal is activated, if there is a connection request and wake-up command sent by the remote service platform, the digital wake-up module can wake up the vehicle terminal by processing the connection request and wake-up command, that is, realize the switching of the working state of the vehicle terminal, that is, switching from the shallow sleep state to the working state.

[0055] Step 203: If the current working state does not meet the preset wake-up conditions, close the listening port. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

[0056] Specifically, if the digital wake-up module determines that the vehicle terminal is not in a shallow sleep state, or although it is in a shallow sleep state but a preset wake-up source exists, then it determines that the current working state does not meet the preset wake-up conditions. In this case, if the listening port has already been started, the digital wake-up module will close the listening port. As a specific implementation method, closing the listening port can include stopping accepting new connection requests, disconnecting existing connections, releasing socket resources, and deregistering connection event callback functions. This method can release system resources in a timely manner and avoid unnecessary power consumption.

[0057] By controlling the start and stop of the listening port as described above, technical issues such as invalid resource occupation, security risks, and cross-domain state mismatch are resolved. Specifically, if the listening port is always open, the SOC kernel needs to allocate a socket descriptor, maintaining port listening and continuous processing even in normal operation and deep sleep states, which leads to unnecessary resource waste. Meanwhile, this application closes the listening port in non-shallow sleep states or when a preset wake-up source exists. In this case, even if an attacker obtains the address of the vehicle terminal and sends a connection request, no processing will be initiated because the vehicle terminal port is closed, further improving the security of the vehicle terminal. Furthermore, by using the operating state as the trigger condition for starting and stopping the vehicle terminal's listening port, this application also achieves cross-domain linkage between the communication layer and the power management layer.

[0058] In one embodiment of this application, step 202 above, waking up the vehicle terminal by receiving connection and wake-up commands from the remote service platform through the listening port, includes: Step 2021: Receive a connection request sent by the remote service platform through the listening port, and establish a connection with the remote service platform after verifying the connection request.

[0059] Specifically, the connection request received through the listening port can be a TCP connection request sent by the remote service platform based on TCP (Transmission Control Protocol). In other embodiments, the connection request can also be a UDP connection request sent based on UDP (User Datagram Protocol). Furthermore, the connection request can also use other custom transport protocols; this embodiment does not specifically limit the network protocol used for the connection request.

[0060] After receiving a connection request through the listening port, the digital wake-up module first performs a security check on the connection request. Only after the security check passes will a connection be established with the remote service platform. If the check fails, the connection with the remote service platform will be refused to ensure the security of the vehicle terminal.

[0061] As a specific implementation of this embodiment, the step 2021 above, which establishes a connection with the remote service platform after the connection request is verified, includes: if the number of connection requests is less than or equal to a preset number, and the connection duration is less than or equal to a preset duration, then a connection is established with the remote service platform.

[0062] Specifically, upon receiving a connection request, the digital wake-up module first determines the number of currently received connection requests. For example, the digital wake-up module can maintain a concurrent connection counter. If the number of connection requests received at the same time exceeds a preset number (e.g., 5), it is determined to be a suspected denial-of-service attack, and subsequent requests are directly discarded. This can prevent malicious attacks and resource abuse.

[0063] When the Wake-up module determines that the number of connection requests meets a preset condition (i.e., the number of connection requests is less than or equal to a preset number), it further verifies the connection duration of the current connection request. For example, the Wake-up module can set a timer. If the remote service platform fails to complete the handshake or send valid data within a specified time (e.g., 10 seconds) after initiating a connection, the Wake-up module will forcibly disconnect the connection to prevent malicious clients from occupying server resources without transmitting data.

[0064] Step 2022: Receive the wake-up command sent by the remote service platform, and wake up the vehicle terminal after verifying the wake-up command.

[0065] Specifically, the wake-up command sent by the remote service platform is usually encrypted. Therefore, after receiving the wake-up command, the digital wake-up module first decrypts it using a pre-stored digital wake-up key, obtaining the signature and message information within the command. Then, it verifies both the signature and the message information. The signature verification ensures the consistency and integrity of the wake-up message, guaranteeing it hasn't been intercepted or tampered with by other devices, thus ensuring its security. It also guarantees that the wake-up message was sent by a trusted remote service platform. The message information verification further confirms that the wake-up message was indeed sent by a trusted remote service platform.

[0066] As a specific implementation of this embodiment, the step 2022 above, in which the vehicle terminal is woken up after the wake-up command verification is passed, may specifically include the following steps: Step a1: Determine whether the data volume of the wake-up command message information meets the preset conditions.

[0067] Specifically, after obtaining the signature and message information, this embodiment first determines the data volume of the message information. If the wake-up message has not been tampered with or the remote service platform has not sent an incorrect message, the data volume of the wake-up message will theoretically not be too large. Therefore, the security of the wake-up message can be verified by combining preset conditions. These preset conditions include a preset data volume, such as 256 bytes. If the data volume of the wake-up message is not less than the preset data volume, it indicates that the wake-up message may have been tampered with or the remote service platform has sent an incorrect message. In this case, the subsequent verification process can be discontinued. That is, the wake-up process fails, and the digital wake-up module can report the wake-up failure information to the remote service platform.

[0068] Step a2: If the amount of data in the wake-up command message meets the preset conditions, the signature of the wake-up command is verified using a pre-stored digital wake-up key.

[0069] Specifically, if the data volume of the wake-up command message meets preset conditions, the signature of the wake-up command can be further verified. The signature verification process can be implemented using relevant technologies. For example, the plaintext digest obtained by decrypting the signature using the digital wake-up key is compared with the digest obtained by hashing the message information. If they match, the signature verification is successful.

[0070] Step a3: After the signature verification is passed, the start character of the wake-up command message information is verified.

[0071] Specifically, after the signature verification passes, the starting character of the message information is verified. For example, it can check whether the message header contains a specific protocol start character (such as "%A"), which can quickly filter out non-protocol format wake-up commands and ensure the security of the vehicle terminal.

[0072] Step a4: After the starting character verification passes, the timestamp of the message information is verified.

[0073] Specifically, the wake-up command message usually includes timestamp information. After the start character verification passes, the timestamp information in the message information is further obtained, and the timestamp is compared with the local time to determine whether the difference between the two is within the tolerance range. For example, if the difference between the two is within the ±5 second tolerance range, the timestamp verification passes; otherwise, the command is determined to be a replay attack or an expired command and is rejected.

[0074] Step a5: After the timestamp verification is passed, the vehicle identification code of the message information is verified.

[0075] Specifically, the Vehicle Identification Number (VIN) is a unique identifier representing a vehicle. If the timestamp verification passes, the VIN in the message information is compared with the locally stored VIN. If they match, the verification passes; otherwise, the verification fails, and the wake-up command is rejected.

[0076] Step a6: After the vehicle identification code is verified, the block check character of the message information is verified.

[0077] Specifically, the Block Check Character (BCC), also known as XOR check, is a check character added after the data segment of a frame to determine whether the data block transmission has errors. Based on this, this embodiment further checks whether the block check character in the message information matches the locally stored block check character; if they match, the check passes.

[0078] Step a7: After the block verification character passes the verification, the wake-up command is confirmed to have passed the verification, and the power management module is used to wake up the vehicle terminal. Specifically, when all the above verifications pass, the wake-up command verification passes, and the power management module can be used to switch the working state of the vehicle terminal to wake it up.

[0079] In one embodiment of this application, after receiving a connection request sent by a remote service platform through the listening port, the method further includes: if the address information corresponding to the connection request is in a pre-built blocking list, refusing to establish a connection with the remote service platform, wherein the pre-built blocking list is dynamically updated, and the dynamic update includes determining whether to add the address information of the remote service platform to the blocking list based on whether the connection request passes verification and whether the wake-up command passes verification.

[0080] Specifically, this embodiment also maintains a blocking list, which is dynamically updated based on the communication process between the vehicle terminal and the remote service platform. Specifically, each time the vehicle terminal is woken up via the remote service platform, the vehicle terminal determines whether to add the remote service platform to the blocking list based on whether the connection request and wake-up command to the remote service platform pass verification.

[0081] As a specific implementation of this embodiment, the blocking list may include a dynamic blocking list and a long-term blocking list, wherein the validity period of the long-term blocking list is longer than that of the dynamic blocking list. For example, the validity period of the long-term blocking list is 24 hours, while the validity period of the dynamic blocking list is 30 minutes. In practical applications, the address of the remote service platform can be added to the dynamic blocking list or the long-term blocking list based on the specific object that fails the verification.

[0082] In this embodiment, if the connection time with the remote service platform expires, the remote service platform is added to the dynamic blocking list; if the data volume of the wake-up command message does not meet the preset conditions, the number of abnormalities of the remote service platform is increased by one; if the cumulative number reaches three, the address information of the remote service platform is added to the long-term blocking list.

[0083] It should be noted that once any remote service platform has been added to the blacklist for the required period, it can be removed from the blacklist. Furthermore, new remote service platforms may be added to the blacklist through the wake-up process of the vehicle terminal, thus achieving dynamic updates to the blacklist.

[0084] Based on this dynamically updated blocking list, when the vehicle terminal receives a new connection request, it first compares the address information of the remote service platform that sent the request with the blocking list. If the address information of the remote service platform is in the blocking list, the connection of the remote service platform is directly rejected and recorded in the log. If the address information of the remote service platform is not in the blocking list, the connection, verification, and wake-up process described in steps 201 and 202 above is executed.

[0085] Based on the aforementioned vehicle-mounted terminal remote wake-up system, this application provides a method for remote wake-up of a vehicle-mounted terminal, which is applied to a remote service platform. Figure 3 This is a schematic flowchart illustrating a remote wake-up method for a vehicle-mounted terminal provided in an embodiment of this application, such as... Figure 3 As shown, the method includes: Step 301: Send connection and wake-up commands to the vehicle terminal to wake up the vehicle terminal. The vehicle terminal includes a power management module, a digital wake-up module, and a listening port. The power management module is used to manage the working state of the vehicle terminal, which includes a shallow sleep state and a non-shallow sleep state. The digital wake-up module is used to start the listening port to receive connection and wake-up commands when the current working state of the vehicle terminal meets the preset wake-up conditions, and to shut down the listening port when the current working state of the vehicle terminal does not meet the preset wake-up conditions. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

[0086] Specifically, the remote service platform can send a connection request to the vehicle terminal based on the control signal initiated by the user terminal, enabling the vehicle terminal to establish a connection with the remote service platform based on the connection request. Furthermore, the remote service platform can generate and send a wake-up command to the vehicle terminal based on the established connection.

[0087] In one embodiment of this application, step 301 above, sending a connection and wake-up command to the vehicle terminal to wake up the vehicle terminal, may specifically include: Step 3011: When it is determined that the vehicle terminal has remote wake-up capability, obtain the address information of the vehicle terminal when it is registered based on the dedicated network.

[0088] Specifically, after receiving a remote control signal initiated by a user terminal, the remote service platform can first determine whether the vehicle terminal to be woken up has remote wake-up capability. For example, the remote service platform can obtain the vehicle's digital wake-up capability bit based on the vehicle model information contained in the remote control signal or relevant information during vehicle registration. This capability bit is a status identifier used to distinguish whether the vehicle has remote wake-up capability. If the capability bit is 0 (no remote wake-up capability), the remote service platform will automatically downgrade to the SMS wake-up process; if the capability bit is 1 (remote wake-up capability), the digital wake-up process will continue.

[0089] Once it is determined that the vehicle-mounted terminal has remote wake-up capability, the address information of the vehicle-mounted terminal is further obtained. This address information includes, but is not limited to, the Internet Protocol address (IP address) and port number of the vehicle-mounted terminal. In practical applications, the Internet Protocol address (IP address) of the vehicle-mounted terminal can specifically be the static IP address of the vehicle-mounted terminal.

[0090] As a specific implementation, the remote service platform can send a query request to the Connectivity Management Platform (CMP) to obtain the address information of the vehicle terminal. The CMP, as the operator's IoT card management platform, is responsible for managing the SIM card's session state. The platform inputs the vehicle's identification code, and the CMP returns the static IP address and port number (i.e., the listening port number) assigned to the vehicle terminal when registering on the APN (Access Point Name) private network. Communicating through a private network effectively avoids public network congestion and interference, ensuring reliable delivery of wake-up commands. Before obtaining the address information, the vehicle terminal obtains a pre-configured APN private network, then dials through the APN to obtain a dialing signal, and finally obtains the static IP address based on the dialing information.

[0091] Step 3012: Send a connection request to the vehicle terminal based on the address information to establish a connection with the vehicle terminal; specifically, after the remote service platform obtains the address information of the vehicle terminal, it can send a connection request, such as a Transmission Control Protocol (TCP) connection request, to the vehicle terminal based on the Internet Protocol address and port number in the address information to request the establishment of a connection with the vehicle terminal.

[0092] Step 3013: Send a wake-up command to the vehicle terminal to wake it up. Before sending the wake-up command, the remote service platform can first generate message information based on the vehicle identification number and block check character, then perform hash calculation on the message information to obtain plaintext digest information, and encrypt the plaintext digest information using a digital wake-up key to obtain a signature. The signature and message information are then encrypted and used as the wake-up command, which is sent to the vehicle terminal based on the established connection.

[0093] In one embodiment of this application, the method further includes: receiving a login request sent by a woken-up vehicle terminal, the login request carrying a digital wake-up capability bit; and disconnecting the connection with the vehicle terminal when the login is successful.

[0094] Specifically, after the vehicle-mounted terminal is activated by the connection and wake-up command sent by the remote service platform, it sends a login request to the remote service platform. This login request includes its digital wake-up capability bit, used to reconfirm its status with the remote service platform. The remote service platform receives the login request and performs authentication. Once the remote service platform confirms successful login and that the vehicle-mounted terminal is operational, it will proactively disconnect from the vehicle-mounted terminal. This prevents connection hijacking or abuse.

[0095] Figure 4 This is a flowchart of a key acquisition method according to an embodiment of this application, such as... Figure 4 As shown, after the vehicle terminal logs into the remote service platform, it can initiate a key request to the remote service platform (TSP) and receive a digital wake-up key issued by the platform. Then, based on the received digital wake-up key, it checks the locally stored digital wake-up key. If the locally stored key is empty, the digital wake-up key issued by the remote service platform is saved; if the received key and the locally stored key are inconsistent, the locally stored key is updated. If the received key and the locally stored key match, the locally stored key is maintained. The resulting local wake-up key can then be used in subsequent wake-up command signature verification or message decryption scenarios.

[0096] This application also provides a vehicle terminal remote wake-up system, which includes a vehicle terminal, a power management module, a digital wake-up module, and a listening port. The digital wake-up module is used to execute the vehicle terminal remote wake-up method in the above embodiments, and a remote service platform is used to execute the vehicle terminal remote wake-up method in the above embodiments.

[0097] Figure 5 Schematic diagram of the structure of the vehicle terminal remote wake-up system provided in the embodiments of this application Figure 2 ,like Figure 5 As shown, the system can be divided into four layers: a cloud platform layer, a network layer, an in-vehicle terminal layer, and a security protection layer. The cloud platform layer is responsible for command generation, key management, static IP address lookup, and connection establishment, specifically including a remote service platform and a connection management platform. The network layer provides a secure and reliable communication channel through an APN private network, isolated from the internet and free from public network congestion. The in-vehicle terminal layer includes a power management module, a digital wake-up module, and a monitoring port. The in-vehicle terminal layer maintains network monitoring capabilities in a shallow sleep state, and the digital wake-up module obtains the current operating status through the power management module to control the start and stop of the monitoring port. The security protection layer ensures the system is protected from malicious wake-up attacks through multiple security mechanisms, including connection limit, connection duration limit, data packet limit, and shielding mechanisms.

[0098] To more clearly illustrate the technical solutions provided in the embodiments of this application, the following is in conjunction with... Figure 6 and Figure 7 The working principle of the vehicle-mounted terminal remote wake-up system provided in this application is explained as follows: Step 1: System initialization configuration.

[0099] (1) APN private network configuration. The vehicle terminal uses the APN private network for dial-up registration and obtains a static IP address.

[0100] (2) TCP service establishment. By creating a TCP server (i.e., vehicle terminal) on a specified port, it only responds to APN private network requests and filters non-private network traffic.

[0101] (3) Key pre-configuration: When the vehicle terminal logs into the remote service platform (also known as the TCP client), it obtains the digital wake-up key and completes local storage.

[0102] Step 2: Management of shallow hibernation state.

[0103] (1) The power management module monitors the system status in real time.

[0104] (2) If the current working state is a shallow sleep state and there is no wake-up source, start the listening port and register the connection event callback; if the current working state is normal operation, all business functions can be run directly; if the current working state is a deep sleep state, turn off the cellular module and enter the lowest power consumption state; if the current working state is a shallow sleep state but there is a wake-up source, turn off the listening port and keep other wake-up channels open.

[0105] (3) Keep the cellular module powered, keep the APN private network online, and keep the listening port available.

[0106] Step 3: Digital wake-up command processing.

[0107] (1) When the remote service platform receives the user's remote control signal, it checks whether the vehicle terminal has remote wake-up capability (i.e., checks the digital wake-up capability bit), and then queries the static IP address of the vehicle terminal through the connection management platform to initiate a TCP connection to the vehicle terminal.

[0108] (2) Verify the legitimacy of the client through a multi-layered security protection mechanism, including checking the block list, checking the number of connections (≤5), and checking the connection duration.

[0109] (3) The vehicle terminal receives the wake-up command. After parsing the wake-up command, it first performs data volume verification of the message information; then performs signature verification; and then performs the following four verifications: start character verification (%A); timestamp verification (±5 seconds tolerance); VIN number consistency verification; BCC check code verification. If the verification fails, it switches to SMS wake-up.

[0110] Step 4: Activate execution and provide feedback.

[0111] After successful verification, the vehicle terminal is woken up. The vehicle terminal actively logs into the remote service platform and reports the digital command wake-up capability bit. After successful login, the remote service platform actively disconnects the TCP connection.

[0112] Step 5: Exception handling mechanism.

[0113] (1) Verification failed: Switch to the traditional SMS wake-up process.

[0114] (2) Timeout handling: Failure to log in within 45 seconds is considered a wake-up failure.

[0115] (3) Security protection: triggering security measures such as updating the block list and disconnecting the connection.

[0116] (4) Connection timeout (10 seconds): Force disconnection, address added to dynamic blocking list (30 minutes).

[0117] (5) Data exceeds 256 bytes: Force disconnect, increment the address's abnormal count by 1, and add it to the long-term blocking list (24 hours) after 3 abnormal counts. When the abnormal count of an address reaches 3 times, it indicates that the address has continuous abnormal behavior, and the vehicle terminal adds it to the long-term blocking list, which is valid for 24 hours. During this period, all TCP connection requests for this address will be directly rejected by the vehicle terminal.

[0118] (6) Remote service platforms in the block list: directly refuse connection and record log.

[0119] In this application, a mechanism for on-demand activation and deactivation of the vehicle terminal's monitoring port is implemented, activating monitoring only in shallow sleep mode and when there is no wake-up source; otherwise, it is immediately deactivated to avoid resource consumption. This ensures that the activation and deactivation of the vehicle terminal's monitoring port precisely matches the actual vehicle status. During shallow sleep, the cellular module maintains online access to the APN private network, but replaces the traditional client heartbeat keep-alive mode with a server-side standby mode, significantly reducing power consumption. Furthermore, remote connection and wake-up commands replace SMS, reducing costs by over 90%. APN private network communication avoids public network transmission costs and reliability issues. Direct connection based on static IP reduces relay links. Simultaneously, the APN private network ensures connection stability and eliminates public network congestion; quadruple message verification ensures that only legitimate commands trigger wake-up, preventing false wake-ups; and automatic fallback to SMS wake-up when digital wake-up fails ensures functional availability.

[0120] Figure 8 Schematic diagram of the structure of the vehicle terminal remote wake-up device provided in the embodiments of this application Figure 1 The vehicle-mounted terminal includes a power management module, a digital wake-up module, and a listening port. The power management module manages the operating state of the vehicle-mounted terminal, which includes a shallow sleep state and a non-shallow sleep state. The remote wake-up device for the vehicle-mounted terminal is applied to the digital wake-up module, such as... Figure 8 As shown, the device includes: Status acquisition module 801 is used to acquire the current working status of the vehicle terminal; The port startup module 802 is used to start the listening port when the current working state meets the preset wake-up conditions, so as to wake up the vehicle terminal by receiving the connection and wake-up instructions of the remote service platform through the listening port. The port shutdown module 803 is used to shut down the listening port when the current working state does not meet the preset wake-up conditions. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

[0121] In one embodiment of this application, the port startup module specifically includes: The connection module is used to receive connection requests sent by the remote service platform through the listening port, and establish a connection with the remote service platform after verifying the connection request. The wake-up module is used to receive the wake-up command sent by the remote service platform and wake up the vehicle terminal after verifying the wake-up command.

[0122] In one embodiment of this application, the connection module is specifically used to: establish a connection with the remote service platform if the connection duration is less than or equal to the preset duration when the number of connection requests is less than or equal to the preset number.

[0123] In one embodiment of this application, the wake-up module is specifically used to: determine whether the data volume of the wake-up command message information meets a preset condition; if the data volume of the wake-up command message information meets the preset condition, verify the signature of the wake-up command using a pre-stored digital wake-up key; after the signature verification passes, verify the start character of the wake-up command message information; after the start character verification passes, verify the timestamp of the message information; after the timestamp verification passes, verify the vehicle identification code of the message information; after the vehicle identification code verification passes, verify the block check character of the message information; after the block check character verification passes, determine that the wake-up command verification passes, and wake up the vehicle terminal using the power management module.

[0124] In one embodiment of this application, the connection module is further configured to: refuse to establish a connection with the remote service platform if the address information corresponding to the connection request is in a pre-built blocking list, wherein the pre-built blocking list is dynamically updated, and the dynamic update includes determining whether to add the address information of the remote service platform to the blocking list based on whether the connection request passes verification and whether the wake-up command passes verification.

[0125] Figure 9 Schematic diagram of the structure of the vehicle terminal remote wake-up device provided in the embodiments of this application Figure 2 This vehicle-mounted terminal remote wake-up device is used in remote service platforms, such as... Figure 9 As shown, the device includes: The sending module 901 is used to send connection and wake-up commands to the vehicle terminal to wake up the vehicle terminal. The vehicle terminal includes a power management module, a digital wake-up module, and a listening port. The power management module is used to manage the working state of the vehicle terminal, which includes a shallow sleep state and a non-shallow sleep state. The digital wake-up module is used to start the listening port to receive connection and wake-up commands when the current working state of the vehicle terminal meets the preset wake-up conditions, and to shut down the listening port when the current working state of the vehicle terminal does not meet the preset wake-up conditions. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

[0126] In one embodiment of this application, the sending module is specifically used to: when it is determined that the vehicle terminal has remote wake-up capability, obtain the address information of the vehicle terminal when it is registered on a dedicated network; send a connection request to the vehicle terminal based on the address information to establish a connection with the vehicle terminal; and send a wake-up command to the vehicle terminal to wake up the vehicle terminal.

[0127] In one embodiment of this application, the vehicle terminal remote wake-up device further includes: a login module, configured to receive a login request sent by the woken-up vehicle terminal, the login request carrying a digital wake-up capability bit; and disconnect the connection with the vehicle terminal when login is successful.

[0128] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0129] Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 10 As shown, the electronic device of this embodiment includes a processor 1001 and a memory 1002.

[0130] The memory 1002 stores computer execution instructions; the processor 1001 executes the computer execution instructions stored in the memory to implement the various steps performed by the electronic device in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0131] Alternatively, the memory 1002 can be either standalone or integrated with the processor 1001.

[0132] When the memory 1002 is set up independently, the electronic device also includes a bus 1003 for connecting the memory 1002 and the processor 1001.

[0133] This application also provides a vehicle, which includes: an in-vehicle terminal, the in-vehicle terminal including a power management module, a digital wake-up module and a listening port, the digital wake-up module being used to execute the in-vehicle terminal remote wake-up method described in the above embodiments.

[0134] This application also provides a computer storage medium storing computer execution instructions. When the processor executes the computer execution instructions, the above-described vehicle terminal remote wake-up method is implemented.

[0135] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the above-described vehicle terminal remote wake-up method.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0137] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0138] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0139] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0140] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0141] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0142] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0143] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0144] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. Both the processor and the storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.

[0145] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0146] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for remote wake-up of a vehicle-mounted terminal, characterized in that, The vehicle-mounted terminal includes a power management module, a digital wake-up module, and a listening port. The power management module manages the operating state of the vehicle-mounted terminal, which includes a shallow sleep state and a non-shallow sleep state. The method is applied to the digital wake-up module and includes: Obtain the current working status of the vehicle terminal; When the current working state meets the preset wake-up conditions, the listening port is activated to receive connection and wake-up commands from the remote service platform through the listening port to wake up the vehicle terminal; If the current working state does not meet the preset wake-up conditions, the listening port is closed. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

2. The method for remote wake-up of a vehicle terminal according to claim 1, characterized in that, The vehicle terminal is woken up by receiving connection and wake-up commands from the remote service platform through the listening port, including: The system receives connection requests sent by the remote service platform through the listening port, and establishes a connection with the remote service platform after verifying the connection request. The system receives a wake-up command sent by the remote service platform and wakes up the vehicle terminal after verifying the wake-up command.

3. The method for remote wake-up of a vehicle terminal according to claim 2, characterized in that, After the connection request is verified, a connection is established with the remote service platform, including: If the number of connection requests is less than or equal to a preset number, and the connection duration is less than or equal to a preset duration, then a connection is established with the remote service platform.

4. The method for remote wake-up of a vehicle terminal according to claim 2, characterized in that, After the wake-up command is verified, the vehicle terminal is woken up, including: Determine whether the data volume of the wake-up command message meets the preset conditions; If the amount of data in the wake-up command message meets the preset conditions, the signature of the wake-up command is verified using a pre-stored digital wake-up key. After the signature verification is passed, the start character of the wake-up command message information is verified. After the initial character verification passes, the timestamp of the message information is verified. After the timestamp verification is passed, the vehicle identification number of the message information is verified. After the vehicle identification code is verified, the block check character of the message information is verified. After the block verification character passes the verification, it is determined that the wake-up command has passed the verification, and the power management module is used to wake up the vehicle terminal.

5. The method for remote wake-up of a vehicle terminal according to claim 2, characterized in that, After receiving a connection request from a remote service platform through the listening port, the method further includes: If the address information corresponding to the connection request is in a pre-built blocking list, the connection with the remote service platform is refused. The pre-built blocking list is dynamically updated, and the dynamic update includes determining whether to add the address information of the remote service platform to the blocking list based on whether the connection request is verified and whether the wake-up command is verified.

6. A method for remote wake-up of a vehicle-mounted terminal, characterized in that, Applied to a remote service platform, the method includes: A connection and wake-up command is sent to the vehicle terminal to wake it up. The vehicle terminal includes a power management module, a digital wake-up module, and a listening port. The power management module manages the working state of the vehicle terminal, which includes a shallow sleep state and a non-shallow sleep state. The digital wake-up module activates the listening port to receive connection and wake-up commands when the current working state of the vehicle terminal meets preset wake-up conditions, and deactivates the listening port when the current working state of the vehicle terminal does not meet the preset wake-up conditions. The preset wake-up conditions include that the vehicle terminal is in a shallow sleep state and there is no preset wake-up source at present.

7. The method for remote wake-up of a vehicle terminal according to claim 6, characterized in that, Sending connection and wake-up commands to the vehicle terminal to wake it up includes: When it is determined that the vehicle terminal has remote wake-up capability, the address information of the vehicle terminal when it is registered based on the dedicated network is obtained; Based on the address information, a connection request is sent to the vehicle terminal to establish a connection with the vehicle terminal; A wake-up command is sent to the vehicle terminal to wake it up.

8. The method for remote wake-up of a vehicle terminal according to claim 6, characterized in that, The method further includes: Receive a login request sent by the woken-up vehicle terminal, the login request carrying a digital wake-up capability bit; Upon successful login, disconnect from the vehicle terminal.

9. A vehicle-mounted terminal remote wake-up system, characterized in that, The system includes: A vehicle-mounted terminal, the vehicle-mounted terminal including a power management module, a digital wake-up module and a listening port, the digital wake-up module being used to execute the vehicle-mounted terminal remote wake-up method according to any one of claims 1-5; A remote service platform for executing the vehicle terminal remote wake-up method according to any one of claims 6-8.

10. A vehicle, characterized in that, The vehicle includes an on-board terminal, which includes a power management module, a digital wake-up module, and a listening port. The digital wake-up module is used to execute the on-board terminal remote wake-up method according to any one of claims 1-5.

Images