WIFI flow control method, electronic equipment and vehicle

Abstract

The invention provides a WIFI flow control method, electronic equipment and a vehicle, which can determine the flow setting of a hot spot by decrypting and encrypting response when the WIFI is successfully interconnected with the hot spot, the hot spot declarates that the network type is a non-charging network, and the hot spot type is a mobile terminal hot spot, and perform dynamic flow limit control according to the flow setting of the hot spot and the service type. After the WIFI connection hotspot is determined to be in the non-charging mode, information of the hotspot equipment is inquired through the verification request packet, and when the hotspot is a mobile interruption hotspot, the limitation condition of the hotspot equipment on the shared traffic is determined through the hotspot traffic setting; and through dynamic flow limiting control, it is ensured that the core service can be used, meanwhile, part of non-core services are limited, dynamic flow limiting control set according to the service type and the hotspot flow is achieved, normal use of the vehicle core function is ensured, meanwhile, abnormal user flow loss is avoided, the user flow sharing cost is saved, and the user experience is improved. And the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle network control technology, and in particular to a WIFI traffic control method, electronic device and vehicle. Background Technology

[0002] The vehicle connects to an external hotspot via WiFi, but it's unclear whether the hotspot is provided by a mobile phone, router, or other device. Regardless of whether it's a mobile device or another, the vehicle's infotainment system will be informed that it's in a non-billing mode. When the external hotspot is provided by a mobile phone, the lack of effective data usage control mechanisms could lead to abnormal data loss for mobile users after prolonged use. Summary of the Invention

[0003] In view of this, the purpose of this application is to propose a WIFI traffic control method, electronic device and vehicle, which performs traffic control when WIFI and mobile terminal hotspot connection is detected, so as to ensure that core functions can be used while avoiding abnormal loss of user traffic.

[0004] To achieve the above objectives, this application provides a WIFI traffic control method, comprising: In response to the successful interconnection between WIFI and the hotspot, and the hotspot declares the network type as a non-billing network, a constructed verification request packet is sent to the hotspot device providing the hotspot, so that the hotspot device can return an encrypted response based on the verification request packet; The hotspot type is determined based on the encrypted response; In response to the hotspot type being a mobile terminal hotspot, the hotspot traffic settings are determined by decrypting the encrypted response, and dynamic traffic restriction control is performed based on the hotspot traffic settings and service type.

[0005] Optionally, the dynamic traffic restriction control based on the hotspot traffic settings and service type includes: In response to the hotspot traffic setting being configured to have valid traffic, the local system policy layer sets the current WIFI mode to billing mode and marks the hotspot as a billing network; Dynamic traffic limiting control is performed based on the service type and the effective traffic settings.

[0006] Optionally, the dynamic traffic limiting control based on the service type and the effective traffic settings includes: The initial available traffic is determined based on the effective traffic settings. The disabled and available services are determined based on the initial available traffic, the network speed requirements of each service, and the service type. The disabled service is prohibited from using hotspot traffic, and the real-time available traffic is determined based on a preset time interval and the initial available traffic, and the real-time available traffic is displayed. The available services are updated based on the real-time available traffic and the service type.

[0007] Optionally, determining the real-time available traffic based on a preset time interval and the initial available traffic includes: The used traffic of the available service is determined based on the time interval; The difference between the initial available traffic and the used traffic is determined as the real-time available traffic.

[0008] Optionally, updating the available services based on the real-time available traffic and the service type includes: The current traffic restriction level is determined based on the real-time available traffic and the preset traffic restriction relationship; Based on the current traffic disabling level and the service type, identify new disabled services from the available services and delete the newly disabled services identified from the available services.

[0009] Optionally, the WIFI traffic control method also includes: The security threshold traffic is determined based on the initial available traffic and the preset security factor; In response to the fact that the used traffic is greater than or equal to the safety threshold traffic, but less than the initial available traffic, a traffic usage warning is issued based on the real-time available traffic. In response to the used traffic being greater than or equal to the initial available traffic, all non-core services in the available services are deleted, and the warning level is increased.

[0010] Optionally, determining the disabled and available services based on the initial available traffic, the network speed requirements of each service, and the service type includes: In response to the fact that the service type is a core service, the core service is determined to be a mandatory available service; In response to the fact that the service type is a non-core service, the initial available traffic disabling level is determined based on the initial available traffic, and the initially disabled service and the initially available service are determined in the non-core service based on the initial available traffic disabling level; Based on the network speed requirements and the initial available traffic, a service is temporarily unblocked from the initially disabled services; The available services are obtained by integrating the initially available services, the required available services, and the temporarily unblocked services; The temporarily unblocked services in the initially disabled services are deleted to obtain the disabled services.

[0011] Optionally, the verification request package includes a device query request and a traffic configuration query request; the device query request is used to query whether the hotspot device is a mobile terminal; the traffic configuration query request is used to query the traffic package limit or custom hotspot limit of the hotspot device.

[0012] Based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the method described above when executing the computer program.

[0013] Based on the same inventive concept, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing a computer to perform the method described above.

[0014] As can be seen from the above, the WIFI traffic control method, electronic device, and vehicle provided in this application can successfully connect to a WIFI hotspot, and when the hotspot declares its network type as a non-billing network, send a constructed verification request packet to the hotspot device providing the hotspot. The hotspot device then returns an encrypted response based on the verification request packet. The hotspot type is determined based on the encrypted response. If the hotspot type is a mobile terminal hotspot, the hotspot traffic settings are determined by decrypting the encrypted response, and dynamic traffic restriction control is performed based on the hotspot traffic settings and service type. After confirming successful WIFI and hotspot connection and that it is in non-billing mode, the information of the hotspot device is queried through the verification request packet. When the hotspot is a mobile interrupted hotspot, the hotspot traffic settings determine the hotspot device's restrictions on shared traffic. Dynamic traffic restriction control ensures that core services can be used while restricting some non-core services. This achieves dynamic traffic restriction control based on service type and hotspot traffic settings, ensuring the normal use of the vehicle's core functions while preventing abnormal user traffic loss, saving user traffic sharing costs, and improving the user experience. Attached Figure Description

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

[0016] Figure 1 This is a flowchart of the WIFI traffic control method according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating how an SOC chip drives a WIFI chip to establish a hotspot connection, as described in an embodiment of this application. Figure 3 This is a schematic diagram illustrating dynamic flow control in an embodiment of this application. Figure 4 This is a flowchart illustrating dynamic traffic restriction control based on service type and effective traffic settings in an embodiment of this application. Figure 5 This is a flowchart illustrating the warning mechanism for exceeding traffic limits in an embodiment of this application. Figure 6 This is a schematic diagram of a WIFI traffic control device according to an embodiment of this application; Figure 7 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0018] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0019] In this article, it is important to understand that any number of elements in the accompanying figures is for illustrative purposes and not for limitation, and any naming is for distinction only and has no limiting meaning.

[0020] Based on the above background description, the following situations also exist in the related technologies: In related technologies, the vehicle's Wi-Fi data transmission process is as follows: the in-vehicle Wi-Fi connects to an external hotspot (such as a mobile phone, T-Box network, or router hotspot) to obtain internet services. Once successfully connected to the hotspot, the vehicle's infotainment system can access online video and music content and utilize the data traffic provided by the hotspot for online playback. This allows passengers to enjoy a high-quality multimedia experience while driving.

[0021] When a vehicle's infotainment system connects to an external hotspot via its in-vehicle Wi-Fi, it doesn't actively identify the device providing the hotspot. This means the system is unsure whether the hotspot is provided by a mobile phone, router, or other device. Regardless of whether it's a mobile phone or another device, the system defaults to non-billing mode. To prevent abnormal mobile data usage, it's necessary to accurately identify whether the external hotspot is provided by a mobile phone. If so, the system should switch from non-billing to billing mode to implement data usage control on the infotainment system, effectively managing mobile data consumption when the system and the phone are connected.

[0022] In related technologies, when a mobile phone connects to the vehicle's infotainment system via WiFi, the phone acts as a hotspot. In this situation, the vehicle's infotainment system accesses the phone's non-billed network. Since the vehicle's data usage solution lacks data control measures, online multimedia applications on the vehicle's infotainment system cannot effectively manage the data usage from the mobile hotspot. Due to the lack of an effective data control mechanism, the interconnection between in-vehicle WiFi and mobile devices may lead to uncontrolled mobile data consumption, especially during prolonged use. This could result in abnormal data loss for mobile users, increasing the cost of users enabling their own hotspots for the vehicle's infotainment system and leading to a poor user experience.

[0023] The WIFI traffic control method, electronic device, and vehicle provided in this application embodiment can, upon successful WIFI and hotspot interconnection and when the hotspot declares its network type as a non-billing network, send a constructed verification request packet to the hotspot device providing the hotspot. The hotspot device then returns an encrypted response based on the verification request packet. The hotspot type is determined based on the encrypted response. If the hotspot type is a mobile terminal hotspot, the hotspot traffic settings are determined by decrypting the encrypted response, and dynamic traffic restriction control is performed based on the hotspot traffic settings and service type. After confirming successful WIFI and hotspot interconnection and that it is in non-billing mode, the information of the hotspot device is queried through the verification request packet. When the hotspot is a mobile interruption hotspot, the hotspot traffic settings determine the hotspot device's restrictions on shared traffic. Dynamic traffic restriction control ensures that core services can be used while restricting some non-core services. This achieves dynamic traffic restriction control based on service type and hotspot traffic settings, ensuring the normal use of the vehicle's core functions while preventing abnormal user traffic loss, saving user traffic sharing costs, and improving the user experience.

[0024] The following describes in detail, with reference to the accompanying drawings, the WIFI traffic control method provided by the embodiments of this application.

[0025] In some embodiments, such as Figure 1 As shown, the WIFI traffic control method includes steps 101-103.

[0026] Step 101: In response to the successful interconnection between WIFI and the hotspot, and the hotspot's declared network type as non-billing network, a pre-constructed verification request packet is sent to the hotspot device providing the hotspot, so that the hotspot device can return an encrypted response based on the verification request packet.

[0027] In practical implementation, we will take connecting a mobile hotspot to an in-vehicle Wi-Fi network as an example. A schematic diagram illustrating the communication connection between the vehicle's internal systems and an external hotspot via in-vehicle Wi-Fi is shown below. Figure 2 As shown, the vehicle's infotainment system uses a system-on-chip (SoC) to drive Wi-Fi for hotspot connections.

[0028] Among them, the in-vehicle SoC chip is a core component of the vehicle's electronic system and the core computing unit of intelligent vehicles. It highly integrates multiple processors, memory, and interface modules to handle complex tasks such as intelligent driving and intelligent cockpits. Compared to traditional microcontroller units (MCUs), SoC chips have higher integration and stronger processing capabilities. MCUs can only perform simple real-time control (such as engine management and braking) and typically run lightweight systems such as AUTOSAR CP, with limited computing power. SoC chips support complex operating systems (such as QNX / Linux / Android) and handle high-order tasks (such as autonomous driving algorithms and multi-screen interaction), with computing power reaching hundreds of TOPS. SoC chips integrate heterogeneous computing units such as the Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural Network Processing Unit (NPU), Internet Service Provider (ISP), memory, and communication interfaces onto a single chip, enabling multi-task parallel processing. The CPU cluster is responsible for system scheduling and general logic operations (such as path planning). The GPU handles graphics rendering (such as instrument panel and AR-HUD graphics rendering) and parallel computing (such as BEV bird's-eye view generation). NPUs specialize in accelerating neural networks (e.g., lane recognition).

[0029] The SoC chip provides powerful computing and graphics processing capabilities, supporting high-definition displays, multitasking, and complex user interfaces, enhancing the in-vehicle entertainment experience. Its functions include in-vehicle infotainment systems, fully digital instrument clusters, head-up displays, streaming rearview mirrors, vehicle connectivity, and in-vehicle occupant monitoring systems, providing ample computing power for the intelligence of the smart cockpit.

[0030] The Wi-Fi chip is used in smart cockpits to connect with external hotspots (such as mobile phones). It enables data transmission between the mobile phone and the vehicle's SoC chip, thereby realizing in-vehicle Wi-Fi or AP-related functions, such as mobile data traffic and video transmission between the mobile phone and the vehicle's infotainment system. The specific interaction with the mobile phone is handled by the Wi-Fi chip, and the SoC chip receives the relevant data and displays the relevant functions. The Wi-Fi chip and the SoC chip connect and transmit data through transmission methods such as Pulse Code Modulation (PCM), Universal Asynchronous Receiver / Transmitter (UART), and Peripheral Component Interconnect Express (PCIe).

[0031] PCM is used to transmit digital audio streams, primarily for audio data transmission between the WiFi chip and the SoC in automotive scenarios (such as voice assistant calls). Once a mobile hotspot connection is successful, the PCM channel transmits the mobile audio stream (such as navigation commands and music) to the vehicle's audio system. Its transmission bandwidth is 1.5Mbps, and it features low latency (<10ms).

[0032] UART provides a low-speed command control channel (typically with a baud rate of 115.2kbps). The SoC sends AT commands (such as AT+CWJAP="hotspot name", "password") to the WiFi chip via UART to control its scanning, authentication, and connection to mobile hotspots. The asynchronous nature of UART makes it suitable for control command transmissions with lower real-time requirements. Its transmission bandwidth ranges from 115Kbps to 4Mbps and it is resistant to electromagnetic interference.

[0033] PCIe serves as a high-speed data channel (with bandwidth up to 16Gbps), handling tasks involving large data transfers, such as high-precision map downloads and OTA firmware updates. After connecting to a hotspot, the phone's network data is directly transferred to the SoC's memory via PCIe, and then processed by the SoC's NPU or CPU. The SoC chip drives the WiFi chip through a layered protocol stack to complete the hotspot connection process as follows: 1. WiFi chip initialization. The SoC chip sends an AT+RST command via UART to reset the WiFi chip, load firmware, and initialize the 802.11 protocol stack (supporting WiFi 5 / 6).

[0034] 2. Hotspot scanning and authentication.

[0035] The SoC chip sends an AT+CWLAP command to trigger the WiFi chip to scan for nearby hotspots, obtaining signal strength (RSSI) and encryption method (WPA2 / WPA3). The scan results are returned to the SoC chip via UART, allowing the user or vehicle system to select a target hotspot or automatically connect to a previously secure hotspot.

[0036] 3. Secure handshake and IP allocation.

[0037] The WiFi chip executes a security protocol based on the hotspot encryption method (such as AES-CCMP encryption) and completes a four-way handshake with the SoC chip via PCIe or UART. Upon successful handshake, the mobile hotspot's DHCP server assigns an IP address, and the WiFi chip transmits the IP address back to the SoC chip via the AT+CIPSTA command.

[0038] 4. Data routing.

[0039] After the connection is established, the SoC chip sets the WiFi chip as the default gateway, receives network data packets from the mobile hotspot via PCIe, and parses and distributes them to in-vehicle applications (such as navigation and online music) by the SoC's built-in TCP / IP protocol stack (such as LwIP).

[0040] After a successful connection between the in-vehicle Wi-Fi and a hotspot, the hotspot is marked as a "non-metered network," a system default behavior based on Wi-Fi protocol attributes. Metered networks are those charged by operators based on data usage or time (such as cellular data), and the system restricts background updates and large file downloads to save on data charges. Non-metered networks typically refer to "unlimited" networks like Wi-Fi, where the system defaults to allowing free high-data-consumption tasks (such as system updates and app downloads). For example, with a mobile hotspot, the phone system identifies it as a "non-metered network" because it uses the Wi-Fi protocol, similar to home / public Wi-Fi, and the system doesn't automatically distinguish whether the hotspot's data usage comes from a mobile data plan. This leads to unlimited data consumption; after the in-vehicle Wi-Fi connects to a mobile hotspot, the system doesn't suppress background data activities (such as real-time map updates and automatic app synchronization), potentially exceeding data limits (if your mobile data plan has a cap). Users need to actively monitor their data usage. The actual cost of data depends on the mobile plan rules (such as whether the targeted data covers hotspots, and whether there are speed limits / charges for exceeding the limit). Users need to pay attention to their data usage themselves.

[0041] Although the phone's system may mark hotspots as "non-billed networks," carriers may still charge separately for hotspot data usage. This creates a conflict between system logic (automatic exemption of limits) and carrier policies (potential charges), requiring users to manually configure settings to prevent over-limit usage, resulting in a poor user experience. In other words, marking hotspots as "non-billed networks" is a default system behavior based on Wi-Fi protocol attributes, but the actual cost depends on the carrier's data plan rules. Users need to manually control data usage on their phones through three steps: setting data limits, selecting appropriate data plans, and manually managing high-energy-consuming applications, to avoid unexpected charges from in-vehicle network connectivity. This highlights the lack of vehicle-side data limiting strategies in the relevant technologies.

[0042] In a typical scenario where in-vehicle infotainment systems and smartphones are interconnected via Wi-Fi hotspots, traffic control often fails due to misjudgment of network type: when a mobile phone acts as a hotspot device, if its operating system marks its own hotspot as a "non-billed network" by default (i.e., the user has not actively set traffic limits), the vehicle's infotainment system may mistakenly believe that the connection does not require traffic control, thus allowing high-bandwidth applications (such as video streaming or map updates) to run, which may lead to the risk of users unexpectedly incurring high traffic charges.

[0043] To systematically address this issue, after the vehicle's infotainment system establishes a Wi-Fi connection with the hotspot, if it receives a "non-billing network mode" status (i.e., the hotspot has not configured a traffic restriction policy) actively declared by the hotspot through a predefined protocol (such as based on IEEE 802.11u or a custom API), the vehicle's infotainment system will immediately initiate a secure handshake interaction process. This design avoids the shortcomings of unidirectional reliance on hotspot device declarations and ensures the reliability of network type determination.

[0044] This application avoids the shortcomings of one-way declarations through two-way verification, including the vehicle-mounted unit (VMU) request phase and the device response phase. VMU request phase: After declaring the network type as a non-charging network, the VMU sends a pre-constructed verification request packet (containing device identification and query instructions) to the hotspot device providing the hotspot, explicitly requesting two key pieces of information: (a) Whether the current access hotspot is a mobile device hotspot (i.e., mobile hotspot type); (b) Whether the current access hotspot has been configured with traffic thresholds or usage restriction policies (such as operator package limits or user-defined hotspot limits).

[0045] The verification request package includes a device query request and a traffic configuration query request; the device query request is used to query whether the hotspot device is a mobile terminal; the traffic configuration query request is used to query the traffic package limit or custom hotspot limit of the hotspot device.

[0046] During the mobile phone response phase, the hotspot device returns an encrypted response based on the verification request packet. After parsing the request, the hotspot device obtains a device query request and a traffic configuration query request. The device query request is used to query the device type of the hotspot device, or directly query whether the hotspot device is a mobile terminal.

[0047] For example, device type identification is achieved by requesting the Service Set Identifier (SSID) and Media Access Control Address (MAC). The name of a mobile hotspot typically includes the mobile phone brand or a custom identifier. Querying the SSID of the hotspot device determines whether it is a mobile terminal. If the retrieved SSID contains the mobile phone brand or model, the hotspot device is confirmed to be a mobile terminal. If the retrieved SSID does not contain the mobile phone brand or model, the hotspot device is confirmed not to be a mobile terminal.

[0048] Alternatively, MAC prefix matching can be used to determine if a hotspot device is a mobile terminal. Mobile phone manufacturers' MAC addresses have specific prefixes (such as 00:53:7F or 00:36:CF). The hotspot device's MAC address can be requested and compared to the manufacturer's database (sent with the verification data packet and automatically deleted after matching) to determine if it is a mobile terminal. If the manufacturer's database contains data matching the returned MAC address, the hotspot device is confirmed to be a mobile terminal. If the manufacturer's database does not contain data matching the returned MAC address, the hotspot device is confirmed not to be a mobile terminal.

[0049] You can also determine if a hotspot device is a mobile terminal by identifying its signal frequency band. Mobile hotspots typically only support the 2.4GHz band, while in-vehicle routers may support both bands. Therefore, you can request a query to determine the supported frequency bands of the hotspot device to help identify if it is a mobile phone. If the hotspot device finds that it supports dual-band signals, it is not a mobile terminal. If the hotspot device finds that it only supports a single-band (2.4GHz) signal, it is a mobile terminal.

[0050] Another way to determine if a device is a mobile terminal is by requesting its gateway address. Mobile hotspots typically use gateway addresses like 192.168.43.1 or 172.20.10.1, while vehicle routers often use 192.168.8.1 or 192.168.0.1. You can request the hotspot's gateway address and compare it to the mobile gateway database (sent with the verification data packet and deleted after a match) to determine if it's a mobile terminal. If the database contains data matching the requested gateway address, the hotspot is confirmed to be a mobile terminal. If the database does not contain data matching the requested gateway address, the hotspot is not a mobile terminal.

[0051] Therefore, priority should be given to querying the SSID name and the IP / MAC information of the hotspot device for quick identification to determine whether the hotspot device is a mobile terminal; if a higher accuracy judgment is required, it can be combined with querying the signal frequency band analysis or gateway address matching, and the signal frequency band coverage range can be used as an auxiliary judgment.

[0052] The device type query is achieved by directly requesting the hotspot device to determine its own identity. Specifically, the request asks whether the hotspot device is a mobile terminal. The hotspot device then performs a self-check to confirm its identity and returns the result to the vehicle's infotainment system. If the hotspot device determines it is a mobile terminal device such as a phone, it continues to query its data usage configuration to see if it has enabled data throttling or data saving modes, and checks its remaining data allowance.

[0053] The mobile phone system records the cellular data usage of all applications in real time through the network protocol stack, including foreground and background data usage. The system automatically accumulates the consumed data on a monthly basis (customizable) and subtracts the used amount from the preset data allowance to calculate the remaining data, allowing users to check their remaining data. The mobile phone system can also determine its remaining data allowance by accessing the carrier's application or by sending a data usage query SMS to the carrier.

[0054] At the same time, it requests a query to see if the user has enabled a custom hotspot limit. If the hotspot device determines that it has enabled a custom hotspot limit after self-checking, it queries the custom limit value.

[0055] If the mobile device does not have data throttling or data saving mode enabled, and does not have custom hotspot limit enabled, infinity will be set as the data limit value.

[0056] If the mobile device has enabled data throttling mode or data saving mode, and has enabled custom hotspot limit, the minimum of the custom limit value and the remaining data will be determined as the data limit value.

[0057] If the mobile device has enabled data throttling or data saving mode and has not enabled custom hotspot limits, the remaining data will be set as the data limit value.

[0058] If the mobile device does not have data throttling or data saving mode enabled, and a custom hotspot limit is enabled, the custom limit value will be set as the data limit value.

[0059] After receiving the verification request packet, the hotspot device checks its own device type and traffic limit value according to the verification request packet, and returns the encrypted device type and traffic limit value as the encrypted response value to the vehicle system.

[0060] Step 102: Determine the hotspot type based on the encrypted response.

[0061] In practice, the encrypted response is decrypted, and the data content corresponding to the device type is read to determine the corresponding hotspot type. For example, if the device type data in the encrypted response is a mobile phone, the hotspot type is determined to be a mobile terminal hotspot. If the device type data in the encrypted response is a vehicle gateway, the hotspot type is determined to be a vehicle hotspot.

[0062] Step 103: In response to the hotspot type being a mobile terminal hotspot, the hotspot traffic settings are determined by decrypting the encrypted response, and dynamic traffic restriction control is performed based on the hotspot traffic settings and service type.

[0063] In practice, after determining that the hotspot type is a mobile terminal hotspot, the hotspot traffic settings are determined by decrypting the encrypted response. If the traffic limit value is 0, the hotspot traffic is set to prevent other devices from using its data through the hotspot. If the traffic limit value is infinite, the hotspot traffic is set to allow other devices to use its data through the hotspot without restricting other devices from using its data, and dynamic traffic restriction control is not required. If the traffic limit value is neither infinite nor 0, dynamic traffic restriction control is performed based on the traffic limit value.

[0064] The dynamic traffic limit control process is as follows: the initial available traffic is determined based on the traffic limit value, and the applications that need to be prohibited from using mobile terminal traffic are determined based on the initial available traffic. Generally, these are non-core services and applications that use a lot of traffic. Core applications and applications that use less traffic can be used, and some high-traffic applications are disabled first.

[0065] At the same time, the system monitors the traffic usage of available services in real time to determine the remaining traffic. As the remaining traffic decreases, applications with medium traffic are further disabled. As the remaining traffic continues to decrease, it may even be possible to retain only core services while shutting down all non-core services. This ensures that the core functions of the vehicle can be used while preventing abnormal loss of traffic for users with limited access, reducing the traffic usage cost for users, and improving the user experience.

[0066] It should be noted that the process of determining the vehicle type can be transferred to the hotspot device for determination.

[0067] Optionally, if the device type is a mobile terminal and the data limit value is not 0 or infinite, the encrypted verification signal and data limit value are returned to the vehicle's infotainment system as an encrypted response. After parsing the encrypted response, the vehicle's infotainment system directly enables dynamic data limit control based on the data limit value.

[0068] Optionally, if the device type is not a mobile terminal, the encrypted verification failure signal is returned to the vehicle's infotainment system as an encrypted response. After parsing the encrypted response, the vehicle's infotainment system terminates the traffic restriction control process and restores the initial network policy.

[0069] Optionally, if the device type is a mobile terminal and the traffic limit is 0, an encrypted verification failure signal and a hotspot unusable signal will be returned to the vehicle's infotainment system as an encrypted response. After parsing the encrypted response, the vehicle's infotainment system will indicate that the hotspot is unusable and terminate the dynamic traffic limit control.

[0070] Optionally, if the device type is a mobile terminal and the traffic limit is infinite, the encrypted verification failure signal and the no-traffic-limit signal are returned to the vehicle's infotainment system as an encrypted response. After parsing the encrypted response, the vehicle's infotainment system terminates the traffic restriction control process and restores the initial network policy.

[0071] By using verification failure and verification success signals, the vehicle system is informed whether to perform dynamic traffic restriction control, reducing the decision-making process on the vehicle system side.

[0072] In summary, the WIFI traffic control method provided in this application can, when WIFI and a hotspot are successfully interconnected and the hotspot declares its network type as a non-billing network, send a constructed verification request packet to the hotspot device providing the hotspot. The hotspot device then returns an encrypted response based on the verification request packet. The hotspot type is determined based on the encrypted response. If the hotspot type is a mobile terminal hotspot, the hotspot traffic settings are determined by decrypting the encrypted response, and dynamic traffic restriction control is performed based on the hotspot traffic settings and service type. After confirming successful WIFI and hotspot interconnection and that it is in non-billing mode, the hotspot device information is queried through the verification request packet. If the hotspot is a mobile interruption hotspot, the hotspot traffic settings determine the hotspot device's restrictions on shared traffic. Dynamic traffic restriction control ensures that core services can be used while restricting some non-core services. This achieves dynamic traffic restriction control based on service type and hotspot traffic settings, ensuring the normal use of core vehicle functions while preventing abnormal user traffic loss, saving user traffic sharing costs, and improving the user experience.

[0073] In some implementations, such as Figure 3 As shown, dynamic traffic limiting control is implemented based on hotspot traffic settings and service type, including: Step 301: In response to the hotspot traffic setting having valid traffic, the current WIFI mode is set to billing mode at the local system policy layer, and the hotspot is marked as a billing network.

[0074] In practice, after establishing a Wi-Fi connection with the mobile terminal, the system does not change the mobile terminal's data usage configuration information. Instead, it alters the vehicle's data usage policy to achieve seamless dynamic data limit control for the user, improving the user experience. This can be achieved by modifying the NetworkManager's .nmconnection configuration file (usually located at / etc / NetworkManager / system-connections / ). Specifically, add or adjust the following attributes: set connection.metered to yes, indicating that the network is marked as a billed type and enters billing mode. The hotspot is then marked as a billed network, and dynamic data limit control is automatically enabled when reconnecting shortly after (within 7 self-defined days).

[0075] Step 302: Implement dynamic traffic limiting control based on service type and effective traffic settings.

[0076] In practical implementation, the vehicle-mounted system can provide different types of services. Services such as navigation, voice interaction, and safety-related controls are essential during vehicle operation and are therefore designated as core services. Services available during vehicle operation that are not core services are considered non-core services. Based on the varying importance of each service type, dynamic traffic control is implemented according to the service type and available traffic volume. The specific process is illustrated in the following example.

[0077] In some embodiments, such as Figure 4 As shown, dynamic traffic limiting control is implemented based on service type and effective traffic settings, including: Step 401: Determine the initial available traffic based on the effective traffic settings.

[0078] In practice, to provide users with some leeway and avoid additional data charges, dynamic data control requires determining the mobile terminal's hotspot data limit based on the effective data usage settings. These settings include whether the mobile terminal is in data-limiting or data-saving mode, and whether a custom hotspot limit is enabled. Therefore, the initial available data usage determined based on these effective data usage settings includes: When the mobile device is not in data throttling or data saving mode, and no custom hotspot limit is enabled, infinity will be used as the data limit value. When the mobile device is in data throttling or data saving mode, and a custom hotspot limit is enabled, the minimum of the custom limit and remaining data will be used as the data limit value. When the mobile device is in data throttling or data saving mode, and no custom hotspot limit is enabled, the remaining data will be used as the data limit value. When the mobile device is in data throttling or data saving mode, and a custom hotspot limit is enabled, the custom limit value will be used as the data limit value.

[0079] After determining the mobile terminal's own data usage limits, to avoid altering users' mobile terminal usage habits, data throttling from the vehicle's perspective requires first determining the maximum usable data volume (data limit). Then, a certain amount of margin is reserved based on the maximum data volume, resulting in an initial available data volume less than the maximum. For example, the initial available data volume can be determined based on a preset margin and data limit: Initial available data volume = Data limit - Margin. Alternatively, it can be determined based on a preset reservation coefficient (e.g., 0.95) and data limit: Initial available data volume = Data limit × Reservation coefficient. By reserving a portion of the data volume through initial available data volume, the user's mobile terminal data usage is guaranteed. Furthermore, this allows for advance data reservation to address scenarios where core vehicle functions experience sudden increases in data usage, preventing damage to core functions due to data throttling.

[0080] Step 402: Determine which services to disable and which to enable based on the initial available traffic, the network speed requirements of each service, and the service type.

[0081] In practice, due to limited traffic, it is necessary to allocate and limit traffic at the vehicle end. When allocating traffic, priority should be given to ensuring the normal use of core services, while some non-core services should be disabled. The process of determining disabled and available services is shown in the following example.

[0082] In some embodiments, the disabled and available services are determined based on initial available traffic, the network speed requirements of each service, and the service type, including: Step 4021: In response to the service type being core service, determine the core service as a mandatory available service.

[0083] In practical implementation, the core services form the basic framework of the vehicle's infotainment system, directly interacting with vehicle hardware, security, and underlying control. These services are typically deeply customized by the automaker or system developer and cannot be arbitrarily replaced or disabled. They include vehicle control and status management services, input and driving safety services, underlying system communication services, and user and access control services. Vehicle control and state management services: Real-time monitoring of vehicle attributes (such as speed, tire pressure, battery status), control hardware (air conditioning, lights, windows), and power management (sleep / wake-up logic). Directly linked to vehicle safety and basic functions, malfunctions can lead to system failure or vehicle loss of control. For example, CarPropertyService manages vehicle attributes (such as engine status, window / door operation). CarPowerManagementService handles vehicle power status (such as entering low-power mode after engine shutdown). CarDrivingStateService infers driving status (driving / parking) and triggers safety restrictions (such as disabling video while driving).

[0084] Input and Driving Safety Services: Handle physical button and knob inputs and restrict dangerous operations based on driving conditions (e.g., disabling touchscreen while driving) to ensure driver focus and prevent accidents caused by distracted operation. For example: CarInputService: Monitors hardware input events (steering wheel buttons, center console knobs). CarUxRestrictionsService: Dynamically restricts interactions based on vehicle speed / road conditions (e.g., disabling complex operations).

[0085] System-level communication services: Acting as a bridge between the vehicle's infotainment system and vehicle hardware (ECU / CAN bus), these services enable command issuance and data acquisition, facilitating cross-process communication based on HIDL / AIDL. Examples include: Vehicle HAL (Hardware Abstraction Layer): A standardized interface that converts vehicle signals (such as braking status) into system-readable data. VmsBrokerService: Handles the subscription and distribution of vehicle sensor data (such as tire pressure monitoring).

[0086] User and permission management services: support multi-account switching, driver profile storage, and function permission control (such as restricting passengers from operating vehicle settings), for example, CarUserService, CarPackageManagerService, etc.

[0087] Since the normal use of core services is essential for the normal operation and safety of vehicles, it is necessary to ensure the availability of core services. Therefore, it is necessary to ensure that core services can use traffic to operate normally. Thus, core services need to be included as part of the available services. When the service type is core service, core services are identified as mandatory available services to ensure the normal and safe operation of vehicles.

[0088] Step 4022: In response to the fact that the service type is a non-core service, determine the initial available traffic disabling level based on the initial available traffic, and determine the initially disabled service and the initially available service in the non-core services based on the initial available traffic disabling level.

[0089] In practice, non-core services focus on user experience and entertainment functions, typically existing as applications that can be updated, replaced, or disabled without affecting the vehicle's basic operation. Non-core services include: Infotainment application services: including navigation, music, video and other services.

[0090] Smart connectivity and extended services: including mobile screen mirroring, smart home control, voice assistant and other services.

[0091] Personalization and tools services: including UI theme changes (dashboard style, live wallpaper), vehicle system optimization services (cache clearing), and entertainment functions such as games.

[0092] Value-added services: online payment (parking fees), social networking (WeChat in-car), OBD diagnostics (requires external equipment), etc.

[0093] While preserving traffic usage for core services, non-core services, which do not affect normal vehicle use and driving safety, require traffic restrictions. Since different initial available traffic levels represent the severity of these restrictions, the first step is to determine the traffic restriction level based on the initial available traffic. Higher initial available traffic results in a lower restriction level, meaning less non-core traffic needs to be restricted. Finally, based on the initial available traffic restriction level, services with higher initial traffic usage are identified as initially restricted, while those with lower initial available traffic usage are identified as initially available.

[0094] For example, traffic restriction levels are divided into 80G, 60G, 40G, 20G, and 10G. If the initial available traffic is greater than or equal to 80G, the traffic restriction level is determined to be Level 1; if 80G > initial available traffic ≥ 60G, the traffic restriction level is determined to be Level 2; if 60G > initial available traffic ≥ 40G, the traffic restriction level is determined to be Level 3; if 40G > initial available traffic ≥ 20G, the traffic restriction level is determined to be Level 4; if 20G > initial available traffic ≥ 10G, the traffic restriction level is determined to be Level 5; and if 10G > initial available traffic, the traffic restriction level is determined to be Level 6.

[0095] When classifying non-core services according to traffic restriction levels, each service has a corresponding level label. The type can be classified according to the level label. For example, when the traffic restriction level is level 3, non-core services with level labels 1, 2, and 3 are classified as initially restricted services, and non-core services with level labels 4, 5, and 6 are classified as initially available services.

[0096] Step 4023: Determine the temporarily unblocked services from the initially disabled services based on network speed requirements and initial available traffic.

[0097] In practice, the level label is generally determined based on the weekly (daily) average traffic of the corresponding service. However, there are services that use a large amount of traffic in a short period of time and have low traffic at the beginning of the period of time. For such services, when the traffic is relatively sufficient, they can be temporarily unbanned. Therefore, the services that are temporarily unbanned can be determined from the initially banned services based on the network speed requirements and the initial available traffic. For example, if the initial available traffic is 25G and the network speed requirement of service A with a level label of 4 is lower than the preset network speed threshold, service A is determined to be a temporarily unbanned service. Service A is kept unbanned until the traffic ban level changes to level 5. After the traffic ban level changes to level 5, service A is restored to a banned service.

[0098] Step 4024: Integrate the initially available services, the required available services, and the temporarily unblocked services to obtain available services.

[0099] In practice, all initially available services, mandatory available services, and temporarily unblocked services will be considered as available services under the current traffic restriction level.

[0100] Step 4025: Delete the temporarily unblocked services from the initial disabled services to obtain the disabled services.

[0101] In practice, since the temporarily unblocked services have already been temporarily unblocked, the temporarily unblocked services in the initial disabled services are deleted, and the remaining services in the initial disabled services are determined as disabled services under the current traffic disabling level.

[0102] Step 403: Disable the use of hotspot traffic for the disabled service, determine the real-time available traffic based on the preset time interval and the initial available traffic, and display the real-time available traffic.

[0103] In some embodiments, determining real-time available traffic based on a preset time interval and initial available traffic includes: Determine the used traffic of available services based on time intervals; The difference between the initial available traffic and the used traffic is determined as the real-time available traffic.

[0104] In practical implementation, taking a 30-minute interval as an example, in order to avoid abnormal traffic loss, the use of hot traffic by disabled services is prohibited. Traffic monitoring is performed every 30 minutes to determine the traffic used by available services, that is, to determine the usage of initial available traffic. The difference between the initial available traffic and the used traffic is determined as the real-time available traffic and displayed to provide users with a digital display so that users can fully understand the traffic usage. When displaying, the amount of traffic used by each service and each application can be shown.

[0105] Step 404: Update available services based on real-time available traffic and service type.

[0106] In practice, the dynamic changes in real-time available traffic will lead to changes in traffic restriction levels. Therefore, it is necessary to dynamically update the traffic restriction levels based on the real-time available traffic, thereby realizing dynamic updates of available and restricted services and achieving dynamic traffic restriction control.

[0107] In some embodiments, updating available services based on real-time available traffic and service type includes: The current traffic restriction level is determined based on the real-time available traffic and the preset traffic restriction relationship; Based on the current traffic restriction level and service type, identify the new services to be restricted from the available services, and then delete the newly identified restricted services from the available services.

[0108] In practice, the current traffic restriction level is determined based on the real-time available traffic value and the boundary traffic value of each traffic restriction level in the traffic restriction relationship. When the traffic restriction level changes, some available services will be reclassified as restricted services. Among them, the core services in the available services are not allowed to be reclassified, so only the non-core services in the available services need to be reclassified according to the current traffic restriction level to identify the newly added restricted services that need to be changed to the restricted state. The newly added restricted services in the available services are then deleted, and the newly added restricted services are added to the restricted services, so as to realize the dynamic update of available services and restricted services and realize dynamic traffic restriction control.

[0109] In some embodiments, such as Figure 5 As shown, the WIFI traffic control method also includes: Step 501: Determine the security threshold traffic based on the initial available traffic and the preset security factor.

[0110] In practice, when the initial available traffic is about to run out, users need to be promptly notified to avoid exceeding the traffic limit without their knowledge. Therefore, the safety threshold traffic needs to be determined based on the initial available traffic and the preset safety factor. Taking a safety factor of 0.9 as an example, the safety threshold traffic = initial available traffic × safety factor.

[0111] Step 502: In response to the used traffic being greater than or equal to the safety threshold traffic, but less than the initial available traffic, issue a traffic usage warning based on the real-time available traffic.

[0112] In practice, when the used traffic is greater than or equal to the safe threshold traffic, it means that the available services have used most of the initial available traffic. At this time, a traffic usage warning is issued based on the real-time available traffic to inform users of the risk of exceeding the traffic limit and to avoid unexpected traffic overuse.

[0113] Step 503: In response to the used traffic being greater than or equal to the initial available traffic, delete all non-core services from the available services and raise the alert level.

[0114] In practice, when the used data traffic is greater than or equal to the initial available data traffic, it indicates that the available services have used all of the initial available data traffic. At this point, the mobile terminal's data traffic is being used excessively, posing a risk of additional data charges. In this situation, only core services are allowed to use data traffic to ensure vehicle safety and normal operation, while all non-core services are disabled to avoid unnecessary excessive data usage. Data usage warnings are issued based on real-time available data traffic. The warning intensity at this point is greater than the warning intensity when the used data traffic exceeds or equals the safety threshold. This informs the user of the risk of additional data charges, preventing significant excess data charges and improving the user experience. Directly disconnecting the hotspot connection should be avoided to prevent unexpected interruptions to core services and potential driving safety risks.

[0115] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0116] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0117] Based on the same inventive concept, and corresponding to any of the above embodiments, this application also provides a WIFI traffic control device.

[0118] refer to Figure 6 The WIFI traffic control device includes: The two-way authentication module 10 is configured to: in response to the successful interconnection between WIFI and the hotspot, and the hotspot declares the network type as a non-billing network, send a constructed authentication request packet to the hotspot device providing the hotspot, so that the hotspot device can return an encrypted response based on the authentication request packet; The type determination module 20 is configured to: determine the hotspot type based on the encrypted response; The dynamic traffic limiting module 30 is configured to: in response to a hotspot type of mobile terminal hotspot, determine the hotspot traffic setting by decrypting the encrypted response, and perform dynamic traffic limiting control based on the hotspot traffic setting and service type.

[0119] Optionally, the dynamic current limiting module 30 is also configured as follows: In response to the hotspot traffic setting being set to have valid traffic, the local system policy layer sets the current WIFI mode to billing mode and marks the hotspot as a billing network; Dynamic traffic limiting is implemented based on service type and effective traffic settings.

[0120] Optionally, the dynamic current limiting module 30 is also configured as follows: Determine the initial available traffic based on the effective traffic settings; Determine which services to disable and which to enable based on initial available traffic, the network speed requirements of each service, and the service type. Disable the use of hotspot traffic for the disabled service, and determine and display the real-time available traffic based on the preset time interval and the initial available traffic.

[0121] Update available services based on real-time available traffic and service type.

[0122] Optionally, the dynamic current limiting module 30 is also configured as follows: Determine the used traffic of available services based on time intervals; The difference between the initial available traffic and the used traffic is determined as the real-time available traffic.

[0123] Optionally, the dynamic current limiting module 30 is also configured as follows: The current traffic restriction level is determined based on the real-time available traffic and the preset traffic restriction relationship; Based on the current traffic restriction level and service type, identify the new services to be restricted from the available services, and then delete the newly identified restricted services from the available services.

[0124] Optionally, the dynamic current limiting module 30 is also configured as follows: The security threshold flow rate is determined based on the initial available flow rate and the preset security factor. In response to a situation where the used traffic is greater than or equal to the safety threshold traffic, but less than the initial available traffic, a traffic usage warning is issued based on the real-time available traffic. In response to a situation where the used traffic is greater than or equal to the initial available traffic, all non-core services among the available services are deleted, and the alert level is increased.

[0125] Optionally, the dynamic current limiting module 30 is also configured as follows: In response to the service type being core service, the core service is identified as a mandatory available service; In response to the fact that the service type is a non-core service, the initial available traffic disabling level is determined based on the initial available traffic, and the initial disabled service and the initial available service are determined in the non-core service based on the initial available traffic disabling level; Determine the temporarily unblocked services from the initially disabled services based on network speed requirements and initial available traffic. By integrating initially available services, required available services, and temporarily unblocked services, available services are obtained. Remove the temporarily unbanned services from the initial disabled services list to obtain the disabled services.

[0126] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0127] The apparatus described above is used to implement the corresponding WIFI traffic control method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0128] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the WIFI traffic control method described in any of the above embodiments.

[0129] Figure 7 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0130] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0131] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0132] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0133] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0134] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0135] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0136] The electronic devices described above are used to implement the corresponding WIFI traffic control methods in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0137] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the WIFI traffic control method as described in any of the above embodiments.

[0138] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0139] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the WIFI traffic control method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0140] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a vehicle, including the electronic device or WIFI traffic control device of the above embodiments, and executes the WIFI traffic control method as described in any of the above embodiments through the electronic device or WIFI traffic control device of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0141] It is understood that before using the technical solutions of the various embodiments in this application, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0142] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations described in this application.

[0143] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0144] It is understood that the above notification and user authorization process is merely illustrative and does not limit the implementation of this application. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this application.

[0145] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application is limited to these examples; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0146] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0147] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0148] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the claims of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A method for WIFI traffic control, the method comprising: The method comprises the following steps: In response to the successful interconnection of WIFI and the hotspot, and the hotspot declaring the network type as a non-charging network, a built verification request package is sent to the hotspot device providing the hotspot, so that the hotspot device returns an encrypted response according to the verification request package; The hotspot type of the hotspot is determined according to the encrypted response; In response to the hotspot type being a mobile terminal hotspot, the hotspot traffic setting is determined by decrypting the encrypted response, and dynamic traffic limit control is performed according to the hotspot traffic setting and the service type.

2. The WIFI flow control method of claim 1, wherein, The dynamic traffic limit control according to the hotspot traffic setting and the service type comprises: In response to the hotspot traffic setting being an effective traffic setting, the current WIFI mode is set to a charging mode in the local system policy layer, and the hotspot is marked as a charging network; Dynamic traffic limit control is performed according to the service type and the effective traffic setting.

3. The WIFI flow control method of claim 2, wherein, The dynamic traffic limit control according to the service type and the effective traffic setting comprises: An initial available traffic is determined according to the effective traffic setting; Disabled services and available services are determined according to the initial available traffic, the network speed requirement of each service, and the service type; The disabled services are prohibited from using hotspot traffic, and real-time available traffic is determined according to a preset time interval and the initial available traffic, and the real-time available traffic is displayed; The available services are updated according to the real-time available traffic and the service type.

4. The WIFI flow control method of claim 3, wherein, The determination of real-time available traffic according to a preset time interval and the initial available traffic comprises: The used traffic of the available services is determined according to the time interval; The difference between the initial available traffic and the used traffic is determined as real-time available traffic.

5. The WIFI flow control method of claim 3, wherein, The updating of the available services according to the real-time available traffic and the service type comprises: A current traffic disable level is determined according to the real-time available traffic and a preset traffic disable relationship; According to the current traffic disable level and the service type, new disabled services are determined in the available services, and the new disabled services determined in the available services are deleted.

6. The WIFI flow control method of claim 4, wherein, Further comprising: A safety threshold traffic is determined according to the initial available traffic and a preset safety coefficient; In response to the used traffic being greater than or equal to the safety threshold traffic and less than the initial available traffic, a traffic use warning is performed according to the real-time available traffic; In response to the used traffic being greater than or equal to the initial available traffic, all non-core services in the available services are deleted, and the warning level is increased.

7. The WIFI flow control method of claim 3, wherein, The determination of disabled services and available services according to the initial available traffic, the network speed requirement of each service, and the service type comprises: In response to the service type being a core service, the core service is determined as a required available service; In response to the service type being a non-core service, an initial available traffic disable level is determined according to the initial available traffic, and initial disabled services and initial available services are determined in the non-core services according to the initial available traffic disable level; Temporary unblocked services are determined in the initial disabled services according to the network speed requirement and the initial available traffic; integrating the initial available services, the mandatory available services and the temporarily unblocked services to obtain the available services; deleting the temporarily unblocked services in the initial disabled services to obtain the disabled services.

8. The WIFI flow control method of claim 1, wherein, The verification request packet comprises a device query request and a traffic configuration query request; the device query request is used to query whether the hotspot device is a mobile terminal; the traffic configuration query request is used to query a traffic package upper limit or a custom hotspot limit of the hotspot device.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor implements the method of any one of claims 1 to 8 when executing the program.

10. A vehicle characterized by comprising: The electronic device of claim 9 is included. The electronic device of claim 9 is included.

Images