Method and device for checking compliance of optical transmission performance index hook-up point, and electronic equipment

Abstract

The application discloses a method and device for checking compliance of an optical transmission performance index hanging point and electronic equipment, comprising: performing rule analysis on a standardized requirement document to obtain a check metadata model object, and establishing a hash mapping table of card types and corresponding constraint conditions; when the warehousing analysis of the performance index data of the current batch is completed, filtering a target card ID list and a target port ID list according to a batch identifier and a target card type, and querying corresponding static configuration information in a PostgreSQL configuration library; performing entity existence check, port type compliance check and layer rate matching check on the performance index data according to the hash mapping table and the static configuration information to obtain a check result; and generating a multidimensional visual report according to entity existence, optical power index and section layer monitoring performance index. The application improves the efficiency and reliability of the compliance check of the optical transmission performance index hanging point, and can be widely applied to the technical field of optical transmission networks.

Description

Technical Field

[0001] This invention relates to the field of optical transmission network technology, and in particular to a method, apparatus, and electronic device for verifying the compliance of optical transmission performance indicators at connection points. Background Technology

[0002] In optical transmission networks, network management systems periodically report hundreds of performance metrics. This data is stored in CSV files via parsing services in search engines such as Elasticsearch (ES) for subsequent analysis. To ensure the accuracy and availability of performance data, operations and maintenance personnel must manually verify whether the connection points for performance metrics meet the standards, based on documents such as "Performance Standardization Test Requirements." For example, the document specifies that "the optical power index of the optical amplifier board must be connected to a PTP port with an LR_OPTICAL_SECTION layer rate."

[0003] The existing verification process has the following problems: 1) Manual verification is inefficient and prone to errors: It requires comparing the dynamic indicators in ES, the static port model in the PostgreSQL (PG) configuration library, and the standard Excel document one by one. The data of the three are heterogeneous and have different formats. Manual cross-system verification is very time-consuming, and it is extremely difficult to find hidden errors caused by missing layer rate attributes or mismatched attachment point types under the massive combination of ports and indicators.

[0004] 2) Standardized documents cannot be directly executed by machines: Documents such as "Performance Standardization Test Requirements" describe constraint rules in natural language and tabular form. Computers cannot directly understand and execute the attachment point restrictions in them, resulting in an "execution gap" between the document specifications and the actual system operation data.

[0005] 3) Lack of efficient and low-intrusion verification mechanisms: Simply using a full cross-database join query for consistency verification would generate enormous transient pressure on the database, affecting the response speed of normal network management system operations. No tiered filtering and targeted verification solutions for this scenario are currently available in the technology.

[0006] The above problems urgently need to be addressed. Summary of the Invention

[0007] The purpose of this invention is to at least partially solve one of the technical problems existing in the prior art.

[0008] Therefore, one objective of this invention is to provide a method for verifying the compliance of optical transmission performance index connection points. This method realizes a closed-loop transformation from operation and maintenance rules to automatic verification, significantly reduces the cross-database query pressure, and improves the efficiency and reliability of verifying the compliance of optical transmission performance index connection points.

[0009] Another objective of this invention is to provide a device for verifying the compliance of optical transmission performance indicators at connection points.

[0010] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of the present invention include: On one hand, embodiments of the present invention provide a method for verifying the compliance of optical transmission performance indicators at splice points, comprising the following steps: The standardized requirements document is parsed to obtain a verification metadata model object, and a hash mapping table between the board type and the corresponding constraint is established based on the verification metadata model object; Once the performance metrics data for the current batch is successfully entered into the database and parsed, a verification task is triggered. The target board ID list and target port ID list are filtered according to the batch identifier and target board type. The corresponding static configuration information is then retrieved from the PostgreSQL configuration database based on the target board ID list and the target port ID list. The performance indicator data is verified for entity existence, port type compliance, and layer rate matching based on the hash mapping table and the static configuration information to obtain the verification results. Based on the verification results, a multi-dimensional visualization report is generated according to entity existence, optical power index, and segment-level monitoring performance index.

[0011] Furthermore, in one embodiment of the present invention, the step of parsing the standardized requirements document to obtain a verification metadata model object, and establishing a hash mapping table between the board type and the corresponding constraint conditions based on the verification metadata model object, specifically includes: The standardized requirements document is converted into the verification metadata model object by the parsing adapter. The verification metadata model object includes a preset board type, a preset performance indicator name, an expected port object type, and an expected layer rate identifier. The hash mapping table is established using the preset board type as the key and the preset performance indicator name, the expected port object type, and the expected layer rate identifier as the constraint value.

[0012] Furthermore, in one embodiment of the present invention, the step of triggering a verification task after completing the data entry and parsing of the current batch performance index data, and filtering the target board ID list and the target port ID list according to the batch identifier and target board type, specifically includes: Once the current batch of performance metrics data has been successfully stored and parsed, the index status will be changed to "parsed". When the index status is detected as resolved, an asynchronous verification task is triggered to determine the corresponding batch identifier and the target board type; The batch identifier and the target board type are used as filtering conditions to perform an inverted index in the ES engine to obtain the target board ID list and the target port ID list.

[0013] Furthermore, in one embodiment of the present invention, the step of querying the corresponding static configuration information in the PostgreSQL configuration database based on the target board ID list and the target port ID list specifically includes: The target board ID list is used as input to initiate a batch query in the board model table of the PostgreSQL configuration database to obtain the board model information; A batch query is initiated on the port model table in the PostgreSQL configuration database using the target port ID list as input to obtain port service type information and layer rate list information; The static configuration information is obtained by summarizing the board model information, the port service type information, and the layer rate list information.

[0014] Furthermore, in one embodiment of the present invention, the step of performing entity existence verification, port type compliance verification, and layer rate matching verification on the performance indicator data based on the hash mapping table and the static configuration information to obtain the verification result specifically includes: A verification engine is constructed based on the hash mapping table; Based on the verification engine, the entity IDs of multiple entity objects in the performance metric data are determined, and it is determined whether the entity IDs exist in the static configuration information; Based on the verification engine, the expected port object type corresponding to the performance indicator data is determined, and it is determined whether the expected port object type is consistent with the port service type information contained in the static configuration information. Based on the verification engine, the layer rate field carried by the performance indicator data is determined, and it is determined whether the layer rate field is consistent with the layer rate list information contained in the static configuration information. If the entity ID exists in the static configuration information, the expected port object type is consistent with the port service type information contained in the static configuration information, and the layer rate field is consistent with the layer rate list information contained in the static configuration information, then the verification is confirmed to be successful.

[0015] Furthermore, in one embodiment of the present invention, the step of generating a multi-dimensional visualization report based on the verification results according to entity existence, optical power index, and segment-level monitoring performance index specifically includes: Create a first display area, a second display area, and a third display area in the visualization file; Based on the verification results, the existence records and associated records of each entity ID in the PostgreSQL configuration database are output to the first display area; Based on the verification results, the verification process details of the segment-level monitoring performance indicators will be output to the second display area; Based on the verification results, the verification process details of the optical power index will be output to the third display area; The multi-dimensional visualization report is generated based on the visualization file.

[0016] Furthermore, in one embodiment of the present invention, the optical transmission performance index connection point compliance verification method further includes the following steps: The verification execution process outputs a structured log and redirects it to the scheduling platform, and the execution result is fed back to the scheduling platform through a standard exit code; The scheduling platform triggers the archiving of verification result files and notification of verification results based on the standard exit code.

[0017] On the other hand, embodiments of the present invention provide a device for verifying the compliance of optical transmission performance indicators at splice points, comprising: The standardization rule parsing module is used to parse the standardization requirement document into a verification metadata model object, and to establish a hash mapping table between the board type and the corresponding constraint conditions based on the verification metadata model object. The configuration information query module is used to complete the storage and parsing of the performance index data of the current batch, trigger the verification task, filter the target board ID list and target port ID list according to the batch identifier and target board type, and query the corresponding static configuration information in the PostgreSQL configuration database according to the target board ID list and the target port ID list. The hierarchical verification module is used to perform entity existence verification, port type compliance verification, and layer rate matching verification on the performance indicator data according to the hash mapping table and the static configuration information, and obtain the verification results. The multi-dimensional report generation module is used to generate a multi-dimensional visualization report based on the verification results, according to entity existence, optical power index, and segment-level monitoring performance index.

[0018] On the other hand, embodiments of the present invention provide an electronic device, the electronic device including a memory, a processor, a computer program stored in the memory and executable on the processor, and a data bus for implementing connection communication between the processor and the memory, wherein the computer program, when executed by the processor, implements the optical transmission performance index connection point compliance verification method as described above.

[0019] On the other hand, embodiments of the present invention also provide a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more computer programs, which can be executed by one or more processors to implement the optical transmission performance index connection point compliance verification method as described above.

[0020] On the other hand, embodiments of the present invention also provide a computer program product, including a computer program, which, when executed by a processor, implements the optical transmission performance index connection point compliance verification method as described above.

[0021] The advantages and beneficial effects of the present invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention: In this embodiment of the invention, a verification metadata model object is obtained by parsing the standardized requirements document according to rules. A hash mapping table between the board type and the corresponding constraint is established based on the verification metadata model object. When the performance index data of the current batch is entered into the database and parsed, a verification task is triggered. The target board ID list and the target port ID list are filtered according to the batch identifier and the target board type. The corresponding static configuration information is obtained by querying the PostgreSQL configuration database according to the target board ID list and the target port ID list. The entity existence verification, port type compliance verification and layer rate matching verification are performed on the performance index data according to the hash mapping table and the static configuration information to obtain the verification results. Based on the verification results, a multi-dimensional visualization report is generated according to the entity existence, optical power index and segment layer monitoring performance index. This invention generates a verification metadata model by parsing standardized requirement documents, extracts indicator records from a dynamic performance database using asynchronous triggering and a hierarchical verification pipeline, and performs batch precise queries on a static configuration database. It completes multi-dimensional logical consistency verification of entity existence, port type compliance, and layer rate matching in memory, and finally outputs multi-dimensional visual reports by region based on focus points. This achieves a closed-loop transformation from operation and maintenance rules to automatic verification, significantly reducing cross-database query pressure and improving the efficiency and reliability of optical transmission performance indicator connection point compliance verification. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the embodiments of the present invention are described below. It should be understood that the drawings described below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1A flowchart illustrating the steps of a method for verifying the compliance of optical transmission performance indicators at splice points, as provided in an embodiment of the present invention. Figure 2 A flowchart of step S101 provided in an embodiment of the present invention; Figure 3 A flowchart of step S102 provided in an embodiment of the present invention; Figure 4 Another flowchart of step S102 provided in an embodiment of the present invention; Figure 5 A flowchart of step S103 provided in an embodiment of the present invention; Figure 6 A flowchart of step S104 provided in an embodiment of the present invention; Figure 7 Another flowchart of the method for verifying the compliance of optical transmission performance indicators at splice points provided in this embodiment of the invention; Figure 8 A schematic diagram of the structure of the optical transmission performance index connection point compliance verification device provided in an embodiment of the present invention; Figure 9 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of the storage medium provided in an embodiment of the present invention. Detailed Implementation

[0024] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. It should be noted that although functional modules are divided in the system schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system schematic diagram or the order in the flowchart. The step numbers in the following embodiments are only set for ease of explanation and do not limit the order between steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

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

[0026] This invention provides a method for verifying the compliance of optical transmission performance indicators at connection points, addressing technical problems such as efficiency bottlenecks caused by existing manual verification, difficulty in automatically comparing heterogeneous data, and high performance overhead of cross-database queries. Specifically, it includes: 1) Convert unstructured standardized requirements documents into a system-recognizable and executable verification metadata model; 2) Construct an asynchronous hierarchical verification pipeline to reduce the waste of computing power when verifying across heterogeneous data sources; 3) Achieve closed-loop verification of the logical consistency between dynamic performance data and static resource configuration, replacing manual review one by one.

[0027] This invention generates a verification metadata model by parsing standardized requirement documents. Utilizing an asynchronous triggering and hierarchical verification pipeline, it extracts indicator records from a dynamic performance database and performs batch, precise queries on a static configuration database. It completes multi-dimensional logical consistency verification of entity existence, port type compliance, and layer rate matching in memory, and finally outputs verification reports based on the areas of interest. This invention achieves a closed-loop transformation from operation and maintenance rules to automatic verification, significantly reduces cross-database query pressure, accurately identifies hidden logical conflicts, and possesses good scalability.

[0028] The following explains some of the terms used in the embodiments of the present invention.

[0029] Elasticsearch: A distributed search engine, used in this invention to store dynamic performance metrics data reported by the network management system.

[0030] OPT_INPUTP: Current input optical power, optical power performance index of the optical amplifier board or circuit board.

[0031] SM: Section Monitoring.

[0032] SM_BBE: Background block error.

[0033] LR_OPTICAL_SECTION: Optical segment layer rate identifier, corresponding to enumeration value 49.

[0034] layerrate_list: A list of layer rates in the port table of the PG library, storing all layer rate enumeration values ​​(comma-separated) supported by the port.

[0035] The optical transmission performance index connection point compliance verification method provided in this application embodiment can be applied to terminals, servers, or software running on terminals or servers. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network; the software can be an application implementing a driver status monitoring method based on machine vision, but is not limited to the above forms.

[0036] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0037] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0038] like Figure 1 The diagram shows a flowchart of one step in the optical transmission performance index splice point compliance verification method provided by an embodiment of the present invention. (Refer to...) Figure 1 This invention provides a method for verifying the compliance of optical transmission performance indicators at splice points, specifically including the following steps: S101. Perform rule parsing on the standardized requirements document to obtain the verification metadata model object, and establish a hash mapping table between the board type and the corresponding constraint conditions based on the verification metadata model object; S102. When the performance index data of the current batch is entered into the database and parsed, a verification task is triggered. The target board ID list and the target port ID list are filtered according to the batch identifier and the target board type. The corresponding static configuration information is obtained by querying the PostgreSQL configuration database according to the target board ID list and the target port ID list. S103. Based on the hash mapping table and static configuration information, perform entity existence verification, port type compliance verification, and layer rate matching verification on the performance indicator data to obtain the verification results. S104. Generate a multi-dimensional visualization report based on the verification results, including entity existence, optical power index, and segment-level monitoring performance index.

[0039] This invention converts unstructured documents such as "Performance Standardization Test Requirements" into computer-executable verification rule data structures, establishes a hash mapping table between board types and constraints, triggers verification tasks by monitoring the ES index status, performs coarse screening of performance records, and batch queries PG to obtain a list of board models, port types, and layer rates. It performs three-level verification in memory—entity ID existence, port type compliance, and layer rate matching—and only considers a record qualified if all three levels pass. It outputs Excel reports in separate sheets based on dimensions such as entity existence, optical power indicators, and SM performance indicators, and supports scheduled scheduling and result notification.

[0040] It can be recognized that the embodiments of the present invention generate a verification metadata model by parsing standardized requirement documents, extract indicator records from the dynamic performance library using asynchronous triggering and hierarchical verification pipeline, and perform batch precise queries on the static configuration library. Multi-dimensional logical consistency verification of entity existence, port type compliance and layer rate matching is completed in memory. Finally, multi-dimensional visualization reports are output according to the focus areas, realizing the closed-loop transformation from operation and maintenance rules to automatic verification, significantly reducing the cross-database query pressure, and improving the efficiency and reliability of optical transmission performance indicator connection point compliance verification.

[0041] like Figure 2 The diagram shown is a flowchart of step S101 provided in an embodiment of the present invention. (Refer to...) Figure 2 As an optional implementation, the standardized requirements document is parsed to obtain a verification metadata model object. A hash mapping table between the board type and corresponding constraints is then established based on the verification metadata model object. Specifically, this includes: S1011. Convert the standardized requirements document into a verification metadata model object through the parsing adapter. The verification metadata model object includes the preset board type, preset performance indicator name, expected port object type and expected layer rate identifier. S1012. Establish a hash mapping table with the preset board type as the key and the preset performance indicator name, expected port object type and expected layer rate identifier as the constraint conditions value.

[0042] Specifically, the adapter reads the "Performance Standardization Test Requirements" configuration file, extracts the constraints, and generates a verification rule object containing the following fields: target board type (e.g., optical amplifier board, circuit board), target performance indicator name (e.g., OPT_INPUTP, SM_BBE), expected port object type, and required layer rate identifier (e.g., requiring PTP port and layer rate including LR_OPTICAL_SECTION). The parsed verification rules are then constructed into a memory-level hash mapping table, using the board type as the key to associate the corresponding indicator with the list of connection point constraints.

[0043] In existing technologies, standardized documents such as "Performance Standardization Test Requirements" exist in natural language and tabular form. Computer systems cannot directly read and execute the hook point constraint rules in them, resulting in a natural "execution gap" between the document specifications and the actual system operation data.

[0044] This invention proposes a structured parsing method for standardized requirement documents. A parsing adapter converts standardized requirement documents in Excel or JSON format into a system-recognizable verification metadata model object. This metadata model includes at least: a list of target board types, a list of target performance indicator names, expected port object types, and a set of required layer rate identifiers. After parsing, all rules are constructed into a memory-level hash mapping table with board type as the key and corresponding constraint conditions as the value, allowing the subsequent verification engine to quickly find the correct match.

[0045] like Figure 3 The diagram shown is a flowchart of step S102 provided in an embodiment of the present invention. (Refer to...) Figure 3 As an optional implementation, upon completion of the data entry and parsing of the current batch of performance metrics, a verification task is triggered. This involves filtering the target board ID list and the target port ID list based on the batch identifier and target board type. Specifically, this includes: S1021. Once the current batch of performance indicator data has been successfully entered into the database and parsed, change the index status flag to "parsed". S1022. When the index status is detected as resolved, an asynchronous verification task is triggered to determine the corresponding batch identifier and target board type. S1023. Use the batch identifier and target board type as filtering conditions to perform an inverted index in the ES engine to obtain a list of target board IDs and a list of target port IDs.

[0046] Specifically, after the Elasticsearch (ES) database ingestion service completes the full parsing of a batch of performance data, it changes the index status to "parsed". The verification service listens for this status change and asynchronously triggers a verification task. The verification task first uses ES's inverted index to perform a first-round coarse screening using only the batch identifier (traceId) and the target board type as filtering conditions, extracting fields such as board_id (board ID), port_id (port ID), and parameterName (parameter name).

[0047] like Figure 4 The diagram shown is another flowchart of step S102 provided in an embodiment of the present invention. (Refer to...) Figure 4 As an optional implementation, the corresponding static configuration information is retrieved from the PostgreSQL configuration database based on the target board ID list and the target port ID list, specifically including: S1024. Initiate a batch query in the board model table of the PostgreSQL configuration database with the target board ID list as input to obtain board model information; S1025. Initiate a batch query in the port model table of the PostgreSQL configuration database with the target port ID list as input to obtain port service type information and layer rate list information; S1026. Static configuration information is obtained by summarizing the board model information, port service type information, and layer rate list information.

[0048] Specifically, the obtained list of `board_id`s is used as input to initiate a single batch query to the board model table in the PG library to obtain the board model; and the list of `port_id`s is used to initiate a single batch query to the port model table to obtain the port's service type (`tp_type`) and the list of supported layer rates (`layerrate_list`). The layer rate list is stored as a numeric enumeration value, which the system converts into readable rate names or directly uses a set of numbers for matching through a pre-defined enumeration mapping table (which can be derived from a CSV file).

[0049] It is recognized that using full cross-database join queries (ES Join PG) for consistency verification can lead to severe database connection storms when massive amounts of high-performance data are imported into the database, impacting the real-time business response performance of the network management and monitoring system. Current technologies lack low-intrusion, high-efficiency verification mechanisms specifically for this scenario.

[0050] This invention designs a three-stage funnel-style verification pipeline: "ES-side pre-screening → PG-side batch precise query → in-memory rule matching". The first stage utilizes Elasticsearch's high-performance inverted index to perform coarse screening locally, extracting only performance records of the relevant board types and metrics. The second stage sends the unique ID list output from the first stage to the PG database through parameterized batch queries, retrieving all necessary static configuration information at once. The third stage completes rule matching and compliance determination in memory, eliminating the need for further database access.

[0051] like Figure 5 The diagram shown is a flowchart of step S103 provided in an embodiment of the present invention. (Refer to...) Figure 5 As an optional implementation, the performance indicator data is further validated based on the hash mapping table and static configuration information to verify entity existence, port type compliance, and layer rate matching, yielding the validation results, specifically including: S1031. Construct a verification engine based on the hash mapping table; S1032. Determine the entity IDs of multiple entity objects in the performance indicator data based on the verification engine, and determine whether the entity IDs exist in the static configuration information; S1033. Determine the expected port object type corresponding to the performance indicator data based on the verification engine, and determine whether the expected port object type is consistent with the port service type information contained in the static configuration information. S1034. Determine the layer rate field carried by the performance indicator data based on the verification engine, and determine whether the layer rate field is consistent with the layer rate list information contained in the static configuration information. S1035. When the entity ID exists in the static configuration information, the expected port object type is consistent with the port service type information contained in the static configuration information, and the layer rate field is consistent with the layer rate list information contained in the static configuration information, the verification is confirmed to be successful.

[0052] Specifically, a verification engine is built in memory based on the hash map table to perform the following step-by-step verification on each performance record: 1) Entity Existence Verification: Check whether the neId, shelfId, boardId, and portId in the record exist in the corresponding network element, subrack, board, and port tables of the static configuration information in the PG configuration library. Any missing one will be marked as abnormal. 2) Port type compliance verification: Execute different branches according to the indicator category. If it is an optical power indicator (such as OPT_INPUTP, OPT_OUTPOW, etc.), determine whether the port tp_type is equal to the PTP identifier value; if it is an SM performance indicator (such as SM_BBE, SM_UAS, etc.), determine whether the port tp_type belongs to the allowed OTU port type set (PTP / FTP / CTP). 3) Layer rate matching verification: The layer field value (layer rate value or name) carried in the ES performance record is compared with the set of layer rates supported by the port in PG. The comparison method is to parse the layerrate_list of PG into a set of numbers or a set of names, and then determine whether the layer value of ES belongs to the set. If either the port type or the layer rate does not meet the rule requirements, an exception record containing the exception type, expected value and actual value is generated.

[0053] Manual verification can often only detect format errors or missing metrics at the file parsing level, and it is difficult to find deeper logical conflicts that are “seemingly normal but actually abnormal” – for example, performance metric data has been successfully reported to ES, but the layer rate configuration or port type of the port does not meet the standard specifications for carrying the metric.

[0054] This invention establishes a cross-storage engine logical verification mechanism that performs verification on each performance record in at least three dimensions: The first dimension verifies whether the entity ID (network element, subrack, board, port) in the performance record exists in the static configuration library; the second dimension determines whether the service type of the port meets the specification requirements based on the indicator category (e.g., optical power indicator requires PTP port, SM indicator requires OTU port); the third dimension precisely matches the layer rate value carried in the performance record with the actual set of layer rates supported by the port (by parsing the enumeration value list in PG into a set of numbers or a set of names, and then determining whether the layer value reported by ES belongs to that set).

[0055] like Figure 6 The diagram shown is a flowchart of step S104 provided in an embodiment of the present invention. (Refer to...) Figure 6 As an optional implementation, a multi-dimensional visualization report is generated based on the verification results, according to entity existence, optical power index, and segment-level monitoring performance index, specifically including: S1041. Create a first display area, a second display area, and a third display area in the visualization file; S1042. Based on the verification results, output the existence records and associated records of each entity ID in the PostgreSQL configuration database to the first display area; S1043. Based on the verification results, output the verification process details of the segment-level monitoring performance indicators to the second display area; S1044. Output the detailed verification process of the optical power index to the third display area based on the verification results. S1045. Generate a multi-dimensional visualization report based on the visualization file.

[0056] Specifically, a visualization report is generated based on the verification results and output to at least three independent display areas (such as different sheets in an Excel spreadsheet) according to the focus: the first area displays the existence of each entity ID in the PG and the number of associated records; the second area only displays the verification conclusions of the SM performance indicators; and the third area only displays the verification conclusions of the optical power indicators. The report may further include information such as the reasons for failure and the expected layer rate configuration.

[0057] Existing anomaly reports typically mix all verification results in one table, making it difficult for maintenance personnel with different responsibilities to quickly focus on their respective concerns. In addition, the large number of "N / A" markings causes visual clutter and reduces troubleshooting efficiency.

[0058] This invention proposes a method for generating verification reports by region based on business focus. Based on the verification results of the same batch, at least three independent display areas (such as multiple Excel sheets or multiple CSV files) are automatically generated: the first area displays the existence of each entity ID in the configuration database and the number of associated performance records, for resource configuration administrators; the second area only displays the verification details and conclusions of SM-type performance indicators, for SDH / OTN operations and maintenance personnel; the third area only displays the verification details and conclusions of optical power-type performance indicators, for optical layer operations and maintenance personnel. Each area retains only relevant columns, eliminating redundant information.

[0059] To save storage, layer rates are often stored as numeric enumeration values ​​in network device configuration libraries (e.g., 49 represents LR_OPTICAL_SECTION), while performance reporting data may be carried in name or numeric form. If the enumeration mapping relationship is hardcoded in the code, the verification logic will fail when a new rate is introduced during a network upgrade.

[0060] This invention uses an external mapping file (CSV or configuration file) to store the mapping relationship between enumeration values ​​and readable names, which is dynamically loaded into the memory dictionary when the system starts. When names need to be displayed, numbers are quickly converted into names; when numerical comparison is required, the original data is parsed into a set of integers and directly used for mathematical comparison. The update of the mapping file is decoupled from the main program logic; adding a new enumeration value only requires appending a line to the CSV file without modifying the code.

[0061] In some optional embodiments, a simplified exception list can also be generated by classifying exception records by port, metric, and exception type, which will not be elaborated here.

[0062] like Figure 7 The diagram shows another step flowchart of the optical transmission performance index connection point compliance verification method provided by an embodiment of the present invention. Further, as an optional implementation, the optical transmission performance index connection point compliance verification method also includes the following steps: S201. Output structured logs of the verification execution process and redirect them to the scheduling platform, and feed back the execution results to the scheduling platform through standard exit codes; S202. The scheduling platform triggers the archiving of verification result files and notification of verification results based on the standard exit code.

[0063] Specifically, manually executing the verification script requires operations and maintenance personnel to remember the execution time and manually check the results, making it difficult to achieve routine monitoring; and occasional network fluctuations or service anomalies may cause the script to be interrupted without anyone knowing.

[0064] This invention integrates the verification script with Jenkins or other continuous integration scheduling platforms to achieve fully automated periodic execution through the following measures: script parameters are injected through environment variables to avoid hard coding; all execution processes output structured logs and are redirected to the scheduling platform console; the script provides feedback on the execution results to the scheduling platform using standard exit codes (0 / 1); the verification result file is automatically archived as a build artifact; and the scheduling platform triggers email or instant messaging notifications based on the exit codes.

[0065] The technical solution of the present invention will be further explained below in conjunction with specific application scenarios.

[0066] This embodiment implements the core logic of the optical transmission performance indicator connection point compliance verification method on a Linux server using Python, and integrates it with Jenkins to achieve timed triggering. The specific steps are as follows: Step 1: Rule Parsing When the script starts, it loads the standardized rules configuration file rules_schema.json, whose content structure is as follows (example): json { "rules": [ { "rule_id": "RULE_OPT", "target_board_models": ["OA","Optical Amplifier Board"], "target_kpi_names": ["OPT_INPUTP","OPT_OUTPOW",…], "expected_location": { "port_object_type": "PTP", "required_layer_rate": 49 } }, { "rule_id": "RULE_SM", "target_board_models": ["PCB","H2PCx10"], "target_kpi_names": ["SM_BBE","SM_BBER","SM_SES","SM_UAS"], "expected_location": { "port_object_type": "OTU", "allowed_port_types": [1,2,3,4], "required_layer_rates": [107,108,109,316,317,318,326,343,345,354,356,340] } } ] } At the same time, the layer rate enumeration mapping table layerrate_enum_map.csv is loaded to form a two-way mapping relationship from numbers to names.

[0067] Step 2: ES data retrieval and PG existence check The verification service initiates a single query to Elasticsearch based on the preset board ID (boardId), retrieving fields including neId, shelfId, boardId, portId, parameterName, and layer to obtain all relevant performance records. It extracts all unique neId, shelfId, boardId, and portId, and verifies their existence in the network element table, subrack table, board table, and port table in the Group Grid (PG) using parameterized queries (= ANY(%s)), returning a set of records containing each ID.

[0068] Step 3: Obtain Port Details Using all portIds as input, batch query the layerrate_list and tp_type fields from the port table to construct the memory mapping.

[0069] Step 4: Perform multi-level verification for each item For each performance record, first determine whether parameterName belongs to the set of metrics of interest (OPT_KPIS ∪ SM_KPIS). If so, proceed to the validation pipeline: L1: Check if neId, shelfId, boardId, and portId exist in PG. If any one is missing, record the exception and skip the subsequent checks.

[0070] L2: Retrieve the PG information corresponding to this port, and parse layerrate_list into a set of integers (e.g., "40,50,108" → {40,50,108}). Convert the layer field value in Elasticsearch to an integer (e.g., 108).

[0071] L3: Execute a branch based on the indicator type: If it is an optical power indicator: check if tp_type is equal to 1 (PTP) and if the layer value contains 49 (LR_OPTICAL_SECTION). If both conditions are met, it passes; otherwise, it is marked as abnormal.

[0072] If it is an SM indicator: check if tp_type belongs to {1,2,3,4} and if the layer value belongs to the preset OTU rate set. If both conditions are met, pass; otherwise, mark as an exception.

[0073] Step 5: Report Generation Based on the above verification results, use openpyxl to generate a multi-sheet Excel file: Sheet1 "Entity Existence Check": Lists the existence status and associated record count for each entity ID.

[0074] Sheet2 "SM Performance Verification Results": Only outputs the fields of the SM metrics, the verification conclusion (pass / fail), and the reason for failure.

[0075] Sheet3 "Optical Power Performance Verification Results": The structure is the same as above.

[0076] Jenkins scheduled tasks (e.g., 2 AM daily) automatically trigger script execution, archive the results files, and support email notifications.

[0077] Through the above implementation methods, the present invention successfully achieves fully automated verification of the compliance of optical network performance indicators at connection points, significantly reducing operation and maintenance costs and improving the data quality assurance level of optical transmission networks.

[0078] The method flow of the present invention has been described above. It is understood that the embodiments of the present invention generate a verification metadata model by parsing standardized requirement documents, extract indicator records from a dynamic performance database using asynchronous triggering and a hierarchical verification pipeline, and perform batch precise queries on a static configuration database. Multi-dimensional logical consistency verification of entity existence, port type compliance, and layer rate matching is completed in memory. Finally, multi-dimensional visual reports are output according to the focus areas, achieving a closed-loop transformation from operation and maintenance rules to automatic verification. This significantly reduces cross-database query pressure and improves the efficiency and reliability of optical transmission performance indicator connection point compliance verification.

[0079] like Figure 8 The diagram shown is a structural schematic of the optical transmission performance index connection point compliance verification device provided in an embodiment of the present invention. (Refer to...) Figure 8 This invention provides a device for verifying the compliance of optical transmission performance indicators at splice points, comprising: The standardization rule parsing module is used to parse the standardization requirement document into a verification metadata model object, and to establish a hash mapping table between the board type and the corresponding constraint conditions based on the verification metadata model object. The configuration information query module is used to complete the parsing of the performance index data of the current batch, trigger the verification task, filter the target board ID list and target port ID list according to the batch identifier and target board type, and query the corresponding static configuration information in the PostgreSQL configuration database according to the target board ID list and target port ID list. The hierarchical verification module is used to perform entity existence verification, port type compliance verification, and layer rate matching verification on performance indicator data based on the hash mapping table and static configuration information, and obtain the verification results. The multi-dimensional report generation module is used to generate multi-dimensional visual reports based on the verification results, including entity existence, optical power index, and segment-level monitoring performance index.

[0080] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0081] This invention also provides an electronic device, comprising: a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for communication between the processor and the memory. When the program is executed by the processor, it implements the aforementioned method for verifying the compliance of optical transmission performance indicators at connection points. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0082] like Figure 9The diagram shown is a hardware structure schematic of an electronic device provided in an embodiment of the present invention. (Refer to...) Figure 9 This invention provides an electronic device, comprising: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention. The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 to execute the optical transmission performance index connection point compliance verification method of the embodiments of this invention. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0083] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0084] like Figure 10 The diagram shown is a structural schematic of the storage medium provided in an embodiment of the present invention. (Refer to...) Figure 10The present invention also provides a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more programs 1001, which can be executed by one or more processors to implement the above-mentioned optical transmission performance index connection point compliance verification method.

[0085] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0086] This invention also discloses a computer program product, including a computer program that, when executed by a processor, implements the above-described method for verifying the compliance of optical transmission performance indicators at connection points.

[0087] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0088] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0089] The embodiments described in this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems.

[0090] The terms "first," "second," "third," "fourth," etc. (if present) in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0091] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the aforementioned blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0092] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the aforementioned functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0093] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0094] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0095] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the aforementioned program can be printed, because the aforementioned program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0096] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0097] In the foregoing description of this specification, references to terms such as "one embodiment," "another embodiment," or "some embodiments" indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0098] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0099] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for verifying the compliance of optical transmission performance indicators at splice points, characterized in that, Includes the following steps: The standardized requirements document is parsed to obtain a verification metadata model object, and a hash mapping table between the board type and the corresponding constraint is established based on the verification metadata model object; Once the performance metrics data for the current batch is successfully entered into the database and parsed, a verification task is triggered. The target board ID list and target port ID list are filtered according to the batch identifier and target board type. The corresponding static configuration information is then retrieved from the PostgreSQL configuration database based on the target board ID list and the target port ID list. The performance indicator data is verified for entity existence, port type compliance, and layer rate matching based on the hash mapping table and the static configuration information to obtain the verification results. Based on the verification results, a multi-dimensional visualization report is generated according to entity existence, optical power index, and segment-level monitoring performance index.

2. The method for verifying the compliance of optical transmission performance indicators at connection points according to claim 1, characterized in that, The process of parsing the standardized requirements document to obtain a verification metadata model object, and establishing a hash mapping table between the board type and the corresponding constraints based on the verification metadata model object, specifically includes: The standardized requirements document is converted into the verification metadata model object by the parsing adapter. The verification metadata model object includes a preset board type, a preset performance indicator name, an expected port object type, and an expected layer rate identifier. The hash mapping table is established using the preset board type as the key and the preset performance indicator name, the expected port object type, and the expected layer rate identifier as the constraint value.

3. The method for verifying the compliance of optical transmission performance indicators at connection points according to claim 1, characterized in that, When the current batch of performance indicator data is successfully imported and parsed, a verification task is triggered. This involves filtering the target board ID list and the target port ID list based on the batch identifier and target board type. Specifically, this includes: Once the current batch of performance metrics data has been successfully imported and parsed, the index status will be changed to "parsed". When the index status is detected as resolved, an asynchronous verification task is triggered to determine the corresponding batch identifier and the target board type; The batch identifier and the target board type are used as filtering conditions to perform an inverted index in the ES engine to obtain the target board ID list and the target port ID list.

4. The method for verifying the compliance of optical transmission performance indicators at connection points according to claim 1, characterized in that, The step of retrieving the corresponding static configuration information from the PostgreSQL configuration database based on the target board ID list and the target port ID list specifically includes: The target board ID list is used as input to initiate a batch query in the board model table of the PostgreSQL configuration database to obtain the board model information; A batch query is initiated on the port model table in the PostgreSQL configuration database using the target port ID list as input to obtain port service type information and layer rate list information; The static configuration information is obtained by summarizing the board model information, the port service type information, and the layer rate list information.

5. The method for verifying the compliance of optical transmission performance indicators at connection points according to claim 1, characterized in that, The step of performing entity existence verification, port type compliance verification, and layer rate matching verification on the performance indicator data based on the hash mapping table and the static configuration information to obtain the verification results specifically includes: A verification engine is constructed based on the hash mapping table; Based on the verification engine, the entity IDs of multiple entity objects in the performance metric data are determined, and it is determined whether the entity IDs exist in the static configuration information; Based on the verification engine, the expected port object type corresponding to the performance indicator data is determined, and it is determined whether the expected port object type is consistent with the port service type information contained in the static configuration information. Based on the verification engine, the layer rate field carried by the performance indicator data is determined, and it is determined whether the layer rate field is consistent with the layer rate list information contained in the static configuration information. If the entity ID exists in the static configuration information, the expected port object type is consistent with the port service type information contained in the static configuration information, and the layer rate field is consistent with the layer rate list information contained in the static configuration information, then the verification is confirmed to be successful.

6. The method for verifying the compliance of optical transmission performance indicators at connection points according to claim 1, characterized in that, The process of generating a multi-dimensional visualization report based on the verification results, according to entity existence, optical power index, and segment-level monitoring performance index, specifically includes: Create a first display area, a second display area, and a third display area in the visualization file; Based on the verification results, the existence records and associated records of each entity ID in the PostgreSQL configuration database are output to the first display area; Based on the verification results, the verification process details of the segment-level monitoring performance indicators will be output to the second display area; Based on the verification results, the verification process details of the optical power index will be output to the third display area; The multi-dimensional visualization report is generated based on the visualization file.

7. A method for verifying the compliance of optical transmission performance indicators at splice points according to any one of claims 1 to 6, characterized in that, The method for verifying the compliance of optical transmission performance indicators at connection points also includes the following steps: The verification execution process outputs a structured log and redirects it to the scheduling platform, and the execution result is fed back to the scheduling platform through a standard exit code; The scheduling platform triggers the archiving of verification result files and notification of verification results based on the standard exit code.

8. A device for verifying the compliance of optical transmission performance indicators at connection points, characterized in that, include: The standardization rule parsing module is used to parse the standardization requirement document into a verification metadata model object, and to establish a hash mapping table between the board type and the corresponding constraint conditions based on the verification metadata model object. The configuration information query module is used to complete the storage and parsing of the performance index data of the current batch, trigger the verification task, filter the target board ID list and target port ID list according to the batch identifier and target board type, and query the corresponding static configuration information in the PostgreSQL configuration database according to the target board ID list and the target port ID list. The hierarchical verification module is used to perform entity existence verification, port type compliance verification, and layer rate matching verification on the performance indicator data according to the hash mapping table and the static configuration information, and obtain the verification results. The multi-dimensional report generation module is used to generate a multi-dimensional visualization report based on the verification results, according to entity existence, optical power index, and segment-level monitoring performance index.

9. An electronic device, characterized in that, The electronic device includes a memory, a processor, a computer program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory. When the computer program is executed by the processor, it implements the optical transmission performance index connection point compliance verification method as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the optical transmission performance index connection point compliance verification method as described in any one of claims 1 to 7.

Images