Data acquisition reliability test method for radio and television optical transmission network facing northbound interface

Abstract

The invention discloses a data acquisition reliability test method for a radio and television optical transmission network oriented to a northbound interface. The method comprises long link detection based on a heartbeat packet and data transmission pressure test. According to the heartbeat packet-based long link detection, a heartbeat script is deployed at the joint of a data acquisition end and a northbound interface and is used for judging whether a data acquisition service is correctly and stably operated or not, and meanwhile, the throughput of the northbound interface is monitored; the data transmission pressure test is to perform a pressure test on a northbound interface, simulate a network management system to concurrently send a plurality of alarms, and observe the capability of a data acquisition end to correctly receive the alarms. According to the invention, the docking reliability of the data acquisition end and the northbound interface can be tested, and the method has the advantages of accurate test result and convenient operation.

Description

Technical Field

[0001] The present invention relates to the field of radio and television technology, and in particular to a method for testing the reliability of radio and television optical transmission network data collection facing a northbound interface. Background Art

[0002] Data collection is the only way to improve the management efficiency of different business systems of the provincial backbone network. It is the first step to realize the comprehensive supervision and operation and maintenance system. It can flexibly and efficiently support the development of automated operation and maintenance and digital maintenance. At present, the northbound interface of the provincial backbone network transmission equipment management system is an important channel for third-party data collection. Therefore, the reliable connection between the northbound interface and the data collection end has become an important feature that the system operation and maintenance subject pays attention to in the process of building comprehensive supervision and operation and maintenance software. The existing northbound interface test method mainly focuses on automated functional testing, and does not cover the reliability test of long link stability and burst data transmission under the scenario of correct connection between the collection end and the northbound interface. In addition, in the traditional test process, the network management system cannot generate alarms by itself. The monitoring module will trigger alarms based on preset thresholds and conditions. Alarms will only be generated when the data collected by the network management exceeds the threshold range or the device loses connection. Therefore, how to generate a large number of alarms at the same time is a problem that needs to be solved in this test. Furthermore, traditional network equipment sends alarm information to the network management system through SNMP, which is the most commonly used alarm transmission protocol. Different alarms have different data packets, and the content information in the data packets is also different. To simulate the occurrence of an alarm, you need to obtain the response data packet, analyze its content, and use it. So first of all, we need to solve how to obtain the data packet related to the alarm from a large number of forwarded data packets, and then solve how to use it to simulate the occurrence of an alarm by analyzing the content of the data packet. Summary of the invention

[0003] The purpose of the present invention is to provide a method for testing the reliability of data acquisition in a broadcasting and television optical transmission network facing a northbound interface. The present invention can test the reliability of the connection between a data acquisition terminal and a northbound interface, and has the advantages of accurate test results and easy operation.

[0004] The technical solution of the present invention: a method for testing the reliability of data acquisition in a broadcasting and television optical transmission network facing a northbound interface, including long link detection based on a heartbeat packet and a data transmission stress test;

[0005] The long link detection based on heartbeat packets is to deploy a heartbeat script at the connection point between the data acquisition end and the northbound interface to determine whether the data acquisition service is running correctly and stably, and also monitor the throughput of the northbound interface;

[0006] The data transmission stress test is to perform a stress test on the northbound interface, simulating the network management system to send multiple alarms simultaneously, and observing the ability of the data acquisition end to correctly receive alarms.

[0007] The above-mentioned northbound interface-oriented radio and television optical transmission network data acquisition reliability test method, the long link detection based on heartbeat packets includes the server actively sending heartbeat packets, and the process is as follows: the server establishes a timer and sends heartbeat packets to the client at a regular interval. After the client receives the heartbeat packet, it immediately sends the heartbeat packet to the server. After receiving the heartbeat packet sent by the client, the server confirms that the client's connection is available and does not perform operations related to releasing the socket; if the server does not receive a heartbeat packet in response to the client within the specified time interval, the server considers that the client's connection is unavailable and performs operations related to releasing the socket.

[0008] The aforementioned northbound interface-oriented radio and television optical transmission network data acquisition reliability test method, the heartbeat packet-based long link detection includes the client actively sending a heartbeat packet, and the process is as follows: the client sends a heartbeat packet to the server, and the server marks the relevant socket after receiving the heartbeat packet, and then the server sends a response heartbeat packet to the client, and the client considers that the connection is available when it receives the heartbeat packet; if the server does not receive the heartbeat packet for more than a period of time, the identifier of the relevant socket will be downgraded until it expires, and then the server releases the socket-related resources.

[0009] The aforementioned northbound interface-oriented radio and television optical transmission network data acquisition reliability test method, the heartbeat script is written as follows: first import the necessary modules of the heartbeat packet, then set the heartbeat time interval, then define the heartbeat signal sending function, heartbeat signal processing function and throughput calculation function, and finally start the heartbeat cycle.

[0010] The aforementioned method for testing the reliability of data acquisition in the radio and television optical transmission network facing the northbound interface, the deployment process of the heartbeat script is: first, determine that the CORBA middleware has been installed at the connection point between the data acquisition end and the northbound interface, and then use the interface definition language IDL to describe the CORBA service and implement the service logic; then deploy the implemented service to the CORBA server, and test it after the deployment is completed.

[0011] The aforementioned method for testing the reliability of data collection in the broadcasting and television optical transmission network facing the northbound interface, the process of the data transmission stress test is as follows: first prepare the stress test tool and make prerequisite preparations, then create a test plan and configure HTTP requests, then add parameterization and listeners in turn, and finally perform performance testing.

[0012] The aforementioned northbound interface-oriented radio and television optical transmission network data acquisition reliability test method, the stress testing tool is Apache JMeter; the prerequisite preparation includes configuring the test environment and obtaining data packets; the configuration of the test environment is used to ensure that the test environment is similar to the actual environment, and the data packets are obtained by filtering and screening using packet capture software to obtain network management alarm data packets, and then the data packet content is analyzed to obtain the alarm format for simulating alarm concurrency.

[0013] The aforementioned method for testing the reliability of data acquisition in a broadcasting and television optical transmission network facing the northbound interface, wherein creating a test plan includes adding a thread group, setting the number of threads, setting a ramp-up period, and setting the number of cycles.

[0014] The aforementioned method for testing the reliability of radio and television optical transmission network data collection facing the northbound interface, wherein the configuration of the HTTP request is to add an HTTP request sampler, add an HTTP request under the thread group, and then configure the URL and request method of the northbound interface.

[0015] The aforementioned method for testing the reliability of data collection in a radio and television optical transmission network facing the northbound interface, wherein the added parameterization is to use a CSV data set configuration plug-in to read a variety of alarm data, so as to simulate the diversity in a real scenario;

[0016] The listener includes an aggregate report and a graphic result listener; the aggregate report listener is used to find out the test results and performance indicators; the graphic result listener is used to view the performance changes of concurrent requests.

[0017] Compared with the prior art, the present invention provides a long link detection method based on heartbeat packets and a data transmission stress test method for alarm concurrency scenarios. The present invention deploys a heartbeat script at the docking point between the data acquisition terminal and the northbound interface, which can be used to determine whether the data acquisition service is running correctly and stably, and also monitors the throughput of the northbound interface; the data transmission stress test of the present invention can generate a large number of alarms and can simulate the network management system; at the same time, the present invention can also obtain alarm-related data packets from a large number of forwarded data packets, and can analyze the content of the data packets and use them in the simulated alarm occurrence, so as to test whether the data acquisition terminal can operate normally and the operating conditions, so as to evaluate its performance and responsiveness. Therefore, the present invention can test the reliability of the docking between the data acquisition terminal and the northbound interface, and has the advantages of accurate test results and easy operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a schematic flow diagram of the method of the present invention;

[0019] Figure 2 This is a flow chart of the server actively sending heartbeat packets;

[0020] Figure 3 This is a flow chart of the client actively sending heartbeat packets;

[0021] Figure 4 This is a diagram for writing a heartbeat script;

[0022] Figure 5 This is a diagram of the deployment process of the heartbeat script. DETAILED DESCRIPTION

[0023] The present invention is further described below in conjunction with the accompanying drawings and embodiments, but they are not intended to limit the present invention.

[0024] Embodiment: A method for testing the reliability of data collection in a radio and television optical transmission network facing a northbound interface, such as Figure 1 As shown, it includes long link detection based on heartbeat packets and data transmission stress testing;

[0025] The long link detection based on heartbeat packets is to deploy a heartbeat script at the connection point between the data acquisition end and the northbound interface to determine whether the data acquisition service is running correctly and stably, and also monitor the throughput of the northbound interface;

[0026] The principle of the heartbeat script is to maintain the validity of the connection and detect the network status by sending requests to the server at regular intervals. This mechanism is very important in network programming, especially in application scenarios that require a continuous connection between the client and the server, such as instant messaging, online testing, etc. Its basic principles are as follows:

[0027] 1. Send heartbeat packets regularly: A heartbeat packet is a data packet in a predefined format, usually containing simple information such as a timestamp or a specific identifier. It is designed to help the system control the allocation and use of resources, ensuring that active connections are maintained only when necessary, while also allowing management to understand the system's operating status, thereby improving the overall performance of the system.

[0028] 2. Confirmation of connection status: The client sends a heartbeat packet to the server at regular intervals, and the server can confirm the client's connection status after receiving it. If the heartbeat packet is not received within the scheduled time, the server can determine that the connection may have been disconnected.

[0029] There are two ways to confirm the connection status:

[0030] 2.1. The server actively sends heartbeat packets: For the server actively sending heartbeat packets, the server sets up a timer and sends heartbeat packets to the client at regular intervals. After the client receives the heartbeat packet, it immediately sends the heartbeat packet to the server. After receiving the heartbeat packet sent by the client, the server confirms that the client's connection is available and does not perform operations related to releasing the socket. If the server does not receive a heartbeat packet in response from the client within the specified time interval, the server considers that the client's connection is unavailable and performs operations related to releasing the socket. Figure 2 The advantages of this approach are real-time, centralized management, and state retention. That is, the server can detect the client's connection status more timely and quickly find the disconnected client; the server can uniformly manage the heartbeat logic, simplify the client's implementation, and reduce the client's burden; the server can dynamically adjust resource allocation and connection status based on heartbeat feedback to improve the overall performance of the system.

[0031] 2.2. The client actively sends a heartbeat packet: For the client to actively send a heartbeat packet at a fixed time, the client sends a request to the server. After receiving the heartbeat packet, the server identifies the relevant socket, and then sends a response heartbeat packet to the client. The client receives the heartbeat packet and believes that the connection is available. If the server does not receive the heartbeat packet for a period of time, the identifier of the relevant socket will be downgraded until it expires, and then the server will release the socket-related resources. See the principle flow chart Figure 3 The advantages of this approach are initiative, flexibility, and high resource utilization. That is, the client can actively control the frequency and timing of sending heartbeats to adapt to network conditions and business needs; the client can decide when to send heartbeats based on its own business logic, and can better handle network fluctuations and reconnection strategies; when the client does not need to communicate with the server temporarily, it can reduce unnecessary requests, thereby saving resources.

[0032] This embodiment uses the client actively sending a heartbeat packet to implement the heartbeat mechanism. The heartbeat script writing process is as follows: Figure 4 shown.

[0033] First, we need to import the necessary modules. In this example, the necessary modules include the time module, the socket module, the threading module, and the requests module; the time module is used to obtain the current time and perform time delay operations; the socket module is used to create a socket to communicate with the server; the threading module is used to create threads for heartbeat sending and processing; the request module can be used to send protocol requests.

[0034] Secondly, set the heartbeat time interval, which refers to the time interval for sending heartbeat signals, and can be set according to actual needs. In this embodiment, it is set to 10s.

[0035] Third, define the function of sending heartbeat signal, this function will be called in each heartbeat time interval, and is used to send heartbeat signal to server. In the present embodiment, a function named send_heartbeat is defined, which is used to send heartbeat signal to server regularly, and its function is to ensure that the connection with server remains active and monitor the connection status. First, create a socket, and then connect to the server. After the connection is successful, send a heartbeat signal heartbeat as a heartbeat signal to tell the server that the client is still active, waiting for and receiving the data returned by the server. Errors may occur during connection and communication. In order to deal with errors that may occur during connection or communication, use try-except-finally structure to ensure that the socket can be safely closed even when an error occurs. Regardless of whether the code in the try block throws an exception, the code in the finally block will be executed to close the socket and release system resources. Finally, wait for the heartbeat time interval, and then send the next heartbeat. Each time a heartbeat request is sent, it will be counted, and finally the number of heartbeat request packets sent within a period of time can be obtained.

[0036] Fourth, define a function for processing heartbeat signals. This function will be called when a heartbeat signal is received. In this embodiment, a function called handle_response is defined. In this function, it is determined whether the received data is a heartbeat signal. If it is a heartbeat signal, the received heartbeat signal is printed; otherwise, an invalid heartbeat response is printed.

[0037] Fifth, define the throughput calculation function. Throughput refers to the number of requests successfully processed per unit time. The calculation formula for throughput is: number of successful requests / total number of requests multiplied by the average time of each request (assuming 5 seconds). The throughput can be calculated by recording the number of requests completed within a certain period of time. This embodiment defines a function called throughput_check, which measures the throughput of the target interface by sending multiple requests and outputs the number of successful requests per second, where the variable successful_requests is used to count the number of successful requests. In the try block, use the requests.get() method to send a GET request and set the timeout to 5 seconds. If the request is successful, the returned response object will be stored in response. Check the status code of the response. Only when the status code is 200 (indicating a successful request), the successful_requests variable (successful request count) will increase by 1. If any exception occurs during the request process (such as timeout, connection error, etc.), catch RequestException, and use continue to skip the current loop and continue to send the next request.

[0038] Finally, start the heartbeat loop, which will continuously send heartbeat signals to the server in the background.

[0039] Based on the heartbeat script written above, when deploying the script using the northbound interface of the CORBA protocol, the following steps are mainly required:

[0040] First, make sure that CORBA middleware, such as ORB (Object Request Broker), has been installed at the connection point between the data collection end and the northbound interface. Commonly used ORBs include JacORB, OpenORB, etc. These middleware will be responsible for handling communication between objects. Then use the interface definition language (IDL) to describe the CORBA service. IDL allows you to define the interface of the service, including the name of the method, parameter type, and return value type, and generate Python's ORBA binding code: After compiling the IDL file, the corresponding client and server code will be generated. Implement the service logic according to the code generated by IDL. Deploy the implemented service to the CORBA server, such as Figure 5 According to the CORBA middleware used, you need to configure the relevant service registration and name resolution functions so that the client can find and call the service.

[0041] After deployment, conduct sufficient testing to verify whether the northbound interface can correctly receive requests and return expected results. If it meets the requirements, monitor the performance and availability of the interface regularly and perform necessary optimization and maintenance based on actual usage.

[0042] From the data we can see that the software ran normally within 48 hours and no alarms were generated.

[0043] In this embodiment, the data transmission stress test is to perform stress testing on the northbound interface, simulate the network management system to send multiple alarms at the same time, and observe the ability of the data acquisition end to correctly receive alarms. The main process is as follows: first prepare the stress test tool and make prerequisite preparations, then create a test plan and configure HTTP requests, then add parameterization and listeners in turn, and finally perform performance testing.

[0044] The stress test tool in this embodiment is Apache JMeter, which is an open source load testing tool widely used in performance testing, stress testing and load testing. By simulating the northbound interface network management to generate a large number of alarms at the same time, observe whether the data acquisition end can operate normally and how it operates, so as to evaluate its performance and responsiveness.

[0045] The prerequisite preparation of this embodiment includes configuring the test environment and obtaining data packets; the configuration of the test environment is used to ensure that the test environment is similar to the actual environment, including server configuration, network settings, etc.; the acquisition of data packets is to use the packet capture software to filter and screen, obtain the Huawei network management alarm data packet, and then analyze the data packet content to obtain the alarm format for simulating alarm concurrency. Here, it is necessary to obtain all the alarms that can be generated by Huawei Huawei network management in advance after a certain period of time, and store the alarm data in categories for simulating the alarm source.

[0046] The creation of a test plan in this embodiment includes adding a thread group, setting the number of threads, setting a ramp-up period, and setting the number of loops. Adding a thread group includes setting the number of concurrent alarms, the number of loops, etc. Setting the number of threads is to set the alarm concurrency that needs to be simulated; setting the ramp-up period is to set the time for the threads to start so as to gradually increase the load; setting the number of loops: set to Forever or a specified number of times, as needed.

[0047] The configuration of HTTP request in this embodiment is to add HTTP request sampler (Sampler), add HTTP request under thread group, and then configure the URL and request method of northbound interface. In this process, the request body contains alarm data, and CSV data set configuration (CSV Data Set Config) can be used to read multiple alarm data to simulate different types of alarms.

[0048] The added parameterization in this embodiment uses a CSV Data Set Config plug-in, which can read a variety of alarm data from a CSV file to simulate the diversity in real scenarios.

[0049] The added listeners in this embodiment include listeners such as aggregate report and graphical result, so as to view the test results and performance indicators. The aggregate report listener can view the average response time, maximum response time, error rate, etc. The graphical result listener can intuitively view the performance changes of concurrent requests.

[0050] The performance test in this embodiment includes running tests and collecting data. Running tests refers to starting tests and observing the performance of the data collection end after the gateway system generates a large number of alarms. Collecting data refers to viewing the result data in JMeter, focusing on the following indicators: the number of alarms generated, response time, and throughput. Check the situation of the data collection end, observe the actual number of alarms received, and make a comparison.

[0051] Finally, observe whether the data collection end can work normally and respond to multiple concurrent alarms. Analyze the aggregate report and graphical results to evaluate the stability and performance of the data collection end under high concurrency. Collect the corresponding data and make it into a table to show the results more intuitively.

[0052] Based on the above detailed description of the method of the present invention, the experimental object of this embodiment is the provincial backbone network comprehensive data collection platform software, and the new script based on the long link detection of the heartbeat packet is configured in the data acquisition terminal interface to obtain the test results shown in Table 1:

[0053]

[0054]

[0055] Table 1

[0056] As can be seen from Table 1, the software ran normally within 48 hours and no alarms were generated.

[0057] During the data transmission stress test of this embodiment, the data acquisition end is connected to the Huawei SDH and OTN network management through the Huawei northbound interface to collect optical fiber optical power data in real time. When the optical power data is not within the normal range, a corresponding alarm will be generated. When a failure occurs during the operation of the data acquisition end, the acquisition end will generate a corresponding alarm, and some alarms may directly stop the data acquisition end from working. Referring to Table 2 and Table 3, Table 2 is a concurrent test table for optical fiber performance and equipment operation alarm tests; Table 3 is a collection end operation fault alarm test.

[0058]

[0059] Table 2

[0060]

[0061] Table 3

[0062] From the data analysis of Table 2 and Table 3, it can be seen that the software can operate normally under the pressure environment of multiple concurrent alarms and has a certain self-recovery ability.

[0063] In summary, the present invention provides a long link detection method based on heartbeat packets and a data transmission stress testing method for alarm concurrency scenarios. The present invention deploys a heartbeat script at the docking point between the data acquisition terminal and the northbound interface, which can be used to determine whether the data acquisition service is running correctly and stably, and also monitors the throughput of the northbound interface; the data transmission stress test of the present invention can generate a large number of alarms and can simulate the network management system; at the same time, the present invention can also obtain alarm-related data packets from a large number of forwarded data packets, and can analyze the content of the data packets and use them to simulate the occurrence of alarms, so as to test whether the data acquisition terminal can operate normally and the operating conditions, so as to evaluate its performance and responsiveness. Therefore, the present invention can test the reliability of the docking between the data acquisition terminal and the northbound interface, and has the advantages of accurate test results and easy operation.

Claims

1. A method for testing the reliability of data collection in a broadcast and television optical transmission network facing a northbound interface, characterized in that: Including long link detection and data transmission stress test based on heartbeat packets; The long link detection based on heartbeat packets is to deploy a heartbeat script at the connection point between the data acquisition end and the northbound interface to determine whether the data acquisition service is running correctly and stably, and also monitor the throughput of the northbound interface; The data transmission stress test is to perform a stress test on the northbound interface, simulate the network management system to send multiple alarms simultaneously, and observe the ability of the data acquisition end to correctly receive alarms.

2. The method for testing the reliability of data acquisition in a broadcast and television optical transmission network facing a northbound interface according to claim 1 is characterized in that: The long link detection based on the heartbeat packet includes the server actively sending a heartbeat packet, and the process is as follows: the server sets up a timer and sends a heartbeat packet to the client at a fixed time. After the client receives the heartbeat packet, it immediately sends the heartbeat packet to the server. After receiving the heartbeat packet sent by the client, the server confirms that the client's connection is available and does not perform operations related to releasing the socket; If the server does not receive a heartbeat packet in response to the client within the specified time interval, the server considers the client's connection unavailable and performs operations related to releasing the socket.

3. The method for testing the reliability of data acquisition in a broadcast and television optical transmission network facing a northbound interface according to claim 1 is characterized in that: The heartbeat packet-based long link detection includes the client actively sending a heartbeat packet, and the process is as follows: the client sends a heartbeat packet to the server, and the server identifies the relevant socket after receiving the heartbeat packet, and then the server sends a response heartbeat packet to the client, and the client considers that the connection is available when it receives the heartbeat packet; if the server does not receive the heartbeat packet for more than a period of time, the identifier of the relevant socket will be downgraded until it expires, and then the server releases the resources related to the socket.

4. The method for testing the reliability of data acquisition in a broadcast and television optical transmission network facing a northbound interface according to claim 3 is characterized in that: The heartbeat script is written as follows: first import the necessary modules of the heartbeat package, then set the heartbeat time interval, then define the heartbeat signal sending function, heartbeat signal processing function and throughput calculation function, and finally start the heartbeat cycle.

5. The method for testing the reliability of data acquisition in a broadcast and television optical transmission network facing a northbound interface according to claim 1 is characterized in that: The deployment process of the heartbeat script is: first, make sure that the CORBA middleware has been installed at the data acquisition end and the northbound interface connection point, then use the interface definition language IDL to describe the CORBA service and implement the service logic; then deploy the implemented service to the CORBA server, and test it after the deployment is completed.

6. The method for testing the reliability of data collection in a broadcast and television optical transmission network facing a northbound interface according to claim 1 is characterized in that: The process of the data transmission stress test is as follows: first prepare the stress test tool and perform prerequisite preparations, then create a test plan and configure HTTP requests, then add parameterization and listeners in sequence, and finally perform performance testing.

7. The method for testing the reliability of data collection in a broadcast and television optical transmission network facing a northbound interface according to claim 6 is characterized in that: The stress testing tool is Apache JMeter; the prerequisite preparation includes configuring the test environment and obtaining data packets; the configuration of the test environment is used to ensure that the test environment is similar to the actual environment, and the data packets are obtained by filtering and screening using packet capture software to obtain network management alarm data packets, and then the data packet content is analyzed to obtain the alarm format for simulating alarm concurrency.

8. The method for testing the reliability of data collection in a broadcast and television optical transmission network facing a northbound interface according to claim 6 is characterized in that: The creation of the test plan includes adding a thread group, setting the number of threads, setting a ramp-up period, and setting the number of loops.

9. The method for testing the reliability of data collection in a broadcast and television optical transmission network facing a northbound interface according to claim 6, characterized in that: The configuration of the HTTP request is to add an HTTP request sampler, add an HTTP request under the thread group, and then configure the URL and request method of the northbound interface.

10. The method for testing the reliability of data collection in a broadcast and television optical transmission network facing a northbound interface according to claim 6, characterized in that: The added parameterization is to use the CSV data set configuration plug-in to read a variety of alarm data to simulate the diversity in real scenarios; The listener includes an aggregate report and a graphic result listener; the aggregate report listener is used to find out the test results and performance indicators; the graphic result listener is used to view the performance changes of concurrent requests.

Images