Equipment parameter verification method and device of FTTR equipment, equipment and medium

Abstract

The embodiment of the invention provides an equipment parameter verification method and device of FTTR equipment, equipment and a medium. According to the method and the device, the parameter tree containing the parameter specified characteristics is constructed for the FTTR equipment, and the batch parameter positioning and verification driven by the verification path are realized in combination with the intelligent node search engine, so that the batch automatic multi-dimensional verification of a plurality of parameters can be realized at one time, and compared with a method of manually verifying the parameters one by one in the traditional technology, the efficiency is improved. The verification time can be remarkably shortened, and misjudgment and missing detection can be avoided, so that the accuracy and efficiency of equipment parameter verification of the FTTR equipment are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of communication network technology, and in particular to a method, apparatus, device and medium for verifying the device parameters of FTTR equipment. Background Technology

[0002] In recent years, Fiber To The Room (FTTR) networking has been deployed on a large scale. Efficiently verifying the massive number of device parameters of FTTR equipment (such as the master gateway and slave gateway devices in FTTR networking) has become the key to ensuring the quality of network services.

[0003] Currently, the verification of FTTR device parameters mainly relies on manual methods (for example, maintenance personnel verify the parameter value of each device against the expected reference value one by one). This manual verification method is not only inefficient but also prone to errors, and cannot meet the maintenance needs of large-scale networks. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, device, and medium for verifying the device parameters of an FTTR device, so as to achieve accurate and efficient verification of FTTR device parameters.

[0005] This application provides a method for verifying device parameters of an FTTR device, the method comprising: Generate a corresponding parameter tree for the FTTR device; each node in the parameter tree represents a parameter of the corresponding TR-069 protocol configured for the FTTR device; different nodes represent different parameters, and any node is associated with a specified characteristic of the parameter corresponding to that node; the specified characteristic includes at least: the timestamp of the parameter being last updated, and writability permission: indicating whether the parameter can be remotely written to and modified via the TR-069 protocol; When there is a parameter verification requirement, the intelligent node search engine is invoked to search for each parameter to be verified in batches from the parameter tree based on the verification path; each parameter is verified based on the specified characteristics associated with it; the verification path includes each path composed of parameters that meet the parameter verification requirement.

[0006] As an example, the specified characteristics associated with any node also include: the path from the root node to the node; the root node corresponds to the FTTR device; the path is used to generate an alarm log entry for the parameter when an anomaly occurs in the verification of the parameter corresponding to the node.

[0007] As an example, the specified characteristics associated with any node also include: parameter name, parameter type, and parameter value data type; The parameter type is used to indicate whether a parameter has a corresponding parameter value; if the parameter type of any parameter is of the first type, it indicates that the parameter has a corresponding parameter value; if the parameter type of any parameter is of the second type, it indicates that the parameter does not have a corresponding parameter value. The parameter value data type includes at least one of the following data types: string data type, numeric data type, and boolean data type.

[0008] As one embodiment, the step of calling the intelligent node search engine to batch search for the parameters to be verified from the parameter tree based on the verification path includes: The intelligent node search engine is invoked to find a target path template that matches the parameter verification requirements from the pre-existing path templates; the target path template contains the verification path.

[0009] As one embodiment, the verification of each parameter based on the specified characteristics associated with each parameter includes: For each parameter, verify whether the data type of the parameter value in the specified feature associated with the parameter matches the expected data type of the parameter value in the parameter verification requirement; if they do not match, output an exception alarm indicating that the data type of the parameter value does not match. And / or, Verify whether the writability permission in the specified feature associated with the parameter matches the expected writability permission of the parameter in the parameter verification requirement; if they do not match, output an abnormal alarm indicating that the writability permission does not match. And / or, Verify whether the parameter value in the specified feature associated with the parameter matches the expected parameter value in the parameter verification requirement. If they do not match, output an abnormal alarm indicating that the parameter values ​​do not match.

[0010] As one embodiment, the method includes: If a node corresponding to a parameter to be verified cannot be found in the parameter tree, an abnormal alarm indicating that the parameter does not exist will be output.

[0011] This application embodiment also provides a device parameter verification apparatus for an FTTR device, the apparatus comprising: A construction module is used to generate a corresponding parameter tree for the FTTR device; each node in the parameter tree represents a parameter of the corresponding TR-069 protocol configured for the FTTR device; different nodes represent different parameters, and any node is associated with a specified characteristic of the parameter corresponding to that node; the specified characteristic includes at least: the timestamp of the parameter being last updated, and writability permission: indicating whether the parameter can be remotely written to and modified through the TR-069 protocol; The verification module is used to call the intelligent node search engine to find each parameter to be verified in batches from the parameter tree based on the verification path when there is a parameter verification requirement; and to verify each parameter based on the specified characteristics associated with each parameter; the verification path includes each path composed of parameters that meet the parameter verification requirements.

[0012] As an example, the specified characteristics associated with any node also include: the path from the root node to the node; the root node corresponds to the FTTR device; the path is used to generate an alarm log entry for the parameter when an anomaly occurs in the verification of the parameter corresponding to the node.

[0013] As an example, the specified characteristics associated with any node also include: parameter name, parameter type, and parameter value data type; The parameter type is used to indicate whether a parameter has a corresponding parameter value; if the parameter type of any parameter is of the first type, it indicates that the parameter has a corresponding parameter value; if the parameter type of any parameter is of the second type, it indicates that the parameter does not have a corresponding parameter value. The parameter value data type includes at least one of the following data types: string data type, numeric data type, and boolean data type.

[0014] As one embodiment, the step of calling the intelligent node search engine to batch search for the parameters to be verified from the parameter tree based on the verification path includes: The intelligent node search engine is invoked to find a target path template that matches the parameter verification requirements from the pre-existing path templates; the target path template contains the verification path.

[0015] As one embodiment, the verification of each parameter based on the specified characteristics associated with each parameter includes: For each parameter, verify whether the data type of the parameter value in the specified feature associated with the parameter matches the expected data type of the parameter value in the parameter verification requirement; if they do not match, output an exception alarm indicating that the data type of the parameter value does not match. And / or, Verify whether the writability permission in the specified feature associated with the parameter matches the expected writability permission of the parameter in the parameter verification requirement; if they do not match, output an abnormal alarm indicating that the writability permission does not match. And / or, Verify whether the parameter value in the specified feature associated with the parameter matches the expected parameter value in the parameter verification requirement. If they do not match, output an abnormal alarm indicating that the parameter values ​​do not match.

[0016] As one embodiment, the verification module is further configured to: If a node corresponding to a parameter to be verified cannot be found in the parameter tree, an abnormal alarm indicating that the parameter does not exist will be output.

[0017] This application also provides an electronic device, including: a processor and a computer-readable storage medium for storing computer program instructions, wherein the computer program instructions, when executed by the computer-readable storage medium, cause the processor to perform the steps of the above method.

[0018] This application also provides a machine-readable storage medium storing computer program instructions that, when executed, enable the implementation of the steps described above.

[0019] As can be seen from the above technical solution, in this embodiment, firstly, a corresponding parameter tree is generated for the FTTR device. Each node in the parameter tree represents a unique parameter configured for the FTTR device under the TR-069 protocol. Different nodes correspond to different parameters, and each node is associated with a specified characteristic of its corresponding parameter. Then, when parameter verification is required, an intelligent node search engine is invoked to batch search for all parameter nodes to be verified in the parameter tree based on a predefined verification path. Furthermore, these parameters are automatically verified by combining the specified characteristics associated with each parameter node. This automated batch parameter location and verification method, compared to the traditional method of manually verifying each parameter one by one, not only significantly shortens the verification time but also avoids misjudgments and missed detections, thereby significantly improving the accuracy and efficiency of FTTR device parameter verification.

[0020] Furthermore, since the specified characteristics of each node associated with its corresponding parameter include not only the parameter value, but also the timestamp of the parameter's last update and writability permissions, it enables multi-dimensional automated verification of each parameter, thereby effectively improving the accuracy and reliability of the verification. Attached Figure Description

[0021] Figure 1 This is a diagram of the FTTR networking architecture provided in the embodiments of this application; Figure 2 A flowchart illustrating the method provided in the embodiments of this application; Figure 3 A schematic diagram of the process for generating a parameter tree provided in an embodiment of this application; Figure 4 A flowchart illustrating the process of finding and verifying parameters from a parameter tree, as provided in this application embodiment; Figure 5 This is a schematic diagram of the device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions provided in the embodiments of this application, and to make the above-mentioned objectives, features and advantages of the embodiments of this application more apparent and understandable, the technical solutions in the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0023] To better describe this solution, the FTTR networking provided in the embodiments of this application will be described first before describing the solution itself: FTTR networking is an ultimate broadband networking solution that directly lays fiber optic cables to each room, achieving whole-house gigabit-level, low-latency coverage.

[0024] See Figure 1 , Figure 1 This is a network architecture diagram of an FTTR network provided in an embodiment of this application.

[0025] like Figure 1 As shown, this FTTR network includes one master gateway device and multiple slave gateway devices. Both the master gateway device and the slave gateway devices can be referred to as FTTR devices.

[0026] In this network architecture, the main gateway device is the core control and aggregation device in the FTTR network. It is responsible for fiber-to-the-home (FTTH) access, network-wide service distribution, and centralized management and policy control of all slave gateways. Slave gateway devices are fiber optic access points deployed in each room. They are managed by the main gateway and are responsible for converting the backbone fiber optic signal into local high-performance wireless LAN (Wi-Fi) and wired networks.

[0027] Both the primary and secondary gateway devices need to be remotely managed and configured by the operator through the CPE WAN Management Protocol (CWMP), also known as the TR-069 protocol. The platform on which the operator manages these FTTR devices is the Remote Management System (RMS) platform, which is also the management platform for the TR-069 protocol.

[0028] After introducing FTTR networking, the method provided in the application embodiments will be described in detail below: See Figure 2 , Figure 2 This is a flowchart illustrating a method provided in one embodiment of this application. Optionally, the method can be applied to an improved RMS platform (by improving the configuration of the intelligent node lookup engine on the existing RMS platform), and the method can also be applied to a server independent of the RMS platform.

[0029] like Figure 2 As shown, the method may include the following steps: S201, Generate a corresponding parameter tree for the FTTR device; each node in the parameter tree represents a parameter configured for the FTTR device under the corresponding TR-069 protocol; different nodes represent different parameters, and any node is associated with the specified characteristics of the parameter corresponding to that node; the specified characteristics include at least: the timestamp of the parameter being last updated, and writability permission: indicating whether the parameter can be remotely written to and modified through the TR-069 protocol.

[0030] In this embodiment, the device parameters are those under the TR-069 protocol, representing all managed parameters of the FTTR device. Some of these parameters work together to support the FTTR device in achieving its service functions. Examples include parameters such as manufacturer, serial number, software version, Wi-Fi name, Wi-Fi enable switch, Ethernet port status, firewall level, and address pool address.

[0031] In this embodiment, in the parameter tree, the specified characteristics of the parameter corresponding to any node include not only the timestamp of the last update of the parameter and the writability permission, but also at least one of the following characteristics: the path from the root node to the node, the parameter name, the parameter type, the parameter value data type, and the parameter value.

[0032] The writability permission indicates whether the parameter can be remotely written to and modified via the TR-069 protocol.

[0033] The path from the root node to this node (i.e., the unique and complete path from the root node to this node), for example, InternetGatewayDevice.LANDevice.1.WLANConfiguration.1.SSID, represents a path InternetGatewayDevice→LANDevice.1→WLANConfiguration.1.SSID. This path is used to generate an alarm log entry for the parameter when an anomaly occurs during the verification of the parameter corresponding to this node. Furthermore, this path can also provide auxiliary location functionality when searching for the parameter to be verified in the parameter tree.

[0034] The parameter type indicates whether a parameter has a corresponding value. If any parameter's parameter type is the first type (indicated by `_object=false`), it means that the parameter has a corresponding value. In this case, the node type of the node corresponding to the parameter in the parameter tree is an object node. The specified characteristics associated with the node corresponding to the parameter include: parameter name, path from the root node to the node, parameter value, parameter type, parameter value data type, timestamp of the parameter's last update, and writability permissions.

[0035] If any parameter's parameter type is type 2 (indicated by _object=true), it means that the parameter does not have a corresponding parameter value. In this case, the node type of the node corresponding to the parameter in the parameter tree is a parameter node. The specified characteristics associated with the node corresponding to the parameter include: parameter name, path from the root node to the node, parameter type, timestamp of the parameter's last update, and writability permissions.

[0036] Parameter value data types are data types used to represent parameter values, including at least one of the following data types: string data type, numeric data type, and boolean data type. Parameter value data types conform to the TR-069 standard data type set.

[0037] It should be noted that for a parameter, if the parameter type in the specified characteristic associated with the parameter is of type 1, then the specified characteristic will have parameter value and parameter value data type. If the parameter type in the specified characteristic associated with the parameter is of type 2, then the specified characteristic will not have parameter value and parameter value data type.

[0038] In this embodiment, the specific implementation method for generating the corresponding parameter tree for the FTTR device will be illustrated with examples later, and will not be repeated here.

[0039] S202, when there is a parameter verification requirement, the intelligent node search engine is invoked to search for each parameter to be verified in batches from the parameter tree based on the verification path; each parameter is verified based on the specified characteristics associated with each parameter; the verification path includes each path composed of parameters that meet the parameter verification requirement.

[0040] In this embodiment, the intelligent node search engine is invoked to find nodes that match each path in the verification path from the parameter tree. The parameters corresponding to each found node are the parameters to be verified. The specified characteristics associated with each found node are the specified characteristics associated with each parameter.

[0041] As for how to call the intelligent node search engine to find the parameters to be verified in batches from the parameter tree based on the verification path, and the specific implementation method of verifying each parameter based on the specified characteristics associated with each parameter, it will be illustrated with examples later, and will not be elaborated here.

[0042] This concludes the process. Figure 2 The process is shown below.

[0043] pass Figure 2 As shown in the flowchart, in this embodiment, firstly, a corresponding parameter tree is generated for the FTTR device. Each node in the parameter tree represents a unique parameter configured for the FTTR device under the TR-069 protocol. Different nodes correspond to different parameters, and each node is associated with a specified characteristic of its corresponding parameter. Then, when parameter verification is required, the intelligent node search engine is invoked to batch search for all parameter nodes to be verified in the parameter tree based on a predefined verification path. Furthermore, these parameters are automatically verified by combining the specified characteristics associated with each parameter node. This automated batch parameter location and verification method, compared to the traditional method of manually verifying each parameter one by one, not only significantly shortens the verification time but also avoids false positives and false negatives, thereby significantly improving the accuracy and efficiency of FTTR device parameter verification.

[0044] Furthermore, since the specified characteristics of each node associated with its corresponding parameter include not only the parameter value, but also the timestamp of the parameter's last update and writability permissions, it enables multi-dimensional automated verification of each parameter, thereby effectively improving the accuracy and reliability of the verification.

[0045] The following section elaborates on generating the corresponding parameter tree for FTTR devices: See Figure 3 , Figure 3 This is a schematic diagram of the process for generating a parameter tree provided in an embodiment of this application.

[0046] like Figure 3 As shown, the process includes the following steps: S301, via the TR-069 protocol, sends a Get ParameterValues ​​request to the FTTR device to be verified.

[0047] S302 receives a response message containing a root_json file returned by the FTTR device.

[0048] Specifically, after the FTTR network is deployed, the FTTR devices need to be accepted. At this time, the server will receive a request to create a parameter tree. During operation and maintenance, when the device parameters of the FTTR devices need to be updated (for example, the version iteration of the master gateway device and the slave gateway device), the server will receive a request to create a parameter tree.

[0049] When the server receives a request from the client to create a parameter tree, it sends a Get Parameter Values ​​request to the FTTR device to be verified via the TR-069 protocol. This request instructs the FTTR device receiving the request to return a root_json file indicating the device parameter configuration of that FTTR device. The root_json file is a multi-level nested dictionary structure that implicitly contains the hierarchical relationship of all parameters of the FTTR device.

[0050] S303 analyzes the hierarchical structure of each parameter in the root_json file and constructs a parameter tree based on the analysis results.

[0051] Specifically, the hierarchical structure of each parameter in the root_json file is analyzed by a recursive depth-first traversal algorithm, and a complete in-memory parameter tree with accurate node relationships and specified characteristics is reconstructed based on the analysis results.

[0052] For example, the system identifies each parameter and its specified characteristics from the root_json file. These specified characteristics are distinguished from the parameters by feature identifiers (such as underscores). Fields starting with an underscore are the specified characteristics of the parameters, while fields without underscores are the parameters themselves. The system also analyzes the hierarchical relationship between the parameters, which is indicated by hierarchical relationship identifiers (such as parentheses).

[0053] A recursive depth-first traversal algorithm is used to iterate through each parameter in the root_json file. For the currently traversed parameter, it is determined whether the parameter has a parent parameter. If so, the parent parameter node is found in the current parameter tree (initially, the parameter tree only has a root node), and a child node corresponding to that parameter is created under the found node. The parameter's feature information is then associated with the newly created child node. If no parent parameter exists, the child node corresponding to that parameter is directly created under the root node, and the parameter's feature information is associated with the newly created child node. This process is repeated until the complete parameter tree is constructed.

[0054] In this embodiment, the deeply nested dictionary (root_json) returned by the TR-069 protocol, which is difficult to query directly, is transformed into a parameter tree with clear node relationships through a recursive depth-first traversal algorithm. This parameter tree displays the hierarchical relationships of the FTTR device's parameters by showing the topological structure of each node. This not only facilitates maintenance personnel's work based on the parameter tree but also provides a solid foundation for automatically batch searching for parameters to be verified when needed.

[0055] The above provides a detailed explanation of how to generate the corresponding parameter tree for FTTR devices.

[0056] The following section elaborates on how the intelligent node lookup engine retrieves the parameters to be verified in batches from the parameter tree based on the verification path, and how it verifies each parameter based on the specified characteristics associated with it: See Figure 4 , Figure 4 This is a schematic diagram illustrating the process of finding and verifying parameters from a parameter tree, as provided in an embodiment of this application.

[0057] like Figure 4 As shown, the process includes the following steps: S401 invokes the intelligent node search engine to find the target path template that matches the parameter verification requirements from the pre-existing path templates. The target path template contains the verification path.

[0058] Specifically, after the FFTR network deployment is completed, the FTTR devices need to be accepted. At this time, the server will receive parameter verification requests. Alternatively, during the FTTR device version iteration during operation and maintenance, or after configuring certain service functions of the FTTR devices, the server will also receive parameter verification requests. These parameter verification requests carry the various service functions of the FTTR device to be verified, or the parameters associated with the service functions to be verified, as well as the expected specified characteristics of each parameter.

[0059] After receiving a parameter verification request, the server will call the intelligent node search engine to find a target path template that matches the parameter verification request from the pre-existing path templates. For example, it will search for a matching target path template based on each business function to be verified. The target path template includes a verification path, which refers to each path that carries the parameters that meet the requirements of each business function.

[0060] Alternatively, as an example, each path in the verification path can be represented by a regular expression.

[0061] For example, if the parameter verification requirement is to verify the SSIDs of all WLAN Configuration instances (i.e., the parameter to be verified is the SSIDs of all WLAN Configuration instances), then the target path template for verifying the SSIDs of all WLAN Configuration instances is found from the existing path templates. Each path in the verification path of the target path template can be represented by the following regular expression: "InternetGatewayDevice.LANDevice.{i}.WLANConfiguration.{j}.SSID", The value of i is determined by the number of LANDevices in the FTTR device. For example, if the number of LANDevices is 4, then the value of i is 1, 2, 3, or 4.

[0062] Similarly, the range of values ​​for j is determined by the number of WLANConfiguration instances in the FTTR device.

[0063] In related technologies, one parameter corresponds to one path, which is the path from the root node to the node corresponding to that parameter. Furthermore, during the construction of the path template, this path needs to be manually generated based on the hierarchical relationship of the parameters. However, in this embodiment, the regular expression is a comprehensive expression of multiple paths, not a path corresponding to a single parameter (i.e., a fixed path). It can correspond to multiple parameters, making it more convenient to look up multiple parameters at once.

[0064] It should be noted that each path in the verification path of the target path template can be expressed by a regular expression alone, or by multiple paths (that is, one parameter path corresponding to one parameter, such as InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.Enable), or by multiple paths and regular expressions together. The specific composition depends on how the paths in the existing path template are composed, and this application embodiment does not specifically limit it.

[0065] It should also be noted that if a target path template matching the parameter validation requirements is not obtained, the paths consisting of parameters that meet the validation requirements (e.g., including regular expressions and fixed paths) are input into the intelligent node search engine in the form of an Excel spreadsheet. The intelligent node search engine uses these paths to batch search for the parameters to be validated in the parameter tree and saves the Excel spreadsheet as a path template. This path template includes the aforementioned paths and the business functions required by the parameter validation requirements. Since the parameters to be validated are relatively fixed during version updates, a target path template matching the parameter validation requirements can usually be obtained.

[0066] S402, based on the paths composed of parameters that meet the parameter verification requirements in the verification path, find each parameter to be verified in batches from the parameter tree.

[0067] Specifically, for each path, the corresponding nodes are searched in batches from the parameter tree. The specified characteristics associated with each node are the specified characteristics of the parameters to be verified. The batch search method follows the conventional method of traversing the parameter tree, which will not be described in detail in this embodiment.

[0068] In this embodiment, based on the constructed parameter book, combined with the depth-first traversal algorithm and regular expressions, multiple parameters can be obtained in batches at once, whereas in related technologies, only one parameter can be obtained at a time. If 100 parameters are queried, the method of this application embodiment only needs to query once, while the method of related technologies requires 100 queries. Reducing the number of queries from 100 to 1 significantly reduces the query time.

[0069] S403, Verify each parameter based on the specified characteristics associated with each parameter.

[0070] Specifically, validating a parameter for each specified characteristic associated with it includes validating it using at least one of the following validation dimensions: Verification Dimension 1: Verify whether the data type of the parameter value in the specified feature associated with this parameter matches the expected data type of the parameter value in the parameter verification requirements. If they do not match, output an exception alarm indicating that the data type of the parameter value does not match. If they match, the verification passes in this dimension. This is a verification in the type compliance dimension, used to check whether the data type of the parameter value conforms to the data type compatibility requirements of the TR-069 standard.

[0071] Verification Dimension 2: Verify whether the writability permission in the specified feature associated with the parameter matches the expected writability permission of the parameter in the parameter verification requirements; if they do not match, output an exception alarm indicating that the writability permission does not match; if they match, the verification is passed in this verification dimension. This is a verification in the permission compliance dimension, used to verify whether the writability permission of the parameter meets the business logic requirements.

[0072] Verification Dimension 3: Verify whether the parameter value in the specified feature associated with the parameter matches the expected parameter value in the parameter verification requirement. If they do not match, output an exception alarm indicating that the parameter values ​​do not match. If they match, the verification is passed in this dimension. This is a verification in the value range accuracy dimension, used to verify whether the parameter value meets expectations.

[0073] Optionally, the specific implementation methods for verifying whether the parameter value in the specified feature associated with the parameter matches the expected parameter value in the parameter verification requirement include at least one of the following methods: 1. Supports regular expression matching: The expected parameter value input can be a regular expression. If the parameter value in the specified feature associated with the parameter matches the regular expression matching logic, then a match is determined and the verification is passed; otherwise, a mismatch is confirmed and an exception alarm is sent.

[0074] 2. Support for range-based logical validation: The expected parameter value can be expressed by the range of values. For example, if the expected parameter value range is (0, 10), if the parameter value in the specified feature associated with the parameter is within the range of 0 to 10, then a match is determined and the validation is passed; otherwise, a mismatch is confirmed and an exception alarm is sent.

[0075] 3. Supports inclusion relationship verification: Expected parameter values ​​can be in the form of a list, such as ['A', 'B']. If the parameter value in the specified feature associated with the parameter exists in the list, then a match is determined and the verification is passed; otherwise, a mismatch is confirmed and an exception alarm is sent.

[0076] Furthermore, as an example, if the node corresponding to a parameter to be verified in the verification path cannot be found in the parameter tree, an exception alarm indicating that the parameter does not exist is output. This belongs to verification dimension 4, the existence verification dimension, which is used to verify whether the parameter to be verified is in the parameter tree.

[0077] By using the above method, each parameter is verified from the four verification dimensions mentioned above. Compared with the single dimension of parameter value verification in related technologies, the verification of the four verification dimensions not only verifies the parameter value, but also simultaneously verifies data type compliance, writability permissions, etc., to achieve more comprehensive verification and thus promptly discover configuration defects of device parameters.

[0078] Furthermore, in this embodiment of the application, the above method can not only verify parameter abnormalities, but also accurately verify the type of abnormality, thereby facilitating subsequent anomaly investigation.

[0079] The methods provided in the embodiments of this application have been described above. The apparatus provided in the embodiments of this application is described below: See Figure 5 , Figure 5 This is a structural diagram of the device provided in an embodiment of this application. Figure 5 As shown, the device 500 includes a construction module 501 and a verification module 502.

[0080] The construction module 501 is used to generate a corresponding parameter tree for the FTTR device; each node in the parameter tree represents a parameter of the corresponding TR-069 protocol configured for the FTTR device; different nodes represent different parameters, and any node is associated with a specified characteristic of the parameter corresponding to that node; the specified characteristic includes at least: the timestamp of the parameter being last updated, and writability permission: indicating whether the parameter can be remotely written and modified through the TR-069 protocol; The verification module 502 is used to call the intelligent node search engine to search for each parameter to be verified in batches from the parameter tree based on the verification path when there is a parameter verification requirement; and to verify each parameter based on the specified characteristics associated with each parameter; the verification path includes each path composed of parameters that meet the parameter verification requirements.

[0081] As an example, the specified characteristics associated with any node also include: the path from the root node to the node; the FTTR device corresponding to the root node; and the path used to generate an alarm log entry for the parameter when an anomaly occurs in the verification of the parameter corresponding to the node.

[0082] As an example, the specified characteristics associated with any node also include: parameter name, parameter type, and parameter value data type; The parameter type indicates whether a parameter has a corresponding parameter value. If the parameter type of any parameter is of type 1, it means that the parameter has a corresponding parameter value. If the parameter type of any parameter is of type 2, it means that the parameter does not have a corresponding parameter value. The parameter value data type includes at least one of the following data types: string data type, numeric data type, and boolean data type.

[0083] As an example, calling the intelligent node search engine to batch search for the parameters to be verified from the parameter tree based on the verification path includes: The intelligent node search engine is invoked to find the target path template that matches the parameter verification requirements from the pre-existing path templates; the target path template contains the verification path.

[0084] As an example, verifying each parameter based on the specified characteristics associated with each parameter includes: For each parameter, verify whether the data type of the parameter value in the specified feature associated with the parameter matches the expected data type of the parameter value in the parameter verification requirements; if they do not match, output an exception alarm indicating that the data type of the parameter value does not match. And / or, Verify whether the writability permission in the specified feature associated with the parameter matches the expected writability permission of the parameter in the parameter verification requirements; if they do not match, output an exception alarm indicating that the writability permission does not match. And / or, Verify whether the parameter value in the specified feature associated with the parameter matches the expected parameter value in the parameter verification requirement. If they do not match, output an exception alarm indicating that the parameter values ​​do not match.

[0085] As one example, the verification module is also used for: If the node corresponding to a parameter to be verified in the verification path cannot be found in the parameter tree, an abnormal alarm indicating that the parameter does not exist will be output.

[0086] This application also provides an electronic device, including: a processor and a computer-readable storage medium for storing computer program instructions, wherein the computer program instructions, when executed by the computer-readable storage medium, cause the processor to perform the steps of the above method.

[0087] This concludes the process. Figure 5 Structural description of the device shown.

[0088] See Figure 6 , Figure 6 This is a structural diagram of an electronic device provided in an embodiment of this application. Figure 6 As shown, the hardware structure may include: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the method disclosed in the above example of this application.

[0089] Based on the same application concept as the above method, this application embodiment also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the method disclosed in the above examples of this application.

[0090] For example, the aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For instance, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0091] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for verifying the parameters of an FTTR device, characterized in that, The method includes: Generate a corresponding parameter tree for the FTTR device; each node in the parameter tree represents a parameter of the corresponding TR-069 protocol configured for the FTTR device; different nodes represent different parameters, and any node is associated with a specified characteristic of the parameter corresponding to that node; the specified characteristic includes at least: the timestamp of the parameter being last updated, and writability permission: indicating whether the parameter can be remotely written to and modified via the TR-069 protocol; When there is a parameter verification requirement, the intelligent node search engine is invoked to search for each parameter to be verified in batches from the parameter tree based on the verification path; each parameter is verified based on the specified characteristics associated with it; the verification path includes each path composed of parameters that meet the parameter verification requirement.

2. The method according to claim 1, characterized in that, The specified characteristics associated with any node also include: the path from the root node to the node; the root node corresponds to the FTTR device; the path is used to generate an alarm log entry for the parameter when an anomaly occurs in the verification of the parameter corresponding to the node.

3. The method according to claim 1, characterized in that, The specified characteristics associated with any node also include: parameter name, parameter type, and parameter value data type; The parameter type is used to indicate whether a parameter has a corresponding parameter value; if the parameter type of any parameter is of the first type, it indicates that the parameter has a corresponding parameter value; if the parameter type of any parameter is of the second type, it indicates that the parameter does not have a corresponding parameter value. The parameter value data type includes at least one of the following data types: string data type, numeric data type, and boolean data type.

4. The method according to claim 1, characterized in that, The process of calling the intelligent node search engine to batch search for the parameters to be verified from the parameter tree based on the verification path includes: The intelligent node search engine is invoked to find a target path template that matches the parameter verification requirements from the pre-existing path templates; the target path template contains the verification path.

5. The method according to claim 1, characterized in that, The verification of each parameter based on the specified characteristics associated with each parameter includes: For each parameter, verify whether the data type of the parameter value in the specified feature associated with the parameter matches the expected data type of the parameter value in the parameter verification requirement; if they do not match, output an exception alarm indicating that the data type of the parameter value does not match. And / or, Verify whether the writability permission in the specified feature associated with the parameter matches the expected writability permission of the parameter in the parameter verification requirement; if they do not match, output an abnormal alarm indicating that the writability permission does not match. And / or, Verify whether the parameter value in the specified feature associated with the parameter matches the expected parameter value in the parameter verification requirement. If they do not match, output an abnormal alarm indicating that the parameter values ​​do not match.

6. The method according to any one of claims 1 to 5, characterized in that, The method includes: If a node corresponding to a parameter to be verified cannot be found in the parameter tree, an abnormal alarm indicating that the parameter does not exist will be output.

7. A device for verifying the parameters of an FTTR (Flexible Transmission Time) device, characterized in that, The device includes: A construction module is used to generate a corresponding parameter tree for the FTTR device; each node in the parameter tree represents a parameter of the corresponding TR-069 protocol configured for the FTTR device; different nodes represent different parameters, and any node is associated with a specified characteristic of the parameter corresponding to that node; the specified characteristic includes at least: the timestamp of the parameter being last updated, and writability permission: indicating whether the parameter can be remotely written to and modified through the TR-069 protocol; The verification module is used to call the intelligent node search engine to find each parameter to be verified in batches from the parameter tree based on the verification path when there is a parameter verification requirement; and to verify each parameter based on the specified characteristics associated with each parameter; the verification path includes each path composed of parameters that meet the parameter verification requirements.

8. The apparatus according to claim 7, characterized in that, The specified characteristics associated with any node also include: the path from the root node to the node; the root node corresponds to the FTTR device; the path is used to generate an alarm log entry for the parameter when the verification of the parameter corresponding to the node is abnormal; And / or, The specified characteristics associated with any node also include: parameter name, parameter type, and parameter value data type; The parameter type is used to indicate whether a parameter has a corresponding parameter value; if the parameter type of any parameter is of the first type, it indicates that the parameter has a corresponding parameter value; if the parameter type of any parameter is of the second type, it indicates that the parameter does not have a corresponding parameter value. The parameter value data type includes at least one of the following data types: string data type, numeric data type, and boolean data type; And / or, The process of calling the intelligent node search engine to batch search for the parameters to be verified from the parameter tree based on the verification path includes: The intelligent node search engine is invoked to find a target path template that matches the parameter verification requirements from the pre-existing path templates; the target path template contains the verification path. And / or, The verification of each parameter based on the specified characteristics associated with each parameter includes: For each parameter, verify whether the data type of the parameter value in the specified feature associated with the parameter matches the expected data type of the parameter value in the parameter verification requirement; if they do not match, output an exception alarm indicating that the data type of the parameter value does not match. And / or, Verify whether the writability permission in the specified feature associated with the parameter matches the expected writability permission of the parameter in the parameter verification requirement; if they do not match, output an abnormal alarm indicating that the writability permission does not match. And / or, Verify whether the parameter value in the specified feature associated with the parameter matches the expected parameter value in the parameter verification requirement. If they do not match, output an abnormal alarm indicating that the parameter values ​​do not match. And / or, The verification module is also used for: If a node corresponding to a parameter to be verified cannot be found in the parameter tree, an abnormal alarm indicating that the parameter does not exist will be output.

9. An electronic device, characterized in that, The electronic device includes: Processor; and A computer-readable storage medium storing computer program instructions that, when executed by the processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 6.

Images