Automation of approval in chang of virtualized environment of network

Abstract

To promptly and accurately approve a change.SOLUTION: A processor acquires a present change application of a virtualized environment of a network and, in a case where a determination reference matching values of comparison items included in the present change application is not discovered in a determination reference management database, automatically refuses the present change application. In a case where a determination reference matching the values of the comparison items is discovered in the determination reference management database, the processor retrieves a history of past changes matching the determination reference (execution results of past changes executed in accordance with the same type of past change applications as the present change application). In a case where the execution results of the past changes are not discovered, the processor automatically refuses the present change application. In a case where an execution result of the past change is discovered, the processor automatically approves the present change application if a predetermined condition relating to the execution result of the past change is satisfied, or automatically refuses the present change application if the predetermined condition is not satisfied.SELECTED DRAWING: Figure 15

Description

[Technical Field]

[0001] The present disclosure relates to automating approvals for changes in a network virtualization environment. [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] When making any changes to the operation of a network virtualization environment, an approval process is generally established to determine whether or not the change can be implemented, in order to prevent accidents, etc. The purposes for making changes in the operation of a network virtualization environment can be broadly divided into two categories: 1. Changes performed for planned maintenance purposes such as patching, software upgrades, and hardware replacements. 2. Changes to recover after a problem occurs.

[0005] Changes to be applied to the above-mentioned commercial environment are generally verified in a test environment in advance and submitted only after confirming that there are no problems. However, because the virtualized environments used in mobile networks are large-scale, it is extremely difficult from a cost perspective to build a test environment equivalent to a commercial environment. Therefore, even if no problems are confirmed in the test environment, problems may arise in the commercial environment. Therefore, when approving change applications, it is necessary to have people with high technical skills, extensive experience, and excellent judgment as change approvers.

[0006] When changes are made for the reason stated above, approval of the changes can take a huge amount of time and effort due to the large number and / or variety of changes. In addition, similar changes may be requested multiple times, which again requires a lot of time for approval. When changes are made for the reason mentioned above, the types and number of changes are usually small, but a decision on whether to implement them is required quickly in order to resolve the issue quickly. In other words, approval is required quickly within a limited time frame.

[0007] Therefore, the present disclosure provides a technique that can quickly and accurately approve changes to a network virtualization environment. [Means for solving the problem]

[0008] One aspect of the present disclosure provides a network management device, the network management device having at least one processor. The processor obtains the current change request from a change request management database that stores change requests for a network virtualization environment, extracts the value of a comparison item included in the current change request, searches for a judgment criterion that matches the value of the comparison item in a judgment criterion management database that stores judgment criteria, and automatically rejects the current change request if no judgment criterion that matches the value of the comparison item is found in the judgment criterion management database.If a judgment criterion that matches the value of the comparison item is found in the judgment criterion management database, the processor searches for execution results of past changes that were executed in response to past change requests of the same type as the current change request, which is a history of past changes that match the judgment criterion, in a change history management database that stores a history of changes executed in response to past change requests.If no execution results of the past changes are found in the change history management database, automatically rejects the current change request.If execution results of the past changes are found in the change history management database, the processor determines whether a predetermined condition related to the execution results of the past changes is met, and if the predetermined condition is met, automatically approves the current change request, and if the predetermined condition is not met, automatically rejects the current change request.

[0009] One aspect of the present disclosure provides a network management method, which includes: acquiring a current change request from a change request management database that stores change requests for a virtualized environment of a network; extracting a value of a comparison item included in the current change request; searching for a judgment criterion that matches the value of the comparison item in a judgment criterion management database that stores judgment criteria; automatically rejecting the current change request if no judgment criterion that matches the value of the comparison item is found in the judgment criterion management database; and, if the judgment criterion that matches the value of the comparison item is found in the judgment criterion management database, automatically rejecting the current change request. searching for execution results of past changes executed in response to past change requests of the same type as the current change request, which is a history of past changes that meet the judgment criteria; automatically rejecting the current change request if the execution results of the past changes are not found in the change history management database; determining whether or not predetermined conditions related to the execution results of the past changes are met if the execution results of the past changes are found in the change history management database; automatically approving the current change request if the predetermined conditions are met; and automatically rejecting the current change request if the predetermined conditions are not met. [Effects of the Invention]

[0010] In an aspect of the present disclosure, if a judgment criterion matching the comparison item included in the current change request is stored, the execution results of a similar change that was previously executed are searched for. If the execution results of the previous change are found, it is determined whether a predetermined condition related to the execution results of the previous change is satisfied. If the predetermined condition is satisfied, the current change request is automatically approved. In this way, the decision on whether to approve the current change request is based on the execution results of the same type of previous change, allowing for quick and accurate approval of changes to the network virtualization environment. [Brief explanation of the drawings]

[0011] [Figure 1] Figure 1 is a block diagram illustrating components in a network virtualization environment defined by ETSI NFV. [Figure 2] FIG. 2 is a diagram illustrating an example of installation of an approval device according to the present disclosure. [Figure 3] FIG. 3 is a diagram showing another example of installation of the approval device according to the present disclosure. [Figure 4] FIG. 4 is a block diagram illustrating an example of a hardware configuration of the approval device. [Figure 5] FIG. 5 is a block diagram showing an example of the hardware configuration of the approval device from another perspective. [Figure 6] FIG. 6 is a table showing an example of an application for changing a network virtualization environment. [Figure 7] FIG. 7 is a table showing an example of a change history of a network virtualization environment. [Figure 8] FIG. 8 is a table showing an example of criteria for automatic approval of a change request. [Figure 9] FIG. 9 is a table showing another example of the criteria for automatic approval of a change request. [Figure 10] FIG. 10 is a table showing another example of criteria for automatic approval of a change request. [Figure 11] FIG. 11 is a table showing another example of the criteria for automatic approval of a change request. [Figure 12] FIG. 12 is a sequence diagram showing a basic example of the process of registering a change request, the process of registering change approval, and the process of executing a change in a network virtualization environment according to the present disclosure. [Figure 13] FIG. 13 is a sequence diagram illustrating an example of a process for registering a determination criterion in a network virtualization environment according to the present disclosure. [Figure 14] FIG. 14 is a sequence diagram illustrating an example of a process for registering a change request and a process for automatically approving the change request in a network virtualization environment according to the present disclosure. [Figure 15] FIG. 15 is a continuation of FIG. [Figure 16]FIG. 16 is a flowchart showing the details of the determination of whether to allow automatic approval of the change request in FIG. [Figure 17] FIG. 17 is a sequence diagram showing the learning process of the learning model according to the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

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

[0013] Figure 1 is a block diagram illustrating 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. Furthermore, when the NFVO receives a report indicating that the processing load of a component in the virtualized environment exceeds the allowable value, the NFVO has the function of sending an auto-scaling command to a component related to auto-scaling in order to automatically add a new 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] As mentioned above, the VNF / CNF may function as an element of the EPC or an element of the IMS for a mobile service. Therefore, there exists a network for applications (VNF / CNF) to provide services.,The thick solid line in Fig. 7 indicates the network for mobile services,used for mobile services in a virtualized environment. The mobile service network connects the mobile network Mo and multiple VNFs / CNFs. The VNFs / CNFs communicate with the mobile network Mo via the mobile service network and communicate with each other via the mobile service network.

[0023] In this embodiment, an approval device is provided that automatically approves an application for a change to the virtualization environment when the change is requested. Figures 2 and 3 each show an example of the installation of the approval device. In the example of FIG. 2, the authorization device is provided inside the OSS / BSS. In the example of FIG. 3, an authorizing device is connected to an OSS / BSS.

[0024] As shown in FIG. 4, the approval device has 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 approval device, as well as data such as parameters required for the operation of the approval 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.

[0025] 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 authorization device can give instructions to the CPU. In the installation example of FIG. 3, the authorizing device has a communication interface (not shown) for communicating with the OSS or NVFO.

[0026] 5 is a block diagram showing an example of the hardware configuration of the approval device from another perspective. The approval device has a determination unit, a change application management database, a change history management database, and a determination criteria management database. The determination unit corresponds to the CPU in FIG.

[0027] The change application management database, change history management database, and judgment criteria management database are stored in the HDDs shown in Fig. 4. These databases may be stored on a single HDD or on multiple HDDs. The change request management database is where requests for changes to the network virtualization environment are registered. The requester of the change sends the change request to the OSS, which then registers the change request in the change request management database. The change history management database stores the history of changes that have been made in response to past change requests. When a change is made, regardless of whether the change was successful or not, the OSS registers the change history, including the results of the change, in the change history management database.

[0028] The criteria management database stores multiple criteria used to determine whether a change request should be automatically approved or rejected. A change approver, who is the person who normally approves change requests, registers the criteria in the criteria management database. The criteria have comparison items that may be common to the change request and the change history. The judgment unit obtains a change request from the change request management database, and if the judgment criteria management database contains stored judgment criteria that match the comparison items included in the change request, it searches the change history management database for past change history that match the judgment criteria (the results of similar changes that were executed in the past). If the results of past changes are found, the judgment unit determines whether predetermined conditions related to the results of the past changes are met. If the predetermined conditions are met, the judgment unit automatically approves the change request, and if the predetermined conditions are not met, the judgment unit automatically rejects the change request. In this way, the judgment unit determines whether to approve the change request based on the results of similar past changes, allowing for quick and accurate approval of changes to the network virtualization environment.

[0029] The judgment criteria management database may store a learning model for assisting the judgment unit in approving change requests.

[0030] With reference to FIG. 6, an example of items included in a change application registered in the change application management database will be described. The ID is used to uniquely identify and manage changes. The ID is assigned to a change request by the system every time a new change request is created. The change group name is used to identify and manage changes of the same type. An example of a change of the same type would be a firmware update for a patch to the same hardware. For example, multiple identical changes may be made, but only in different regions and at different times. In this case, multiple change requests with different IDs are registered in the change request management database, but the same change group name allows them to be identified as the same type of change. Priority / Urgency indicates the priority and urgency of the change. Priority and urgency are determined in accordance with the rules of the system management company. For example, "P1" indicates the highest priority and urgency, and "P4" indicates the lowest priority and urgency. The impact indicates the degree of impact on existing services caused by the change. For example, "Major" indicates a large impact, "Minor" indicates a small impact, and "No impact" indicates no impact.

[0031] The target domain indicates the target domain where the change is to be implemented. For example, "Infra" indicates infrastructure, "RAN" indicates radio access network, and "Core" indicates core network. The type of hardware indicates the model number of the hardware to be replaced or the model number of the hardware to which the software or firmware update is applied. Examples of hardware include a server, a CPU, memory, an HDD, an SSD (Solid State Drive), and a NIC (Network Interface Card). One change request may specify multiple pieces of hardware. The firmware version indicates the version of the firmware to be updated in the hardware. Examples of firmware include a BMC (Baseboard Management Controller), a BIOS (Basic Input Output System), and a RAID (Redundant Array of Inexpensive Disks) controller. One change request may specify multiple firmware. The software version indicates the version of the software to be updated in the hardware. Examples of software include an operating system (OS), a platform, an application, and a device driver. One change request may specify multiple pieces of software.

[0032] The change procedure explanation, scheduled start time, scheduled end time, and list of anticipated defects are referenced not only by the person who approves the change but also by the person who implements the change. The change procedure description is a string of characters that describes the procedure for implementing the change, and may include a guide image to make the procedure easier to understand, if necessary. If an execution program is used to implement the change, the value of the change procedure description includes the version of the execution program used to implement the change. The change implementer implements the change while referring to the value of the change procedure description. The scheduled start time indicates the scheduled date and time when the change will start. The change executor starts the change at the scheduled start time. The scheduled end time indicates the scheduled date and time when the change is to be completed. The change maker completes the change at or by the scheduled end time. The list of expected defects contains a list of all defects that are expected to occur during the implementation of the change. The person implementing the change will refer to the list of expected defects and implement the change in a way that avoids the defects.

[0033] Referring to Figure 7, an example of items contained in the change history registered in the change history management database will be described. When a change is executed, regardless of whether the change is successful or unsuccessful, the OSS registers the change history, including the execution results, in the change history management database. At this time, the OSS adds the actual execution results to the change request to generate the change history. Therefore, many of the items contained in the change history are the same as the items contained in the change request in Figure 6. Specifically, the ID, change group name, priority / urgency, impact, target domain, hardware type, firmware version, software version, change procedure description, scheduled start time, scheduled end time, and list of anticipated defects are carried over from the change request.

[0034] On the other hand, the list of defects, start time, end time, execution result explanation, and success / failure flag are not included in the change request, but are included in the change history. These are notified to the OSS by the component that has the change target, or by the change executor. The list of defects that occurred should include all defects that actually occurred when the change was implemented. The start time indicates the date and time when the change actually started. The end time indicates the date and time when the change actually ended. The execution result explanation should include a log or other information that confirms the execution result. The success / failure flag indicates whether the change was successful or not, for example, "O" indicates success and "1" indicates failure.

[0035] 8 to 11 show examples of criteria for automatic approval of change requests. These criteria are stored in a criteria management database. Each example of the criteria includes the change group name, priority / urgency, impact, target domain, hardware type, firmware version, software version, and success count threshold. In the criteria, the change group name, priority / urgency, impact, target domain, hardware type, firmware version, and software version are comparison items. The comparison items are used to determine whether there are any criteria that should be applied to a change request. The comparison items are included in a change request (see Figure 6), and if the values ​​of all the comparison items included in a change request match the comparison items of a certain criterion stored in the criteria management database, that criterion is applied to that change request. Comparison items are also included in the change history (see Figure 7). If there are judgment criteria to be applied to a change request, the change history management database is searched for change history with comparison items that match all of the comparison items of the judgment criteria. Change history with comparison items that match all of the comparison items of the judgment criteria is the execution result of past changes that were executed in response to past change requests of the same type as the change request. Therefore, comparison items are items for searching the execution result of past changes that were executed in response to past change requests of the same type as the change request.

[0036] In the criteria, the change group name is used to identify and manage changes of the same type, similar to change requests. In the criteria, the change group name value may have multiple change group names. In the criteria, the priority / urgency values ​​may have a range of priority / urgency as shown in Figures 8 and 9, or may have a specific priority / urgency value as shown in Figure 10. For example, if a certain change request has a priority / urgency value of P1 or P2, the criteria in Figure 8 may match that change request, but the criteria in Figures 9 and 10 do not match that change request. Also, for example, if a certain change request matches the criteria in Figure 9, a change history with a priority / urgency value of P3 or P4 is searched for in the change history management database.

[0037] In the criteria, the value of the impact may have a range of impact as shown in FIGS. 8 and 9, or may have a specific impact value as shown in FIG. In the judgment criteria, the value of the target domain indicates the target domain, as in the change request.

[0038] In the criteria, the value of the hardware type indicates, as in the change request, the model number of the hardware to be replaced, or the model number of the hardware to which the software or firmware update is applied. In the criteria, the firmware version may have a range of versions as shown in FIGS. 8 and 9, or may have a specific version value as shown in FIG. In the criteria, the software version may have a version range as shown in FIG. 8, or may have a specific version value as shown in FIG.

[0039] In a criterion, it is not necessary to specify values ​​for all comparison items. For example, in Figure 10, the value of the software version is empty. Comparison items with no specified values ​​function as wildcards, and regardless of the value of that comparison item in the change request, the value of that comparison item in the criterion will match the value of that comparison item in the change request. Also, for comparison items with no specified criterion values, regardless of the value of that comparison item in the change history, the value of that comparison item in the change history will match the value of that comparison item in the criterion. As shown in Figure 11, only one comparison item may have a value. In this case, if a change request has a change group name value of Patch application 3, the change request meets the judgment criteria illustrated in Figure 11, regardless of the other items in the change request. Also, in this case, if a change history has a change group name value of Patch application 3, the change history meets the judgment criteria illustrated in Figure 11, regardless of the other items in the change history.

[0040] In addition to the comparison items, the judgment criteria also include a success count threshold. The success count threshold is a criterion for whether or not to automatically approve a change request. Specifically, if the number of successful past changes executed in response to past change requests of the same type as the change request is less than the success count threshold, the change request is automatically rejected. If the number of successful past changes of the same type executed is equal to or greater than the success count threshold and there have been no failures in the past changes of the same type executed, the change request is automatically approved.

[0041] 12 shows basic examples of process A for registering a change request, process B for registering approval of a change request, and process C for executing a change in a network virtualization environment according to the present disclosure. In the example of Fig. 12, process B for registering approval of a change request is approved by a change approver rather than automatically approved. 12 to 15, DB indicates a database.

[0042] In process A of registering a change request, the change requester sends a change request registration request to the OSS from his / her own communication device (e.g., a computer). The change request registration request includes the change request shown in Figure 6. The OSS forwards the change request registration request to the approval device, which then registers the change request in the change request management database. Thereafter, the approval device returns a change application registration completion notification to the OSS, and the OSS forwards the change application registration completion notification to the communication device of the change applicant. In this way, a plurality of change applications are accumulated in the change application management database.

[0043] In process B of registering approval of a change request, the change approver checks each change request stored in the change request management database. If there is a defect in the change request, the change approver rejects the change request and communicates the rejection of the change request and the reason for the rejection from his / her own communication device (e.g., a computer) to the communication device of the change requester. When the change approver approves the change request, the change approver sends a change approval notice to the OSS from his / her own communication device. The OSS forwards the change approval notice to the approval device, which then registers the change request as approved in the change request management database. Registering approval may involve, for example, deleting the change request from the change request management database. The approval device then returns a change approval completion notification to the OSS, and the OSS forwards the change approval completion notification to the communication device of the change approver. Upon receiving the change approval completion notification, the change approver transmits an approval notification from his / her own communication device to the change executor. The approval notification includes the change request.

[0044] Upon receiving the approval notification, in change execution process C, the change executor sends a change execution request to the OSS from their own communication device (e.g., a computer). The change execution request includes a change application. The OSS forwards the change execution request to the NFVO, VNFM, or VIM that has jurisdiction over the VNF, CNF, or NFVI that has the change target, and the NFVO, VNFM, or VIM forwards the change execution request to the VNF, CNF, or NFVI. Upon receiving the change execution request, the VNF, CNF, or NFVI executes the change. The VNF, CNF, or NFVI then sends a change completion notification back to the NFVO, VNFM, or VIM, which forwards the change completion notification to the OSS. Upon receiving the change completion notification, the OSS sends an execution result registration request to the approval device. The execution result registration request includes the change history shown in Figure 7. The approval device registers the change history in the change history management database. The approval device then returns an execution result registration completion notification to the OSS, which then sends a change completion notification to the communication device of the change executor.

[0045] By repeating the process B of registering approval of the change request and the process C of executing the change, multiple change histories are accumulated in the change history management database. In the change execution process C in Figure 12, it is assumed that the VNF, CNF, or NFVI has the change target. However, if the NFVO, VNFM, or VIM has the change target, the change is executed in the NFVO, VNFM, or VIM, and after the change is completed, the NFVO, VNFM, or VIM returns a change completion notification to the OSS. In change execution process C in Figure 12, it is assumed that the change is automatically executed in the component that has the change target. In this case, the component includes a list of occurred defects, start time, end time, and an explanation of the execution result in the change completion notification that it returns. However, if the change maker replaces the hardware of a component in the virtualized environment, the change maker will go to the necessary location to perform the change work. In this case, the change maker sends a change completion notification including a list of occurred defects, start time, end time, and an explanation of the execution result from its own communication device on behalf of the component to the OSS, and the OSS sends an execution result registration request including a change history including these items to the approval device.

[0046] FIG. 13 shows an example of process D for registering criteria in a network virtualization environment according to the present disclosure. In process D, when a change approver generates the criteria exemplified in FIGS. 8 to 11, the change approver uses his / her own communication device to send a criteria registration request to the OSS. The criteria registration request includes the criteria. The OSS forwards the criteria registration request to the approval device, and the approval device registers the criteria in the criteria management database. The approval device then returns a notification of completion of the criteria registration to the OSS, which then forwards the notification to the communication device of the change approver. In this way, a plurality of criteria are stored in the criteria management database.

[0047] Next, the process of automatically approving a change request in a network virtualization environment according to the present disclosure will be described with reference to FIGS. To execute the automatic approval process for a change request, the change execution process C in FIG. 12 must be executed a sufficient number of times, and the criteria registration process D in FIG. 13 must also be executed a sufficient number of times.

[0048] When process A for registering the change request is completed and the OSS transfers a notification of completion of the change request registration to the communication device of the change requester, the process for automatically approving the change request begins. In the automatic approval process for a change request, the OSS first sends an automatic approval request to the approval device. Then, the decision unit (that is, the CPU) of the approval device reads (obtains) the change application (the current change application) registered in the change application registration process A from the change application management database.

[0049] The decision unit of the approval device extracts the values ​​of all comparison items included in the read current change request, and then searches the decision criteria management database for decision criteria having comparison item values ​​that match the values ​​of the comparison items extracted from the current change request. Next, in step D1, the judgment unit determines whether a judgment criterion is found whose value of a comparison item matches the value of the comparison item extracted from the current change request. If no judgment criterion is found, the judgment unit automatically rejects the current change request and sends a rejection notice to the OSS. The OSS (a communication device that communicates with the network management device) that receives the rejection notice sends an approval request to the communication device of the change approver. Therefore, if the change request is automatically rejected, the change approver can know that he or she must approve the change request. In response to the approval request, the change approver can check the current change request. That is, process B of registering approval of the change request in Figure 12 is executed.

[0050] When the judgment criterion is found, the judgment unit searches the change history management database for past change history (the execution results of past changes executed in response to past change requests of the same type as the current change request) that has a value of a comparison item that matches the value of the comparison item of the judgment criterion. Next, in step D2 (FIG. 15), the determination unit determines whether a past change history has been found. If a past change history has not been found, the determination unit automatically rejects the current change request and sends a rejection notice to the OSS. Upon receiving the rejection notice, the OSS sends an approval request to the communication device of the change approver. If a past change history is found, the determination unit determines whether to allow automatic approval in step D3. Specifically, the determination unit determines whether a predetermined condition related to the execution result of the past change is satisfied.

[0051] If the predetermined conditions are not met, the determination in step D3 is negative, and the determination unit automatically rejects the change request and sends a rejection notice to the OSS. The OSS, upon receiving the rejection notice, sends an approval request to the communication device of the change approver. Therefore, the change approver knows that he or she must approve the change request.

[0052] If the predetermined conditions are met, the determination in step D3 is affirmative, and the determination unit automatically approves the change request and sends an approval notice to the OSS. Upon receiving the approval notice, the OSS sends a change approval notice to the approval device, which then registers that the change request has been approved in the change request management database. Registering that the change request has been approved may, for example, involve deleting the change request from the change request management database. The approval device then returns a change approval completion notification to the OSS. The OSS (a communication device that communicates with the network management device) then sends an approval notification to the communication device of the change maker. Therefore, if the change request is automatically approved, the change maker can know that the change request has been approved. The approval notification includes the change request. In response to the approval notification, change execution process C in Figure 12 is executed.

[0053] In this way, whether or not to approve a current change request is determined based on the results of past execution of similar changes, so changes to the network virtualization environment can be approved quickly and accurately.

[0054] Next, the determination of whether to permit automatic approval of the change request (step D3) in FIG. 15 will be described in detail with reference to the flowchart in FIG. First, in step S1, the judgment unit references the values ​​of the success / failure flags of past change histories (execution results of past changes executed in response to past change requests of the same type as the current change request) found in the change history management database, and judges whether the number of successful changes of the same type is equal to or greater than the success count threshold specified in the judgment criteria. If the number of past change histories with the success / failure flag value "0" (success) is equal to or greater than the success count threshold specified in the judgment criteria, the judgment in step S1 is positive; otherwise, the judgment is negative.

[0055] If the determination in step S1 is positive, the operation proceeds to step S2. In step S2, the determination unit refers to the value of the past change history success / failure flag and determines whether there has been a failure in the same type of change. If at least one past change history with a success / failure flag value of "1" (failure) is found, the determination in step S2 is positive; otherwise, the determination is negative. If the determination in step S2 is negative, the operation proceeds to step S3, where the determination unit allows automatic approval and the operation ends. On the other hand, if the determination in step S1 is negative, the operation proceeds to step S4. In step S4, the determination unit rejects automatic approval, and the operation ends. That is, the current change request is automatically rejected.

[0056] Therefore, the judgment unit refers to the execution results of past changes executed in response to past change requests of the same type as the current change request, and automatically rejects the current change request if the number of successful past changes is less than a threshold, and automatically approves the current change request if the number of successful past changes is equal to or greater than the threshold and there have been no failures in the past changes. If the number of successful past changes executed in response to past change requests of the same type as the current change request is equal to or greater than the threshold and there have been no failures in the past changes, there is a high possibility that the changes executed in response to the current change request will be successful. In this case, the current change request can be quickly and automatically approved.

[0057] If the determination in step S2 is positive (i.e., the number of successful past changes is equal to or greater than the threshold value and there is a failure in the past changes), the operation proceeds to step S5. In step S5, the determination unit compares the value of the list of expected defects for the current change request with the value of the list of defects that occurred in all past failed change histories, and determines whether the expected defects in the current change request include all of the defects that occurred in the past failed changes. If the determination in step S5 is negative (if the problems expected in the current change request do not include all of the problems that occurred in the previous failed change), the operation proceeds to step S4, where the determination unit rejects automatic approval. That is, the current change request is automatically rejected. If the anticipated defects in the current change request are insufficient compared to the defects that occurred in previous failed changes, there is a high possibility that the current change request is flawed. For example, a previous change may have caused an unexpected defect, but the current change request may not have taken that defect into consideration. In such a case, even if the change is executed according to the current change request, there is a high possibility that the change will fail, so the change requester must revise the change request. If the above deficiency is not a defect in the change request, further identification of the cause is required, so the change request must be reviewed by the change approver and change requester, etc. Automatically rejecting the current change request can encourage the personnel involved in the change to take action.

[0058] If the determination in step S5 is affirmative, the operation proceeds to step S6. In step S6, the determination unit refers to the change procedure description and execution result description of the failed past change history, and determines whether the past failure was caused by human error based on the values ​​of the change procedure description and execution result description for the failed past change. This determination may take into account the difference between the estimated time required for the change (the difference between the scheduled start time and the scheduled end time) and the time actually required for the change (the difference between the start time and the end time). In the determination of step S6, the determination unit preferably uses a determination policy generated by a learning model (see FIG. 5) stored in the determination criteria management database. That is, the determination unit preferably determines whether or not a past failure was caused by human error in accordance with the determination policy. As will be described later, the determination policy reflects multiple determination patterns used by a human change approver to determine whether or not a past failure was caused by human error based on a change procedure description and an execution result description for a failed past change.

[0059] If the determination in step S6 is affirmative (if it is determined that the past failure was caused by human error), the operation proceeds to step S4, where the determination unit rejects automatic approval, i.e., the current change request is automatically rejected. If a past failure was caused by a human error by the person who performed the change, there is a high possibility that the same failure will occur even if the change is executed in accordance with the current change request. Therefore, the change approval person must improve the change execution procedure, etc. By automatically rejecting the current change request, it is possible to prompt the personnel involved in the change to take measures.

[0060] If the determination in step S6 is negative, the operation proceeds to step S7, where the determination unit refers to the change procedure description and execution result description of the past failed change history and determines whether the past failure was caused by a defect in the change procedure description or a defect in the execution program used to execute the past failed change. In the determination of step S7, the determination unit preferably uses a discovery policy generated by a learning model stored in the determination criteria management database. That is, the determination unit preferably determines, in accordance with the discovery policy, whether a past failure was caused by an incomplete change procedure description or an incomplete execution program used to execute the past failed change. As will be described later, the discovery policy reflects multiple discovery patterns by which a human change approver discovered the incomplete change procedure description or the incomplete execution program.

[0061] If the determination in step S7 is negative (if it is determined that the past failure was not caused by an incomplete change procedure description or an incomplete execution program used to execute the past failed change), the operation proceeds to step S4, where the determination unit rejects automatic approval, i.e., the current change request is automatically rejected. If it is determined that the past failure was not caused by an inadequate explanation of the change procedure or a defect in the execution program, the cause of the past failure is unknown, and there is a high possibility that the same failure will occur even if the current change is carried out. Therefore, some kind of action must be taken by the person requesting the change. By automatically rejecting the current change request, it is possible to prompt the personnel involved in the change to take action.

[0062] If the determination in step S7 is affirmative (if it is determined that the past failure was caused by an incomplete change procedure description or an incomplete execution program used to execute the past failed change), the operation proceeds to step S8. In step S8, the judgment unit compares the value of the change procedure description for the failed previous change (which may include the version of the execution program) with the value of the change procedure description for the current change request (which may include the version of the execution program).The judgment unit then determines whether the deficiency in the change procedure description or the execution program has been corrected.If the value of the change procedure description for the current change request (excluding the version of the execution program) differs from the value of the change procedure description for the failed previous change (excluding the version of the execution program), the judgment unit determines that the deficiency in the change procedure description has been corrected.If the version of the execution program used in the change related to the current change request is later than the version of the execution program used in the failed previous change, the judgment unit determines that the deficiency in the execution program has been corrected.

[0063] If the determination in step S8 is negative (if the deficiency has not been corrected), the operation proceeds to step S4, where the determination unit rejects automatic approval, i.e., the current change request is automatically rejected. If it is determined that a past failure was caused by an inadequate change procedure explanation or an inadequate execution program, the same failure is likely to occur even if the current change is executed as long as the same change procedure explanation or execution program is used. Therefore, the change requester must improve the change procedure explanation or execution program. By automatically rejecting the current change request, the personnel involved in the change can be prompted to take measures.

[0064] If the determination in step S8 is affirmative (if the deficiency has been corrected), the operation proceeds to step S3, and the determination unit permits automatic approval. Even if a previous change request of the same type as the current change request failed, if the deficiency that caused the previous failure has been corrected, the change to be made in response to the current change request is likely to be successful. In this case, the current change request can be quickly and automatically approved.

[0065] As described above, in this embodiment, changes to the virtualized environment of the network can be approved quickly and accurately. However, step S5 may be omitted, and in this case, if the determination in step S2 is positive, the operation may proceed directly to step S6. Also, step S6 may be omitted, in which case, if the determination in step S5 is positive, the operation may proceed directly to step S7. Also, steps S7 and S8 may be omitted. In this case, if the determination in step S6 is negative, the operation may proceed to step S3.

[0066] Next, learning of the learning model (see FIG. 5) stored in the criteria management database will be described with reference to FIG. First, a learning process E for generating a decision policy that can be used in the decision in step S6 of FIG. 16 will be described. The change approver analyzes the history of past failed changes and determines whether the past failures were caused by human error based on the change procedure description and execution result description for the past failed changes. Next, the change approver uses his / her own communication device to send the history of past failed changes and the determination result to the OSS. In this case, the determination result is sent to the OSS whether the determination result is that the past failures were caused by human error or not. The change approver may use his / her own communication device to send the reason for the determination to the OSS in addition to the history of past failed changes and the determination result.

[0067] The OSS transfers the history of past failed changes and the judgment results (the basis for the judgment) to the judgment unit of the approval device, and the judgment unit stores these in a learning model in the judgment criteria management database. Once a certain amount of these have been accumulated in the learning model, the judgment unit has the learning model learn the judgment patterns used by human change approvers to determine whether past failures were caused by human error based on the change procedure explanations and execution result explanations for past failed changes, and has the learning model generate a judgment policy based on the judgment patterns. The learning model learns the judgment patterns of human change approvers and generates a judgment policy based on the judgment patterns, allowing the judgment unit in step S6 to easily and appropriately determine whether past failures were caused by human error.

[0068] Next, a learning process F for generating a discovery policy that can be used in the determination in step S7 of FIG. 16 will be described. The change approver analyzes the history of past failed changes and discovers deficiencies in the change procedure instructions or deficiencies in the execution program for the past failed changes. Next, the change approver uses his / her communication device to send the history of past failed changes and the results of the discovery to the OSS. The results of the discovery may be the locations of deficiencies in the change procedure instructions or the locations of deficiencies in the execution program. The change approver may also use his / her communication device to send the history of past failed changes and the results of the discovery to the OSS, along with the reasons for the deficiencies.

[0069] The OSS transfers the history of past failed changes and the results of the detection (and the reasons for the defects) to the judgment unit of the approval device, and the judgment unit stores these in a learning model in the judgment criteria management database. Once a certain amount of these have been accumulated in the learning model, the judgment unit trains the learning model in the detection patterns that human change approvers used to discover defects in the change procedure explanations or execution programs for past failed changes, and has the learning model generate a detection policy based on the detection patterns. The learning model learns the discovery patterns of human change approvers and generates discovery policies based on the discovery patterns, so that in step S7 the judgment unit can easily and appropriately determine whether past failures were caused by inadequate change procedure explanations or inadequate execution programs.

[0070] 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.

[0071] As can be seen from the items illustrated in Figures 6 to 11, the automatic approval according to the present disclosure is useful when the change is a patch application and / or a firmware or software update. However, the automatic approval according to the present disclosure is also useful for updating a cloud component's configuration file (changing the setting values ​​in that file), moving a platform into maintenance mode, detaching a failed server or storage resource from the cloud before physically replacing it, or incorporating a new server or storage resource into the cloud after replacement. Items related to these changes can be added to the items illustrated in Figures 6 to 11 as needed.

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

[0073] [1] Retrieve the current change request from a change request management database that stores change requests for the network virtualization environment. Extract the values ​​of the comparison items included in the change request, Searching for a criterion matching the value of the comparison item in a criterion management database that stores the criterion; If no criteria matching the value of the comparison item are found in the criteria management database, the current change request is automatically rejected; When a judgment criterion matching the value of the comparison item is found in the judgment criterion management database, a change history management database that stores the history of changes executed in response to past change requests is searched for execution results of past changes executed in response to past change requests of the same type as the current change request, which is the history of past changes that match the judgment criterion; If the execution result of the past change is not found in the change history management database, the current change request is automatically rejected; When the execution result of the past change is found in the change history management database, determining whether a predetermined condition related to the execution result of the past change is satisfied; If the predetermined conditions are met, the change request is automatically approved; If the predetermined conditions are not met, the current change request is automatically rejected. At least one processor A network management device comprising:

[0074] [2] The processor: By referring to the results of the past changes, if the number of successful changes made in the past is less than a threshold, the current change request is automatically rejected; If the number of successful past changes executed is equal to or greater than a threshold and there are no failures in the past changes executed, the current change request is automatically approved. The network management device according to [1].

[0075] [3] The processor: If the number of successful past changes is equal to or greater than a threshold and there are failures in the past changes, determine whether the problems expected in the current change request include all of the problems that occurred in the failed past changes; If the expected defects in the current change request do not include all of the defects that occurred in the previous failed change, the current change request is automatically rejected. The network management device according to [2].

[0076] [4] The processor: If the number of successful past changes is equal to or greater than a threshold value and there is a failure in the past changes, determine whether the past failure was caused by human error based on a change procedure description and an execution result description for the failed past change; If the previous failure is determined to be due to human error, the current change request is automatically rejected. The network management device according to [2] or [3],

[0077] [5] The processor: If the number of successful past changes is equal to or greater than a threshold value and there is a failure in the past changes, determine whether the past failure is due to an inadequate change procedure description or a inadequate execution program used to execute the failed past changes; automatically rejecting the current change request if it is determined that the previous failure was not caused by an incomplete change procedure description or an incomplete execution program used to execute the previous failed change; If it is determined that the past failure was caused by a defect in the change procedure description or a defect in the execution program used to execute the past failed change, determining whether the defect has been remedied; If the deficiencies have been corrected, the change request will be automatically approved. If the deficiency is not corrected, the change request will be automatically rejected. The network management device according to [2] or [3],

[0078] [6] The processor: A learning model is trained to learn a judgment pattern in which a human change approver judges whether or not a past failure was caused by human error based on a change procedure description and an execution result description for the past failed change, and a judgment policy based on the judgment pattern is generated in the learning model; Determine whether the past failure was due to human error in accordance with the decision policy. The network management device according to [4].

[0079] [7] The processor: a learning model learning a discovery pattern in which a human change approver has discovered a defect in the change procedure description or a defect in the execution program, and generating a discovery policy based on the discovery pattern in the learning model; determining whether the past failure was due to a flaw in the change procedure description or a flaw in the executable program used to perform the failed past change in accordance with the discovery policy; The network management device according to [5].

[0080] [8] A network management device according to any one of [1] to [3], and a communication device that communicates with the network management device, When the processor automatically approves the change request, the communication device transmits an approval notification to the device of the change executor, and when the processor automatically rejects the change request, the communication device transmits an approval request to the device of the change approver. A network management system comprising:

[0081] [9] retrieving the current change request from a change request management database that stores change requests for the network virtualization environment; Extracting values ​​of comparison items included in the current change request; searching for a criterion matching the value of the comparison item in a criterion management database that stores the criterion; If no judgment criteria matching the value of the comparison item is found in the judgment criteria management database, the current change request is automatically rejected; When a judgment criterion matching the value of the comparison item is found in the judgment criterion management database, a change history management database that stores the history of changes executed in response to past change requests is searched for execution results of past changes executed in response to past change requests of the same type as the current change request, which are the history of past changes that match the judgment criterion; automatically rejecting the current change request if the execution result of the past change is not found in the change history management database; When the execution result of the past change is found in the change history management database, determining whether a predetermined condition related to the execution result of the past change is satisfied; automatically approving the current change request if the predetermined conditions are met; If the predetermined conditions are not met, the current change request is automatically rejected. A network management method comprising: [Explanation of symbols]

[0082] Mo...mobile network, A...processing for registering change requests, B...processing for registering approval of change requests, C...processing for executing changes, D...processing for registering judgment criteria, E...learning process for generating judgment policies, F...learning process for generating discovery policies

Claims

1. The change request is acquired from a change request management database that stores change requests for the network virtualization environment. Extract the values ​​of the comparison items included in the change request, Searching for a criterion matching the value of the comparison item in a criterion management database that stores the criterion; If no criteria matching the value of the comparison item are found in the criteria management database, the current change request is automatically rejected; When a judgment criterion matching the value of the comparison item is found in the judgment criterion management database, a change history management database that stores the history of changes executed in response to past change requests is searched for execution results of past changes executed in response to past change requests of the same type as the current change request, which is the history of past changes that match the judgment criterion; If the execution result of the past change is not found in the change history management database, the current change request is automatically rejected; When the execution result of the past change is found in the change history management database, determining whether a predetermined condition related to the execution result of the past change is satisfied; If the predetermined conditions are met, the change request is automatically approved; If the predetermined conditions are not met, the current change request is automatically rejected. At least one processor A network management device comprising:

2. The processor: By referring to the results of the past changes, if the number of successful changes made in the past is less than a threshold, the current change request is automatically rejected; If the number of successful past changes executed is equal to or greater than a threshold and there are no failures in the past changes executed, the current change request is automatically approved.

2. The network management device according to claim 1.

3. The processor: If the number of successful past changes is equal to or greater than a threshold and there are failures in the past changes, determine whether the problems expected in the current change request include all of the problems that occurred in the failed past changes; If the expected defects in the current change request do not include all of the defects that occurred in the previous failed change, the current change request is automatically rejected.

3. The network management device according to claim 2.

4. The processor: If the number of successful past changes is equal to or greater than a threshold value and there is a failure in the past changes, determine whether the past failure was caused by a human error based on a change procedure description and an execution result description for the failed past change; If the previous failure is determined to be due to human error, the current change request is automatically rejected.

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

5. The processor: If the number of successful past changes is equal to or greater than a threshold value and there is a failure in the past changes, determine whether the past failure is due to an inadequate change procedure description or a inadequate execution program used to execute the failed past changes; automatically rejecting the current change request if it is determined that the previous failure was not caused by an incomplete change procedure description or an incomplete execution program used to execute the previous failed change; If it is determined that the past failure was caused by a defect in the change procedure description or a defect in the execution program used to execute the past failed change, determining whether the defect has been remedied; If the deficiencies have been corrected, the change request will be automatically approved. If the deficiency is not corrected, the change request will be automatically rejected.

5. The network management device according to claim 2, wherein the network management device is a network management device.

6. The processor: A learning model is trained to learn a judgment pattern in which a human change approver judges whether or not a past failure was caused by human error based on a change procedure description and an execution result description for the past failed change, and a judgment policy based on the judgment pattern is generated in the learning model; Determine whether the past failure was due to human error in accordance with the decision policy.

5. The network management device according to claim 4.

7. The processor: a learning model learning a discovery pattern in which a human change approver has discovered a defect in the change procedure description or a defect in the execution program, and generating a discovery policy based on the discovery pattern in the learning model; determining whether the past failure was due to a flaw in the change procedure description or a flaw in the executable program used to perform the failed past change in accordance with the discovery policy; 6. The network management device according to claim 5.

8. A network management system comprising: a network management device according to any one of claims 1 to 7; and a communication device that communicates with the network management device; When the processor automatically approves the change request, the communication device transmits an approval notification to the device of the change executor, and when the processor automatically rejects the change request, the communication device transmits an approval request to the device of the change approver. A network management system comprising:

9. Obtaining the current change request from a change request management database that stores change requests for the network virtualization environment; Extracting values ​​of comparison items included in the current change request; searching for a criterion matching the value of the comparison item in a criterion management database that stores the criterion; If no judgment criteria matching the value of the comparison item is found in the judgment criteria management database, the current change request is automatically rejected; When a judgment criterion matching the value of the comparison item is found in the judgment criterion management database, a change history management database that stores the history of changes executed in response to past change requests is searched for execution results of past changes executed in response to past change requests of the same type as the current change request, which are the history of past changes matching the judgment criterion; when the execution results of the past changes are not found in the change history management database, automatically rejecting the current change request; when the execution results of the past changes are found in the change history management database, determining whether or not a predetermined condition related to the execution results of the past changes is satisfied. automatically approving the current change request if the predetermined conditions are met; If the predetermined conditions are not met, the current change request is automatically rejected. A network management method comprising:

Images