WO2024045765A1 - Slave gateway configuration method, electronic device and computer-readable storage medium - Google Patents

Abstract

Provided in the present disclosure are a slave gateway configuration method, an electronic device and a computer-readable storage medium. The slave gateway configuration method comprises: generating a slave gateway configuration file according to a configuration parameter of the current master gateway and a template configuration file that corresponds to a slave gateway; and issuing the slave gateway configuration file to the slave gateway when the slave gateway accesses the current master gateway.

Description

From gateway configuration methods, electronic devices and computer-readable storage media

Cross-references to related applications

This application claims priority to Chinese patent application CN202211055723.2 titled "Slave gateway configuration method, electronic device and computer-readable storage medium" filed on August 30, 2022, the entire content of which is incorporated herein by reference.

Technical field

The present disclosure relates to the field of communications, and in particular, to a slave gateway configuration method, an electronic device, and a computer-readable storage medium.

Background technique

In the current all-optical gateway networking mode of fiber laying to the remote node (FTTR, Fiber to the Room), most of the current master and slave gateway configurations are still performed by the Auto-Configuration Server (ACS, Auto-Configuration Server) Integrated Terminal Management System (ITMS) , Integrated Terminal Management System) network management or cloud platform and other media for management. In FTTR networking mode, due to the large number of slave gateways, the master and slave gateways need to report 0boot when connecting for the first time, and slave gateway device status information needs to be reported periodically. For example, some ITMS specifications define the master gateway extended parameter LANDevice node LANPONInterfaceConfig .{i}To obtain the main gateway user-side optical port enablement, Passive Optical Network (PON, Passive Optical Network) port status, device information, logical identification (LOID) and other information, and actively report to the network management when the node status changes. And if the configuration and management of the gateway are all managed by the ITMS network management or cloud platform, it will have a certain impact on the processing load of the ITMS network management or cloud platform.

Contents of the invention

The present disclosure provides a slave gateway configuration method, an electronic device, and a computer-readable storage medium.

The present disclosure provides a slave gateway configuration method for a master gateway. The slave gateway configuration method includes: configuring according to the current configuration parameters of the master gateway and the template corresponding to the slave gateway. configuration file to generate a slave gateway configuration file; when the slave gateway accesses the current primary gateway, deliver the slave gateway configuration file to the slave gateway.

The present disclosure also provides a slave gateway configuration method for the slave gateway. The slave gateway configuration method includes: receiving a slave gateway configuration file issued by a master gateway currently connected to the slave gateway, wherein the slave gateway configuration The file includes a slave gateway configuration file generated based on the master gateway configuration parameters of the master gateway currently connected to the slave gateway and the template configuration file corresponding to the current slave gateway.

The present disclosure also provides an electronic device. The electronic device includes: one or more processors; a memory on which one or more programs are stored. When the one or more programs are processed by the one or more The processor executes, causing the one or more processors to implement the slave gateway configuration method according to the present disclosure.

The present disclosure also provides a computer-readable storage medium. A computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the processor implements the slave gateway configuration method according to the present disclosure. .

Description of drawings

Figure 1 is a flow chart of a slave gateway configuration method according to the present disclosure.

Figure 2 is another flowchart of a slave gateway configuration method according to the present disclosure.

Figure 3 is a flow chart of a slave gateway configuration method according to the present disclosure.

Figure 4 is a flow chart of a slave gateway configuration method according to the present disclosure.

Figure 5 is a flow chart of a slave gateway configuration method according to the present disclosure.

Figure 6 is a flow chart of a slave gateway configuration method according to the present disclosure.

Figure 7 is a flow chart of a slave gateway configuration method according to the present disclosure.

Figure 8 is another flowchart of a slave gateway configuration method according to the present disclosure.

Figure 9 is another flowchart of a slave gateway configuration method according to the present disclosure.

Figure 10 is another flowchart of a slave gateway configuration method according to the present disclosure.

Figure 11 is another flowchart of a slave gateway configuration method according to the present disclosure.

Figure 12 is another flowchart of a slave gateway configuration method according to the present disclosure.

Figure 13 is another flowchart of a slave gateway configuration method according to the present disclosure.

Figure 14 is a schematic diagram of the traditional FTTR master and slave gateway configuration and management architecture.

Figure 15 is a schematic diagram of the FTTR master and slave gateway configuration file synchronization architecture according to the present disclosure.

Figure 16 is a flow chart of reporting file information in the MIB synchronization stage according to the present disclosure.

Figure 17 is a flowchart of querying file information after MIB synchronization according to the present disclosure.

Figure 18 is a normal flow chart for delivering a configuration file from a gateway according to the present disclosure.

Figure 19 is a flow chart of issuing exceptions from a gateway configuration file according to the present disclosure.

Figure 20 is a flow diagram for preflighting from a gateway configuration file in accordance with the present disclosure.

Figure 21 is a schematic diagram of a slave gateway XML configuration file format according to the present disclosure.

Figure 22 is a schematic diagram of a slave gateway JSON configuration file format according to the present disclosure.

Figure 23 is a schematic diagram of an electronic device according to the present disclosure.

Figure 24 is a schematic diagram of a computer-readable storage medium in accordance with the present disclosure.

Detailed ways

It should be understood that the specific embodiments described here are only used to explain the present disclosure and are not used to limit the present disclosure.

In the following description, suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present disclosure and have no specific meaning in themselves. Therefore, "module", "component" or "unit" may be used interchangeably.

In the FTTR master and slave gateway networking scenario, the configurations of each slave gateway under the same master gateway are basically the same. Some solutions propose that the wired and wireless related configurations of the slave gateway should be supported through the eLink extension protocol between the master and slave gateways, involving dynamic hosts. Configuration protocol (DHCP, Dynamic Host Configuration Protocol) address allocation, traffic forwarding control, WAN (Wide Area Network) connection configuration, interactive Internet TV (IPTV) business, wireless access and other parameter configurations. In the existing methods of managing optical network units (ONU, Optical Network Unit) through ITMS network management or cloud platforms and eLink plug-ins using data bus (DBUS) interfaces, the configuration management process for each business delivery is still relatively complex.

The configuration of the slave gateway is generally relatively simple, and most configurations can be synchronized directly from the main gateway, such as WIFI account passwords, etc. How to simplify the configuration management of the slave gateway to achieve plug-and-play from the slave gateway and reduce the processing load of the slave gateway on the ITMS network management or cloud platform requires an effective solution. In response to the above problems, for the FTTR comprehensive group How to simplify the configuration management of the slave gateway in the network scenario. This disclosure provides a solution in which the master gateway directly issues the configuration file to the slave gateway. While simplifying the configuration management of the slave gateway, it also reduces the slave gateway's need for ITMS network management or The processing load of the cloud platform.

An embodiment of the present disclosure provides a slave gateway configuration method for a master gateway. As shown in Figure 1, the slave gateway configuration method includes the following steps S100 to S200.

In step S100, a slave gateway configuration file is generated based on the configuration parameters of the current master gateway and the template configuration file corresponding to the slave gateway.

In step S200, when the slave gateway accesses the current primary gateway, the slave gateway configuration file is delivered to the slave gateway.

Since in the FTTR master and slave gateway networking scenario, the configurations of the slave gateways under the same master gateway are basically the same, and most configurations can be directly synchronized from the master gateway, therefore, the slave gateway configuration file can be generated based on the configuration parameters of the current master gateway. . In order to facilitate subsequent version updates, a template configuration file in a pre-specified standard format is used as the basic template for all slave gateway configuration files. The master gateway configuration parameters that need to be synchronized to the slave gateway are stored according to the format of the template configuration file and generated for the next step. Slave gateway configuration file sent to each slave gateway.

In some embodiments, the template configuration file corresponding to the slave gateway includes configuration parameter templates respectively corresponding to each service of the slave gateway.

The slave gateways in a real network may be devices from many different manufacturers, and multiple different types of services are run on each slave gateway. Therefore, corresponding configuration parameter templates can be set for each slave gateway's device form and each service type. The master gateway determines the configuration parameter template corresponding to each service based on the device form of the slave gateway and the various service types running on the slave gateway, obtains the template configuration file corresponding to the slave gateway, and combines it with the configuration of the master gateway itself parameters and the determined configuration template file to generate a slave gateway configuration file corresponding to the slave gateway.

In some embodiments, before delivering the secondary gateway configuration file to the secondary gateway, the method further includes: obtaining the configuration parameters of the primary gateway through the service configuration issued by the network management or management platform to which the current primary gateway belongs.

It should be noted that the source of the master gateway configuration file is not limited. The master gateway can automatically generate a slave gateway configuration file based on the business configuration issued by the current network management or management platform. You can also use the configuration file currently stored on the master gateway as the slave gateway configuration file. The format of the generated configuration file is not limited. It can be a file encoding format such as Extensible Markup Language (XML, Extensible Markup Language) or JSON (JavaScript Object Notation) with a modular structure, which facilitates the addition of configuration parameters. Deletion, assignment, modification, and other operations also facilitate subsequent direct distribution of the configuration file to the optical network unit through the optical network unit management and control interface (OMCI, ONU Management and Control Interface) or extended operations management and maintenance (OAM, Operations, Administration and Maintenance) protocol. from the gateway.

When accessing from the slave gateway, the preset LOID and password are used for the PON authentication process. After the master gateway performs LOID and password authentication on the accessed slave gateway, the master gateway that supports the Mini Optical Line Terminal (MiniOLT, Mini Optical Line Terminal) function can support Through physical layer operation management and maintenance (PLOAM, Physical Layer Operations, Administration and Maintenance) and OMCI management, the PON layer characteristics of the PON interface on the WAN side of the gateway are configured. The functions implemented by OMCI mainly include: basic information query from the gateway, LOID and LOID password Authentication, basic business model configuration from the gateway, MiniOLT actively reports information from the gateway or itself. Under this configuration model, in terms of specific implementation, it can be further expanded through "ONU XML configuration download" or (MEClass=65300) in the OMCI private definition, and private attributes are added to deliver configuration parameters related to the slave gateway.

After the gateway is powered on, it can meet the basic Internet and IPTV business needs according to the default preconfiguration. The basic configuration of the device includes: the default LOID and password registered to the main gateway PON port, the World Wide Web (WEB, World Wide Web) Login account password, wireless 2.4G and 5G wireless service set identifier (SSID, Service Set Identifier) name and key, each WAN connection working mode (bridge or routing, the default works in bridge mode), etc.

In this disclosure, the slave gateway does not need to modify the configuration, and can automatically synchronize the ordinary user administrator password of the master device, and can automatically synchronize the master device Wi-Fi and other configurations. You can modify the ordinary user administrator password, and modify the 2.4G and 5G SSID or password through the main device web page. The master gateway automatically generates the slave gateway XML or JSON configuration file based on the local configuration. When the slave gateway is powered on and connected, it generates a Gigabit-Capable Passive optical network (GPON) Optical Network) or Ethernet Passive Optical Network (EPON, Ethernet Passive Optical Network) and other application scenarios, download through OMCI or extended OAM transparent channel transmission. For the newly added parameter configuration items, the instructions are displayed through the XML incremental configuration file, and the application programming interface (API, Application Program Interface) interface provided by the relevant business module is called after parsing from the gateway and takes effect synchronously in real time. As described above, all 2.4G and 5G SSID and password configurations of the slave gateway can be synchronized in real time.

In this disclosure, the master gateway can achieve zero-configuration access after the slave gateway is powered on by synchronously delivering the slave gateway configuration file to the slave gateway. It no longer requires the ITMS network management to issue work orders or the cloud platform plug-in to issue configurations for management. It can achieve the advantages of plug and play.

In some embodiments, as shown in Figure 3, the slave gateway configuration method further includes the following steps S211 to S212.

In step S211, when the configuration parameters of the master gateway are changed, a slave gateway configuration file is regenerated based on the changed configuration parameters of the master gateway and the template configuration file corresponding to the slave gateway.

In step S212, the regenerated slave gateway configuration file is delivered to the slave gateway corresponding to the changed configuration parameters.

In this embodiment of the present disclosure, since the slave gateway no longer updates the configuration file from the network management, but directly synchronizes the configuration file from the master gateway, when the user makes modifications to the configuration parameters of the current master gateway through the network management, or directly in the master gateway When some parameters are modified, or the parameters in the slave gateway configuration file are changed due to other reasons, the current master gateway needs to regenerate the changed slave gateway configuration file and actively synchronize the configuration with the slave gateway.

Before the master gateway actively synchronizes the configuration to the slave gateway, it can first send an update instruction message to the slave gateway, and the slave gateway determines whether to synchronize the configuration based on the version information and verification information of the configuration file. If the secondary gateway determines that configuration synchronization is required, it sends a configuration file update request to the primary gateway. After receiving the update request, the master gateway starts to synchronize the changed slave gateway configuration file to the slave gateway.

In some embodiments, as shown in Figure 4, the slave gateway configuration method further includes the following steps S221 to S222.

In step S221, when the configuration parameters of the main gateway are changed, Generate an incremental configuration file for the slave gateway based on the changed configuration parameters of the master gateway and the template configuration file corresponding to the slave gateway, where the incremental configuration file is a modified configuration for the master gateway Parameter generated configuration fragment.

In step S222, the incremental configuration file is delivered to the slave gateway connected to the current master gateway, so that the incremental configuration file is merged with the slave gateway configuration file stored on the slave gateway to form the changed From the gateway configuration file.

Changes in configuration parameters include operations such as adding, deleting, and modifying configuration parameters. Sometimes only a few parameters change. It would be a waste of network resources to regenerate the complete slave gateway configuration file every time and then synchronize the complete configuration file to all slave gateways. Therefore, in addition to generating a complete slave gateway configuration file based on the changed parameters, the master gateway can also use incremental configuration files to synchronize the configuration to the slave gateway in order to save resources and reduce the burden of file transfer on the network. For example, using modular file encoding formats such as XML and JSON, an incremental file only contains module content with parameter changes to achieve lightweight configuration synchronization. After receiving it from the gateway, only the parameters in the incremental configuration can be synchronously updated based on the existing configuration file, leaving other content unchanged.

Similar to full synchronization, before the master gateway actively performs incremental configuration synchronization with the slave gateway, it can first send an update instruction message to the slave gateway, and the slave gateway will determine whether to configure based on the version information and verification information of the configuration file. Synchronize. If the secondary gateway determines that configuration synchronization is required, it sends a configuration file update request to the primary gateway. After receiving the update request, the master gateway begins to deliver the incremental configuration file to the slave gateway.

In some embodiments, as shown in Figure 5, the slave gateway configuration method further includes the following steps S231 to S232.

In step S231, the slave gateway to be updated is determined according to the configuration update information of the slave gateway.

In step S232, the slave gateway configuration file stored locally by the current master gateway is delivered to the slave gateway to be updated.

Further, as shown in Figure 6, before determining the slave gateway to be updated according to the configuration update information of the slave gateway (ie, step S231), the following steps S233 to S234 are also included.

In step S233, send a slave gateway to at least one slave gateway connected to the current master gateway. Update check message for gateway configuration file.

In step S234, the configuration update information fed back by each slave gateway to the current master gateway in response to the update check message is received.

Further, as shown in Figure 7, before determining the slave gateway to be updated according to the configuration update information of the slave gateway (ie, step S231), the following steps S235 to S236 are also included.

In step S235, a configuration file query message is sent to the slave gateway connected to the current master gateway.

In step S236, receive the configuration update information sent by the slave gateway for the configuration file query message.

Further, determining the slave gateway to be updated according to the configuration update information of the slave gateway (ie, step S231) includes: parsing the configuration update information to obtain the version information of the slave gateway configuration file stored locally by the slave gateway; in the If the version information of the slave gateway configuration file stored on the slave gateway is different from the version information of the slave gateway configuration file stored locally on the current master gateway, the slave gateway is determined to be the slave gateway to be updated.

Alternatively or additionally, determining the slave gateway to be updated based on the configuration update information of the slave gateway (ie, step S231) includes: parsing the configuration update information, and obtaining the slave gateway stored in the slave gateway for verification. Hashcode of the configuration file integrity; if the hash code verification fails, the slave gateway is determined to be the slave gateway to be updated.

In some embodiments, the slave gateway configuration file is delivered to the slave gateway through a privately defined channel of OMCI or a channel of extended OAM. In scenarios such as when the main gateway is powered on and the main gateway comes online, the Management Information Base (MIB) will be synchronized. During the MIB synchronization phase, the main gateway will send an update check to all slave gateways registered with the current main gateway. According to Determine which slave gateway configuration files need to be synchronized from the version information fed back by the gateway. After synchronization is completed, in daily operation, the master gateway can also send a query (GET) message to the slave gateway through MIB audit (Audit) to obtain the version information, hashcode, time information, etc. of the configuration file stored on the slave gateway, and determine which Configuration files from the gateway need to be synchronized.

The master gateway sends the version information containing the slave gateway configuration file to the slave gateway or the slave network When reporting the version information of the configuration file on the slave gateway to the master gateway, it can also send a Hashcode for verifying the integrity of the configuration file.

When the master gateway checks the configuration file update to the slave gateway, the master gateway checks the update status of the configuration file based on the "Hashcode" attribute value reported by the slave gateway. Based on the update status, it optionally initiates a configuration file delivery operation to the slave gateway. There are two options for reporting "Hashcode" from the gateway. One is that during the MIB Upload stage, the master gateway sends an update check message to the slave gateway, and the slave gateway reports it through the MIB Upload next response message; the other is that after the MIB audit is completed, the master gateway The gateway queries the XML configuration file information from the gateway through a configuration file query message (GET message). Both methods can obtain the configuration file version information, corresponding Hashcode, and update time information of the slave gateway. Based on this information, you can determine which slave gateways will be used as slave gateways to be updated.

In some embodiments, delivering the secondary gateway configuration file to the secondary gateway (ie, step S200) further includes: in response to receiving a configuration file synchronization request from the secondary gateway, delivering the secondary gateway to the secondary gateway. Gateway configuration file.

In addition to the above scenarios, there are also scenarios such as powering on the slave gateway with an empty configuration, restarting the slave gateway, and connecting to the network for the first time. In these scenarios, the slave gateway actively sends a configuration synchronization request to the master gateway. Whether the master gateway sends the configuration file or the slave gateway downloads the configuration file, the step of delivering the slave gateway configuration file to the slave gateway (ie, step S200) can be implemented.

In some embodiments, the slave gateway configuration file is delivered to the slave gateway through a privately defined channel of OMCI or a channel of extended OAM.

It should be noted that according to application scenarios such as GPON or EPON, you can choose to use a privately defined channel through OMCI or an extended OAM channel to deliver the slave gateway configuration file to the slave gateway, including but not limited to the embodiments of this disclosure. The various scenarios in which the master gateway delivers the slave gateway configuration file to the slave gateway can include the slave gateway configuration file sent by the master gateway when the slave gateway first accesses, or can include the master gateway configuration file when the master gateway configuration parameters change. The changed slave gateway configuration file or incremental configuration file issued by the gateway can also include the slave gateway configuration file issued during the MIB synchronization or MIB audit phase. We will not list them one by one here. All the private gateway configuration files issued by the master gateway through OMCI Scenarios in which a defined channel or an extended OAM channel delivers a configuration file to a slave gateway fall within the protection scope of this disclosure.

It should be noted that in an optical network, the slave gateway can be an ONU, and the master gateway can be an optical line terminal (OLT, Optical Line Terminal) or an ONU that supports the MiniOLT function. For convenience of description, in the embodiment of the present disclosure, the ONU is used as the slave gateway for illustration, but the present disclosure is not limited to the scenario of using the ONU as the slave gateway.

In the embodiment of the present disclosure, the default preconfiguration file is loaded from the gateway when it is powered on. For example, the default preconfiguration file presets the Internet bridge to implement basic Internet access and IPTV multicast services, and ensures that the slave gateway can register to the main gateway normally. The master gateway saves the basic service XML or JSON default configuration file template of the slave gateway. The XML or JSON file format content is defined according to the TR098 parameter specification and the internal DB storage parameters of each business module. After the master gateway is powered on, it reads and loads the slave gateway XML template configuration file. After the slave gateway is connected, it obtains the slave gateway's current configuration file version and last update time information, and confirms whether the slave gateway configuration file needs to be updated.

Downloading the configuration from the gateway involves private definition expansion, which is expanded through "ONU XML configuration download" or (MEClass=65300) in the OMCI private definition, adding the following two attributes: (1) FileVersion, indicating the configuration file version information, not Equal to the software version information; (2) Hashcode, indicating the overall MD5 summary information of the latest successfully updated configuration file.

The main gateway checks the configuration file update. The main gateway checks the configuration file update based on the "Hashcode" attribute value reported from the slave gateway, and optionally initiates a configuration file delivery operation. There are two options for reporting "Hashcode" from the gateway. One is during the MIB Upload stage, and the slave gateway reports it through the MIB Upload next response message; the other is that after the MIB audit is completed, the main gateway queries the slave gateway XML configuration file through the GET message. information.

When the master gateway confirms that it needs to update the slave gateway XML configuration file, for example, if the user account of the slave gateway is modified through the WEB, it needs to notify all online slave gateways to immediately update the relevant configuration files. The basic format of the XML file in the slave gateway is consistent with the default pre-configuration file of the master and slave gateway versions. Figure 21 shows the basic format of the XML configuration file. The basic content is as follows: Add the HashCode attribute to the <DB> tag, and the content is to perform the entire file The value calculated by the MD5 digest algorithm is used to verify the integrity of the entire XML file content. There must be a Version field configuration of the CfgFile table in each XML, and the configuration of the table must Located at the front. The CfgFile table only includes the field Version. Version represents the iteration of the configuration file. According to the Version, it is confirmed whether it is applicable to the current slave gateway. HashCode uses the MD5 digest algorithm. After the configuration file takes effect, it is used to save the hash value of the entire original configuration file received from the main gateway. After each subsequent restart, the content of this field is reported from the gateway to the main gateway to detect whether it needs to be updated. From the gateway configuration file.

The present disclosure also provides a slave gateway configuration method for the slave gateway. As shown in Figure 2, the slave gateway configuration method includes the following steps S300.

In step S300, receive the slave gateway configuration file issued by the master gateway currently connected to the slave gateway, wherein the slave gateway configuration file includes the master gateway configuration parameters based on the master gateway currently connected to the slave gateway and the configuration parameters related to the current slave gateway. The gateway configuration file is generated from the template configuration file corresponding to the gateway.

In some embodiments, the template configuration file corresponding to the slave gateway includes configuration parameter templates respectively corresponding to each service of the slave gateway.

In this disclosure, the master gateway generates a slave gateway configuration file for the slave gateway registered in the current master gateway based on the service configuration of the current master gateway. In some scenarios, such as changes in configuration parameters, MIB synchronization phase, MIB audit phase, etc., the master gateway will actively check for configuration updates, or query the configuration-related information of the slave gateway, determine the slave gateway to be updated, and indicate the slave gateway to be updated. The slave gateway performs configuration synchronization; in other scenarios, such as powering on the slave gateway with an empty configuration, restarting the slave gateway, connecting to the network for the first time, etc., the slave gateway will also actively send a configuration synchronization request to the master gateway.

The slave gateway determines whether it is necessary to send a configuration synchronization request to the master gateway by comparing the version information of the configuration file currently stored on the slave gateway with the version information of the slave gateway configuration file generated by the master gateway. Different version information means different configuration files, and you need to perform the steps of synchronizing the slave gateway configuration file from the master gateway.

In some embodiments, as shown in Figure 8, in the case that the current slave gateway has stored the slave gateway configuration file issued by the master gateway to which the current slave gateway is connected, the slave gateway configuration method also includes the following step S311 .

In step S311, the slave gateway configuration file re-issued by the master gateway is received.

In some embodiments, as shown in Figure 9, the slave gateway configuration method further includes the following steps S321 to S322.

In step S321, the re-issued slave gateway configuration file is parsed to obtain an incremental configuration file. The incremental configuration file is a configuration fragment generated by the master gateway for the changed master gateway configuration parameters.

In step S322, the incremental slave gateway configuration file is merged with the slave gateway configuration file currently stored on the slave gateway to form a modified slave gateway configuration file.

Configuration changes sometimes only change individual parameters. It would be a waste of network resources to regenerate the complete slave gateway configuration file every time and then synchronize the complete configuration file to all slave gateways. Therefore, in addition to generating a complete slave gateway configuration file based on the changed parameters, the master gateway can also use incremental configuration files to synchronize the configuration to the slave gateway in order to save resources and reduce the burden of file transfer on the network. For example, using modular file encoding formats such as XML and JSON, an incremental file only contains necessary module content to achieve lightweight configuration synchronization. After receiving it from the gateway, only the parameters in the incremental configuration can be synchronously updated based on the existing configuration file, leaving other content unchanged.

In some embodiments, as shown in Figure 10, the secondary gateway configuration method further includes the following step S331.

In step S331, configuration update information is sent to the master gateway to represent the version of the current slave gateway.

Further, as shown in Figure 11, during the MIB synchronization phase, before sending the configuration update information to the main gateway (ie, step S331), the following step S332 is also included.

In step S332, in response to the file update check message of the main gateway, configuration update information for the file update check message is fed back to the main gateway.

Further, as shown in Figure 12, after the MIB audit is completed and before sending the configuration update information to the main gateway (ie, step S331), step S333 is also included.

In step S333, in response to the configuration file query message of the main gateway, configuration update information for the configuration file query message will be sent to the main gateway.

Further, the configuration update information includes: version information of the slave gateway configuration file stored on the slave gateway, and/or a hash code used to verify the integrity of the slave gateway configuration file stored on the slave gateway.

In some scenarios, such as configuration changes, the master gateway GETs to the slave network in MIB audit If the configuration file version is inconsistent, etc., the master gateway will actively initiate configuration synchronization with the slave gateway. The slave gateway will receive an update instruction from the master gateway to update the configuration file, and then perform the configuration synchronization steps.

In other scenarios, such as when the main gateway is powered on, the main gateway will first send an update check message to collect the version information fed back from the slave gateway and the hash code corresponding to the current configuration file. The main gateway will determine whether to continue performing configuration synchronization. step.

In some embodiments, as shown in Figure 13, after the step of receiving the slave gateway configuration file issued by the primary gateway to which the slave gateway is currently connected (ie, step 300), the following steps S341 to S343 are also included.

In step S341, the slave gateway configuration file issued by the master gateway is verified.

In step S342, if the verification fails, a download failure response is sent to the main gateway.

In step S343, if the verification is successful, the relevant business module is called to configure parameters.

In some embodiments, verifying the slave gateway configuration file issued by the master gateway (ie, step S341) includes at least one of the following verifications: file legality verification, time verification, download integrity Verification, content validity verification, configuration validity verification.

In some embodiments, if the verification is successful, before the step of calling the relevant business module to configure parameters (ie, step S343), it also includes: performing the verification on the slave gateway configuration file issued by the master gateway. Configuration check.

The configuration check includes at least one of the following checks: file basic element check, file integrity check, and parameter value legality check.

When the master gateway confirms that it needs to update the slave gateway XML configuration file, for example, if the user account of the slave gateway is modified through the WEB, it needs to notify all online slave gateways to immediately update the relevant configuration files. The basic format of the XML file in the slave gateway is consistent with the default pre-configuration file of the master and slave gateway versions. Figure 21 shows the basic format of the XML configuration file. The basic content is as follows: Add the HashCode attribute in the <DB> tag, and the content is to perform the entire file The value calculated by the MD5 digest algorithm is used to verify the integrity of the entire XML file content. There must be a Version field configuration of the CfgFile table in each XML, and the configuration of this table must be at the front. The CfgFile table only includes the field Version, which represents the configuration file. According to the iteration of the software, the product confirms whether it is suitable for the current gateway based on the Version.

The HashCode in the above XML configuration file header is generated based on the entire file using the MD5 algorithm. After the MD5 value is calculated, it is backfilled into the HashCode field. That is, the HashCode is the secret key of the MD5 algorithm. The processing of XML configuration files from inside the gateway ONU is mainly divided into two processes: verification and configuration. During the verification phase, if a parameter fails to pass the verification, failure will be returned immediately. After all items have been successfully verified, the configuration phase will be entered. If any parameter configuration fails during the configuration phase, continue with subsequent configuration items. Layered verification of XML configuration files includes the following aspects:

1) Legality verification: Configuration file header verification to confirm whether the file is suitable for the current ONU product;

2) Time verification: Configuration file header verification to confirm whether the file is an updated file;

3) Download the complete check: the main gateway calculates the CRC based on the entire file, receives it from the gateway and calculates the comparison. This check is optional and its function is close to the MD5 function;

4) Content validity verification: Complete content verification based on the MD5 information summary in the file header;

5) Configuration validity verification: Pre-check the parameter content one by one, mainly checking whether the table is correct and whether the fields and field values are correct.

Parsing and configuring the XML configuration file includes calling the API interface provided by each module to configure parameters, so that the business configuration can take effect immediately.

The configuration files need to be checked and merged from the gateway. Configuration checks are mainly divided into basic element checks of XML files, complete file integrity checks, and parameter value legality checks, among which:

1) The basic element inspection of XML files is completed by the XML framework;

2) File integrity check is completed by the configuration download function framework;

3) Parameter value legality check is completed by the corresponding business module.

When changes are found in the master gateway configuration, if a slave gateway is involved, the XML configuration file will be updated synchronously and notified to be re-issued. The slave gateway will check the correctness and completeness of the content of the configuration file.

In some embodiments, the slave gateway configuration file issued by the master gateway is received through a privately defined channel of OMCI or an extended OAM channel.

It should be noted that you can choose to use it according to application scenarios such as GPON or EPON. Deliver the slave gateway configuration file to the slave gateway through the privately defined channel of OMCI or the extended OAM channel, including but not limited to the various master gateways described in the embodiments of this disclosure that deliver the slave gateway configuration to the slave gateway. The file scenario can include the slave gateway configuration file issued by the master gateway when the slave gateway first accesses, or the changed slave gateway configuration file issued by the master gateway when the master gateway configuration parameters change, or incremental configuration. Files can also include slave gateway configuration files issued during the MIB synchronization or MIB audit phase. We will not list them all here. All master gateways issue configuration files to the slave gateway through the privately defined channel of OMCI or the extended OAM channel. All scenarios fall within the protection scope of this disclosure.

In some embodiments, the slave gateway configuration method further includes: when the slave gateway detects that a synchronization condition is met, sending a configuration file synchronization request to the master gateway, wherein the synchronization condition includes at least one of the following conditions: Types: Power on from the gateway, restart from the gateway, newly join the network from the gateway, and only have the default configuration from the gateway.

In addition to the master gateway taking the initiative to synchronize configuration with the slave gateway, the slave gateway can also actively request configuration synchronization. When the slave gateway defaults to zero configuration (it can also have a default pre-configuration), the master gateway will deliver the gateway configuration file to the slave gateway, and the slave gateway configuration file will take effect immediately on the slave gateway, thereby realizing immediate deployment of the slave gateway. Plug and play.

One of the purposes of this disclosure is to simplify the process of ITMS network management to manage the slave gateway due to the complicated configuration and management of the slave gateway. The slave gateway is no longer managed through the ITMS network management. The slave gateway does not issue work orders separately, and the master gateway directly synchronizes key configurations (or Delivered) to the slave gateway, and the slave gateway implements plug-and-play.

The main advantages of this disclosed solution include: simplifying the configuration process of the slave gateway, enabling plug-and-play, and no longer requiring ITMS network management or cloud platforms to directly configure and manage the slave gateway, which is automatically generated by the master gateway based on the current network configuration. From the gateway's XML configuration file, load the XML file or incremental XML file from the gateway to meet business validation requirements.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the disclosure. The objectives and other advantages of the present disclosure may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

The slave gateway configuration method of the present disclosure will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, without conflict, the embodiments and implementations in this application The features in the examples can be combined with each other.

Example 1

Figure 14 is a schematic diagram of the configuration and management architecture of the FTTR master and slave gateways. In the current master and slave gateway networking architecture, the configuration management of the master and slave gateways is still controlled by the ACS network management and cloud platform. For example, when accessing from a gateway, the master gateway needs to perform device platform authentication on behalf of the slave gateway. The master gateway controls the slave gateway based on the authentication results of the gateway management platform. At present, the configuration management of the above-mentioned slave gateway is basically the same as that of the master gateway, which puts a heavy load on the ACS network management and cloud platform. In the existing master and slave gateway networking mode, the slave gateway generally works in bridge forwarding mode, and the network configuration is relatively simple. The configuration parameters of the slave gateway depend on the master gateway. In fact, the configuration of the slave gateway can be directly downloaded through the master gateway. Send for synchronization. This disclosure optimizes the configuration management architecture of the FTTR master and slave gateways.

Figure 15 is a schematic diagram of the master and slave gateway configuration file synchronization framework according to the present disclosure. This disclosure proposes a method for synchronizing the master and slave gateway configurations. The master gateway (Master ONU) presets the slave gateway XML template configuration file, and the slave gateway (Slave ONU) successfully registers with the master gateway through LOID or serial number (SN, Serial Number). Afterwards, the slave gateway does not need to modify the configuration and can automatically synchronize the relevant configuration of the master device. The slave gateway device is powered on and connected to the master gateway. The master gateway can automatically generate the slave gateway XML configuration file according to the local configuration. When the slave gateway is powered on and connected, it is transmitted and downloaded through OMCI or extended OAM transparent channels. For newly added parameter configuration items, the instructions are displayed through the XML incremental configuration file, and the API interface provided by the relevant business module is called after parsing from the gateway to take effect synchronously in real time. When the slave gateway defaults to zero configuration (it can also have default pre-configuration), the master gateway delivers the XML configuration file to the slave gateway and it takes effect immediately.

When FTTR networking is activated, first save the basic template cfg.xml file to the main gateway. For example, pre-configure an Internet transparent transmission bridge and wireless service set identifier (SSID, Service Set Identifier) and key-related configurations as the default template configuration file to ensure that basic services can be implemented after accessing from the gateway. After the gateway is powered on or restored to factory settings, it automatically interacts with the main gateway to download the XML configuration file. After the configuration file is delivered, the ONU will call the relevant business module to reload the configuration and take effect immediately without restarting the ONU to reduce the impact of configuration upgrades on the user experience. Impact.

The configuration file can be viewed and modified through the local WEB page of the main gateway. The main gateway When receiving relevant business configuration parameter change messages issued by ITMS network management or cloud platform, the slave gateway cfg.xml file will be dynamically and synchronously updated, and the cfg.xml configuration will be automatically delivered to multiple slave gateway ONUs.

As long as it detects that the slave gateway cfg.xml has been updated, the ONU must re-download cfg.xml.

The content in the above XML file is privately defined based on specific business scenarios and functional requirements, including basic data service forwarding configuration on the WAN side and LAN side. For new functional services, the XML file format needs to be expanded and adjusted simultaneously.

The XML file can also be pre-configured according to specific customization requirements. The content of the XML file can be full configuration or incremental configuration.

Example 2

Figure 16 is a flow chart of reporting file time information in the MIB synchronization stage according to the present disclosure, including the following steps 201 to 204.

In step 201, the main gateway actively requests a file update check (MIB Upload next) during the MIB synchronization phase.

In step 202, the gateway reports the MIB Upload next response message through the MIB Upload next response message, which includes: the version information FileVersion of the configuration file (xml cfg), and the hash code (HashCode) corresponding to the configuration file.

In step 203, the master gateway checks whether the file needs to be updated.

In step 204, if the XML configuration file needs to be updated, download the configuration file.

Example 3

Figure 17 is a flow chart of querying file time information after MIB synchronization according to the present disclosure, including the following steps 301 to 304.

In step 301, the master and slave gateway MIB audits are synchronized.

In step 302, the master gateway actively queries (GET) the slave gateway XML file time information.

In step 303, the master gateway receives the slave gateway query response (GET response) and checks whether the file needs to be updated.

In step 304, if the XML configuration file needs to be updated, download the configuration file. load.

Example 4

Figure 18 is a normal flow chart for delivering a configuration file from a gateway according to the present disclosure, including the following steps 401 to 406.

In step 401, the master gateway requests to obtain the current configuration file version and update time (UpdateTime) of the slave gateway.

In step 402, after receiving the request from the gateway, fill in relevant parameters and respond.

In step 403, the main gateway checks and compares the XML configuration file to see if there is an update. If there is an update, it downloads the configuration file through "ONU XML configuration download" in the OMCI private definition and MEClass=65300.

In step 404, after receiving the download configuration file end message (EndDownLoad) from the gateway, the Cyclic Redundancy Check (CRC, Cyclic Redundancy Check) is checked to verify legality and integrity, and to verify the update time.

In step 405, if the above verifications all pass, an EndDownLoad response message will be sent. result=0 indicates success and the main gateway is notified that the download is successful.

In step 406, each relevant business module is called from the gateway for configuration, and the local XML file version and update time are updated.

Example 5

Figure 19 is a flow chart of delivering an exception from a gateway configuration file according to the present disclosure, including the following steps 501 to 505.

Steps 501 to 504 are the same as steps 301 to 304 in Figure 17 and will not be described again.

In step 505, after receiving the EndDownLoad message from the gateway to download the configuration file, check the CRC, verify the legality and integrity, and verify the update time. If one of the verifications fails, the EndDownLoad response message is sent, result=1 Indicates failure, notifying the main gateway that the download failed.

Example 6

Figure 20 is a flow chart of preflighting the gateway XML configuration file according to the present disclosure, including the following steps 601 to 605.

In step 601, the XML configuration file download end event is received from the gateway, and the XML configuration file version and update time are checked and compared. If no update is required, a download failure of the main gateway that supports the MiniOLT function is responded to; if an update is required, proceed to step 602 as follows. .

In step 602, calculate and verify the CRC. If the verification fails, respond to the main gateway that the MiniOLT download failed; if the verification succeeds, proceed to the following step 603.

In step 603, calculate and verify the MD5. If the verification fails, respond to the main gateway that the MiniOLT download failed; if the verification succeeds, proceed to the following step 604.

In step 604, each parameter field is checked table by table in a loop. If the intermediate verification fails, respond to the main gateway that the MiniOLT download failed; if the verification is successful, continue to load other entries.

In step 605, in response to the successful download of MiniOLT from the main gateway, the relevant parameter nodes are parsed and the original TR069 related parameter API is called for service distribution to ensure that the service takes effect simultaneously and in real time.

Example 7

Figure 21 is a schematic diagram of the format of the secondary gateway XML configuration file according to an embodiment of the present disclosure. The format definition of this XML file can refer to the TR098 standard specification. During specific implementation, the specific parameter DB storage format of the WAN side or LAN side entity object can be redefined according to this specification. , such as InternetGatewayDevice.WANDevice.{i}.

WANConnectionDevice.XXX parameter configuration can be converted into each parameter item in the DB Table table WANC. At the same time, the configuration file can be delivered from the complete set of gateway service XML configuration files or incremental XML configuration parameter sets.

Example 8

Figure 22 is a schematic diagram of the slave gateway JSON configuration file format according to an embodiment of the present disclosure. The format definition of the JSON file is organized according to the key/value format of the JSON file standard, and parameter names and parameters are defined according to the requirements of each business object entity. value content.

Other configuration file encoding formats between the master and slave gateways can also be supported, and can be expanded and defined based on business needs.

The present disclosure can also have various other embodiments. Without departing from the spirit and essence of the present disclosure, those skilled in the art can make various corresponding changes and modifications based on the present disclosure. However, these corresponding changes and All modifications shall belong to the claims attached to this disclosure. scope of protection.

In summary, the present disclosure discloses a method for FTTR master and slave gateways to synchronize business data through configuration files. This method can effectively simplify the configuration management of the slave gateway and realize plug-and-play of the slave gateway.

It should be noted that the above embodiments illustrate preferred embodiments of the present disclosure and do not limit the scope of rights of the present disclosure. In addition to the above implementation methods, the master gateway can also act as the ITMS network management role and issue configurations to the slave gateways through TR069 work orders.

An embodiment of the present disclosure also provides an electronic device, as shown in Figure 23, which includes: one or more processors 701; and a memory 702, on which one or more programs are stored. When one or more programs are processed by a Or multiple processors execute, so that one or more processors implement the slave gateway configuration method according to various embodiments of the present disclosure.

In addition, the electronic device may also include one or more I/O interfaces 703, connected between the processor and the memory, and configured to implement information exchange between the processor and the memory.

The processor 701 is a device with data processing capabilities, including but not limited to a central processing unit (CPU), etc.; the memory 702 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM). , DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); the I/O interface (read-write interface) 703 is connected between the processor 701 and the memory 702, and can Implement information interaction between the processor 701 and the memory 702, which includes but is not limited to a data bus (Bus), etc.

In some embodiments, processor 701, memory 702, and I/O interface 703 are connected to each other and, in turn, to other components of the computing device via bus 704.

Embodiments of the present disclosure also provide a computer-readable storage medium. As shown in Figure 24, a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the slave gateway configuration method according to various embodiments of the present disclosure is implemented. .

Aiming at the problem of complicated configuration and management of slave gateways in existing FTTR all-optical networking scenarios, this disclosure proposes a method for the FTTR master gateway to directly synchronize configuration files with the slave gateway to achieve business data synchronization. The master gateway automatically generates a slave gateway configuration file based on the configuration information delivered to the current master gateway by the ITMS network management or cloud platform, and subsequently delivers the configuration file directly to the slave gateway through OCMI or extended OAM transparent channels. This method no longer passes ITMS network management can effectively simplify the configuration and management process of the slave gateway, allowing zero-configuration access from the slave gateway and realizing plug-and-play from the slave gateway. While simplifying the configuration management of the slave gateway, it also reduces the processing load of the slave gateway on the ITMS network management or cloud platform.

Those of ordinary skill in the art can understand that all or some steps, systems, and functional modules/units in the devices disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof.

In hardware implementations, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may consist of several physical components. Components execute cooperatively. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit . Such software may be distributed on computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). As is known to those of ordinary skill in the art, the term computer storage media includes volatile and nonvolatile media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. removable, removable and non-removable media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassettes, tapes, disk storage or other magnetic storage devices, or may Any other medium used to store the desired information and that can be accessed by a computer. Additionally, it is known to those of ordinary skill in the art that communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

The preferred embodiments of the present disclosure have been described above with reference to the accompanying drawings, but the scope of rights of the present disclosure is not thereby limited. Any modifications, equivalent substitutions and improvements made by those skilled in the art without departing from the scope and essence of the present disclosure shall be within the scope of rights of the present disclosure.

Claims (25)

1. A slave gateway configuration method for the master gateway, including:

   Generate a slave gateway configuration file based on the configuration parameters of the current master gateway and the template configuration file corresponding to the slave gateway;

   When the slave gateway accesses the current primary gateway, the slave gateway configuration file is delivered to the slave gateway.
2. The slave gateway configuration method according to claim 1, wherein the template configuration file corresponding to the slave gateway includes configuration parameter templates respectively corresponding to each service of the slave gateway.
3. The secondary gateway configuration method according to claim 1, further comprising:

   In the case where the configuration parameters of the primary gateway are changed, regenerate the secondary gateway configuration file based on the changed configuration parameters of the primary gateway and the template configuration file corresponding to the secondary gateway;

   Deliver the regenerated slave gateway configuration file to the slave gateway corresponding to the changed configuration parameters.
4. The secondary gateway configuration method according to claim 1, further comprising:

   In the case where the configuration parameters of the primary gateway are changed, an incremental configuration file of the secondary gateway is generated based on the changed configuration parameters of the primary gateway and the template configuration file corresponding to the secondary gateway, wherein, The incremental configuration file is a configuration fragment generated for the changed configuration parameters of the main gateway;

   The incremental configuration file is delivered to the slave gateway connected to the current master gateway, so that the incremental configuration file is merged with the slave gateway configuration file stored on the slave gateway to form a changed slave gateway configuration file.
5. The secondary gateway configuration method according to claim 1, further comprising:

   Determine the slave gateway to be updated according to the configuration update information of the slave gateway;

   Deliver the slave gateway configuration file stored locally on the current master gateway to the slave gateway to be updated.
6. The slave gateway configuration method according to claim 5, wherein before determining the slave gateway to be updated according to the configuration update information of the slave gateway, the slave gateway configuration method further includes:

   Send an update check message of the slave gateway configuration file to at least one slave gateway connected to the current master gateway;

   Receive configuration update information fed back by each slave gateway to the current master gateway in response to the update check message.
7. The slave gateway configuration method according to claim 5, wherein before determining the slave gateway to be updated based on the configuration update information of the slave gateway, the slave gateway configuration method further includes:

   Send a configuration file query message to the slave gateway connected to the current master gateway;

   Receive configuration update information sent by the slave gateway in response to the configuration file query message.
8. The slave gateway configuration method according to claim 5, wherein determining the slave gateway to be updated according to the configuration update information of the slave gateway includes:

   Parse the configuration update information and obtain the version information of the slave gateway configuration file stored locally on the slave gateway;

   When the version information of the slave gateway configuration file stored on the slave gateway is different from the version information of the slave gateway configuration file stored locally on the current master gateway, the slave gateway is determined to be the slave gateway to be updated.
9. The slave gateway configuration method according to claim 5, wherein determining the slave gateway to be updated according to the configuration update information of the slave gateway includes:

   Parse the configuration update information and obtain a hash code used to verify the integrity of the secondary gateway configuration file stored on the secondary gateway;

   If the hash code verification fails, the slave gateway is determined to be the slave gateway to be updated.
10. The slave gateway configuration method according to any one of claims 1 to 9, wherein the slave gateway is issued to the slave gateway through a privately defined channel of the optical network unit management control interface OMCI or a channel of the extended operation management and maintenance OAM. Gateway configuration file.
11. The slave gateway configuration method according to any one of claims 1 to 9, wherein before issuing the slave gateway configuration file to the slave gateway, the slave gateway configuration method further includes:

    The configuration parameters of the main gateway are obtained through the service configuration issued by the network management or management platform to which the current main gateway belongs.
12. A slave gateway configuration method for slave gateways, including:

    Receive the slave gateway configuration file issued by the master gateway currently connected to the slave gateway, wherein the slave gateway configuration file includes the master gateway configuration parameters based on the master gateway currently connected to the slave gateway and the template configuration corresponding to the current slave gateway. File generated from the gateway configuration file.
13. The slave gateway configuration method according to claim 12, wherein the template configuration file corresponding to the slave gateway includes configuration parameter templates respectively corresponding to each service of the slave gateway.
14. The slave gateway configuration method according to claim 12, wherein in the case that the current slave gateway has stored the slave gateway configuration file issued by the master gateway to which the slave gateway is currently connected, the slave gateway configuration method further includes:

    Receive the slave gateway configuration file re-issued by the master gateway.
15. The secondary gateway configuration method according to claim 14, further comprising:

    The reissued slave gateway configuration file is parsed to obtain an incremental configuration file, where the incremental configuration file is the changed master gateway configuration parameters of the master gateway. Number of generated configuration fragments;

    The incremental slave gateway configuration file is merged with the slave gateway configuration file currently stored on the slave gateway to form a changed slave gateway configuration file.
16. The slave gateway configuration method according to claim 12, further comprising:

    Send configuration update information to the master gateway, used to represent the version of the current slave gateway.
17. The slave gateway configuration method according to claim 16, wherein before sending configuration update information to the master gateway, the slave gateway configuration method further includes:

    In response to the file update check message of the main gateway, configuration update information for the file update check message is fed back to the main gateway.
18. The slave gateway configuration method according to claim 16, wherein before sending configuration update information to the master gateway, the slave gateway configuration method further includes:

    In response to the configuration file query message of the main gateway, send configuration update information for the configuration file query message to the main gateway.
19. The slave gateway configuration method according to claim 16, wherein the configuration update information includes:

    The version information of the secondary gateway configuration file stored on the secondary gateway, and/or

    A hash code used to verify the integrity of the secondary gateway configuration file stored on the secondary gateway.
20. The slave gateway configuration method according to claim 12, wherein after receiving the slave gateway configuration file issued by the primary gateway to which the slave gateway is currently connected, the slave gateway configuration method further includes:

    Verify the slave gateway configuration file issued by the master gateway;

    In the case of verification failure, respond to the main gateway that the download failed;

    If the verification is successful, call the relevant business module to configure parameters.
21. The slave gateway configuration method according to claim 20, wherein the master The verification from the gateway configuration file issued by the gateway includes at least one of the following verifications:

    File legality verification, time verification, download integrity verification, content validity verification, and configuration validity verification.
22. The secondary gateway configuration method according to claim 20, wherein, if the verification is successful, before calling the relevant business module for parameter configuration, the secondary gateway configuration method further includes:

    Check the configuration of the slave gateway configuration file issued by the master gateway,

    Wherein, the configuration check includes at least one of the following checks:

    Check the basic elements of the file, check the integrity of the file, and check the legality of parameter values.
23. The slave gateway configuration method according to any one of claims 12 to 22, wherein the configuration sent by the master gateway is received through a privately defined channel of the optical network unit management control interface OMCI or a channel of the extended operation management and maintenance OAM. From the gateway configuration file.
24. An electronic device, the electronic device includes:

    one or more processors;

    A memory having one or more programs stored thereon. When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 23. The slave gateway configuration method described in the item.
25. A computer-readable storage medium. A computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the slave gateway configuration method according to any one of claims 1 to 23 is implemented.