Software version synchronization method and device of SFU gateway based on PON network

Abstract

The invention discloses a software version synchronization method of an SFU gateway based on a PON network. The software version synchronization method comprises the steps that a version identifier is embedded into a host; the version identifier comprises a software version number, a check code or a timestamp; the sub-machine receives the version identifier, analyzes the version identifier and compares the version identifier with a local version; and if the version identifier is inconsistent with the local version, automatically triggering OTA synchronization. According to the software version synchronization method of the SFU gateway based on the PON network provided by the embodiment of the invention, an additional data communication link or protocol multiplexing does not need to be established, the original Beacon frame is completely multiplexed to realize synchronization, and zero communication consumption is realized; compared with the prior art, the method provided by the invention has the advantages that only a few version fields are added, the network transmission performance is not influenced, the bandwidth occupation is low, and the method can be applied to fiber-to-room (FTTR), enterprise-level FTTR-B and broadband fusion terminal products.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a software version synchronization method and apparatus for an SFU gateway based on a PON network. Background Technology

[0002] In smart homes and optical network gateways (ONU Gateways), mesh networks have become the mainstream solution for achieving wireless interconnection of multiple nodes. Mesh slave devices typically need to maintain the same software version as the host to ensure functional consistency and network stability. Traditional software version synchronization methods mainly rely on active communication mechanisms, such as downloading version information via HTTP, MQTT, or dedicated management channels. These methods require additional communication links or session establishment, increasing bandwidth consumption and power consumption, and also introducing certain latency and complexity. In a mesh network environment, management beacon frames are management signals broadcast periodically between nodes, mainly used for topology maintenance, neighbor discovery, and status announcements. This type of frame naturally has a high broadcast frequency and full node reachability in the network, so if it can be used for version synchronization, communication consumption can be significantly reduced. In existing technologies, mesh slave software version synchronization is usually achieved in the following ways: Method 1: The master node notifies the slave of the version number through a dedicated management channel (such as TCP / HTTP), and the slave actively initiates an update. Method 2: Using periodic heartbeat packets with version information, but heartbeat packets belong to service control communication and will share bandwidth with service data. Method 3: Centralized management via a cloud platform, with slave machines periodically querying version information from the cloud. However, these solutions suffer from excessive communication overhead, such as additional communication links consuming bandwidth resources; increased network processing load on both hosts and slave machines; latency in version information transmission when network connections are weak or mesh routing is complex; inability to quickly complete local synchronization in environments without internet access; and high overall system power consumption. Summary of the Invention

[0003] This invention provides a software version synchronization method and apparatus for an SFU gateway based on a PON network to solve the technical problem of excessive communication consumption in the prior art.

[0004] A software version synchronization method for an SFU gateway based on a PON network includes: embedding a version identifier in the host; the version identifier includes: software version number, checksum, or timestamp; The slave device receives the version identifier, parses it, and compares it with the local version; If the version identifier is inconsistent with the local version, OTA synchronization will be automatically triggered.

[0005] Furthermore, the host embedded version identifier includes: when the host generates a management Beacon frame, an extended field Version_Info is added, which contains the software version number, checksum, and timestamp.

[0006] Furthermore, the slave device receives the version identifier, parses it, and compares it with the local version, including: After receiving the Beacon frame, the slave device automatically parses the Version_Info and compares it with the local version.

[0007] Furthermore, the method also includes: the slave machine performing synchronization confirmation and status feedback.

[0008] Furthermore, the synchronization confirmation and status feedback of the slave device includes: after the slave device completes the synchronization update, it adds an update completion identifier to the Beacon frame it sends and broadcasts it.

[0009] Furthermore, the method also includes: the host receiving the update completion identifier and calculating the synchronization status of the entire network.

[0010] Furthermore, the method also includes maintaining the current version if the submachine compares the version identifier with the local version.

[0011] A software version synchronization device for sub-machines includes: a host and several sub-machines; wherein, the host includes an embedding module, a host communication module, and a statistics module; and each sub-machine includes a sub-machine communication module, a parsing and comparison module, and a synchronization module. The embedding module is used to embed a version identifier; the version identifier includes: software version number, verification code, or timestamp. The host communication module sends the version identifier to the slave device; The slave communication module is used to receive the version identifier; The parsing and comparison module is used to parse the version identifier and compare it with the local identifier; if the version identifier is inconsistent with the local version, the synchronization module automatically triggers OTA synchronization. The slave communication module is also used for synchronizing status feedback; The host communication module is also used to receive the update completion identifier so that the statistics module can count the synchronization status of the entire network.

[0012] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described software version synchronization method for an SFU gateway based on a PON network.

[0013] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described software version synchronization method for an SFU gateway based on a PON network.

[0014] The aforementioned software version synchronization method, apparatus, computer equipment, and storage medium for an SFU gateway based on a PON network eliminates the need for establishing additional data communication links or protocol reuse. Synchronization is achieved entirely using native Beacon frames with zero communication overhead. Only a minimal number of version fields are added, without affecting network transmission performance and resulting in low bandwidth consumption. The version broadcast frequency is consistent with the Beacon frame, enabling version difference detection within seconds and high synchronization efficiency. Version consistency is maintained even in offline environments or local area scenarios, without cloud dependency. Field content can be expanded as needed to achieve differential synchronization or module-level synchronization. The structure is simple, highly scalable, and applicable to Fiber to the Room (FTTR), Fiber to the Room-Business (FTTR-B), and broadband converged terminal products. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of an application environment for a software version synchronization method for an SFU gateway based on a PON network, according to an embodiment of the present invention. Figure 2 This is a flowchart of a software version synchronization method for an SFU gateway based on a PON network according to an embodiment of the present invention. Figure 3 This is a schematic diagram of a slave computer software version synchronization device in one embodiment of the present invention; Figure 4 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] The software version synchronization method for an SFU gateway based on a PON network provided in this embodiment of the invention can be applied to, for example,... Figure 1 The application environment is shown. Specifically, this software version synchronization method for the SFU gateway based on a PON network is applied in a slave device software version synchronization device, which includes, as shown in the example... Figure 1 The diagram illustrates a client and server that communicate over a network to address the issue of excessive synchronization costs in existing technologies. The client, also known as the user terminal, is the program that provides local services to the client, corresponding to the server. The client can be installed on, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0019] In one embodiment, such as Figure 2 As shown, a software version synchronization method for an SFU gateway based on a PON network is provided, which is then applied to... Figure 1 Taking the server in the example, the following steps are included: S1: The host embeds a version identifier; the version identifier includes: software version number, checksum, or timestamp. For example, when generating a management Beacon frame, the host adds an extended field, Version_Info, containing the software version number, checksum, and timestamp. The version number can be used to directly distinguish software iteration versions; the checksum (e.g., SHA256) is used to verify the integrity of software files, avoiding update anomalies caused by data tampering or corruption during transmission; the timestamp (e.g., Unix timestamp) is used to mark the version release / update time, preventing slave machines from repeatedly parsing the same version identifier. Embedding this as an extended field in the native Beacon frame does not change the original structure and transmission logic of the Beacon frame, eliminating the need to establish an additional communication link and achieving "zero communication overhead" from the source.

[0020] S2: The slave device receives the version identifier, parses it, and compares it with the local version. For example, after receiving the Beacon frame, the slave device automatically parses the Version_Info and compares it with the local version. For example, the receiving method may include "passive listening," where the slave device does not need to actively initiate query requests to the host or cloud, reducing network interaction load.

[0021] S3: If the version identifier is inconsistent with the local version, OTA synchronization is automatically triggered. Furthermore, if the version identifier is consistent with the local version, the current version is maintained. The OTA synchronization is executed automatically without manual intervention, adapting to distributed deployment scenarios with multiple submachines in a Mesh network (such as batch synchronization of submachines in multiple rooms using FTTR). The design of "no synchronization if versions are consistent" avoids unnecessary network transmission and device resource consumption, further reducing energy consumption. Furthermore, the method also includes the slave device performing synchronization confirmation and status feedback. For example, after the slave device completes the synchronization update, it adds an update completion identifier to the Beacon frame it sends and broadcasts it. Specifically, the status feedback can also reuse the Beacon frame, continuing the design concept of "zero additional communication consumption," without the need for a new feedback channel; the host statistics function supports operation and maintenance management, enabling real-time monitoring of slave devices that have not successfully synchronized (such as devices that have not completed the update due to network interruption), facilitating subsequent troubleshooting and secondary synchronization triggering; the broadcast feedback design allows other slave devices to also receive the update completion status, which can serve as a reference for their own synchronization decisions (such as avoiding the same slave device being repeatedly triggered for synchronization).

[0022] Furthermore, the method also includes: the host receiving the update completion identifier and calculating the synchronization status of the entire network.

[0023] Preferably, the embodiments provided by the present invention support multiple module version information and differential updates, and have good scalability.

[0024] The software version synchronization method for SFU gateways based on PON networks provided in this invention does not require the establishment of additional data communication links or protocol reuse. It fully reuses native Beacon frames to achieve synchronization with zero communication consumption. It adds only a few version fields, does not affect network transmission performance, and has low bandwidth usage. The version broadcast frequency is consistent with the Beacon frame, and version difference detection can be completed within seconds, resulting in high synchronization efficiency. It can maintain version consistency in offline environments or local area scenarios without relying on the cloud. The field content can be expanded as needed to achieve differential synchronization or module-level synchronization. It has a simple structure, strong scalability, and can be applied to Fiber To The Room (FTTR), Fiber To The Room-Business (FTTR-B), and broadband converged terminal products.

[0025] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0026] In one embodiment, a slave device software version synchronization device is provided, which corresponds one-to-one with the software version synchronization method for an SFU gateway based on a PON network described in the above embodiment. For example... Figure 3 As shown, the submachine software version synchronization device includes a host 100 and several submachines 200; The host 100 includes an embedded module 101, a host communication module 102, and a statistics module 103; the slave device 200 includes a slave device communication module 201, a parsing and comparison module 202, and a synchronization module 203. Detailed descriptions of each functional module are as follows: The embedding module 101 is used to embed a version identifier; the version identifier includes: software version number, checksum, or timestamp. For example, when the host 100 generates a management Beacon frame, an extended field Version_Info is added, containing the software version number, checksum, and timestamp. The host communication module 102 sends the version identifier to the slave machine; The slave communication module 201 is used to receive the version identifier; The parsing and comparison module 202 is used to parse the version identifier and compare it with the local identifier. For example, after receiving a Beacon frame, the slave device automatically parses the Version_Info and compares it with the local version. If the compared version identifier does not match the local version, the synchronization module 203 automatically triggers OTA synchronization. Further, if the compared version identifier matches the local version, the current version is maintained. The slave communication module 201 is also used for synchronous status feedback; for example, after the synchronous update is completed, an update completion identifier is added to the Beacon frame it sends and broadcasts it. The host communication module 102 is also used to receive the update completion identifier so that the statistics module 103 can count the synchronization status of the entire network.

[0027] The slave software version synchronization device provided in this invention does not require the establishment of additional data communication links or protocol reuse. It fully reuses the native Beacon frames to achieve synchronization with zero communication consumption. It adds only a few version fields, does not affect network transmission performance, and has low bandwidth usage. The version broadcast frequency is consistent with the Beacon frame, and version difference detection can be completed within seconds, resulting in high synchronization efficiency. It can still maintain version consistency in offline environments or local area scenarios without relying on the cloud. The field content can be expanded as needed to achieve differential synchronization or module-level synchronization. It has a simple structure, strong scalability, and can be applied to Fiber to the Room (FTTR), enterprise-level Fiber to the Room-Business (FTTR-B), and broadband converged terminal products.

[0028] For specific limitations regarding a slave computer software version synchronization device, please refer to the above description of the software version synchronization method for an SFU gateway based on a PON network, which will not be repeated here. Each module in the aforementioned slave computer software version synchronization device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0029] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a software version synchronization method for an SFU gateway based on a PON network.

[0030] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a software version synchronization method for an SFU gateway based on a PON network as described in the above embodiment. Figure 2 S1-S3, as shown, will not be described again here to avoid repetition. Alternatively, when the processor executes a computer program, it implements the functions of each module / unit in this embodiment of a slave software version synchronization device, for example... Figure 3The functions of the host 100 shown are not described again here to avoid repetition.

[0031] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements a software version synchronization method for an SFU gateway based on a PON network as described in the above embodiment, for example... Figure 2 S1-S3, as shown, will not be described again here to avoid repetition. Alternatively, when the computer program is executed by the processor, it implements the functions of each module / unit in this embodiment of a slave computer software version synchronization device, for example... Figure 3 The functions of the host 100 shown are not described again here to avoid repetition. The computer-readable storage medium may be non-volatile or volatile.

[0032] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0033] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0034] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A software version synchronization method for an SFU gateway based on a PON network, characterized in that, include: The host embeds a version identifier; the version identifier includes: software version number, check code, or timestamp. The slave device receives the version identifier, parses it, and compares it with the local version; If the version identifier is inconsistent with the local version, OTA synchronization will be automatically triggered.

2. The software version synchronization method for an SFU gateway based on a PON network as described in claim 1, characterized in that, The host embedded version identifier includes: when the host generates a management Beacon frame, an extended field Version_Info is added, which contains the software version number, checksum and timestamp.

3. The software version synchronization method for an SFU gateway based on a PON network as described in claim 1, characterized in that, The slave device receives the version identifier, parses it, and compares it with the local version, including: After receiving the Beacon frame, the slave device automatically parses the Version_Info and compares it with the local version.

4. The software version synchronization method for an SFU gateway based on a PON network as described in claim 1, characterized in that, The method further includes: the submachine performing synchronization confirmation and status feedback.

5. The software version synchronization method for an SFU gateway based on a PON network as described in claim 1, characterized in that, The synchronization confirmation and status feedback of the slave device includes: after the slave device completes the synchronization update, it adds an update completion identifier to the Beacon frame it sends and broadcasts it.

6. The software version synchronization method for an SFU gateway based on a PON network as described in claim 1, characterized in that, The method further includes: the host receiving the update completion identifier and calculating the synchronization status of the entire network.

7. The software version synchronization method for an SFU gateway based on a PON network as described in claim 1, characterized in that, The method further includes, if the submachine compares the version identifier with the local version, then it keeps the current version.

8. A device for synchronizing the software version of a slave computer, characterized in that, include: A host and several sub-machines; wherein the host includes an embedded module, a host communication module, and a statistics module; and each sub-machine includes a sub-machine communication module, a parsing and comparison module, and a synchronization module. The embedding module is used to embed a version identifier; the version identifier includes: software version number, verification code, or timestamp. The host communication module sends the version identifier to the slave device; The slave communication module is used to receive the version identifier; The parsing and comparison module is used to parse the version identifier and compare it with the local identifier; if the version identifier is inconsistent with the local version, the synchronization module automatically triggers OTA synchronization. The slave communication module is also used for synchronizing status feedback; The host communication module is also used to receive the update completion identifier so that the statistics module can count the synchronization status of the entire network.

9. A computer 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 computer program, it implements the software version synchronization method for the SFU gateway based on a PON network as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the software version synchronization method for the SFU gateway based on the PON network as described in any one of claims 1 to 7.

Images