Auto-healing suppression in consideration of network failure

Abstract

To appropriately determine whether to perform or suppress auto-healing in consideration of the type of network failure when a network failure occurs in a virtualized environment.SOLUTION: A network management device comprises at least one processor. The processor performs reception processing and first determination processing. The reception processing receives a signal supplied when a failure is detected in any of a plurality of logical networks within a virtualized network environment. The first determination processing determines not to perform auto-healing when a failure is detected in a first logical network used for platform monitoring, but no failure is detected in a second logical network used for application monitoring.SELECTED DRAWING: Figure 17

Description

[Technical Field]

[0001] The present disclosure relates to auto-healing suppression taking into account the type of network failure. [Background technology]

[0002] With the improvement in performance of general-purpose servers and the expansion of network infrastructure, cloud computing (hereafter referred to as "cloud"), which uses virtualized computing resources on physical resources such as servers on demand, has become widespread. NFV (Network Function Virtualization), which virtualizes network functions and provides them on the cloud, is also well known. NFV is a technology that uses virtualization and cloud technologies to separate the hardware and software of various network services that previously ran on dedicated hardware, and runs the software on a virtualized platform. This is expected to lead to more advanced operations and cost reductions. In recent years, virtualization has also been progressing in mobile networks. The European Telecommunications Standards Institute (ETSI) NFV defines the architecture of NFV (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] International Publication No. 2016 / 121830 Summary of the Invention [Problem to be solved by the invention]

[0004] Auto-healing, as defined in ETSI NFV and other standards, enables rapid service recovery by automatically evacuating the faulty VNF / CNF to healthy hardware resources when a failure is detected. Auto-healing removes the faulty VNF or CNF, deploys other hardware resources for that VNF ​​or CNF (creates a VNF or CNF), and then configures the VNF or CNF to optimize its operation. Therefore, service availability will be temporarily reduced from the time the failure occurs until auto-healing is completed (until the recovered VNF / CNF is incorporated into operation and can resume service).

[0005] Generally, failures that trigger auto-healing can be broadly classified into two types: one is a failure of the hardware resources on which the VNF / CNF runs (such as a physical breakdown), and the other is a failure of the VNF / CNF itself (such as a software bug in the application).

[0006] Conventionally, network failures in virtualized environments (e.g., failures in interfaces between components) have not been considered as triggers for auto-healing. Furthermore, as mentioned above, service availability is temporarily reduced from the time the failure occurs until auto-healing is completed.

[0007] Therefore, the present disclosure provides a technology that, when a network failure occurs in a virtualized environment, appropriately determines whether or not to implement auto-healing, taking into account the type of network failure. [Means for solving the problem]

[0008] One aspect of the present disclosure provides a network management device, including at least one processor, which performs a receiving process for receiving a signal provided when a failure is detected in one of a plurality of logical networks in a network virtualization environment, and a first determining process for determining not to perform auto-healing when a failure is detected in a first logical network for platform monitoring but not in a second logical network for application monitoring.

[0009] One aspect of the present disclosure provides a network management method, including receiving a signal provided when a failure is detected in any of a plurality of logical networks in a network virtualization environment, and determining not to perform auto-healing when the failure is detected in a first logical network for platform monitoring but not in a second logical network for application monitoring. [Effects of the Invention]

[0010] In an aspect of the present disclosure, when a failure occurs in a network implemented in a virtualized environment, the type of network failure is taken into consideration and an appropriate decision is made as to whether or not to implement auto-healing. By suppressing unnecessary auto-healing, network availability is improved compared to when auto-healing is not suppressed. [Brief explanation of the drawings]

[0011] [Figure 1] Figure 1 is a block diagram showing the components in the network virtualization environment defined by ETSI NFV, with particular emphasis on the VIM-NFVI platform monitoring network. [Figure 2] Figure 2 is a block diagram showing the above components, highlighting the platform monitoring network between OSS / NFVO and VIM. [Figure 3]Figure 3 is a block diagram showing the above components, with particular emphasis on the platform control network between OSS / NFVO-VIM. [Figure 4] Figure 4 is a block diagram showing the above components, highlighting the application monitoring network between the EMS / VNFM and the VNF / CNF. [Figure 5] Figure 5 is a block diagram showing the above components, with particular emphasis on the application monitoring network between OSS / NFVO-EMS / VNFM. [Figure 6] Figure 6 is a block diagram showing the above components, with particular emphasis on the application control network between OSS / NFVO-EMS / VNFM. [Figure 7] FIG. 7 is a block diagram illustrating the above components, with particular emphasis on the network for mobile services. [Figure 8] FIG. 8 shows the networks of FIGS. 1, 2, 4, and 5 from a different perspective. [Figure 9] FIG. 9 is a diagram illustrating an example of installation of a determination device according to the present disclosure. [Figure 10] FIG. 10 is a diagram showing another example of installation of a determination device according to the present disclosure. [Figure 11] FIG. 11 is a diagram showing another example of installation of a determination device according to the present disclosure. [Figure 12] FIG. 12 is a diagram showing another example of installation of a determination device according to the present disclosure. [Figure 13] FIG. 13 is a block diagram illustrating an example of a hardware configuration of the determination device. [Figure 14] FIG. 14 is a table showing the relationship between network failures and the determination results of the determination device. [Figure 15] FIG. 15 is a sequence diagram illustrating an example of processing in a virtualized environment of a network according to the present disclosure. [Figure 16] FIG. 16 is a sequence diagram illustrating another example of processing in a virtualized environment of a network according to the present disclosure. [Figure 17]FIG. 17 is a flowchart showing the determination operation of the determination device. [Figure 18] FIG. 18 is a table showing examples of monitoring items for determining whether or not a further fault is detected in response to a command from the determination device. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0013] 1 to 7 are block diagrams showing components in a network virtualization environment defined by ETSI NFV. The solid lines in the diagram represent logical connections between components.

[0014] A VNF (Virtual Network Function) corresponds to applications that run on a virtual machine (VM) on a server, and realizes network functions such as directory services, routers, firewalls, and load balancers in software. VNFs may also be implemented as software (virtual machines) to implement elements of the EPC (Evolved Packet Core), which is the core network of a mobile network, or elements of the IMS (IP Multimedia Subsystem). CNF (Containerized Network Function, or Cloud-native Network Function) is an evolution of VNF, and supports applications running in containers on servers, realizing network functions in software. As a CNF, elements of EPC or IMS may be realized in software (containers). Hereinafter, "VNF / CNF" means "VNF" or "CNF".

[0015] An EMS (Element Management System) is a management function attached to each VNF / CNF. Each EMS is connected to the corresponding VNF / CNF and monitors that VNF / CNF.

[0016] NFVI (Network Function Virtualization Infrastructure) is the execution platform for VNF / CNF. NFVI is a platform that enables the flexible handling of hardware resources of physical machines (servers), such as computing, storage, and network functions, as virtualized hardware resources such as virtualized computing, virtualized storage, and virtualized networks, which are virtualized using a virtualization layer such as a hypervisor. In reality, multiple NFVIs are provided, and each NFVI is connected to multiple VNFs / CNFs and monitors those VNFs / CNFs.

[0017] The VIM (Virtualized Infrastructure Manager) plays the role of a cloud controller. In other words, the VIM controls the NFVI via the virtualization layer (managing computing, storage, and network resources, monitoring NFVI faults, and monitoring resource information, which is the execution platform for NFV). In practice, multiple VIMs are provided, and each VIM is connected to and monitors multiple NFVIs.

[0018] The VNFM (VNF Manager) manages VNFs / CNFs. Specifically, the VNFM controls NFVIs via the virtualization layer (managing computing, storage, and network resources, monitoring NFVI faults, monitoring resource information, etc.). In practice, multiple VNFMs are provided, and each VNFM is connected to multiple VNFs / CNFs and multiple VIMs and monitors those VNFs / CNFs and VIMs.

[0019] The NFVO (NFV Orchestrator) orchestrates NFVI resources, manages network resources, and manages network services. The NFVO also has a repository of NFV instances and a repository of NFVI resources. The NFVO is connected to multiple VNFMs and multiple VIMs and monitors those VNFMs and VIMs. In addition, when the NFVO receives a report indicating that a component in the virtualized environment has failed, it has the function of sending an auto-healing command to a component related to auto-healing in order to restore the failed VNF / CNF.

[0020] The NFVO, VNFM, and VIM constitute the Management and Orchestration (MANO), which has the management and orchestration functions for the virtualized environment.

[0021] OSS (Operations Support System) is a system (equipment, software, mechanisms, etc.) required by telecommunications carriers to build and operate services. BSS (Business Support System) is an information system (equipment, software, mechanisms, etc.) used by telecommunications carriers for charging, billing, customer support, etc. The OSS and BSS function in tandem and may be established as an inseparable unit. Hereinafter, "OSS / BSS" refers to a system that includes both the OSS and BSS, but the OSS and BSS may also be established separately. The OSS / BSS is connected to the NFVO and also to multiple EMSs.

[0022] In virtualized environments, some of the NFVO functions (including auto-healing control) may be performed by the OSS. When the OSS performs functions related to receiving auto-healing failure reports and issuing commands for auto-healing (control of auto-healing), the connection corresponding to the solid line between the OSS / BSS and the NFVO in the figure is used to receive reports and send commands. In other words, auto-healing control is performed by the OSS or NFVO. Hereinafter, "OSS / NFVO" means either the OSS or the NFVO.

[0023] The logical networks used to realize auto-healing are classified into networks highlighted with thick solid lines in Figures 1 to 6, and all of them are connected to the OSS / NFVO that controls auto-healing. The OSS / NFVO determines whether to implement auto-healing based on information obtained through these networks.

[0024] The thick solid lines in Figure 1 indicate a platform monitoring network (first logical network) 1 between the VIM and NFVI. Each VIM is connected to multiple NFVIs, and the NFVIs use network 1 to report failures in the hardware resources on which the VNFs / CNFs run. In other words, each VIM uses network 1 to monitor the NFVIs under its control.

[0025] The thick solid line in Figure 2 indicates a platform monitoring network (first logical network) 2 between the OSS / NFVO-VIM. The platform monitoring network 2 includes a network 2a between the NFVO and VIM. When the OSS controls auto-healing, the platform monitoring network 2 further includes a connection 2b between the OSS and the NFVO. The NFVO is connected to multiple VIMs, and each VIM uses network 2a to report hardware resource failures reported by the NFVI via platform monitoring network 1 to the NFVO. When the OSS controls auto-healing, the NFVO forwards the failure report to the OSS via connection 2b. In this way, the platform monitoring networks 1 and 2 are used to report failures in the hardware resources on which the VNFs / CNFs run.

[0026] The thick solid line in Figure 3 indicates the platform control network 3 between the OSS / NFVO-VIM. The platform control network 3 has a network 3a between the NFVO and VIM. When the OSS controls auto-healing, the platform control network 3 further has a connection 3b between the OSS and the NFVO. In other words, the platform control network 3 involves the same components as the platform monitoring network 2 in Figure 2. In auto-healing, the platform control network 3 is used to send commands to remove a faulty VNF / CNF and deploy other hardware resources for that VNF / CNF (create a VNF / CNF). When the OSS controls auto-healing, the OSS sends commands to the NFVO via connection 3b. The NFVO sends commands to the VIM corresponding to the faulty VNF / CNF via network 3a.

[0027] The thick solid lines in Figure 4 indicate an application monitoring network (second logical network) 4 between the EMS / VNFM and the VNF / CNF. "EMS / VNFM" means an EMS or a VNFM. The application monitoring network 4 has a network 4a between the VNFM and the VNF / CNF, and a connection 4b between the EMS and the VNF / CNF. Each VNFM is connected to multiple VNFs / CNFs and monitors the applications of the VNFs / CNFs it serves using network 4a. Each EMS is connected to a corresponding VNF / CNF and monitors the applications of that VNF / CNF via connection 4b. Application monitoring network 4 is used to report application failures. However, depending on the application product used in the virtualized environment, the network 4a or the connection 4b may not be used to report application failures.

[0028] 5 indicates an application monitoring network (second logical network) 5 between the OSS / NFVO-EMS / VNFM. The application monitoring network 5 has a network 5a between the NFVO and VNFM, a connection 5b between the OSS and EMS, and a connection 5c between the OSS and NFVO. The NFVO is connected to multiple VNFMs, and each VNFM reports VNF / CNF application failures detected via network 4a to the NFVO using network 5a. When the OSS controls autohealing, the NFVO forwards the failure report to the OSS via connection 5c. The OSS / BSS is connected to multiple EMSs, and each EMS reports VNF / CNF application failures detected via connection 4b to the OSS / BSS via connection 5b. If the OSS does not control autohealing, the OSS forwards the failure report to the NFVO via connection 5c. In this way, the application monitoring network 5 is used to report application failures. However, if network 4a is not used for application failure reporting, network 5a is not used for application failure reporting, and if connection 4b is not used for application failure reporting, connection 5b is not used for application failure reporting.

[0029] The thick solid lines in Fig. 6 indicate an application control network (third logical network) 6 between the OSS / NFVO-EMS / VNFM. The application control network 6 has a network 6a between the NFVO and VNFM, a connection 6b between the OSS and EMS, and a connection 6c between the OSS and NFVO. In other words, the application control network 6 involves the same components as the application monitoring network 5 in Fig. 5. In autohealing, the application control network 6 is used to provide configuration instructions to optimize the operation of the VNF / CNF created by the platform control network 3 in Figure 3 (i.e., to incorporate the VNF / CNF into operation). When the OSS controls auto-healing, the OSS provides an auto-healing command to the NFVO via connection 6c, and the NFVO forwards the command to the VNFM corresponding to the created VNF / CNF via network 6a. Alternatively, the OSS may provide an auto-healing command to the EMS corresponding to the created VNF / CNF via connection 6b. If the OSS does not control auto-healing, the NFVO provides an auto-healing command to the OSS via connection 6c, and the OSS forwards the command to the EMS corresponding to the created VNF / CNF via connection 6b. Alternatively, the NFVO may provide an auto-healing command to the VNFM corresponding to the created VNF / CNF via network 6a. However, if network 5a is not used for application failure reporting, network 6a is not used for application control in autohealing, and if connection 5b is not used for application failure reporting, connection 6b is not used for application control in autohealing.

[0030] The virtualized environments shown in Figures 1 to 6 may be used as a core network of a mobile network. As mentioned above, the VNF / CNF may function as an element of the EPC or an element of the IMS. Therefore, there is a network for applications (VNF / CNF) to provide services. The thick solid line in Fig. 7 indicates a mobile service network (fourth logical network) 7 used for mobile services in the virtualized environment. The mobile service network 7 connects the mobile network Mo and multiple VNFs / CNFs. The VNFs / CNFs communicate with the mobile network Mo via the mobile service network 7 and also communicate with each other via the mobile service network 7.

[0031] While the seven networks 1 to 7 above are logically separated, they may also be physically separated depending on the network design. Therefore, multiple logical networks may belong to the same physical network or to different physical networks.

[0032] Figure 8 is a diagram showing the platform monitoring network 1 in Figure 1, the platform monitoring network 2 in Figure 2, the application monitoring network 4 in Figure 4, and the application monitoring network 5 in Figure 5 from a different perspective. The networks 1, 2, 4, and 5 can be represented by the hierarchical structure shown in Figure 8.

[0033] Incidentally, when a failure occurs in a section of any of the logical networks 1 to 6, the connection in that section may be cut off. In this way, when a failure occurs in any of the logical networks 1 to 6, the OSS / NFVO may issue a command to execute auto-healing. However, service availability will be temporarily reduced from the time of the failure until auto-healing is completed (until the created VNF / CNF is incorporated into operation and the service can be resumed). On the other hand, even if a failure occurs in platform monitoring networks 1 and 2, which are used to report failures in the hardware resources on which the VNF / CNF runs, the VNF / CNF application (service) may still be operating normally. If a failure is reported from platform monitoring networks 1 and 2, and no failure is reported from the OSS / NFVO via application monitoring networks 4 and 5, it is highly likely that the VNF / CNF application is operating normally and there is simply a failure in the interface between one of the components involved in networks 1 and 2. While the interface failure may have to be addressed at some point, if the VNF / CNF application is operating normally, there is no need to implement auto-healing immediately.

[0034] Therefore, in this embodiment, in a network virtualization environment, a receiving process is performed to receive a signal supplied when a failure is detected in any of the logical networks 1, 2, 4, and 5, and a first judgment process is performed to determine not to perform auto-healing if a failure is detected in the platform monitoring networks 1 and 2 but not in the application monitoring networks 4 and 5. On the other hand, auto-healing may be performed if a failure is detected in the application monitoring networks 4 and 5, regardless of whether a failure is detected in the platform monitoring networks 1 and 2. However, in this case, the failure may simply be in the interface between one of the components involved in the networks 4 and 5. Therefore, as will be described later, further determination processing may be performed, and auto-healing may be performed if certain conditions are met.

[0035] In this embodiment, when a failure occurs in a network implemented in a virtualized environment, the type of network failure is taken into consideration and an appropriate decision is made as to whether or not to implement auto-healing. By suppressing unnecessary auto-healing, network availability is improved compared to when auto-healing is not suppressed.

[0036] If the application is operating normally and the service is being provided, no failure occurs in the mobile service network 7, and therefore the first determination process is not related to the mobile service network 7. The first determination process is also unrelated to the platform control network 3 and application control network 6, which are used to perform auto-healing. The platform control network 3 involves the same components as the platform monitoring network 2, but a failure in the platform monitoring network 2 does not necessarily mean that the platform control network 3 is faulty. The application control network 6 involves the same components as the application monitoring network 5, but a failure in the application monitoring network 5 does not necessarily mean that the application control network 6 is faulty. However, to perform auto-healing, it is necessary that the platform control network 3 and the application control network 6 are free from failures.

[0037] In this embodiment, a determination device is provided to determine whether or not auto-healing should be performed. Figures 9 to 12 show examples of the installation of the determination device. In the example of Figure 9, the decision device is provided in the OSS / BSS, which is preferable when the OSS controls auto-healing. In the example of Figure 10, the decision device is located in the NVFO, which is suitable when the OSS does not control autohealing. In the example of Figure 11, the decision device is connected to the OSS / BSS, which is preferable when the OSS controls the auto-healing. In the example of Figure 12, the decision device is connected to the NVFO, which is preferable if the OSS does not control autohealing.

[0038] As shown in FIG. 13, the determination device includes a CPU (Central Processing Unit), ie, a processor, a ROM (Read Only Memory), a RAM (Random Access Memory), an HDD (Hard Disk Drive), and a UI (User Interface). The ROM or HDD stores computer programs required for the operation of the determination device, and also stores data such as parameters required for the operation of the determination device. The CPU uses data stored in the ROM or HDD to execute a computer program stored in the ROM or HDD, and operates in accordance with the computer program.

[0039] RAM is used as a work area for the CPU. The UI may be a combination of a display device and a pointing device (e.g., a mouse or touchpad), or a touch panel that functions as both a display device and a pointing device. Using the UI, the user of the determination device can give instructions to the CPU. In the installation examples of Figures 11 and 12, the decision device has a communication interface (not shown) for communicating with the OSS or NVFO.

[0040] Figure 14 is a table showing the relationship between a network failure and the determination result of the determination device. The data corresponding to this table is stored in the ROM or HDD of the determination device. When the OSS / NFVO receives a report indicating that a failure has been detected in one of logical networks 1, 2, 4, or 5, the OSS / NFVO supplies a signal requesting a determination to the determination device. Upon receiving this signal, the CPU of the determination device can use the data corresponding to the table in Figure 14 to determine whether or not to perform auto-healing. As shown in Figure 14, failure patterns are classified into 16 depending on whether or not there is a failure (1 or 0) in each of the logical networks 1, 2, 4, and 5. In pattern 1, there is no failure in any of the networks 1, 2, 4, and 5, and no judgment result is given (the judgment device does not need to make a judgment). In patterns 2, 3, 4, 6, 7, 8, 10, 11, 12, 14, 15, and 16, there is a failure in at least one of the application monitoring networks 4 and 5, and the judgment result is B. In patterns 5, 9, and 13, there is a failure in at least one of the platform monitoring networks 1 and 2, but there is no failure in the application monitoring networks 4 and 5, and the judgment result is A.

[0041] If the judgment result is A, the VNF / CNF application is operating normally, so the CPU of the judgment device judges not to perform auto-healing. If the judgment result is B, there is a possibility that the VNF / CNF application is not operating normally. In this case, the CPU of the judgment device may decide to perform auto-healing. However, in this case, there may simply be a failure in the interface between one of the components involved in networks 4 and 5. Therefore, as will be described later, further judgment processing may be performed, and if certain conditions are met, it may be decided to perform auto-healing.

[0042] The sequence diagram in Fig. 15 shows an example of processing in a virtualized environment according to this embodiment. Fig. 15 corresponds to failure pattern 9 in Fig. 14. In FIG. 15, the operations enclosed in dashed rectangles are signal exchanges between components in networks 1, 2, 4, and 5. If the VIM cannot communicate with some NFVIs (servers), i.e., if a failure is detected in platform monitoring network 1, the VIM records that NFVI as unavailable. Then, the VIM sends a failure report to the OSS / NFVO via platform monitoring network 2. The failure report indicates that the NFVI is unavailable and that a failure has been detected in network 1.

[0043] Upon receiving the failure report, the OSS / NFVO records the failure report and transmits a decision request signal to the decision device requesting a decision on whether to perform auto-healing. The decision request signal includes information identifying the logical network in which the failure was detected. The decision request signal resulting from the failure report from the VIM includes information identifying that a failure was detected in network 1. When the judgment request signal is received, the CPU of the judgment device judges whether or not to perform auto-healing. In the case of fault pattern 9 in Figure 14, the judgment result is A. That is, the CPU of the judgment device judges not to perform auto-healing. The CPU of the determination device returns the determination result to the OSS / NFVO. Based on the determination result, the OSS / NFVO will either implement or refrain from implementing auto-healing. In the case of failure pattern 9 in Figure 14, the OSS / NFVO will refrain from implementing auto-healing.

[0044] The sequence diagram in Fig. 16 shows another example of processing in a virtualized environment according to this embodiment. Fig. 16 corresponds to failure pattern 5 in Fig. 14. The operations enclosed in dashed rectangles in FIG. 16 are signal exchanges between components in networks 1, 2, 4, and 5. If the OSS / NFVO cannot communicate with some VIMs, i.e., if a failure is detected in the platform monitoring network 2, the OSS / NFVO records that VIM as unavailable. The OSS / NFVO then sends a determination request signal to the determination device requesting a determination on whether to perform auto-healing. The determination request signal includes information identifying the logical network in which the failure was detected. If a failure is detected in the platform monitoring network 2, the determination request signal includes information identifying that the failure was detected in network 2. When the judgment request signal is received, the CPU of the judgment device judges whether or not to perform auto-healing. In the case of fault pattern 5 in Figure 14, the judgment result is A. That is, the CPU of the judgment device judges not to perform auto-healing. The CPU of the determination device returns the determination result to the OSS / NFVO. Based on the determination result, the OSS / NFVO will either implement or refrain from implementing auto-healing. In the case of failure pattern 5 in Figure 14, the OSS / NFVO will refrain from implementing auto-healing.

[0045] In the case of failure pattern 13 in FIG. 14, the sequence diagram is a combination of FIG. 15 and FIG. 16, which will be understood by those skilled in the art. If the decision device determines that auto-healing should be performed, the OSS / NFVO deletes the faulty VNF / CNF and deploys other hardware resources for that VNF / CNF (creates a VNF / CNF) via the platform control network 3. Then, the OSS / NFVO performs settings via the application control network 6 to optimize the operation of the created VNF / CNF (i.e., incorporate the VNF / CNF into operation).

[0046] Next, the determination operation of the CPU of the determination device will be described in more detail with reference to the flowchart of FIG. In step S1, the CPU determines whether or not it has received a determination request signal from the OSS / NFVO. If the determination in step S1 is affirmative, in step S2 the CPU determines whether the determination result is A or B. If the determination result is A, in step S3 the CPU returns a command not to perform auto-healing to the OSS / NFVO as the determination result.

[0047] If the judgment result is B (if a failure is detected in the application monitoring network 4 or 5), the CPU uses the application control network (third logical network) 6 to monitor the application and executes a first confirmation process to confirm whether a failure is detected in the application monitoring operation on the application control network 6. As described above, the application control network 6 involves the same components as the application monitoring network 5, so network 6 can be temporarily used to monitor the application. If no failure is detected in the application monitoring operation on network 6, it is presumed that there is no failure in network 5. If a failure is detected in the application monitoring operation on network 6, it is presumed that there is indeed a failure in the application monitoring network 5.

[0048] That is, if the determination result is B, the operation proceeds to step S4, and the CPU sends a command to the OSS / NFVO to divert the application control network 6 to application monitoring. In response to the command, the OSS / NFVO temporarily uses the network 6 to monitor the application. Specifically, the OSS / NFVO requests a response from a component (any VNFM) involved in the application control network 6 that corresponds to the failure detected in the application monitoring network 5, checks whether there is a response from that component, and returns the confirmation result to the CPU of the determination device. Additionally or instead, the OSS / NFVO checks whether a component (OSS / NFVO or any VNFM) involved in the application control network 6 that corresponds to the failure detected in the application monitoring network 5 detects any failure, and returns the confirmation result to the CPU of the determination device. Therefore, the first confirmation process of step S4 includes requesting a response from the component and checking whether there is a response from the component. Additionally or alternatively, the first confirmation process includes checking whether the component detects a fault.

[0049] Next, in step S5, the CPU determines whether a failure is detected in the application monitoring operation on the network 6. That is, in step S5, the CPU executes a second determination process. Specifically, if the confirmation result from the OSS / NFVO indicates that there was no response from the component, the determination result in step S5 is positive, and if the confirmation result indicates that there was a response from the component, the determination result in step S5 is negative. Additionally or alternatively, if the confirmation result from the OSS / NFVO indicates that some failure has been detected, the determination result in step S5 is positive, and if the confirmation result indicates that no failure has been detected, the determination result in step S5 is negative.

[0050] If the determination result in step S5 is positive, it is highly likely that the VNF / CNF application is not operating normally. Therefore, in step S6, the CPU returns an instruction to perform auto-healing to the OSS / NFVO as the determination result. In response to the instruction, the OSS / NFVO performs auto-healing.

[0051] If the determination result in step S5 is negative, the operation proceeds to step S7. In step S7, the CPU uses the mobile service network 7 shown in FIG. 7 to confirm whether a failure is detected in the mobile service network 7. That is, in step S7, the CPU executes a second confirmation process. Specifically, the CPU acquires the operation status of the VNF / CNF corresponding to the failure detected in the application monitoring networks 4 and 5 and other VNFs / CNFs that communicate via the mobile service network 7. The operation status can be acquired via the EMS / VNFM. The CPU sends a command to the OSS / NFVO to monitor the mobile service network 7, and the OSS / NFVO acquires the operation status of the target VNF / CNF via the EMS / VNFM and returns it to the CPU of the determination device. When a VNF / CNF application is operating normally, it is estimated that the operational status regarding mobile communications of other VNFs / CNFs that communicate with that VNF / CNF via the mobile service network 7 will not fluctuate significantly. However, when a VNF / CNF application is not operating normally, it is estimated that the operational status regarding mobile communications of other VNFs / CNFs that communicate with that VNF / CNF via the mobile service network 7 will fluctuate significantly.

[0052] Therefore, the second confirmation process of step S7 includes obtaining the operating status as an EPC or IMS of the VNF / CNF corresponding to the failure detected in the application monitoring network 4, 5 and other VNFs / CNFs that communicate via the mobile service network 7. Figure 18 is a table showing examples of monitoring items of the acquired operational status. Data corresponding to this table is stored in the ROM or HDD of the determination device. The accommodated user number decline rate is the decline rate over a specified period of the number of UE (User Equipment) for which the VNF / CNF provides mobile services. The packet loss rate increment is the increase rate over a specified period of the packet loss rate in the mobile service provided by the VNF / CNF. The CPS decline rate is the decline rate over a specified period of the CPS (Calls Per Second) in the mobile service provided by the VNF / CNF.

[0053] Next, in step S8, the CPU determines whether the VNF / CNF is operating normally. That is, in step S8, the CPU executes a third determination process in which it determines not to perform auto-healing if no fault is detected in the second confirmation process, and determines to perform auto-healing if a fault is detected in the second confirmation process. For example, if the rate of decline in the number of accommodated users exceeds threshold T1, the determination in step S8 is negative. If the packet loss rate increase exceeds threshold T2, the determination in step S8 is also negative. If the CPS decline rate exceeds threshold T3, the determination in step S8 is also negative. If the determination in step S8 is negative, it is presumed that a failure has actually occurred in the VNF / CNF corresponding to the failure detected in the application monitoring networks 4 and 5. Therefore, the operation proceeds to step S6, and the CPU returns an instruction to perform auto-healing to the OSS / NFVO as the determination result. In response to the instruction, the OSS / NFVO performs auto-healing.

[0054] 18 does not exceed its threshold, it is estimated that no failure has actually occurred in the VNF / CNF corresponding to the failure detected in the application monitoring networks 4 and 5. In this case, the determination in step S8 is affirmative, the operation proceeds to step S3, and the CPU returns a command not to perform auto-healing to the OSS / NFVO as the determination result.

[0055] As described above, if the above judgment result is B (if a failure is detected in the application monitoring network 4 or 5), operation proceeds to steps S4, S5, and then steps S7 and S8, so if the VNF / CNF application is actually operating normally, unnecessary auto-healing can be suppressed. However, steps S4 and S5 may be omitted. In this case, if the determination in step S2 is negative, the operation proceeds directly to step S7. Steps S7 and S8 may be omitted. In this case, if the determination in step S5 is negative, the operation proceeds directly to step S6.

[0056] While the present disclosure has been shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that changes in form and detail may be made therein without departing from the scope of the appended claims, and such changes, modifications and alterations are intended to be within the scope of the present disclosure.

[0057] Aspects of the present disclosure are also described in the following numbered clauses:

[0058] [1] In a network virtualization environment, a receiving process receives a signal that is provided when a fault is detected in one of a plurality of logical networks; a first determination process for determining not to perform auto-healing when a failure is detected in a first logical network for platform monitoring and a failure is not detected in a second logical network for application monitoring; At least one processor to run A network management device comprising:

[0059] [2] When a failure is detected in the second logical network, the processor performs a first confirmation process of using a third logical network for application control, which involves the same components as the second logical network and is used for auto-healing in the virtualization environment, to monitor the application and confirming whether a failure is detected in the application monitoring operation on the third logical network; a second determination process for determining to perform auto-healing when a failure is detected in the monitoring operation of the application on the third logical network in the first confirmation process; The network management device according to [1] further executes the following.

[0060] [3] The first confirmation process includes requesting a response from a component involved in the third logical network corresponding to the failure detected in the second logical network, and confirming whether or not there is a response from the component. The network management device according to [2].

[0061] [4] The first confirmation process includes confirming whether a component related to the third logical network corresponding to the failure detected in the second logical network detects a failure. The network management device according to [2] or [3],

[0062] [5] When a failure is detected in the second logical network, the processor performs a second confirmation process of using a fourth logical network used for mobile services in the virtualization environment to confirm whether a failure is detected in the fourth logical network; and a third determination process for determining not to perform auto-healing if a failure is not detected in the fourth logical network in the second confirmation process, and for determining to perform auto-healing if a failure is detected in the fourth logical network in the second confirmation process; The network management device according to any one of [1] to [4], further comprising:

[0063] [6] The second confirmation process includes acquiring an operation status of a VNF or a CNF that communicates with a VNF or a CNF corresponding to the failure detected in the second logical network via the fourth logical network. The network management device according to [5].

[0064] [7] In a network virtualization environment, receiving a signal that is provided when a failure is detected in one of multiple logical networks; If a failure is detected in the first logical network for platform monitoring and a failure is not detected in the second logical network for application monitoring, it is determined not to perform auto-healing. Network management methods, including: [Explanation of symbols]

[0065] 1...Platform monitoring network (first logical network), 2...Platform monitoring network (first logical network), 3...Platform control network, 4...Application monitoring network (second logical network), 5...Application monitoring network (second logical network), 6...Application control network (third logical network), 7...Mobile service network (fourth logical network), Mo...Mobile network

Claims

1. a receiving process for receiving a signal provided when a failure is detected in any of a plurality of logical networks in a network virtualization environment; a first determination process for determining not to perform auto-healing when a failure is detected in a first logical network for platform monitoring and a failure is not detected in a second logical network for application monitoring; At least one processor that runs A network management device comprising:

2. a first confirmation process in which, when a failure is detected in the second logical network, the processor uses a third logical network for application control, which involves the same components as the second logical network and is used for autohealing in the virtualized environment, to monitor an application, and confirms whether a failure is detected in the application monitoring operation on the third logical network; a second determination process for determining to perform auto-healing when a failure is detected in the monitoring operation of the application on the third logical network in the first confirmation process; The network management device according to claim 1, further comprising:

3. The first confirmation process includes requesting a response from a component involved in the third logical network corresponding to the failure detected in the second logical network, and confirming whether or not there is a response from the component.

3. The network management device according to claim 2.

4. The first confirmation process includes confirming whether a component involved in the third logical network corresponding to the failure detected in the second logical network detects a failure.

4. The network management device according to claim 2 or 3.

5. a second confirmation process in which, when a failure is detected in the second logical network, the processor uses a fourth logical network used for mobile services in the virtualization environment to confirm whether a failure is detected in the fourth logical network; a third determination process for determining not to perform auto-healing if a failure is not detected in the fourth logical network in the second confirmation process, and for determining to perform auto-healing if a failure is detected in the fourth logical network in the second confirmation process; 3. The network management device according to claim 1, further comprising:

6. The second confirmation process includes acquiring an operation status of a VNF or a CNF that communicates with a VNF or a CNF corresponding to the failure detected in the second logical network via the fourth logical network.

6. The network management device according to claim 5.

7. receiving a signal provided when a fault is detected in one of a plurality of logical networks in a network virtualization environment; and determining not to perform auto-healing when a failure is detected in the first logical network for platform monitoring and no failure is detected in the second logical network for application monitoring. Network management methods, including:

Images