Network element status checking processing method and apparatus, computing device, and storage medium

Abstract

The application discloses a network element state checking processing method and device, computing equipment and a storage medium, and the method comprises the steps of monitoring whether a network element state checking scene is present; if the network element state checking scene is present, controlling at least one target network element to execute at least one preset checking instruction; wherein the preset checking instruction is used for detecting the network element state of a device to be checked; obtaining an echo message generated by executing any preset checking instruction, and judging whether a corresponding checking pass condition is met according to the echo message; if yes, first pass state information is displayed, and the first pass state information is used for indicating that the execution result of the preset checking instruction does not affect a subsequent process. Through the above manner, it can be determined whether the execution result of the checking instruction is a pass state that does not affect the subsequent process, the number of failure results is reduced, the operation and maintenance personnel can quickly make effective discrimination, the discrimination difficulty of the business scene can be quickly and effectively solved, and the fault processing time is shortened.

Description

Technical Field

[0001] This invention relates to the field of information technology, and specifically to a method, apparatus, computing device, and storage medium for network element status verification. Background Technology

[0002] The automatic disaster recovery operation scripts for primary and backup network elements in the 5G core network include a pre-switchover network element status verification script, a switchover script, a pre-switchback network element status verification script, and a rollback script. In existing technologies, for the pre-switchover and pre-switchback network element status verification scripts, the execution results in the sample display file after each query command only show two states: "failure" and "success." While the determination of a "success" result is clear, the determination of a "failure" result is very complex. This is because the business scenarios are complex, and even senior experts cannot fully understand all business scenarios. Using complex formulas also leads to unclear determinations and long script execution times. Maintenance personnel also need to spend a significant amount of time studying and verifying "failure" commands, severely impacting the rapid execution of switchover and rollback operations. Summary of the Invention

[0003] In view of the above problems, the present invention is proposed to provide a network element status verification processing method, apparatus, computing device and storage medium that overcomes or at least partially solves the above problems.

[0004] According to one aspect of the present invention, a network element status verification processing method is provided, comprising:

[0005] Monitoring whether the network element status is being checked;

[0006] If the scenario is a network element status verification scenario, control at least one target network element to execute at least one preset verification instruction; wherein, the preset verification instruction is used to detect the network element status of the device to be verified;

[0007] Obtain the echo message generated by executing any preset verification command, and determine whether the corresponding verification release conditions are met based on the echo message;

[0008] If so, display the first release status information, which indicates that the execution result of the preset verification instruction does not affect the subsequent process.

[0009] Optionally, monitoring whether a network element status verification scenario is in progress further includes:

[0010] Monitor whether the main equipment has malfunctioned; if so, determine that it is in a network element status verification scenario.

[0011] Alternatively, after completing the disaster recovery switchover from primary to backup equipment, monitor whether the faulty primary equipment has recovered; if so, determine that the system is in a network element status verification scenario.

[0012] Optionally, the method further includes:

[0013] Based on the judgment results of whether multiple echo messages meet the verification release conditions, a joint judgment is made on whether the network element status verification of the device to be verified has passed. If so, a second release status information is displayed to indicate that the network element status verification has passed.

[0014] Optionally, monitoring whether a network element status verification scenario is in progress further includes:

[0015] In a scenario where a primary / backup disaster recovery failover occurs in the service NRF, causing a primary / backup disaster recovery failover in the IWF, if the primary / backup disaster recovery failover process of the service NRF is detected to be completed, it is determined that the scenario is a network element status verification scenario, and the device to be verified is the backup IWF device.

[0016] Controlling at least one target network element to execute at least one corresponding preset verification command further includes:

[0017] Control the first target network element to execute the first verification instruction and the second verification instruction; and control the second target network element to execute the third verification instruction and the fourth verification instruction;

[0018] The first verification command is used to log in to the primary service NRF to verify the AUSF status of the backup IWF; the second verification command is used to log in to the primary service NRF to verify the UDM status of the backup IWF; the third verification command is used to log in to the backup service NRF to verify the AUSF status of the backup IWF; and the fourth verification command is used to log in to the backup service NRF to verify the UDM status of the backup IWF.

[0019] Optionally, based on the judgment results of whether multiple echo messages meet the verification release conditions, the joint judgment on whether the network element status verification of the device to be verified has passed further includes:

[0020] If the echo messages corresponding to the first verification command and the second verification command respectively meet the corresponding verification success conditions, and the echo messages corresponding to the third verification command and the fourth verification command respectively meet the corresponding verification release conditions, then the network element status verification of the device to be verified is determined to be successful.

[0021] Alternatively, if the echo messages corresponding to the first and second verification instructions respectively meet the corresponding verification release conditions, and the echo messages corresponding to the third and fourth verification instructions respectively meet the corresponding verification success conditions, then the network element status verification of the device to be verified is determined to be successful.

[0022] Optionally, determining whether the verification and release conditions are met based on the echo message further includes:

[0023] If the echo message is empty, determine whether the preset verification instruction corresponding to the echo message is an asynchronous sample display instruction; if so, determine that the verification release condition is met.

[0024] Optionally, during the pre-switchover network element status verification process, the preset verification instructions include: a fifth verification instruction for verifying the network element status of the primary device; then, determining whether the corresponding verification release conditions are met based on the echo message further includes: if the echo message generated by executing the fifth verification instruction contains fifth preset indication information, then it is determined that the verification release conditions are met; the fifth preset indication information includes: information for indicating that the primary device has alarms and / or link faults.

[0025] According to another aspect of the present invention, a network element status verification processing apparatus is provided, comprising:

[0026] The scene detection module is suitable for monitoring whether a network element status verification scene is in progress.

[0027] The control module is suitable for controlling at least one target network element to execute at least one preset verification instruction in a network element status verification scenario; wherein, the preset verification instruction is used to detect the network element status of the device to be verified;

[0028] The discrimination module is suitable for obtaining the echo message generated by executing any preset verification command, and determining whether the corresponding verification release conditions are met based on the echo message;

[0029] The display module is suitable for displaying the first release status information if the echo message is determined to meet the corresponding verification release conditions. The first release status information is used to indicate that the execution result of the preset verification instruction does not affect the subsequent process.

[0030] Optionally, the scene detection module is further adapted to: monitor whether the primary device has malfunctioned; if so, determine that it is in a network element status verification scene;

[0031] Alternatively, after completing the disaster recovery switchover from primary to backup equipment, monitor whether the faulty primary equipment has recovered; if so, determine that the system is in a network element status verification scenario.

[0032] Optionally, the device further includes: a joint discrimination module, adapted to jointly determine whether the network element status verification of the device to be verified has passed based on the judgment results of whether multiple echo messages meet the verification release conditions; if so, displaying second release status information to indicate that the network element status verification has passed.

[0033] Optionally, the scene detection module is further adapted to:

[0034] In a scenario where a primary / backup disaster recovery failover occurs in the service NRF, causing a primary / backup disaster recovery failover in the IWF, if the primary / backup disaster recovery failover process of the service NRF is detected to be completed, it is determined that the scenario is a network element status verification scenario, and the device to be verified is the backup IWF device.

[0035] The control module is further adapted to: control the first target network element to execute the first verification instruction and the second verification instruction; and control the second target network element to execute the third verification instruction and the fourth verification instruction;

[0036] The first verification command is used to log in to the primary service NRF to verify the AUSF status of the backup IWF; the second verification command is used to log in to the primary service NRF to verify the UDM status of the backup IWF; the third verification command is used to log in to the backup service NRF to verify the AUSF status of the backup IWF; and the fourth verification command is used to log in to the backup service NRF to verify the UDM status of the backup IWF.

[0037] Optionally, the joint discrimination module is further adapted to:

[0038] If the echo messages corresponding to the first verification command and the second verification command respectively meet the corresponding verification success conditions, and the echo messages corresponding to the third verification command and the fourth verification command respectively meet the corresponding verification release conditions, then the network element status verification of the device to be verified is determined to be successful.

[0039] Alternatively, if the echo messages corresponding to the first and second verification instructions respectively meet the corresponding verification release conditions, and the echo messages corresponding to the third and fourth verification instructions respectively meet the corresponding verification success conditions, then the network element status verification of the device to be verified is determined to be successful.

[0040] Optionally, the discrimination module is further adapted to: if the echo message is empty, determine whether the preset verification instruction corresponding to the echo message is an asynchronous sample display instruction; if so, determine that the verification release condition is met.

[0041] Optionally, during the pre-switchover network element status verification process, the preset verification instructions include: a fifth verification instruction for verifying the network element status of the primary device; the discrimination module is further adapted to: if the echo message generated by executing the fifth verification instruction contains fifth preset indication information, then it is determined that the verification release condition is met; the fifth preset indication information includes: information for indicating that the primary device has alarms and / or link faults.

[0042] According to another aspect of the present invention, a computing device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus;

[0043] The memory is used to store at least one executable instruction, which causes the processor to perform the operation corresponding to the above-described network element status verification processing method.

[0044] According to another aspect of the present invention, a computer storage medium is provided, the storage medium storing at least one executable instruction, the executable instruction causing a processor to perform an operation corresponding to the network element status verification processing method described above.

[0045] According to the network element status verification processing method, apparatus, computing device, and storage medium of the present invention, the method includes: monitoring whether a network element status verification scenario is in progress; if a network element status verification scenario is in progress, controlling at least one target network element to execute at least one corresponding preset verification instruction; wherein, the preset verification instruction is used to detect the network element status of the device to be verified; obtaining the echo message generated by executing any preset verification instruction, and determining whether the corresponding verification release condition is met based on the echo message; if so, displaying first release status information, the first release status information being used to indicate that the execution result of the preset verification instruction does not affect subsequent processes. Through the above method, verification release conditions and release status are added. By determining whether the echo message generated by executing the verification instruction meets the verification release conditions, it can be determined whether the execution result of the verification instruction is a release status that does not affect subsequent processes, reducing the number of failure results, enabling maintenance personnel to quickly and effectively make judgments, and quickly and effectively solving the judgment problems of complex business scenarios, shortening fault handling time.

[0046] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0047] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0048] Figure 1 A flowchart of the network element status verification processing method provided in an embodiment of the present invention is shown;

[0049] Figure 2 A schematic diagram illustrating the execution logic of query instructions in an embodiment of the present invention is shown;

[0050] Figure 3a A schematic diagram of primary and backup disaster recovery backup of IWF in an embodiment of the present invention is shown;

[0051] Figure 3b A schematic diagram of primary and backup disaster recovery backup of service NRF in an embodiment of the present invention is shown;

[0052] Figure 4 A flowchart of a network element status verification processing method provided in another embodiment of the present invention is shown;

[0053] Figure 5a A schematic diagram of an echo message in one embodiment of the present invention is shown;

[0054] Figure 5b A schematic diagram of an echo message in another embodiment of the present invention is shown;

[0055] Figure 6 This diagram illustrates the structure of the network element status verification and processing device provided in an embodiment of the present invention.

[0056] Figure 7 A schematic diagram of the structure of a computing device provided in an embodiment of the present invention is shown. Detailed Implementation

[0057] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0058] Figure 1 A flowchart of the network element status verification processing method provided in an embodiment of the present invention is shown, as follows: Figure 1 As shown, the method includes the following steps:

[0059] Step S110: Monitor whether the network element status verification scenario is in progress.

[0060] Among them, the network element status verification scenario refers to the scenario in which network element status verification processing is required.

[0061] Step S120: If the network element status verification scenario is in progress, control at least one target network element to execute at least one preset verification instruction.

[0062] The preset verification instructions are used to detect the network element status of the device to be verified. If a network element status verification is required, the target network element is controlled to execute the preset verification instructions for verifying the network element status of the device to be verified. The number of target network elements can be one or more, and any target network element may execute one or more preset verification instructions.

[0063] Step S130: Obtain the echo message generated by executing any preset verification command, and determine whether the corresponding verification release conditions are met based on the echo message.

[0064] In one alternative approach, the verification and release conditions are determined for the echo message indicating a failure, thereby reducing the amount of data processing and computation.

[0065] The system obtains the echo message generated by executing any preset verification command corresponding to any target network element, and determines whether the preset verification release conditions are met based on the field data contained in the echo message, that is, whether the execution result of the preset verification command is a release.

[0066] Among them, the "open" status is different from the "success" status. The "success" status is the most stringent judgment result, while the "open" status is a prediction that has no impact on the subsequent switchover and rollback process after comprehensive consideration of multiple factors. The verification and open conditions can be set in advance by combining historical experience data, experimental data, live network test data, and problem handling result data. Correspondingly, the verification success condition used to determine whether the execution result of the preset verification command is successful is different from the verification and open conditions used to determine whether the execution result of the preset verification command is open.

[0067] Step S140: If satisfied, display the first release status information. The first release status information is used to indicate that the execution result of the preset verification instruction does not affect the subsequent process.

[0068] If the verification and release conditions are met based on the echo message, the first release status information is displayed to indicate that the execution result of the preset verification instruction does not affect the subsequent processing flow. For example, the first release status information may specifically be: "Does not affect switching" or "Does not affect reversal". The first release status information indicates to the user that although the execution result of the verification instruction is not a successful state, it has no impact on the subsequent process.

[0069] In one alternative approach, in response to a user's triggering of the processing suggestion button, a first release status information is displayed. That is, the processing suggestion button is displayed on the display page of the echo message. When the user clicks the processing suggestion button, a first release status information is displayed to indicate that the execution result does not affect the subsequent process. The processing suggestion button is in a specific color so that the user can intuitively understand the result of the instruction execution.

[0070] According to the network element status verification processing method provided in this embodiment, it monitors whether the network element status verification scenario is in progress. If the network element status verification scenario is in progress, it controls at least one target network element to execute at least one corresponding preset verification instruction. The preset verification instruction is used to detect the network element status of the device to be verified. It obtains the echo message generated by executing any preset verification instruction and determines whether the corresponding verification release condition is met based on the echo message. If so, it displays the first release status information, which is used to indicate that the execution result of the preset verification instruction does not affect the subsequent process. Through the above method, verification release conditions and release status are added. By judging whether the echo message generated by executing the verification instruction meets the verification release conditions, it can be determined whether the execution result of the verification instruction is a release status that does not affect the subsequent process, reducing the number of failure results, enabling operation and maintenance personnel to make effective judgments quickly, and can quickly and effectively solve the judgment problem of complex business scenarios, shortening the fault handling time.

[0071] When the method of this invention is applied to an automatic disaster recovery scenario, the specific implementation of the step of monitoring whether it is in a network element status verification scenario is as follows: Monitor whether the primary device has failed; if so, determine that it is in a network element status verification scenario. When the primary device fails, a disaster recovery switchover from the primary device to the backup device is required. At this time, the device to be verified is the backup device, and a network element status verification process before the switchover is performed on the backup device. Therefore, it is determined that the system is in a network element status verification scenario. Alternatively, after completing the disaster recovery switchover from the primary device to the backup device, monitor whether the failed primary device has recovered. If so, determine that it is in a network element status verification scenario. When the failed primary device recovers, a disaster recovery rollback process from the backup device to the primary device is required. At this time, the device to be verified is the primary device, and a strict network element status verification process before the rollback is performed on the primary device. Therefore, it is determined that the system is in a network element status verification scenario.

[0072] As can be seen, the automatic disaster recovery process of the primary equipment is a closed loop. When a failure is detected in the primary equipment, a strict pre-switchover network element status check is performed on the backup equipment. After the pre-switchover network element status check passes, the switchover process from the primary equipment to the backup equipment is performed. After the disaster recovery switchover from the primary equipment to the backup equipment is completed, if the primary equipment recovers from the failure, a strict pre-switchback network element status check is performed on the primary equipment. After the pre-switchback network element status check passes, the switchover process from the backup equipment to the primary equipment is performed. The network element status check is implemented by automatically executing a disaster recovery check script. The disaster recovery check script contains multiple check commands, specifically divided into query commands, deletion commands, and modification commands. These check commands are executed by multiple network elements, and the execution results can be obtained through the echo files (log files) generated by the execution of the check commands.

[0073] In related technologies, the execution result only includes failure and success states. The method of this embodiment adds a pass state to the execution result of query commands; for modification and deletion commands, no pass state is added. If the echo message shows that the execution result of the modification command or deletion command is failure, the automatic script operation is exited and subsequent manual verification is required.

[0074] The scripts for checking the status of network elements before switchover, before switchback, the switchover script, and the switchback script all contain query commands. Figure 2 The diagram illustrates the execution logic of query instructions in an embodiment of the present invention, as shown below. Figure 2 As shown, the execution logic specifically includes the following steps:

[0075] Step S210: Execute the connection command of the network element.

[0076] The executing network element refers to the network element that needs to execute the verification command. It is one of the target network elements. First, the network management platform needs to establish a connection with the executing network element, and then send the verification command to the connected executing network element for execution.

[0077] Step S220: Execute the network element to execute the target query instruction;

[0078] Step S230: Obtain the instruction execution result; wherein, the instruction execution result includes: success result, release result, and failure result.

[0079] Step S240: Check if there are any unexecuted query instructions. If yes, proceed to step S250; otherwise, proceed to step S260.

[0080] Step S250: The unexecuted query instruction is used as the target query instruction, and the process jumps to step S220;

[0081] Step S260: Determine if there are any other unconnected network elements; if yes, proceed to step S270; if no, the process ends.

[0082] Step S270: Select the other unconnected network element as the execution network element and proceed to step S210.

[0083] In another application scenario, the network element status verification script before switchover and rollback checks network element alarms, SCTP links, HTTP links, etc., and the command execution result is often "failed". This is because there are many alarms, the link status is complex, and the formulas for judgment are unclear.

[0084] Therefore, to improve judgment efficiency and determine which warnings and link states have no impact on subsequent switchover and fallback processes, the execution results of the corresponding verification commands are determined as "allowing". In practical applications, when performing network element status verification before switchover, in addition to verifying the network element status of the standby device, the network element status of the primary device is also monitored and output by executing verification commands. Similarly, when performing network element status verification before fallback, in addition to verifying the network element status of the primary device, the network element status of the standby device is also monitored and output by executing verification commands.

[0085] Specifically, during the pre-switchover network element status verification process, the preset verification instructions include: a fifth verification instruction for verifying the network element status of the primary device; specifically, the fifth verification instruction includes: a verification instruction for detecting alarm information and / or SCTP link status and / or HTTP link status of the primary device; if the echo message generated by executing the fifth verification instruction contains the fifth preset indication information, then the verification release condition is determined to be met; the fifth preset indication information includes: information indicating that the primary device has alarms and / or link faults. During the pre-switchover network element status verification process, if the primary device has alarms and / or SCTP link faults and / or HTTP faults, it is determined that it will not affect the subsequent switchover process, that is, the execution result of the fifth verification instruction is release.

[0086] Accordingly, during the pre-switchback network element status verification process, the preset verification instructions include: a sixth verification instruction for verifying the network element status of the standby device; specifically, the sixth verification instruction includes: a verification instruction for detecting alarm information and / or SCTP link status and / or HTTP link status of the standby device; if the echo message generated by executing the sixth verification instruction contains the sixth preset indication information, then the verification release condition is determined to be met; the sixth preset indication information includes: information indicating that the standby device has alarms and / or link faults. During the pre-switchback network element status verification process, if the standby device has alarms and / or SCTP link faults and / or HTTP faults, it is determined that it does not affect the subsequent switchover process, that is, the execution result of the sixth verification instruction is release.

[0087] The echo message generated by executing the verification command for checking the alarm information of the equipment includes the following information items: Alarm Sequence, Alarm ID, Alarm Type, Alarm Code, Alarm Code Name, Probable Cause Code, Alarm Reason, Severity, Occurrence Time, Slice ID, Network Function ID, NF Name, Additional Information, Position Name, Project Name, Province, and Alarm Status.

[0088] For example, if the fifth verification command is used to check the alarm information of the primary device, for the echo message generated by the fifth verification command, if the alarm information is empty, the execution result is determined to be successful; if the alarm information is not empty, the execution result is determined to be allowed. That is, the echo message meets the verification allowance conditions, and the first allowance status information is displayed to inform the user that there is an alarm in the primary office but it does not affect the subsequent switchover process. The first allowance status information is as follows: The primary office has alarm information, which does not affect the switchover. Please check. If the fifth verification command is used to check the HTTP link status of the primary device, if the echo message shows that the primary office's HTTP dynamic link is "active", the execution result is determined to be successful; if the echo message shows that the primary office's HTTP dynamic link is not "active", the execution result is determined to be allowed. That is, the echo message meets the verification allowance conditions, and the first allowance status information is displayed to inform the user that there is a fault in the primary office's HTTP dynamic link but it does not affect the subsequent switchover process. The first allowance status information is as follows: The primary office's HTTP link is abnormal, which does not affect the switchover. Please check.

[0089] The method of this invention can also be applied to primary / backup disaster recovery scenarios for IWF and service NRF. IWF (Interconnection Gateway) is one of the key nodes in the user data migration bridging scheme of the 5GC SA architecture, providing services to 5G network elements (AMF / SMF / SMSF) for authentication, user data, and service processes. NRF (Network Storage Function Entity) supports service discovery functions, receives NF-Discovery-Requests from network elements, provides discovered network element information to the requester, and also maintains available network element instances and supports related services.

[0090] IWF and Service NRF are based on 5GC SA virtualization and centralized regional deployment, employing a primary / backup disaster recovery scheme at the network element level across regions. Several regions are centrally established, with two regions forming a pair. The primary and backup network elements of IWF (or Service NRF) are deployed on the two paired regions respectively. When equipment in the primary region fails, a "switchover" operation is performed on the network management platform, completely switching over to the entire set of backup network elements in the backup region. When equipment in the primary region is repaired, a "rollback" operation is performed on the network management platform, completely switching back to the entire set of network elements in the primary region.

[0091] Figure 3a This diagram illustrates a primary / standby disaster recovery backup method for IWF in an embodiment of the present invention. Figure 3a As shown, the IWF network element includes front-end network elements (FE / UDM) and back-end network elements (BE / UDR). During disaster recovery, a complete switchover strategy is adopted, that is, the front-end and back-end network elements of the primary area are switched over to the front-end and back-end network elements of the backup area. During the IWF switchover process, it is necessary to query the service NRF primary network element to obtain the status of the front-end and back-end network elements of the backup area IWF to determine whether they are working normally. Figure 3b This diagram illustrates the primary / standby disaster recovery backup of the service NRF in an embodiment of the present invention. When the service NRF performs disaster recovery processing, it affects all network elements (including the UDM, AMF, PCF, and SMF network elements shown in the diagram). This is because these network elements are all registered with the service NRF, but during failover or rollback, the registration status of all network elements is checked in reverse. That is, the disaster recovery processing of the IWF and service NRF is independent of each other, but due to the association between the two types of network elements, there will be interaction between the disaster recovery processing of the IWF and the service NRF.

[0092] In one application scenario, there's an issue where some business NRF commands randomly generate asynchronous sampling. Asynchronous sampling occurs because the echo message file is delayed, and the system initially sends an empty echo message file. For this scenario, if the echo message is empty, it's determined whether the corresponding preset verification command is an asynchronous sampling command; if so, the verification release condition is met. If an empty echo message is detected, it's determined whether the corresponding preset verification command is an asynchronous sampling command; if so, it's determined that the empty echo message file does not affect subsequent processing, the verification release condition is met, and the execution result of the verification command is release.

[0093] Figure 4A flowchart of a network element status verification method according to another embodiment of the present invention is shown. This method is applied to a scenario where a primary / backup disaster recovery switchover of the service NRF causes a primary / backup disaster recovery switchover of the IWF. In this scenario, in the network element status verification script before the IWF switchover, the instruction to verify the AUSF and UDM status of the backup IWF by the primary service NRF will fail. Therefore, it is necessary to verify the AUSF and UDM status of the backup IWF by both the primary and backup service NRFs. Passing the verification of either service NRF is considered a successful verification of the AUSF and UDM status of the backup IWF. Figure 4 As shown, the method includes the following steps:

[0094] Step S410: If the primary / backup disaster recovery failover process of the service NRF is detected to be complete, then the system is determined to be in a network element status verification scenario. The device to be verified is specifically the standby service NRF device.

[0095] If the primary / standby disaster recovery switchover of the service NRF is completed, then the primary / standby disaster recovery switchover of the IWF is required, and the network element status of the standby IWF needs to be checked before the switchover.

[0096] Step S420: Control at least one target network element to execute at least one preset verification command.

[0097] The target network element includes a first target network element and a second target network element. The specific steps are: controlling the first target network element to execute a first verification instruction and a second verification instruction; and controlling the second target network element to execute a third verification instruction and a fourth verification instruction.

[0098] The first verification command is used to log in to the primary service NRF to verify the AUSF status of the backup IWF; the second verification command is used to log in to the primary service NRF to verify the UDM status of the backup IWF; the third verification command is used to log in to the backup service NRF to verify the AUSF status of the backup IWF; and the fourth verification command is used to log in to the backup service NRF to verify the UDM status of the backup IWF.

[0099] In this embodiment, the network element status verification script before IWF switchover includes four instructions for logging into the primary service NRF and the backup service NRF, and verifying the AUSF and UDM status of the backup IWF. The instructions are explained in Table 1 below:

[0100] Table 1

[0101] A1 APP-XNCDxnqSNRF001AHW-07AHW011 DSP REGNFINSTANCE:NFTYPE=NUSF A2 APP-XNCDxnqSNRF001AHW-07AHW011 DSP REGNFINSTANCE:NFTYPE=UDM B1 APP-XNCDxnqSNRF001AHW-07AHW012 DSP REGNFINSTANCE:NFTYPE=NUSF B2 APP-XNCDxnqSNRF001AHW-07AHW012 DSP REGNFINSTANCE:NFTYPE=UDM

[0102] Specifically, the A1 command (first verification command) is used to log in to the primary service NRF to verify the AUSF status of the backup IWF; the A2 command (second verification command) is used to log in to the primary service NRF to verify the UDM status of the backup IWF; the B1 command (third verification command) is used to log in to the backup service NRF to verify the AUSF status of the backup IWF; and the B2 command (fourth verification command) is used to log in to the backup service NRF to verify the UDM status of the backup IWF.

[0103] Step S430: Obtain the echo message generated by executing any preset verification instruction, and determine whether the corresponding verification release conditions are met based on the echo message; if so, display the first release status information, which is used to indicate that the execution result of the preset verification instruction does not affect the subsequent process.

[0104] Specifically, the system obtains the first echo message generated by the first target network element executing the first verification instruction, and determines whether the corresponding verification release conditions are met based on the first echo message; and obtains the second echo message generated by the first target network element executing the second verification instruction, and determines whether the corresponding verification release conditions are met based on the second echo message. The first target network element is the network element whose name is located in the same row as the A1 instruction and the A2 instruction in Table 1.

[0105] Obtain the third echo message generated by the second target network element executing the third verification instruction, and determine whether the corresponding verification release conditions are met based on the third echo message; and obtain the fourth echo message generated by the second target network element executing the fourth verification instruction, and determine whether the corresponding verification release conditions are met based on the fourth echo message. The second target network element is the network element whose name is located in the same row as the B1 instruction and the B2 instruction in Table 1.

[0106] The echo messages generated by executing the above four verification commands all contain the following information items: NF (Network Element Functional Entity) type, IPv4 address, IPv6 address, NF status, FQDN (Fully Qualified Domain Name), and NF group identifier. The verification approval conditions are determined based on the specified field information. Specifically, determining whether an echo message meets the corresponding verification approval condition involves checking whether the echo message contains the specified field information. Different verification commands correspond to different verification approval conditions.

[0107] Figure 5a The diagram shows an echo message according to an embodiment of the present invention. Figure 5aThe diagram shows the echo messages generated by the network element executing the verification command used to log in to the primary service NRF or the backup service NRF to check the AUSF status of the backup IWF. Specifically, it shows the first echo message generated by executing the A1 command or the third echo message generated by executing the B1 command. The echo messages contain command information (i.e., “DSP REGNFINSTANCE:NFTYPE=NUSF” shown in area 511), remaining code and execution status (“Retcode=0” and “Operation successful” shown in area 512), detailed message information (each information item and the information value under the information item shown in area 513, i.e., column value) and the number of execution results (“Number of results = 29” shown in area 514).

[0108] For the first and third echo messages, the column values ​​of the NF instance identifier and the corresponding NF status are checked. If the column value of the NF instance identifier contains multiple specified fields, and the corresponding NF status column values ​​are all registered, then the execution result of the verification command is considered successful. Otherwise, the verification release condition is met, and the execution result of the verification command is considered released. A release result indicates that although the execution result is not successful, it does not affect subsequent processes.

[0109] Specifically, for the first and third echo messages, the "NF instance identifier" column values ​​include: 5F4E9B14-484A-2032-EF40-122B00000001, 5F50D822-484C-2032-387C-122B00000001, 5F50D8A4-484C-2032-AC82-122B00000001, 5F50D92C-484C-2032-4215-122 If the values ​​of B00000001, 5F50D8F1-484C-2032-6342-122B00000001, 5F50D97B-484C-2032-193B-122B00000001 are all "Registered Status", then the verification success condition is met, and the execution result of the verification instruction is determined to be successful. Otherwise, the verification release condition is met, and the execution result of the verification instruction is determined to be released.

[0110] Figure 5b A schematic diagram of an echo message according to another embodiment of the present invention is shown. Figure 5bThe diagram shows the echo message generated by the network element performing the verification execution for logging into the primary service NRF or the backup service NRF to check the UDM status of the backup IWF. Specifically, it shows the second echo message generated by executing the A2 instruction or the fourth echo message generated by executing the B2 instruction. The echo message contains instruction information (i.e., “DSP REGNFINSTANCE:NFTYPE=UDM” shown in area 521), remaining code and execution status (“Retcode=0” and “Operation successful” shown in area 522), detailed message information (each information item and the information value under each information item shown in area 523), and the number of execution results (“Number of results = 30” shown in area 524).

[0111] Specifically, for the second and fourth echo messages, the "NF instance identifier" column values ​​include: 5F4E9B14-484A-2032-4D4C-042B00000001, 5F50D822-484C-2032-6B58-042B00000001, 5F50D8A4-484C-2032-DE11-042B00000001, 5F50D92C-484C-2032-7C9A-042 If the values ​​in column B00000001, 5F50D8F1-484C-2032-4EDD-042B00000001, 5F50D97B-484C-2032-1980-042B00000001 are all in the "NF Status" column, and all of the above column values ​​are in the "Registered Status" column, then the verification success condition is met, and the execution result of the verification instruction is determined to be successful. Otherwise, the verification release condition is met, and the execution result of the verification instruction is determined to be released. A release result indicates that although the execution result is not successful, it does not affect subsequent processes.

[0112] For any echo message, if it is determined that the corresponding verification release conditions are met, the first release status information is displayed on the echo message to indicate that the execution result of the verification instruction corresponding to the echo message does not affect the subsequent process.

[0113] In one optional approach, in addition to displaying the initial release status information, an access point with an echo message is also shown. Responding to the user's triggering action on the access point, the echo message is displayed, allowing the user to view detailed echo messages. In another optional approach, a release status indicator is also displayed, such as a button with a specific color. The display style of the release status indicator differs from that of the success status indicator, so that the user can intuitively understand the command execution result.

[0114] Step S440: Based on the judgment results of whether multiple echo messages meet the verification release conditions, jointly determine whether the network element status verification of the device to be verified has passed. If so, display the second release status information to indicate that the network element status verification has passed.

[0115] Specifically, if the echo messages corresponding to the first and second verification commands respectively meet the corresponding verification success conditions, and the echo messages corresponding to the third and fourth verification commands respectively meet the corresponding verification release conditions, then the network element status verification of the device to be verified is determined to be successful. That is, if the execution result of command A1 is successful and the execution result of command A2 is successful, and the execution result of command B1 is released and the execution result of command B2 is released, then the network element status verification of the backup IWF is determined to be successful, and the second release status information is displayed to indicate that the network element status verification of the backup IWF is successful.

[0116] Alternatively, if the echo messages corresponding to the first and second verification commands respectively meet the corresponding verification release conditions, and the echo messages corresponding to the third and fourth verification commands respectively meet the corresponding verification success conditions, then the network element status verification of the device to be verified is determined to be successful. That is, if the execution result of command A1 is release and the execution result of command A2 is release, and the execution result of command B1 is success and the execution result of command B2 is success, then the network element status verification of the backup IWF is successful, and the second release status information is displayed to indicate that the network element status verification of the backup IWF is successful.

[0117] According to the network element status verification method in this embodiment, in the scenario where the primary and backup service NRFs fail over due to a primary / backup disaster recovery switchover, the verification instructions are executed to log in to the primary service NRF and the backup service NRF to verify the status of the backup IWF's AUSF and UDM. Finally, the network element status verification result of the backup IWF is determined by combining the execution results of the four instructions. This solves the problem of difficulty in determining the execution result of instructions in multi-network element interaction scenarios, avoids complex discrimination formulas, shortens instruction execution time, and helps operation and maintenance personnel to make the fastest and most effective judgment, thereby shortening the fault handling time.

[0118] The method of this invention can be used to assist in handling network-level severe faults that cannot be resolved in a short time, such as unexpected unreachability of IWF and service NRF network elements, significant reduction in node-borne services, sharp decline in key node KPI indicators, and a large number of user complaints, thus forming an automatic disaster recovery capability for 5G network elements.

[0119] Figure 6 A schematic diagram of the network element status verification processing device provided in an embodiment of the present invention is shown, as follows: Figure 6 As shown, the device includes:

[0120] Scene detection module 61 is suitable for monitoring whether the scene is in network element status verification scenario;

[0121] Control module 62 is adapted to control at least one target network element to execute at least one preset verification instruction in a network element status verification scenario; wherein, the preset verification instruction is used to detect the network element status of the device to be verified;

[0122] The discrimination module 63 is adapted to obtain the echo message generated by executing any preset verification instruction, and determine whether the corresponding verification release conditions are met based on the echo message;

[0123] The display module 64 is adapted to display first release status information if the echo message is determined to meet the corresponding verification release conditions. The first release status information is used to indicate that the execution result of the preset verification instruction does not affect the subsequent process.

[0124] In an alternative embodiment, the scene detection module 61 is further adapted to: monitor whether the primary device has malfunctioned; if so, determine that it is in a network element status verification scene;

[0125] Alternatively, after completing the disaster recovery switchover from primary to backup equipment, monitor whether the faulty primary equipment has recovered; if so, determine that the system is in a network element status verification scenario.

[0126] In one alternative embodiment, the device further includes a joint discrimination module, adapted to jointly determine whether the network element status verification of the device to be verified has passed based on the judgment results of whether multiple echo messages meet the verification release conditions; if so, displaying second release status information to indicate that the network element status verification has passed.

[0127] In one alternative embodiment, the scene detection module 61 is further adapted to:

[0128] In a scenario where a primary / backup disaster recovery failover occurs in the service NRF, causing a primary / backup disaster recovery failover in the IWF, if the primary / backup disaster recovery failover process of the service NRF is detected to be completed, it is determined that the scenario is a network element status verification scenario, and the device to be verified is the backup IWF device.

[0129] Control module 62 is further adapted to: control the first target network element to execute the first verification instruction and the second verification instruction; and control the second target network element to execute the third verification instruction and the fourth verification instruction;

[0130] The first verification command is used to log in to the primary service NRF to verify the AUSF status of the backup IWF; the second verification command is used to log in to the primary service NRF to verify the UDM status of the backup IWF; the third verification command is used to log in to the backup service NRF to verify the AUSF status of the backup IWF; and the fourth verification command is used to log in to the backup service NRF to verify the UDM status of the backup IWF.

[0131] In one alternative approach, the joint discrimination module is further adapted to:

[0132] If the echo messages corresponding to the first verification command and the second verification command respectively meet the corresponding verification success conditions, and the echo messages corresponding to the third verification command and the fourth verification command respectively meet the corresponding verification release conditions, then the network element status verification of the device to be verified is determined to be successful.

[0133] Alternatively, if the echo messages corresponding to the first and second verification instructions respectively meet the corresponding verification release conditions, and the echo messages corresponding to the third and fourth verification instructions respectively meet the corresponding verification success conditions, then the network element status verification of the device to be verified is determined to be successful.

[0134] In an alternative approach, the discrimination module 63 is further adapted to: if the echo message is empty, determine whether the preset verification instruction corresponding to the echo message is an asynchronous sample display instruction; if so, determine that the verification release condition is met.

[0135] In one alternative approach, when performing network element status verification processing before switchover, the preset verification instructions include: a fifth verification instruction for verifying the network element status of the primary device; the discrimination module 63 is further adapted to: if the echo message generated by executing the fifth verification instruction contains fifth preset indication information, then it is determined that the verification release condition is met; the fifth preset indication information includes: information for indicating that the primary device has alarms and / or link faults.

[0136] This invention provides a non-volatile computer storage medium storing at least one executable instruction that can execute the network element status verification processing method in any of the above method embodiments.

[0137] Figure 7 The diagram shows a structural schematic of a computing device provided in an embodiment of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the computing device.

[0138] like Figure 7 As shown, the computing device may include a processor, a communications interface, memory, and a communications bus.

[0139] The processor, communication interface, and memory communicate with each other via a communication bus. The communication interface is used to communicate with other network elements, such as clients or other servers. The processor executes programs, specifically the relevant steps described in the embodiment of the network element status verification processing method for computing devices.

[0140] Specifically, the program may include program code, which includes computer verification instructions.

[0141] The processor may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The computing device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0142] Memory is used to store programs. Memory may include high-speed RAM, and may also include non-volatile memory, such as at least one disk drive.

[0143] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0144] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0145] Similarly, it should be understood that, in order to simplify the invention and aid in understanding one or more of the various inventive aspects, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0146] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0147] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0148] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0149] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method for network element status verification, characterized in that, The method includes: Monitoring whether the network element status is being checked; The monitoring of whether it is in the network element status verification scenario further includes: in the scenario where the service NRF undergoes a primary / backup disaster recovery switchover, causing the IWF to undergo a primary / backup disaster recovery switchover, if the primary / backup disaster recovery switchover process of the service NRF is detected to be completed, it is determined that it is in the network element status verification scenario, and the device to be verified is the backup IWF device. If the scenario is a network element status verification scenario, control at least one target network element to execute at least one preset verification instruction; wherein, the preset verification instruction is used to detect the network element status of the device to be verified; The step of controlling at least one target network element to execute at least one corresponding preset verification instruction further includes: controlling the first target network element to execute a first verification instruction and a second verification instruction; and controlling the second target network element to execute a third verification instruction and a fourth verification instruction; wherein the first verification instruction is used to log in to the primary service NRF to verify the AUSF status of the backup IWF, the second verification instruction is used to log in to the primary service NRF to verify the UDM status of the backup IWF, the third verification instruction is used to log in to the backup service NRF to verify the AUSF status of the backup IWF, and the fourth verification instruction is used to log in to the backup service NRF to verify the UDM status of the backup IWF; Obtain the echo message generated by executing any preset verification instruction, and determine whether the corresponding verification release condition is met based on the echo message; if so, display the first release status information, which is used to indicate that the execution result of the preset verification instruction does not affect the subsequent process. If the echo messages corresponding to the first and second verification commands respectively meet the corresponding verification success conditions, and the echo messages corresponding to the third and fourth verification commands respectively meet the corresponding verification release conditions, then the network element status verification of the device to be verified is determined to be successful; or, if the echo messages corresponding to the first and second verification commands respectively meet the corresponding verification release conditions, and the echo messages corresponding to the third and fourth verification commands respectively meet the corresponding verification success conditions, then the network element status verification of the device to be verified is determined to be successful.

2. The method according to claim 1, characterized in that, The monitoring scenario for checking whether a network element is in a state further includes: Monitor whether the main equipment has malfunctioned; if so, determine that it is in a network element status verification scenario. Alternatively, after completing the disaster recovery switchover from primary to backup equipment, monitor whether the faulty primary equipment has recovered; if so, determine that the system is in a network element status verification scenario.

3. The method according to claim 1, characterized in that, The method further includes: If the network element status verification of the device to be verified is deemed to have passed based on the judgment results of whether multiple echo messages meet the verification and release conditions, then the second release status information used to indicate that the network element status verification has passed will be displayed.

4. The method according to claim 1, characterized in that, When performing network element status verification before switchover, the preset verification instruction includes a fifth verification instruction for verifying the network element status of the primary device; then, determining whether the corresponding verification release conditions are met based on the echo message further includes: if the echo message generated by executing the fifth verification instruction contains fifth preset indication information, then it is determined that the verification release conditions are met; the fifth preset indication information includes: information for indicating that the primary device has alarms and / or link faults.

5. A network element status verification and processing device, characterized in that, The device includes: The scene detection module is suitable for monitoring whether a network element status verification scene is in progress. The scenario detection module is further adapted to: in the scenario where the primary and backup disaster recovery failover of the service NRF causes the IWF to fail over, if the primary and backup disaster recovery failover of the service NRF is detected to be completed, then it is determined to be in the network element status verification scenario, and the device to be verified is the backup IWF device. The control module is adapted to control at least one target network element to execute at least one preset verification instruction in a network element status verification scenario; wherein, the preset verification instruction is used to detect the network element status of the device to be verified; The control module is further adapted to: control the first target network element to execute the first verification instruction and the second verification instruction; and control the second target network element to execute the third verification instruction and the fourth verification instruction; wherein the first verification instruction is used to log in to the primary service NRF to verify the AUSF status of the backup IWF, the second verification instruction is used to log in to the primary service NRF to verify the UDM status of the backup IWF, the third verification instruction is used to log in to the backup service NRF to verify the AUSF status of the backup IWF, and the fourth verification instruction is used to log in to the backup service NRF to verify the UDM status of the backup IWF; The discrimination module is adapted to obtain the echo message generated by executing any preset verification instruction, and determine whether the corresponding verification release conditions are met based on the echo message; The display module is adapted to display first release status information if the echo message is determined to meet the corresponding verification release conditions. The first release status information is used to indicate that the execution result of the preset verification instruction does not affect the subsequent process. The joint discrimination module is suitable for determining that the network element status verification of the device to be verified has passed if the echo messages corresponding to the first verification command and the second verification command respectively meet the corresponding verification success conditions, and the echo messages corresponding to the third verification command and the fourth verification command respectively meet the corresponding verification release conditions; or, if the echo messages corresponding to the first verification command and the second verification command respectively meet the corresponding verification release conditions, and the echo messages corresponding to the third verification command and the fourth verification command respectively meet the corresponding verification success conditions, then the network element status verification of the device to be verified has passed.

6. A computing device, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the operation corresponding to the network element status verification process as described in any one of claims 1-4.

7. A computer storage medium storing at least one executable instruction that causes a processor to perform an operation corresponding to the network element status verification process as described in any one of claims 1-4.

Images