Fttr-based deterministic intent synchronization and hybrid decision access control method, system, device and medium

Abstract

This application discloses a deterministic intent synchronization and hybrid decision-based access control method, system, device, and medium based on FTTR. The method is applied to an FTTR network, including a master gateway and at least one sub-gateway. The master gateway maintains a global version number, receives local version numbers reported by sub-gateways, and triggers configuration synchronization based on the differences. Sub-gateways forward configuration change requests to the master gateway, which, as the sole write point, executes the configuration change, updates the global version number, and synchronizes it to all sub-gateways. Sub-gateways make rapid decisions; if a match is not found, they initiate an online verification request to the master gateway and execute access control based on the returned result. This application achieves observable consistency of rules across the entire network, eliminates write conflicts, and does not reduce the speed of access decision-making.

Description

Technical Field

[0001] This application relates to the field of optical communication and wireless network access control technology, specifically to a deterministic intent synchronization and hybrid decision access control method, system, device and medium based on FTTR. Background Technology

[0002] FTTR (Fiber to the Room) is a network architecture that brings fiber optic cables into each user's room, providing a high-speed, stable internet connection. An FTTR network consists of an FTTR main gateway and at least one FTTR sub-gateway, connected via fiber optic or wireless backhaul links. To ensure FTTR network security, a reliable blacklist / whitelist management function is required, allowing only whitelisted user terminals to access the network, or denying access to blacklisted user terminals.

[0003] In existing FTTR networks, a typical scheme for blacklist / whitelist management is as follows: the main management process of the main gateway transmits the blacklist / whitelist configuration to the sub-gateways via an MQTT (Message Queuing Telemetry Transport) server; the sub-gateways receive and synchronize the rules from their subordinate management processes. Simultaneously, the sub-gateways also support configuring blacklists / whitelists via a local web page and synchronizing them back to the main gateway. This scheme has the following problems: 1. Synchronous state is unobservable; MQTT uses an asynchronous publish-subscribe model, and after the main gateway sends the configuration, it cannot confirm whether the sub-gateway has actually received and applied it; in scenarios such as network interruption, sub-gateway restart, or MQTT message backlog, the sub-gateway may run expired rules for a long time; terminals that have been added to the blacklist may still access through the sub-gateway, creating a security vulnerability; or newly added terminals may be wrongly rejected, affecting user experience. 2. Multiple write points lead to rule conflicts; both the main gateway and sub-gateways have the ability to independently modify blacklists and whitelists, forming a multi-write-point architecture. If users perform conflicting operations on the main gateway and different sub-gateways within a short period of time, such as adding and deleting the same MAC address simultaneously, the system lacks a global timing and version arbitration mechanism, which can easily lead to rule version splits and ultimately uncontrollable policies.

[0004] 3. Separation of decision and update leads to ineffective air interface resource consumption; the access decision of the sub-gateway relies entirely on the locally cached rules, and there is a lack of atomic coordination between the management process of the control plane updating the rules and the driver layer of the data plane executing the decision; during the rule update process, the driver layer may continue to allow blacklisted terminals to pass, resulting in a waste of air interface resources; the suppression of illegal terminals remains at the association stage, failing to intercept them in advance when the terminal sends a probe request, and invalid interactions still occupy the channel.

[0005] The aforementioned issues make it difficult for existing systems to balance security determinism, configuration flexibility, and access performance. There is an urgent need for a solution that can improve security consistency without sacrificing performance and flexibility, but this has not yet been resolved. Summary of the Invention

[0006] This application aims to solve the problems in the prior art such as the unobservable synchronization status of blacklists and whitelists in FTTR master-slave gateways, inconsistent rules due to multiple write conflicts, and the mutual constraint between decision speed and rule freshness. It provides a deterministic intent synchronization and hybrid decision access control method, system, device and medium based on FTTR, which can achieve observable and consistent rules across the entire network, eliminate write conflicts, and maintain access decision speed.

[0007] To achieve the above objectives, this application provides a deterministic intent synchronization and hybrid decision-based access control method based on FTTR, applied to an FTTR network. The FTTR network includes a master gateway and at least one sub-gateway, and the master gateway and the sub-gateway communicate via the MQTT protocol. The method includes: the master gateway maintaining a globally monotonically increasing global version number and receiving local version numbers periodically reported by each sub-gateway; the master gateway triggering configuration synchronization to the corresponding sub-gateway based on the difference between the global version number and the local version number to achieve deterministic intent synchronization; when a sub-gateway receives a configuration change request, it forwards the configuration change request to the master gateway; the master gateway, acting as the sole write point, performs the configuration change, updates the global version number, and synchronizes the updated configuration to all sub-gateways to achieve single-master write arbitration; when a sub-gateway receives an access request from a terminal, it first performs a fast decision based on a locally maintained hash table; if the decision fails, it initiates an online verification request to the master gateway and performs access control based on the global decision result returned by the master gateway to achieve a two-stage hybrid decision.

[0008] Optionally, the main gateway triggers configuration synchronization to the corresponding sub-gateway based on the difference between the global version number and the local version number, including: the main gateway determining the number of missing versions of the local version number of the sub-gateway relative to the global version number; if the number of missing versions is lower than a preset threshold, then sending incremental synchronization data to the sub-gateway; if the lag is higher than or equal to the preset threshold, then sending full synchronization data to the sub-gateway.

[0009] Optionally, after performing access control based on the global decision result returned by the main gateway, the sub-gateway further includes: writing the online verification result returned by the main gateway into a hash table for caching, and setting the lifespan of the cached result.

[0010] Optionally, after initiating an online verification request to the main gateway, the sub-gateway further includes: starting a timeout timer; if no response is received from the main gateway before the timeout timer expires, the access request is processed according to a preset security priority or availability priority.

[0011] Preferably, after performing access control based on the global decision result returned by the main gateway, the method further includes: when any gateway among the main gateway and each sub-gateway identifies an illegal terminal, generating a probe silence instruction, the probe silence instruction containing an absolute timestamp based on the network time protocol; the probe silence instruction is synchronized across the entire network via MQTT broadcast and Layer 2 broadcast, and the gateway receiving the probe silence instruction suppresses the probe response to the illegal terminal according to the absolute timestamp, so as to achieve cross-gateway collaborative probe silence.

[0012] This application also provides a deterministic intent synchronization and hybrid decision access control system based on FTTR, for implementing any of the methods described above. The system includes a main gateway and at least one sub-gateway, which communicate with the sub-gateway via the MQTT protocol. The main gateway is used to maintain a globally monotonically increasing global version number and receive local version numbers periodically reported by each sub-gateway. Based on the difference between the global version number and the local version number, it triggers configuration synchronization to the corresponding sub-gateway. It performs configuration changes as the sole write point, updates the global version number, and synchronizes the updated configuration to all sub-gateways. It also receives online verification requests initiated by sub-gateways and returns a global decision result. The sub-gateway is used to periodically report its local version number. When it receives a configuration change request, it forwards the configuration change request to the main gateway. When it receives an access request from a terminal, it first performs a fast decision based on a locally maintained hash table. If the decision fails, it initiates an online verification request to the main gateway and performs access control based on the global decision result returned by the main gateway.

[0013] Optionally, the main gateway is configured to: determine the number of missing versions of the sub-gateway; if the number of missing versions is lower than a preset threshold, send incremental synchronization data to the sub-gateway; if the number of missing versions is higher than or equal to the preset threshold, send full synchronization data to the sub-gateway.

[0014] Optionally, the sub-gateway is further configured to write the online verification result returned by the main gateway into a hash table for caching, and set the lifespan of the cached result; or, the sub-gateway is further configured to generate a probe silence command when an illegal terminal is detected, synchronize it across the entire network via MQTT broadcast and Layer 2 broadcast, and suppress the probe response to the illegal terminal according to the received probe silence command; wherein, the probe silence command includes an absolute timestamp based on the network time protocol.

[0015] 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, when executing the program, implements any of the methods described above.

[0016] This application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements any of the methods described above.

[0017] The deterministic intent synchronization and hybrid decision access control method, system, device, and medium based on FTTR provided in this application have the following beneficial effects: 1. Observable rule status: Through version number and heartbeat reporting, the main gateway can know the actual rule version applied by each sub-gateway, eliminating the uncertainty window of asynchronous synchronization; the blacklist and whitelist rules of the whole network achieve verifiable consistency, avoiding illegal terminal access or false rejection of legitimate terminals due to rule lag; 2. No performance degradation in decision-making: In the two-phase decision-making mechanism, most access requests are quickly decided through a locally maintained hash table, and online verification is only triggered when there is a local miss or doubt; the end-to-end latency of online verification can be controlled in milliseconds, which is usually less than the association timeout threshold; while maintaining the original decision-making speed, the problem of inaccurate local caching is solved. 3. Flexible and conflict-free configuration: The proxy configuration mode allows users to perform configuration operations on any gateway node. All modifications are processed through a single write point on the main gateway, eliminating multiple write conflicts. User habits are not affected, while ensuring the consistency of global configuration data. 4. Improved air interface efficiency: Cross-gateway collaborative probe silence moves the suppression of illegal terminals to the stage when the terminal sends the probe request, and executes it synchronously across the entire network; this reduces invalid association retries and air interface conflicts initiated by illegal terminals, and improves the overall effective throughput of the FTTR network. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments or the prior art 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.

[0019] Figure 1 This is a schematic diagram of the FTTR networking architecture used in the embodiments of this application.

[0020] Figure 2 This is a schematic diagram of the signaling interaction process for deterministic intent synchronization in this application.

[0021] Figure 3 This is a flowchart illustrating the agent configuration and single-master arbitration process in this application.

[0022] Figure 4 This is a flowchart illustrating the two-stage hybrid decision process in this application.

[0023] Figure 5 This is a schematic diagram of the cross-gateway collaborative detection of silence process in this application.

[0024] Figure 6 This is a schematic diagram illustrating the linkage between deterministic intent synchronization and agent configuration collaborative signaling in a PON network under Example 1.

[0025] Figure 7 This is a schematic diagram of the hybrid decision-making and cooperative detection silent linkage in Wi-Fi Mesh networking in Example 2.

[0026] Figure 8 This is a schematic diagram of intent synchronization and collaborative detection of silent cross-level relays in a multi-level cascaded network in Example 3. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0029] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0030] (1) A hash table is usually a key-value pair-based data structure that enables fast lookup, insertion and deletion operations.

[0031] (2) The global version number usually refers to the configuration version identifier that is maintained by the main gateway and is monotonically increasing. It is used to identify different versions of the blacklist and whitelist configuration.

[0032] (3) The local version number usually refers to the configuration version identifier of the current application maintained by the sub-gateway, which is used to identify the blacklist and whitelist configuration version currently running by the sub-gateway.

[0033] This application provides a deterministic intent synchronization and hybrid decision access control method based on FTTR, applied to an FTTR network. The FTTR network includes a main gateway and at least one sub-gateway, and the main gateway and the sub-gateway communicate via the MQTT protocol. (See also...) Figure 1 The diagram shows a schematic of the FTTR networking architecture used in this application embodiment. The diagram includes a main gateway and multiple sub-gateways. The main gateway is connected to the sub-gateways via optical fiber or a passive optical splitter. The main gateway internally displays the httpd process, the main management process, and the Mosquitto process. The sub-gateways internally display the httpd process, the slave management process, and the Wi-Fi driver module.

[0034] The method provided in this application includes at least a deterministic intent synchronization step, a proxy configuration and single-master arbitration step, and a two-stage hybrid decision step.

[0035] S1: Deterministic Intent Synchronization Step. The main gateway maintains a globally monotonically increasing version number and receives local version numbers periodically reported by each sub-gateway. Based on the difference between the global version number and the local version number, the main gateway triggers configuration synchronization to the corresponding sub-gateway to achieve deterministic intent synchronization. (Combined with...) Figure 2 As shown.

[0036] In the main management process of the main gateway, the following is configured to be executed: The main gateway generates a monotonically increasing global version number for each blacklist / whitelist configuration change, and encapsulates the changed content (i.e., configuration data) and the global version number into an intent synchronization signaling. This intent synchronization signaling is distributed to all sub-gateways via the main gateway's MQTT server at QoS 1. Simultaneously, the main gateway also receives local version numbers periodically reported by each sub-gateway, maintaining a sub-gateway version status table that records the latest reported local version number of each sub-gateway. In one specific implementation, the main gateway determines the number of missing versions of a sub-gateway's local version number relative to the current global version number. If the number of missing versions is below a preset threshold, the main gateway sends incremental synchronization data to the sub-gateway for incremental synchronization. Since only partial changes are transmitted, the data transmission volume is reduced, effectively improving synchronization efficiency. When the number of missing versions is higher than or equal to the preset threshold, or when a sub-gateway actively requests the main gateway, the main gateway sends full synchronization data to the sub-gateway for full synchronization. This ensures complete data recovery and prevents data corruption when the number of missing versions is high. The main gateway can promptly obtain the actual rule versions running in each sub-gateway, achieving verifiable consistency of rules across the entire network. By dynamically selecting incremental or full synchronization based on the number of missing versions in the local version number, it can maximize the saving of network bandwidth resources and optimize system performance while ensuring eventual data consistency.

[0037] In the sub-gateway's slave management process, the following steps are configured to be executed: upon receiving the intent synchronization signaling, parse the global version number and configuration data in the intent synchronization signaling, atomically update the local blacklist / whitelist rules and driver layer filter table, and write the current application's global version number to local storage as the local version number, including memory and flash memory; in periodic heartbeat signaling or other interactive signaling, carry the current application's local version number to ensure that the local rules are consistent with the main gateway rules, and to report the local rule status to the main gateway. It is worth noting that after receiving its own intent synchronization signaling, the sub-gateway needs to verify the integrity of the intent synchronization signaling before updating the local rules. The underlying operations such as MQTT message encapsulation, queuing, and retransmission can be handled according to conventional protocols.

[0038] S2: Proxy Configuration and Single-Door Write Arbitration Steps. When a sub-gateway receives a configuration change request, it does not directly execute the configuration modification, but instead forwards the configuration change request to the main gateway. The main gateway, acting as the sole write point, executes the configuration change, updates the global version number, and synchronizes the updated configuration to all sub-gateways to achieve single-master write arbitration. Combined with... Figure 3 As shown.

[0039] The sub-gateway's httpd process is configured to: upon receiving a user-submitted blacklist / whitelist operation, generate a configuration request signaling, including, for example, the operation type, target MAC address, SSID, and timestamp; send the request to the main gateway's Mosquitto process via the sub-gateway's management process and MQTT link; wait for the main gateway's response, and if a timeout occurs or the connection is lost, return an error message to the user; and avoid local caching or delayed writing to eliminate concurrent conflicts between multiple write points and ensure the consistency of global configuration data.

[0040] The main management process of the main gateway is configured to: receive configuration request signaling forwarded by sub-gateways, forward the configuration request signaling to the main gateway's httpd or configuration interface, execute rule changes using the main gateway's httpd or configuration interface as the sole write point, and store the results in the main gateway's configuration database; after successful change, trigger the deterministic intent synchronization process, generate a new version number, and distribute the updated rules to all sub-gateways. The purpose is to ensure that all configuration changes are processed through the main gateway's single write point, avoiding rule version splitting.

[0041] S3: Two-stage hybrid decision-making process. When the sub-gateway receives an access request from a terminal, it first performs a fast decision based on its locally maintained hash table; if the decision fails, it initiates an online verification request to the main gateway and executes access control based on the global decision result returned by the main gateway, thus achieving a two-stage hybrid decision-making process. Combined with... Figure 4 As shown.

[0042] The sub-gateway's decision engine is configured to execute the following: Upon receiving a terminal's association request or data packet in the Wi-Fi driver layer or the MAC authentication callback of the access daemon such as hostapd, it first queries the locally maintained hash table of blacklists and whitelists. If a match is found, meaning the MAC address explicitly exists in the whitelist or blacklist, it is either allowed or denied. If the local query fails, or the MAC address is marked as pending confirmation, an online verification request is generated and sent to the main gateway via an MQTT fast channel from the management process. The final decision is then executed based on the verification result returned by the main gateway. This approach aims to balance access response speed and decision accuracy, improving accuracy without sacrificing speed. The underlying initialization processes, such as hostapd's MAC authentication callback registration and message queue management, can be handled according to standard protocols.

[0043] Preferably, after performing access control based on the global decision result returned by the main gateway, the process further includes: the sub-gateway writing the online verification result returned by the main gateway into a hash table for caching, and setting a timeout for the cached result. By storing the online verification result locally through a local caching mechanism, the number of interactions when the same terminal accesses the network subsequently is reduced, thereby significantly reducing the load on the main gateway and reducing access latency; setting a timeout prevents the cached data from being inconsistent with the main gateway's state due to prolonged lack of updates, ensuring the timeliness of the cache.

[0044] This application provides a deterministic intent synchronization and hybrid decision-based access control method based on FTTR, which optimizes FTTR network access control and solves the problems of inconsistent rules, configuration conflicts, and high decision latency in the prior art. The network-wide rules become verifiable and consistent, the configuration is changed to atomic execution at a single write point, and access decisions ensure rule freshness while maintaining high speed. Illegal terminal interception is moved from the association stage to the probe request stage and achieves network-wide collaborative suppression, thus improving the overall stability, efficiency, and resource utilization of the FTTR network.

[0045] In a preferred embodiment, the method further includes a cross-gateway collaborative detection silence step after the two-stage hybrid decision step.

[0046] S4: Cross-gateway collaborative detection and silencing step. When the main gateway and any of the sub-gateways identify an illegal terminal that has been blacklisted, a detection and silencing command is generated. This command includes an absolute timestamp based on the Network Time Protocol (NTP). The command is synchronized across the entire network via MQTT broadcast and Layer 2 broadcast. Gateways receiving the command suppress their detection response to the illegal terminal based on the absolute timestamp, thus achieving cross-gateway collaborative detection and silencing. Figure 5 As shown.

[0047] The management process of the identification gateway is configured to execute the following: when a terminal is identified as an illegal terminal based on the blacklist, and its association or data packets are blocked at the driver layer, a probe silence command is immediately generated. The probe silence command contains the target MAC address and the suppression validity period, which is represented by an absolute timestamp based on the NTP time of the main gateway. The probe silence command is then published to all other gateways in the network via MQTT, including the main gateway and other sub-gateways. It can also be supplemented by sending it via Layer 2 broadcast. The purpose is to advance the suppression of illegal terminals from the association stage to the probe request stage and execute it synchronously across the entire network, reducing unnecessary air interface interactions.

[0048] The receiving gateway's slave management process is configured to: upon receiving a probe silence command, set a probe response suppression flag for the MAC address in its own Wi-Fi driver or access management; within the validity period, not respond to probe request frames received from the illegal terminal; determine whether it has expired by comparing the local system time with the absolute timestamp in the probe silence command; after the suppression validity period ends, the flag is automatically cleared. The purpose is to coordinate the suppression of probe requests from illegal terminals across the entire network and improve the efficiency of air interface resource utilization.

[0049] This application also provides a deterministic intent synchronization and hybrid decision access control system based on FTTR, used to implement a deterministic intent synchronization and hybrid decision access control method based on FTTR provided in this application. The system includes a main gateway and at least one sub-gateway, and the main gateway and the sub-gateway communicate with each other via the MQTT protocol. The main gateway is used to maintain a globally monotonically increasing version number and receive local version numbers periodically reported by each sub-gateway; based on the difference between the global version number and the local version number, it triggers configuration synchronization to the corresponding sub-gateway; as the sole write point, it performs configuration changes, updates the global version number, and synchronizes the updated configuration to all sub-gateways; and it receives online verification requests initiated by sub-gateways and returns a global judgment result; its purpose is to provide a unified configuration status benchmark for the entire network, eliminate concurrent write conflicts, receive online verification requests initiated by sub-gateways, and return a global judgment result. The sub-gateway is used to periodically report the local version number; when it receives a configuration change request, it forwards the configuration change request to the main gateway; when it receives an access request from a terminal, it first performs a quick decision based on the locally maintained hash table. If the decision fails, it initiates an online verification request to the main gateway and performs access control based on the global decision result returned by the main gateway.

[0050] The system described in this application embodiment achieves the technical effects of the method of this application embodiment through a modular approach of hardware and software, constructing an efficient, consistent, and secure FTTR access control system at the physical device level. Therefore, all implementations of the method of this application embodiment are applicable to the system of this application embodiment.

[0051] In one feasible implementation, the main gateway is specifically used to determine the number of missing versions of the sub-gateways; if the number of missing versions is lower than a preset threshold, incremental synchronization data is sent to the sub-gateways; if the number of missing versions is higher than or equal to the preset threshold, full synchronization data is sent to the sub-gateways. The number of missing versions here is the same concept as the number of missing versions in the method of this application embodiment, and will not be elaborated further here. Similarly, the sub-gateways are also used to write the online verification results returned by the main gateway into a hash table for caching, and set the lifespan of the cached results. Alternatively, the sub-gateways are also used to generate a probe silence command when an illegal terminal is detected, synchronize it across the entire network via MQTT broadcast and Layer 2 broadcast, and suppress the probe response to the illegal terminal according to the received probe silence command; wherein, the probe silence command includes an absolute timestamp based on the Network Time Protocol; its purpose is to report the local version number, forward configuration change requests on behalf of the client, execute a two-stage hybrid decision, and generate and coordinate the probe silence command.

[0052] A specific embodiment of 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. When the processor executes the program, it implements any of the methods described in the embodiments of this application, thereby achieving the technical effects of the above methods.

[0053] A specific embodiment of this application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in any one of the embodiments of this application, and achieves the technical effects of the above-mentioned method.

[0054] The technical solution of this application will be clearly and completely described below with reference to the accompanying drawings and specific embodiments. In actual deployment, the appropriate solution can be selected according to the network topology. The described embodiments are only some embodiments of this application, and not all embodiments.

[0055] Example 1: Taking a basic FTTR master-slave network as an example, using a fiber-optic direct-connection PON network. For example... Figure 6As shown, this embodiment uses one FTTR master gateway and two FTTR sub-gateways, referred to as sub-gateway A and sub-gateway B, respectively. The master gateway and sub-gateways are connected via optical fiber and a passive optical splitter to form a PON connection. The master gateway runs the httpd process, the master management process, and the Mosquitto process; each sub-gateway runs the httpd process, the slave management process, and a Wi-Fi driver module.

[0056] S1: Deterministic Intent Synchronization Steps. A global version number generation module is added to the fttr_manager_master process of the main gateway. The global version number is stored in the configuration partition of flash memory. Each time the configuration changes, the current global version number is read, incremented by 1, and written back as the updated global version number, ensuring that the global version number monotonically increases after a restart. A local version number verification function is added to the fttr_manager_slave process of the sub-gateways to verify the relationship between the global version number and the local version number in the received intent synchronization signaling. Each time an intent synchronization signaling is received, the sub-gateway writes the global version number to a dedicated file in its local flash memory. This global version number is carried in the heartbeat message. The heartbeat interval is configurable, typically ranging from several seconds to tens of seconds, such as 15 to 60 seconds. After receiving a heartbeat, the main gateway maintains a table in memory, recording the device identifier and latest local version number of each sub-gateway. If a sub-gateway reports a local version number lower than the current global version number, an incremental rule indicating the number of missing versions is sent to that sub-gateway via an MQTT point-to-point topic. If the number of missing versions exceeds a preset threshold by several versions (e.g., 3 to 10 versions), or the number of missing versions equals the preset threshold, or the sub-gateway actively requests full synchronization, the complete blacklist / whitelist list is sent directly. By triggering synchronization through the monotonically increasing number of missing versions between the global and local version numbers, the contradiction between unobservable configuration states and uncertain synchronization timing in distributed networks is resolved. This ensures that all network rules reach a verifiable consistency, guaranteeing that the configurations of all sub-gateway applications are always synchronized with the main gateway.

[0057] When a sub-gateway detects a disconnection in the communication link with the main gateway (e.g., multiple consecutive heartbeat timeouts or MQTT connection drops), the sub-gateway first stops receiving new configuration change requests and returns a link disconnection error to the front end. At this time, the sub-gateway makes a decision based solely on its local hash table and no longer initiates online verification requests. For terminals that are not found locally, it decides whether to reject or allow them based on global configuration parameters. Simultaneously, it keeps the current local version number and rules unchanged and does not make any local modifications. After the link is restored, the sub-gateway proactively reports its local version number to the main gateway, and the main gateway triggers incremental or full synchronization based on the number of missing versions.

[0058] After the sub-gateway restarts, it first reads the previously saved local version number from its local flash memory and compares it with the current global version number returned by the main gateway. If the local version number is greater than the global version number, it indicates that a version rollback has occurred (e.g., the main gateway rolls back its configuration). The sub-gateway actively requests a full synchronization and loads the saved blacklist and whitelist rules from its local flash memory to update the driver layer filter table. Once the sub-gateway connects to the main gateway, it immediately reports its local version number without waiting for a heartbeat cycle. After receiving the report, the main gateway triggers incremental or full synchronization based on the version differences. After receiving the synchronization data, the sub-gateway verifies the continuity of the version number to ensure that no intermediate versions are missed.

[0059] S2: Proxy Configuration and Single-Master Arbitration Steps. After receiving a blacklist / whitelist form submission, the sub-gateway's httpd program no longer calls local iptables or hostapd_cli commands. Instead, it assembles the form data into a JSON object and sends it to the local fttr_manager_slave process, for example, via a Unix domain socket. The slave process publishes the data to the MQTT convention topic. The master gateway's fttr_manager_master subscribes to this topic. Upon receiving a request, it forwards it to the master gateway's local httpd CGI interface. This CGI interface modifies the configuration file, triggering version number increment and synchronous deployment. The sub-gateway's webpage needs to wait for the master gateway's response. Due to potential MQTT response delays, the sub-gateway's httpd uses an asynchronous waiting method. The maximum waiting time is configurable, for example, set to several seconds (e.g., 1 to 3 seconds). If a timeout occurs or an error is received, a failure is returned to the frontend. If the MQTT connection is lost, the sub-gateway directly returns an error without saving a local draft to avoid configuration loss or conflicts. By using a sub-gateway to proxy forwarding the single write point to the main gateway, the contradiction between concurrent configuration with multiple write points and the difficulty in guaranteeing configuration consistency is resolved. This eliminates write conflicts during configuration changes, prevents the possibility of concurrent conflicts with multiple write points, and ensures the atomicity and consistency of configuration changes.

[0060] S3: Two-phase hybrid decision process. Modify the MAC authentication callback function in the hostapd source code of the sub-gateway. Insert a decision function before the original authentication process. Maintain a hash table in the decision function; this hash table can be implemented using user-space GHashTable or the netfilter hash table in the kernel. The decision logic of this function is: first, look up the terminal's MAC address in the hash table. If a match is found and the status is clearly whitelisted or blacklisted, return "allow" or "deny" directly. If not found, send a query request to the local fttr_manager_slave via netlink or Unix socket. The slave process converts the query request into an MQTT request-response pattern, sends it to the master gateway, and sets a timeout (i.e., liveness time). The timeout value is configurable, for example, 100 milliseconds to 500 milliseconds. If a response is received within the timeout value, update the local hash table and execute the corresponding action. If no response is received within the timeout value, determine the behavior based on global configuration parameters: global configuration parameters can be preset by the user to prioritize security or availability. In security-first mode, association is rejected; in availability-first mode, it is temporarily allowed and logged, while asynchronous retrying continues several times, for example, up to 3 times. In actual wired PON networks, round-trip latency is typically within milliseconds, so timeouts are rarely triggered. By combining fast decision-making using a locally stored hash table with online verification requests, both access decision speed and rule freshness are balanced, achieving dual optimization of access decision efficiency and rule accuracy. The vast majority of access requests are decided locally within nanoseconds, with only a few missed requests initiating online verification, ensuring both decision speed and rule freshness, achieving an optimal balance between efficiency and accuracy.

[0061] When a sub-gateway detects a disconnection in the main gateway's MQTT connection or a heartbeat timeout (e.g., three consecutive failures to receive a heartbeat response), the sub-gateway enters degraded mode. In degraded mode, the sub-gateway refuses to accept new configuration change requests, directly returns a "main gateway unavailable" error to the frontend, and does not perform local storage. For access decisions, the sub-gateway determines its behavior based on global configuration parameters: if configured for security priority, it rejects all terminals not explicitly matched in the hash table; if configured for availability priority, it allows terminals not matched in the hash table to access, but logs the changes and continuously monitors the main gateway's recovery status. After the main gateway recovers, the sub-gateway proactively initiates a full synchronization request.

[0062] S4: Cross-Gateway Collaborative Detection Silent Step. When hostapd of sub-gateway A rejects the association of a blacklisted terminal, hostapd sends an event to fttr_manager_slave via the control interface. The slave process reads the current system time and adds a preset suppression period to obtain the absolute cutoff timestamp. The suppression period is configurable, typically ranging from tens of seconds to two minutes. Then, a JSON message containing the MAC address and absolute cutoff timestamp is constructed and published to a broadcast topic via MQTT. Upon receiving this message, the slave processes of other sub-gateways parse the MAC address and cutoff timestamp, and either call the hostapd_cli command or add a temporary blocking rule through the driver interface. Each sub-gateway maintains a list of timers, scanning it at a low frequency, such as once per second or every two seconds. If the current time exceeds the absolute cutoff timestamp of an entry, it is deleted. Since the number of entries is usually small, this polling method has extremely low CPU usage. This requires all gateways in the network to enable NTP clients and synchronize with the master gateway or a time server to ensure that the system time error of each gateway is within an acceptable range, such as within approximately one second. If the time synchronization error is large, the actual effect of the suppression cycle will be somewhat deviated, but it will not affect the blocking function.

[0063] This step reduces network resource waste caused by repeated probes from unauthorized terminals by using an absolute timestamp-based probe silence command and a network-wide synchronization mechanism, significantly reducing invalid air interface interactions. Once any gateway identifies an unauthorized terminal, it immediately and synchronously suppresses the terminal's probe response across the entire network, advancing the interception timing from the association phase to the probe request phase, reducing invalid air interface interactions and improving the overall effective throughput of the FTTR network.

[0064] In this example, deterministic intent synchronization provides rule freshness assurance for the two-phase hybrid decision-making process; proxy configuration and single-master write arbitration provide a single data source for deterministic intent synchronization; the two-phase hybrid decision-making process provides an identification basis for cross-gateway collaborative probe silence; and collaborative probe silence provides early interception capability for deterministic intent synchronization. These four steps comprehensively improve FTTR network performance from multiple dimensions, including rule consistency, configuration reliability, decision efficiency, and resource utilization. Based on the low-latency characteristics of PON links, the heartbeat interval and version lag threshold can be flexibly adjusted according to the number of sub-gateways. For example, a shorter heartbeat interval and a smaller lag threshold can be used when the number of sub-gateways is small, while these can be relaxed when the number of sub-gateways is large to reduce the intent synchronization signaling load. In actual deployment, it is recommended to first measure the round-trip latency and packet loss rate in a laboratory environment before configuring the corresponding timeout parameters to ensure that the system performs optimally under various deployment scenarios.

[0065] Example 2: Taking Wi-Fi Mesh backhaul networking as an example. Figure 7As shown, in this embodiment, one FTTR main gateway and two FTTR sub-gateways are used, referred to as sub-gateway A and sub-gateway B, respectively. The hardware of the main gateway and sub-gateways is the same as in Embodiment 1, but the sub-gateways do not have wired backhaul; their uplink interfaces are wireless. The main gateway and each sub-gateway establish a communication connection via the MQTT protocol, with MQTT communication carried over the IP connection provided by the Mesh network. The FTTR sub-gateways establish a backhaul link with the FTTR main gateway via Wi-Fi Mesh. The Mesh protocol can be 802.11s or a vendor-specific protocol. In this embodiment, the focus is on describing the differences from Embodiment 1; the remaining identical content will not be repeated.

[0066] S1: Deterministic Intent Synchronization Steps. The main gateway maintains a monotonically increasing global version number, and sub-gateways report their local version numbers via heartbeats. For Mesh environments, the heartbeat interval is extended to half a minute to one and a half minutes. The main gateway uses consecutive lost heartbeats (e.g., 2 to 3 times) to determine disconnection, avoiding misjudgments due to momentary packet loss. When a sub-gateway's local version lags behind by multiple versions (e.g., 2 to 5 versions), a full synchronization is triggered. This mechanism ensures that even in environments with unstable wireless backhaul, the network rules maintain a verifiable and consistent state.

[0067] The sub-gateway continuously monitors the MQTT connection status and heartbeat response time with the main gateway. When it detects a decline in link quality but not a complete disconnection, the sub-gateway will extend the online verification timeout value. When it detects a complete disconnection, the sub-gateway will reject all unknown terminals and stop the configuration change service based solely on the hash table decision. After the link is restored, the sub-gateway will first conduct a small-volume test to confirm that the link is stable before resuming normal service.

[0068] The recovery of the sub-gateway after a restart still needs to consider the instability of the wireless link. After restarting, the sub-gateway prioritizes establishing an MQTT connection with the main gateway, skipping some initialization processes to speed up recovery. After reading the local version number, the sub-gateway immediately reports to the main gateway, requesting version verification. If the number of missing versions is small, incremental synchronization is requested first to reduce the load on the wireless link. If no response is received from the main gateway within a preset time, the sub-gateway continues to operate based on local rules and continues to retry. Finally, the restart event and recovery process are recorded for troubleshooting. S2: Proxy configuration and single-master write arbitration steps. The sub-gateway forwards configuration change requests to the main gateway, which acts as the sole write point to uniformly execute configuration changes. To address the instability of Mesh backhaul, the sub-gateway's waiting timeout is extended to several seconds (e.g., 3 to 8 seconds), and a retry mechanism is added several times (2 to 5 times), with each retry interval of 1 to several seconds (e.g., 3 seconds). This architecture eliminates concurrent conflicts between multiple write points, ensuring the atomicity and consistency of configuration changes even in a wireless environment.

[0069] S3: Two-phase hybrid decision-making process. The sub-gateway prioritizes a fast decision using a locally stored hash table. If a match is missed, it initiates an online verification with the main gateway, with a timeout set to 100 milliseconds (e.g., 100 to 300 milliseconds). In a Mesh environment, if multiple consecutive (e.g., 3 to 5) online verification timeouts occur, the sub-gateway automatically switches to autonomous blocking mode, rejecting all unknown terminals until the heartbeat resumes. This mechanism ensures decision-making speed while guaranteeing security during link anomalies through intelligent degradation strategies.

[0070] When a sub-gateway detects a disconnection in the main gateway's MQTT connection, it enters a self-blocking mode, rejecting all access requests from unknown terminals. For known whitelisted terminals, the sub-gateway continues to allow access. The sub-gateway continuously attempts to reconnect to the main gateway, employing an exponential backoff strategy at reconnection intervals. Upon successful reconnection, the sub-gateway proactively requests full synchronization to ensure rule consistency.

[0071] S4: Cross-gateway collaborative detection and silence step. After identifying an illegal terminal, the sub-gateway generates a detection and silence command containing an absolute timestamp and broadcasts it to the entire network via MQTT. The suppression period is set to half a minute to one and a half minutes. If the sub-gateway is offline, the silence command cannot be delivered, but it does not affect the overall effect. When it comes back online, the main gateway triggers a full rule distribution. This ensures that invalid air interface interactions can still be effectively reduced in a wireless environment, advancing the interception timing to the detection phase.

[0072] In this embodiment, deterministic intent synchronization ensures rule freshness, proxy configuration eliminates concurrent conflicts, two-stage hybrid decision-making balances efficiency and accuracy, and collaborative detection silence enables early interception. Addressing the characteristics of the Mesh environment, through adaptive parameter adjustment, retry mechanisms, and intelligent degradation strategies, the system maintains high reliability and performance even under unstable wireless backhaul conditions. This comprehensively improves FTTR network performance across multiple dimensions, including rule consistency, configuration reliability, decision efficiency, and resource utilization.

[0073] Example 3: Taking a multi-level cascaded sub-gateway as an example. (e.g.) Figure 8 As shown, the topology in this embodiment is that the main gateway is connected to a first-level sub-gateway A via an Ethernet cable, and the first-level sub-gateway A is then connected to a second-level sub-gateway C via an Ethernet cable. The hardware of the main gateway and each sub-gateway is the same as in Embodiment 1. The second-level sub-gateway C obtains an IP address from the first-level sub-gateway A via DHCP, and then directly establishes an MQTT connection with the main gateway. The first-level sub-gateway A acts as an IP router to forward data packets. In this embodiment, the focus is on describing the differences from Embodiment 1; the remaining identical content will not be repeated.

[0074] S1: Deterministic Intent Synchronization Steps. The intent synchronization signaling issued by the main gateway is forwarded through the IP layer of the first-level sub-gateway A to the second-level sub-gateway C. The local version number reporting of the sub-gateways follows the same process. The main gateway's version status table is indexed by the device ID and is unaffected by topology levels. When the second-level sub-gateway C detects an MQTT disconnection, it attempts to reconnect using an exponential backoff algorithm. The reconnection interval can be gradually increased, with an upper limit of approximately one minute. After a successful reconnection, the second-level sub-gateway C actively requests full synchronization. This method ensures that, in a multi-level cascading environment, the rules across the entire network maintain a verifiable and consistent state.

[0075] In a multi-level cascaded environment, link disconnection scenarios are more complex. If a primary sub-gateway A loses connection with the primary gateway, it enters degraded mode and simultaneously notifies the secondary sub-gateways via a local mechanism. If a secondary sub-gateway C loses connection with primary sub-gateway A, it also enters degraded mode, but this does not affect communication between primary sub-gateway A and the primary gateway. In degraded mode, sub-gateways rely solely on their local hash tables for decision-making, rejecting access if a match is not found. After the link is restored, starting with the furthest sub-gateway, each level reports its version number to the primary gateway and requests synchronization.

[0076] In a multi-level cascaded environment, device restart recovery needs to consider hierarchical relationships. If primary sub-gateway A restarts: the recovery process is the same as in Example 1, but the dependency relationship of secondary sub-gateway C needs to be considered. If secondary sub-gateway C restarts, it first attempts to connect to the main gateway through primary sub-gateway A. If primary sub-gateway A is unavailable, secondary sub-gateway C enters degraded mode and operates based on local rules. After recovery, secondary sub-gateway C reports its version number to the main gateway through primary sub-gateway A. If primary sub-gateway A and secondary sub-gateway C restart simultaneously, primary sub-gateway A recovers first, and then secondary sub-gateway C recovers through primary sub-gateway A. After all sub-gateways recover, the main gateway triggers a network-wide version check to ensure that the version numbers of all sub-gateways are consistent.

[0077] S2: Proxy Configuration and Single-Write Arbitration Steps. Users perform operations on the webpage of the secondary sub-gateway C, and requests are forwarded to the main gateway via the IP address of the primary sub-gateway A, following the same process as in Example 1. When the secondary sub-gateway C detects a disconnected MQTT connection, it directly returns a "main gateway unavailable" error to the front end, without saving local drafts or delaying the write. This architecture eliminates concurrent conflicts at multiple write points in a multi-level cascaded environment, ensuring the atomicity and consistency of configuration changes.

[0078] S3: Two-stage hybrid decision-making process. Secondary sub-gateway C performs an independent lookup in its locally stored hash table. When online verification is required, secondary sub-gateway C queries the main gateway via MQTT. The path is from secondary sub-gateway C to primary sub-gateway A, then to the main gateway. The round-trip latency is typically between a few milliseconds and 10 milliseconds, still far less than the association timeout. The timeout parameter settings are the same as in Example 1. This method can still balance decision-making speed and rule freshness in a multi-level cascading environment.

[0079] When secondary sub-gateway C detects a disconnection in the primary gateway's MQTT connection, it enters degraded mode. For configuration change requests, secondary sub-gateway C directly returns a primary gateway unavailable error to the front end. For access decisions, secondary sub-gateway C uses a hash table for judgment; if the hash table is not found, access is rejected. Primary sub-gateway A, acting as a relay node, also enters degraded mode if it detects a primary gateway disconnection, rejecting all configuration change requests.

[0080] S4: Cross-gateway collaborative detection of silence steps. After the silence command issued by the secondary sub-gateway C is published via MQTT, the main gateway receives it and rebroadcasts it, ensuring that the primary sub-gateway A and other sub-gateways also receive it. If the connection between the secondary sub-gateway C and the main gateway is interrupted, the command cannot be issued, but the secondary sub-gateway C itself will still block the illegal terminal. When the connection is restored, the secondary sub-gateway C reports the local rule change via heartbeat, and the main gateway reissues the network-wide silence command. This ensures that invalid air interface interactions are effectively reduced even in a multi-level cascaded environment.

[0081] In this example, deterministic intent synchronization provides rule freshness assurance for the two-phase hybrid decision-making process; proxy configuration and single-master write arbitration provide a single data source for deterministic intent synchronization; the two-phase hybrid decision-making process provides an identification basis for cross-gateway collaborative probe silence; and collaborative probe silence provides early interception capability for deterministic intent synchronization. These four steps, through IP layer forwarding mechanisms and intelligent reconnection strategies, solve the configuration consistency problem in multi-level cascaded topologies and improve FTTR network performance. The number of cascaded layers should not be too large to ensure end-to-end latency is in the tens of milliseconds range.

[0082] As can be seen from the above, this application has at least the following technical effects: (1) Deterministic intent synchronization steps: The main gateway maintains a monotonically increasing global version number, and the sub-gateways report their local version numbers via heartbeats. Based on the number of missing versions between the global version number and the local version number, incremental synchronization or full synchronization is triggered. This breaks the contradiction between the unobservable configuration state and the uncertain synchronization timing in the distributed network, and transforms the network rules from an uncontrollable state to a verifiable consistent state. This ensures that the configuration of all sub-gateway applications is always synchronized with the main gateway, and effectively prevents configuration version rollback and conflicts. (2) Proxy configuration and single primary write arbitration steps: the configuration change request is forwarded to the primary gateway through the sub-gateway. The primary gateway is the only write point to uniformly execute the configuration change, which solves the contradiction between the concurrent configuration of multiple write points and the difficulty in ensuring configuration consistency, eliminates write conflicts in the configuration change process, eliminates the possibility of concurrent conflicts of multiple write points from the architecture level, and ensures the atomicity and consistency of configuration changes. (3) The two-stage hybrid decision-making process prioritizes the local hash table for quick decision-making through the sub-gateway. When a match is missed, online verification is initiated to the main gateway. This breaks the constraint between access decision-making speed and rule freshness, and balances access decision-making efficiency and rule accuracy. The vast majority of access requests are quickly decided locally, and only a few missed requests are subject to online verification. This ensures both decision-making speed and rule freshness, achieving the optimal balance between efficiency and accuracy. (4) Cross-gateway collaborative probe silence step: After identifying an illegal terminal, a probe silence command containing an absolute timestamp is generated and broadcast to the entire network via MQTT. This breaks the contradiction between repeated probes by illegal terminals when roaming across gateways and the waste of network resources, and effectively reduces invalid air interface interactions. Once any gateway identifies an illegal terminal, it immediately suppresses the probe response of the illegal terminal synchronously throughout the entire network, advancing the interception time from the association stage to the probe request stage, greatly reducing invalid air interface interactions and improving the overall effective throughput of the FTTR network. (5) The mutual cooperation between deterministic intent synchronization, proxy configuration and single-master write arbitration, two-stage hybrid decision and cross-gateway collaborative probe silence forms a closed-loop collaboration, which comprehensively improves the FTTR network performance from multiple dimensions such as rule consistency, configuration reliability, decision efficiency and resource utilization.

[0083] The above descriptions are merely embodiments of this application. Commonly known technical solutions or characteristics are not described in detail here. It should be noted that those skilled in the art can make various modifications and improvements without departing from the technical solution of this application. These modifications and improvements should also be considered within the scope of protection of this application, and will not affect the effectiveness of the application or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A deterministic intent synchronization and hybrid decision access control method based on FTTR, characterized in that, The method is applied to an FTTR network, wherein the FTTR network includes a main gateway and at least one sub-gateway, and the main gateway and the sub-gateway communicate via the MQTT protocol; the method includes: The main gateway maintains a globally monotonically increasing version number and receives local version numbers periodically reported by each sub-gateway; the main gateway triggers configuration synchronization to the corresponding sub-gateway based on the difference between the global version number and the local version number to achieve deterministic intent synchronization. When a sub-gateway receives a configuration change request, it forwards the request to the main gateway. The main gateway, acting as the sole write point, performs the configuration change, updates the global version number, and synchronizes the updated configuration to all sub-gateways to achieve single-master write arbitration. When a sub-gateway receives an access request from a terminal, it first performs a quick decision based on a locally maintained hash table. If the decision fails, it initiates an online verification request to the main gateway and executes access control based on the global decision result returned by the main gateway, thereby achieving a two-stage hybrid decision.

2. The method according to claim 1, characterized in that, The main gateway triggers configuration synchronization to the corresponding sub-gateway based on the difference between the global version number and the local version number, including: The main gateway determines the number of missing versions of the local version number of the sub-gateway relative to the global version number; If the number of missing versions is lower than a preset threshold, incremental synchronization data is sent to the sub-gateway. If the degree of lag is higher than or equal to the preset threshold, then full synchronization data is sent to the sub-gateway.

3. The method according to claim 1, characterized in that, After executing access control based on the global decision result returned by the main gateway, the process further includes: The sub-gateway writes the online verification results returned by the main gateway into a hash table for caching, and sets the lifespan of the cached results.

4. The method according to claim 1 or 3, characterized in that, After initiating an online verification request to the main gateway, the process further includes: The sub-gateway starts a timeout timer; If no response is received from the main gateway before the timeout timer expires, the access request will be processed according to the preset security priority or availability priority.

5. The method according to claim 1, characterized in that, After executing access control based on the global decision result returned by the main gateway: the method further includes generating a probe silence command when any gateway among the main gateway and each sub-gateway identifies an illegal terminal. The probe silence command includes an absolute timestamp based on the network time protocol. The probe silence command is synchronized across the entire network via MQTT broadcast and Layer 2 broadcast. The gateway that receives the probe silence command suppresses its probe response to the illegal terminal based on the absolute timestamp, so as to achieve cross-gateway collaborative probe silence.

6. A deterministic intent synchronization and hybrid decision access control system based on FTTR, characterized in that, For implementing the method as described in any one of claims 1 to 5, the system includes a main gateway and at least one sub-gateway, wherein the main gateway and the sub-gateway communicate via the MQTT protocol; The main gateway is used to maintain a globally monotonically increasing version number and receive local version numbers periodically reported by each sub-gateway; based on the difference between the global version number and the local version number, it triggers configuration synchronization to the corresponding sub-gateway. As the sole write point, it performs configuration changes, updates the global version number, and synchronizes the updated configuration to all sub-gateways; it also receives online verification requests initiated by sub-gateways and returns the global judgment result. The sub-gateway is used to periodically report the local version number; Upon receiving a configuration change request, the configuration change request is forwarded to the main gateway. Upon receiving an access request from a terminal, a quick decision is first made based on a locally maintained hash table. If the decision fails, an online verification request is initiated to the main gateway, and access control is executed based on the global decision result returned by the main gateway.

7. The system according to claim 6, characterized in that, The main gateway is used for: Determine the number of missing versions of the sub-gateway; If the number of missing versions is lower than a preset threshold, incremental synchronization data is sent to the sub-gateway. If the version lag is higher than or equal to the preset threshold, then full synchronization data is sent to the sub-gateway.

8. The system according to claim 6 or 7, characterized in that, The sub-gateway is further configured to write the online verification results returned by the main gateway into a hash table for caching, and set the lifespan of the cached results; or, the sub-gateway is further configured to generate a probe silence command when an illegal terminal is detected, synchronize it across the entire network via MQTT broadcast and Layer 2 broadcast, and suppress the probe response to the illegal terminal according to the received probe silence command; wherein, the probe silence command includes an absolute timestamp based on the network time protocol.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 5.

Images