JP6760886B2 - Operation system - Google Patents

Description

The present invention relates to an operation system (OpS) that monitors and controls each NE in a network composed of a plurality of different types of network devices (NEs: network elements).

Conventionally, a network NE and an operation system for monitoring and controlling the NE have been developed as a set by a NE vendor, and a communication carrier has introduced the NE and an operation system as a set. As a result, since there are many different vendors' operating systems in the carrier's network, the operator of the operator terminal 1 needs to be familiar with the operating systems of each vendor before using them. For example, as shown in FIG. 18, the operation system 2A manufactured by Vendor A is used for NE3A manufactured by Vendor A, and the operation system 2B manufactured by Vendor B is used for NE3B manufactured by Vendor B. Since it is necessary to use the operation system 2C manufactured by the vendor B for the NE3C manufactured by the manufacturer, the operator needs to input the settings to the NE after mastering the operation system of each vendor.
On the other hand, there is also a technique for making the operation system multi-vendor compatible (see Non-Patent Document 1). For example, the operation system 4 has a common function 5 that accepts setting inputs from operators and outputs event notifications from each NE in a vendor-independent manner, and NE3A of company A and NE3B and C of company B. There is a technique in which adapters 6A to 6C for connecting to NE3C are provided for each NE of each vendor (see FIG. 19). According to such an operation system, the operator does not need to be proficient in the operation system of each vendor, so that the setting input to the NE of each vendor can be easily performed.

In recent years, disaggregated equipment (hereinafter referred to as dis-aggregated equipment) that separates and parts network equipment (NE) into small particles has appeared, and a method of constructing a transmission NW by combining disaggregated equipment has been introduced. It is being introduced (see Non-Patent Document 2).
In the following description, when distinguishing between a network device (NE) and a disagreement device, the network device may be referred to as an all-in-one device.

Service activation technology that supports network services, NTT Technology Journal, August 18-21, 2005 [online], [Search June 5, 2017], Internet <URL: http://www.ntt.co.jp /journal/0508/files/jn200508018.pdf> Open ROADM overview, openroadm.org Multi-Source Agreement, [online], [Search June 5, 2017], Internet <URL: http://0201.nccdn.net/1_2/000/000/098/a85 /Open-ROADM-whitepaper-v1-0.pdf>

The conventional operation system technology has the following problems. When managing each individual disagreement device as a network device, (1) the number of network devices that the operator is aware of becomes enormous. (2) Operational efficiency is reduced due to fault isolation. (3) Induce operator misoperation.

The present invention has been made in view of such a background, and the present invention provides an operation system capable of efficiently operating and managing a network device and a disagreement device while reducing erroneous operations of an operator terminal. That is the issue.

In order to solve the above-mentioned problems, the invention according to claim 1 is an operation system for monitoring and controlling a network device and a disaggregation device in which the network device is separated into small particles and made into parts. For each logical network device identification information, the vendor type / component device information, which is information indicating the vendor type of the network device and the component device name of each disaggregation device, and control for the logical network device. In response to a request, a multi-vendor control definition file that defines each of the disaggregation devices that make up the logical network device and its calling order, and a command sequence used to input commands to the network device of the vendor type and device type. The command sequence definition file showing the above, the input order definition file showing the application order of the command sequence definition file, and the input order definition file applied to realize the function for each function used when the command is input. A storage unit that stores a definition file including an input order selection definition file showing identification information, and the network device that receives input of a control order to the network device and inputs a command included in the input control order. Using the identification information of the above as a key, the common unit for specifying the vendor type and device type of the network device to which the command is input, and the network device and the disaggregation device are referred to with reference to the vendor type / component device information. In the case of the disaggregation device, an abstraction unit that determines and transmits the request by decomposing it into an access request for each of the disaggregation devices by referring to the multi-vendor control definition file, and the specified vendor type and device. By referring to the definition file of the type, the input order selection definition file of the network device or the disaggregation device is specified, and the specified input order selection definition file and the network device included in the input control order are assigned. With reference to the identification information of the function required for inputting the command, the request receiving unit that specifies the input order definition file necessary for realizing the function, and the specified input order definition file are referred to. The command sequence definition file is sequentially called in the order shown in the input order definition file, and the called command sequence definition file is called. The operation system is characterized by including a command conversion unit that sequentially executes commands to the network device or the disaggregation device based on the file.

By doing so, the operator terminal does not have to be aware of individual disagreement devices, so that efficient operation and reduction of erroneous operations are possible. As a result, it is possible to efficiently manage the operation of the network device and the disagreement device while reducing the operator's misoperation.

Further, in the invention according to claim 2, the abstraction unit receives a control order from the operator terminal using the logical network device as a single network device, and constitutes the logical network device. The request for the logical network device is divided into individual requests for each physical disaggregation device, and the multi-vendor control is performed so that each physical disaggregation device is treated as a single network device. The operation system is characterized by executing the requests in the order described in the definition file.

By doing so, a single logical NE corresponds to a plurality of IP addresses, and a physical NE: a logical NE = N: 1 can be realized. Since the operator terminal does not have to manage each disagreement device as NE, efficient operation and reduction of erroneous operations are possible.

Further, according to the invention of claim 3, the definition file further includes a notification information definition file showing definition information for converting an event notification from the network device into data used in the common unit, and the above-mentioned. A notification type definition file showing the notification information definition file for each event notification type is included for each vendor type and device type of the network device, and the operating system further sends an event notification from the network device. When received, the vendor type and device type of the network device are specified by referring to the vendor type / configuration device information and the identification information of the network device that is the source of the event notification, and the specified vendor type and device are specified. The notification information definition file regarding the type of event notification from the network device is specified by referring to the notification type definition file in the type definition file, and the specified notification information definition file is referred to from the network device. An event notification conversion unit that converts an event notification into data used in the common unit and outputs the data to the common unit is further provided, and the event notification conversion unit distinguishes between the network device and the disaggregation device, and the disaggregation device is described. In the case of a disaggregation device, the operation system according to claim 1, wherein the alarm generation point information is converted into information indicating a logical network device and output to the common unit.

By doing so, even if event notifications are received from network devices of various vendors and models or logical NEs (collections of disagreement devices), the contents of these event notifications can be interpreted by the common part. , Can be displayed on a display device connected to the operating system.

According to the present invention, it is possible to provide an operation system capable of efficiently operating and managing a network device and a disagreement device while reducing erroneous operations of an operator terminal.

It is a block diagram which shows the operation system which concerns on embodiment of this invention. It is a figure which shows the example of the vendor type / constituent equipment information of the operation system which concerns on embodiment of this invention. It is a figure which shows the example of the multi-vendor control definition file of the operation system which concerns on embodiment of this invention. It is a figure explaining the functional block of the control system of the operation system which concerns on embodiment of this invention. It is a flowchart which shows the process of the abstraction part of the operation system which concerns on embodiment of this invention. It is a flowchart which shows the process of the apparatus interface part of the operation system which concerns on embodiment of this invention. It is a figure explaining the functional block of the monitoring system of the operation system which concerns on embodiment of this invention. It is a flowchart which shows the operation of the alarm / event notification conversion part of the device interface part of the operation system which concerns on embodiment of this invention. It is a figure explaining the key information (device registration) of the operation system which concerns on embodiment of this invention. It is a figure which shows the example of the information which the operator terminal inputs at the time of device registration of the operation system which concerns on embodiment of this invention, (a) is the example in the case of an all-in-one device, and is an example in the case of a disagreement device. It is a figure explaining the key information (control system) of the operation system which concerns on embodiment of this invention. It is a figure which shows the example of the information which the operator terminal 1 inputs at the time of the path registration of the operation system which concerns on embodiment of this invention. It is a figure which shows the example of the distribution data from the common part to the abstract part of the operation system which concerns on embodiment of this invention. It is a figure which shows the example of the distribution data from the abstraction part of the operation system which concerns on embodiment of this invention to a device interface part. It is a figure explaining the key information (monitoring system) of the operation system which concerns on embodiment of this invention. It is a figure which shows the alarm / event information example which is notified from the network apparatus (NE) of the operation system which concerns on embodiment of this invention. It is a figure which shows the example of the distribution data from the device interface part to the common part of the operation system which concerns on embodiment of this invention. It is a figure for demonstrating the prior art. It is a figure for demonstrating the prior art. It is a block block diagram which shows the outline of the conventional operation system. It is a figure explaining the problem when the disaggregation device progresses in the structure of FIG.

Hereinafter, an operation system and the like in a mode for carrying out the present invention (hereinafter, referred to as “the present embodiment”) will be described with reference to the drawings.
(Background explanation)
FIG. 20 is a block configuration diagram showing an outline of an operation system that reduces the burden on the operator.
As shown in FIG. 20, a plurality of operation systems 10 and NE30s (for example, OADM (Optical add-drop multiplexe) devices) constituting the network are installed in the system. The NE30 is a NE30 of various vendors and models (device types). For example, three types of NE30s, NE30A (manufactured by vendor A), NE30B (manufactured by vendor B), and NE30C (manufactured by vendor C) are installed. To.
When the operation system 10 receives the input of the control order 2 for making various settings to each NE 30 from the operator terminal 1, the operation system 10 converts the control order 2 into a device command suitable for the NE 30 of each vendor, and the NE 30. Put it in. Further, when the operation system 10 receives the event notification 3 (for example, an alarm from the NE 30) from each NE 30, the operation system 10 converts the content of the event notification into a format that can be displayed on the operator terminal 1 and outputs the event notification.

The control order 2 to the NE 30 input to the operation system 10 via the operator terminal 1 is received by the common unit 11 (described later) of the operation system 10. The common unit 11 refers to the vendor type / device type information DB 12 and specifies the vendor type and the device type of the network device to which the command is input. The common unit 11 outputs the NE access request 14 (access request to the NE 30) to the device interface unit 13. Then, when the device interface unit 13 receives the NE access request, the device interface unit 13 reads the definition file 20 relating to the command input to the NE 30 of the vendor name and the model name from the vendor name and the model name of the NE 30 included in the NE access request. .. For example, when the command input destination is NE30A, the device interface unit 13 reads the definition file 20A for company A. Then, based on the definition file 20A for company A, the device command 21 is input to NE30A.

Further, when the operation system 10 receives an event notification (for example, an alarm) from the NE30 (for example, NE30B), the device interface unit 13 specifies the vendor name (vendor type) and the model name of the NE30, and this Read the vendor name and model name definition file 20B (for example, the definition file for company B). Then, the device interface unit 13 converts the event notification 22 into the data used in the common unit 11 based on the read definition file, and outputs the event notification 22 to the common unit 11. After that, the common unit 11 outputs the received event notification 15 to the operator terminal 1. Similarly, when the operation system 10 receives an event notification (for example, an alarm) from the NE 30C, the device interface unit 13 specifies the vendor name (vendor type) and model name of the NE 30, and the vendor name and model. Read the name definition file 20C (for example, the definition file for company C).

Here, since the information input / output by the common unit 11 does not depend on the vendor or the model, the load when the operator operates the operation system 10 can be reduced. Further, the operation system 10 is provided with a definition file for converting a command to the NE 30 and an event notification from the NE 30 for each combination of the vendor and the model of the NE 30. By referring to this definition file, various conditions can be obtained. It is possible to convert commands to the NE30 of various vendors and models and event notifications from the NE30. Further, when the specification of NE30 is changed or the model is changed to a new model, this definition file may be modified, so that it is not necessary to modify the programs of the common unit 11 and the device interface unit 13.

In this way, the operation system 10 reduces the burden on the operator by localizing the managed vendor difference in the definition file 20.

FIG. 21 is a diagram illustrating a problem when the disaggregation device is advanced in the configuration of FIG. 20.
As shown by the white arrow in FIG. 21, the management target when the disaggregation device 31 is advanced is that the NE name of the disaggregation device 31A is "aa" and supports function 1, and the vendor is company A. (Hereinafter referred to as (NE name = aa (function 1) (company A)), logic device 31B (NE name = bb (function 2) (company B)), logic device 31C (NE name = cc (function)). 3) (Company C)), ... The NE in the disaggregation device 31 is a logical NE310 (for example, NE name = AA) (see FIG. 21 dashed line box).

In the conventional operation system technology, it is not clear what to manage when the disagreement device 31 progresses. Therefore, (1) the number of network devices that the operator is aware of becomes enormous. (2) Operational efficiency is reduced due to fault isolation. (3) Induce operator misoperation.

(Embodiment)
FIG. 1 is a configuration diagram showing an operation system according to an embodiment of the present invention. The same components as those in FIG. 21 are designated by the same reference numerals.
The operation system 100 is a device including a network device (NE) and an operation system (operation system) for monitoring and controlling a disagreement device in which NE is separated into small particles and made into parts.
As shown in FIG. 1, a plurality of operation systems 100 and NE30s (for example, OADM devices and the like) constituting the network are installed in the system. The NE30 is a NE30 of various vendors and models (device types). For example, three types of NE30s, NE30A (manufactured by vendor A), NE30B (manufactured by vendor B), and NE30C (manufactured by vendor C) are installed. To. In addition, when the disaggregate device 31 progresses, the management targets are the disaggregate device 31A (NE name = aa (function 1) (company A)) and the disaggregate device 31B (NE name = bb (function 2) (company B). )), Disagri device 31C (NE name = cc (function 3) (company C)), ...

The operation system 100 includes a common unit 110, a database (DB) 120 (storage unit) which is a storage area of EMS, an abstraction unit 130, a multi-vendor control definition file 140, a definition file 20, and a device interface unit 150. And.

<Common part 110>
The common unit 110 accepts the input of the control order to the NE30 or the logical NE (set of the disaggregation devices 31), and the NE30 or the logical NE (disaggregation) to which the command included in the input control order is input. Using the identification information of (a set of devices 31) as a key, the vendor type / device type of the network device to which the command is input is specified by referring to the vendor type / configuration device information.

The common unit 110 receives an input of a control order to the NE 30 or a logical NE (a set of disagreement devices 31). Then, the common unit 110 uses the identification information of the NE30 to which the command is input included in the input control order as a key, refers to the vendor type / configuration device information, and refers to the vendor type of the NE30 to which the command is input. And identify the components. Then, the common unit 110 outputs the specified vendor type and component device and the function name included in the control order (identification information of the function realized by the control order) to the abstraction unit 130.
When the common unit 110 receives an event notification from the NE 30 via the alarm / (hereinafter, “/” indicates “and / or”) event notification conversion unit 156 (see FIG. 7 below) of the device interface unit 150. , This alarm / event notification is output to the operator terminal 1.

<DB120>
The DB 120 is information indicating the vendor type of the NE310, the component device name of each disagreement device, and the IP address for each logical identification information of the NE310, which is the vendor type / component device information (see the figure below). 2), the multi-vendor control definition file (CSV) 140 (see FIG. 3 below), and the definition file 20 (see FIG. 4 below). The DB 120 may be outside the common unit 110. The definition file 20 and the like are not particularly limited to the database, and may be stored in any storage unit.

<Vendor type / configuration device information>
In the conventional EMS, the correspondence between the NE name and the IP address of the connected NE is managed in a 1: 1 ratio. That is, since the conventional EMS is supposed to be used in an all-in-one device, the vendor name, the model name, and the connection destination IP address are managed 1: 1 for each NE name. On the other hand, in this embodiment, it corresponds to a disagreement device. Therefore, the logical NE name and the connection destination IP address are managed in a ratio of 1: N.
The vendor type / component device information is stored in the DB 120, which is an EMS storage area, at the time of device registration. At the time of device registration, the operator terminal 1 (see FIG. 1) inputs the NE name / model name / IP address. At the time of each control (path registration, etc.), the operation system 100 specifies the connection destination IP address based on the vendor type / configuration device information.

FIG. 2 is a diagram showing an example of vendor type / constituent device information.
As shown in FIG. 2, the vendor type / component device information includes a logical NE name, a vendor name corresponding to this logical NE name, a model name, a component device name, a connection destination IP address, and the like. Has.
In the case of the disaggregation device shown in FIG. 2, the NE name stores the logical NE names "AA" and "CC". Store "mult" for the vendor name and model name. The component device name stores the name (aa, bb, ...) Of each disaggregate device. The connection destination IP address stores "111. 111. 111. 111", "222. 222. 222. 222", and so on. In this way, for a logical NE name, for example, the NE name "AA", the vendor name and model name "mult", the component device names (aa, bb, cc), and the connection destination IP address "111. 111. 111. 111, "222. 222. 222. 222" and "333. 333. 333. 333" are managed at 1: N.

<Abstract part 130>
The abstraction unit 130 discriminates between an all-in-one device and a disaggregate device, and in the case of a disaggregate device, refers to the multi-vendor control definition file 140, decomposes it into access requests for individual disaggregate devices, and sequentially decomposes the device interface. A request is sent to unit 150.
The abstraction unit 130 accepts the control order from the common unit 110 (see FIG. 1) with the logical NE 310 as a single NE, and treats each physical disagreement device as a single NE. Sends a command that converts and maps the logical NE310 and the physical abstraction device. As a result, the abstraction unit 110 treats the logical NE 310 as a single NE at the upper level on the operator terminal 1 side, and treats each physical disagreement device as a single NE at the lower level. Mutual conversion mapping between the logical NE and the physical NE to be handled is performed.

<Multi-vendor control definition file 140>
The multi-vendor control definition file 140 defines each disagreement device 31 to be called and its calling order in response to a control request for a single logical NE 310. The multi-vendor control definition file 140 prepares a file for each function (device registration, path registration, etc.), and the key for viewing which file is the function name.

FIG. 3 is a diagram showing an example of the multi-vendor control definition file 140, which is stored in the DB 120 (storage unit).
As shown in FIG. 3, in the multi-vendor control definition file 140, for each # file name (setne.csv), the # vendor name (company A, company B, company C ...) and the respective component device names (aa, bb) , Cc, ...) are memorized. The abstraction unit 130 executes the process from the youngest number of the multi-vendor control definition file 140. In this example, 1. Company A, aa, 2. Company B, bb, 3. The processing is executed in the order of company C, cc ...

<Definition file 20>
The definition file 20 is stored in the DB 120 of the common unit 110 together with the vendor type / configuration device information (see FIG. 2) and the multi-vendor control definition file (CSV) 140 (see FIG. 3).
The definition file 20 is a file that is referred to when the device interface unit 150 inputs commands to the NE30 of various vendors and models and converts event notifications from the NE30. The definition file 20 is prepared for each combination of NE30 vendor type and model, and is an input order selection definition file (CSV) 171 (see FIG. 4), an input order definition file (CSV) 172 (see FIG. 4), and an input order. It includes a definition file (script) 173 (see FIG. 4), a command sequence definition file (CSV) 174 (see FIG. 4), and a parameter conversion / sequence control definition file (script) 175 (see FIG. 4). These files are, for example, CSV format files and files in which scripts are described, and can be appropriately rewritten via the input / output unit (not shown). By doing so, it is not necessary to make complicated modifications to the operation system 100 when the specifications or the model of the NE 30 or the disagreement device 31 are changed.

[Functional block (control system)]
Next, the functional blocks of the control system of the operation system 100 will be described.
FIG. 4 is a diagram illustrating a functional block of the control system of the operation system 100. The same components as those in FIG. 1 are designated by the same reference numerals.
As shown in FIG. 4, the operation system 100 includes an abstraction unit 130, a multi-vendor control definition file 140, and a device interface unit 150.

<Device interface unit 150>
The device interface unit 150 includes a request reception unit 151, a command conversion / sequence control unit 152, a communication processing unit 153, a communication processing unit 154, and a communication processing unit 155.

<Request reception department 151>
The request reception unit 151 specifies the input order selection definition file (CSV) 171 of the network device 30 with reference to the specified vendor type and device type definition file 20, and the specified input order selection definition file (CSV) 171. And the identification information of the function required to input the command to the network device or the disagreement device 31 included in the input control order, and the input order definition file (CSV) required to realize the function. Identify 172.
The request reception unit 151 includes the input order selection definition file (CSV) 171 in the definition file 20 related to the NE30 or the disagreement device 31 of the vendor name and model name output from the common unit 110, and the control order input to the operation system 100. The input order definition file (CSV) 172 required to realize the function is specified by referring to the identification information of the function required to input the command to NE30 included in the above.

<Command conversion / sequence control unit 152>
The command conversion / sequence control unit 152 refers to the specified input sequence definition file (CSV) 172, and sequentially calls and calls the command sequence definition file (CSV) 174 in the order shown in the input sequence definition file (CSV) 172. Based on the command sequence definition file (CSV) 174, commands are sequentially executed to the network device 30 or the disagreement device 31.
The command conversion / sequence control unit 152 refers to the input sequence definition file (CSV) 172 specified by the request reception unit 151, and refers to the command sequence definition file (CSV) in the order shown in the input sequence definition file (CSV) 172. Call 174 in sequence. Then, the command conversion / sequence control unit 152 sequentially executes command input to the NE 30 or the disagreement device 31 via the communication processing units 153 to 155 based on the called command sequence definition file (CSV) 174.

<Communication processing unit 153 to 155>
The communication processing units 153 to 155 are interfaces for inputting a command issued from the command conversion / sequence control unit 152 to the NE30 and receiving an event notification from the NE30 side. The communication processing units 153 to 155 are prepared for each protocol used for communication between the NE 30 and the operation system 10, for example. For example, when the protocols used for communication between the NE 30 and the operation system 10 are TL1 (Transaction Language 1), SNMP (Simple Network Management Protocol), and CLI (Command Line Interface), the communication processing unit 153 is used for each communication protocol. Prepare ~ 155.

<DB120>
The DB 120 includes vendor type / configuration device information, a multi-vendor control definition file (CSV) 140 (see FIG. 3), an input order selection definition file (CSV) 171 and an input order definition file (CSV) 172. The definition file (script) 173, the command sequence definition file (CSV) 174, and the parameter conversion / sequence control definition file (script) 175 are stored.

<Input order selection definition file (CSV) 171>
The input order selection definition file (CSV) 171 is a function (for example, setting of NE30, setting of a path between each NE30, etc.) necessary for inputting a command to NE30 or a logical NE310 (a set of disagreement devices 31). ), It is the information indicating the identification information of the input order definition file applied for the realization of the function. For example, the input order selection definition file (CSV) 171 is described in CSV (Comma Separated Value) format, and the function name required for inputting a command to NE30 or a logical NE310 (a set of disaggregate devices 31) and the relevant In addition to the input order definition file name applied to realize the function, the input order determination method of command input by the input order definition file 172 and the input order definition for rollback applied to rollback when an error occurs in command input. The file name, the input order determination method for rollback, and the like may be included.

<Input order definition file (CSV) 172>
The input order definition file (CSV) 172 is information indicating the command sequence definition file to be applied and the application order of the command sequence definition file (CSV) 174. This input order definition file is also described in CSV format, for example (see FIG. 6).
Here, if there is one NE30 to be command input and it can be determined at the time of creating the definition file 20 (see FIG. 1) which command sequence definition file (CSV) 174 is input in which order, the input order definition file In (CSV) 172, a CSV format file is specified as a fixed sequence.

<Input order definition file (script) 173>
The input order definition file (script) 173 is information indicating the command sequence definition file (CSV) 174 to be applied and the application order of the command sequence definition file (CSV) 174, and is described in a script format. That is, the input order definition file (script) 173 describes a script for determining the application order of the command sequence definition file (CSV) 174. For example, python is used to describe the script. By doing so, when the application order (call order) of the command sequence definition file (CSV) 174 is a non-fixed sequence, for example, the command or command input sequence is dynamically changed according to the device status of NE30 or the command response result. If you need to change to, you can handle this.

On the other hand, the definition file 20 (see FIG. 1) determines which input order definition file (CSV) 172 is executed by a plurality of NE30s to be input or logical NE310s (a set of disaggregate devices 31) or which input order definition file (CSV) 172 is executed. ) If it cannot be determined at the time of creation, the input order definition file (script) 173 in the script format may be specified in the input order definition file (script) 173 so as to be a dynamic (non-fixed) sequence. For example, the request reception unit 151 that refers to the input sequence definition file (script) 173 in this script format displays a list showing the input sequence number and the command sequence definition file (CSV) 174 corresponding to each of the input sequence numbers. Output.

<Command sequence definition file (CSV) 174>
The command sequence definition file (CSV) 174 is information indicating a command sequence used for inputting a command to NE30 or a logical NE310 (a set of disagreement devices 31). This command sequence definition file (CSV) 174 is also described in, for example, CSV format. For example, the command sequence definition file (CSV) 174 includes the file name of the command sequence definition file (CSV) 174, how to determine the execution when the command is input, the command ID of the command, the transmission waiting time, and so on. The transmission character string, response timeout waiting time, response waiting character string, how to judge response normality (response normality judgment), function name to be called when a command is input (sequence control definition file), etc. are described.

The command sequence definition file (CSV) 174 may further include a protocol identifier of a communication protocol used for inputting a command to NE30 or a logical NE310 (a set of disagreement devices 31). Then, when the command conversion / sequence control unit 152 (described later) inputs a command to the NE30, the command is input to the NE30 by the protocol module indicated by the protocol identifier shown in the command sequence definition file (CSV) 174.

<Parameter conversion / sequence control definition file (script) 175>
The parameter conversion / sequence control definition file (script) 175 is a file that describes a script to be called when executing a command input based on the command sequence definition file (CSV) 174. For example, a pre-transmission check of a TL1 command or TL1 execution. This is a file that describes a script for determining the result. By preparing the sequence control definition file separately from the command sequence definition file (CSV) 174 in this way, the command sequence itself can be made non-fixed.

Hereinafter, the operation of the operation system 100 configured as described above will be described.
[Outline of operation of operation system 100]
First, an outline of the operation of the operation system 100 will be described.
When the operation system 100 receives an input of a control order 2 for making various settings from the operator terminal 1 to each NE 30 or a logical NE 310 (a set of disagreement devices 31), the operation system 100 receives the control order 2 from each vendor. It is converted into a device command suitable for NE30 and input to NE30. Further, when the operation system 100 receives the event notification 3 (for example, an alarm from the NE 30) from each NE 30, the operation system 100 converts the content of the event notification into a format that can be displayed on the operator terminal 1 and outputs the event notification.

The control order 2 to the NE 30 or the logical NE 310 (a set of disagreement devices 31) input to the operation system 100 via the operator terminal 1 is received by the common unit 110 of the operation system 10. Common unit 110 refers to the vendor type and composition instrument information to identify the vendor type and device type of the input destination network device commands.

The common unit 110 outputs a NE access request (access request to NE30) to the abstraction unit 130.
As shown by the up and down arrows of the broken line in FIG. 1, the operation system 100 treats a logical NE 310 (a set of disagreement devices 31) as 1 NE above the abstraction unit 130. As a result, the conventional VIEW (viewpoint / view) is provided for the operator terminal 1. On the other hand, the operation system 100 treats each physical disagreement device 31 as a single NE below the abstraction unit 130. For this purpose, the abstraction unit 130 converts and maps the logical NE 310 and the physical disagreement device 31 with reference to the multi-vendor control definition file 140 (see FIG. 3). Whereas the system of FIG. 21 had one NE1 IP address, in this embodiment, a single logical NE corresponds to a plurality of IP addresses. Since it is not necessary to be aware of each disagreement device 31, efficient operation and reduction of erroneous operations are possible.

When the device interface unit 150 receives the NE access request, the device interface unit 150 receives a definition file relating to command input to the NE 30 of the vendor name and model name from the vendor name and model name of the NE 30 or the disagreement device 31 included in the NE access request. 20 (see FIG. 1) is read. For example, when the command input destination is NE30A, the device interface unit 150 reads the definition file 20A for company A. Then, based on this definition file 20A, a command is input to the NE30A.

Further, when the operation system 100 receives an event notification (for example, an alarm or the like) from the NE30 (for example, NE30B) (see FIG. 7), the device interface unit 150 determines the vendor name (vendor type) and model name of the NE30. Is specified, and the definition file 20B of the vendor name and the model name (for example, the definition file for company B) is read out. Then, the device interface unit 150 converts the event notification into the data used by the common unit 110 based on the read definition file 20B, and outputs the event notification to the abstraction unit 130.
After that, the common unit 110 outputs the received event notification to the operator terminal 1 (see FIG. 1).
The operation outline of the operation system 100 has been described above. Hereinafter, detailed operations of the abstraction unit 130 and the device interface unit 150 of the operation system 100 will be described.

[Operation of abstraction unit 130 and device interface unit 150]
<Operation of abstraction unit 130>
First, with reference to FIG. 4, the process when the abstraction unit 130 receives the input of the NE access request from the common unit 110 (see FIG. 1) will be described.
As shown in FIG. 4, the abstraction unit 130 receives the NE access request from the common unit 110 (see FIG. 1). The NE access request includes a NE access request to the all-in-one device and a NE access request to the disaggregation device 31.
The abstraction unit 130 determines the NE access request (all-in-one device) and the NE access request (disaggregation device 31) from the vendor name in the NE access request.
In the case of a NE access request (all-in-one device), the abstraction unit 130 transmits the request to the device interface unit 150 (see reference numeral a in FIG. 4).

On the other hand, in the case of a NE access request (disaggregation device 31), the abstraction unit 130 refers to the multi-vendor control definition file 140, and calls each disaggregation device 31 and its addition in response to a control request for a single logical NE 310. The calling order is determined (see reference numeral b in FIG. 4).
Then, the abstraction unit 130 decomposes into NE access requests for each disagreement device 31 and sequentially transmits the requests to the device interface unit 150 (see reference numeral c in FIG. 4).

<Operation of device interface unit 150>
Next, the request receiving unit 151 of the device interface unit 150 receives the NE access request from the abstraction unit 130 to the all-in-one device NE30. The request reception unit 151 specifies the definition file 20 (see FIG. 1) to be called from the vendor name and model name in the NE access request (see reference numeral d in FIG. 4). Then, the request reception unit 151 reads the input order selection definition file (CSV) 171 of the specified definition file 20, and starts from the line corresponding to the function name in the NE access request in the input order selection definition file (CSV) 171. The input sequence definition file (CSV) 172 to be referred to is specified. Further, it is determined whether the calling order of the command sequence definition file (CSV) 174 is a fixed sequence or a non-fixed sequence (see reference numeral e in FIG. 4).

Next, the request receiving unit 151 determines the calling order of the command sequence definition file (CSV) 174 by referring to the specified input order definition file (CSV) 172 (see reference numeral f in FIG. 4). Here, if the specified input order definition file (CSV) 172 is in CSV format, the calling order of the command sequence definition file (CSV) 174 is a fixed sequence. On the other hand, as shown by "OR" in FIG. 4, if the specified input order definition file (CSV) 173 is in script format, the call order of the command sequence definition file (CSV) 174 is a non-fixed sequence (dynamically by the script). The sequence to be determined).

Then, the command conversion / sequence control unit 152 sequentially calls the command sequence definition file (CSV) 174 determined by the request reception unit 151 (see reference numeral g in FIG. 4). Then, the command conversion / sequence control unit 152 executes the contents of the called command sequence definition file (CSV) 174 line by line. The parameter conversion / sequence control definition file (script) 175 can be called at any time by the command sequence definition file (CSV) 174 (see reference numeral h in FIG. 4). The parameter conversion / sequence control definition file (script) 175 is used for checking before sending the TL1 command and determining the execution result of TL1.
When the command sequence definition file (CSV) 174 has a description of the sequence control definition file (CSV), the command conversion / sequence control unit 152 calls the parameter conversion / sequence control definition file (script) 175 accordingly. Execute the script described in this called file.

After that, the command conversion / sequence control unit 152 transmits the execution result (device command) of the command sequence definition file (CSV) 174 to the NE 30 by a predetermined communication protocol via the communication processing units 153 to 155. For example, as illustrated in FIG. 4, when the command conversion / sequence control unit 152 inputs a device command to the NE30A and the communication protocol with the NE30A is TL1, communication implementing the communication protocol of the TL1. A device command (command) is input via the processing units 153 to 155. By doing so, the operation system 100 can input commands to various vendors and various models of NE30.

Next, the details of the processing of the abstraction unit 130 that has received the NE access request described with reference to FIG. 4 will be described with reference to the flowchart of FIG. Further, the details of the processing of the device interface unit 150 that has received the NE access request from the abstraction unit 130 described in the flowchart of FIG. 5 will be described with reference to the flowchart of FIG.
[Details of operation of abstraction unit 130]
5 and 6 are flowcharts showing the operation of the operation system 100, FIG. 5 is a flowchart showing the processing of the abstraction unit 130, and FIG. 6 is an apparatus interface unit migrated by the couplers A and B of FIG. It is a flowchart which shows the process of 150.
As shown in FIG. 5, the abstraction unit 130 receives the NE access request from the common unit 110 (see FIG. 1) (step S10).
In step S11, the abstraction unit 130 determines the all-in-one type OR disagreement type (all-in-one device OR disagreement device) from the vendor name in the NE access request.
If the vendor name is other than "multi", it is determined that it is an all-in-one type, and the process proceeds to the processing of the device interface unit 150 (see FIG. 6).

If the vendor name is "multi", it is determined that it is a disaggregate type, and in step S12, the abstraction unit 130 specifies the multi-vendor control definition file 140 (see FIG. 3) to be called from the function name in the NE access request. To do.
In step S13, the abstraction unit 130 determines whether or not the execution state of the multi-vendor control definition file 120 is the last line. In step S13, the response return portion from the process (see FIG. 5) of the device interface unit 150 is also determined.

When the execution state of the multi-vendor control definition file 140 is the last line (step S13: Yes), the abstraction unit 130 returns a response to the common unit 110 in step S14.
If the execution state of the multi-vendor control definition file 140 is not the last line (step S13: No), the process proceeds to step S15.

In step S15, the abstraction unit 130 executes the evaluation from the unexecuted and youngest line for specifying the multi-vendor control definition file 140 (see FIG. 3). Specifically, the abstraction unit 130 regenerates the NE access request (overwrites the vendor name and the component device name with the acquired values) based on the read information, and transmits the request to the device interface unit 150. The component device name is overwritten with the model name.
After the process of step S15, the process of the abstraction unit 130 of FIG. 4 is skipped and the process proceeds to the process of the device interface unit 150 of FIG.

[Details of operation of device interface unit 150]
Next, the operation of the device interface unit 150 will be described in detail.
As shown in FIG. 5, the device interface unit 150 receives a NE access request from the abstraction unit 130 (see FIG. 1) (step S20).
When the request reception unit 151 of the device interface unit 150 receives the NE access request from the abstraction unit 130 to the NE 30, the input order selection definition file (CSV) to be called from the vendor name and model name in the NE access request in step S21. Identify 171 (see FIG. 2).

In step S22, the request reception unit 151 reads the specified input order selection definition file (CSV) 171 and starts from the line corresponding to the function name in the NE access request, the input order definition file (CSV) 172 (see FIG. 2). To identify.
In step S23, the request receiving unit 151 determines whether the input order of the command sequence definition file (CSV) 174 (see FIG. 2) is fixed or dynamic (non-fixed) from the contents of the input order selection definition file (CSV) 171 specified. To judge.
When it is determined that the input order is fixed (“fixed” in step S23), the request reception unit 151 in step S24 inputs the CSV format shown in the input order selection definition file (CSV) 171 specified in step S21. The sequence definition file (CSV) 172 is read, and the execution procedure of the command sequence definition file (CSV) 174 is determined based on the input sequence definition file (CSV) 172. Then, the process proceeds to step S26.

On the other hand, when it is determined in the determination of step S23 that the input order is not fixed (“dynamic” in step S23), the request receiving unit 151 is shown in the input order selection definition file (CSV) 171 in step S25. , Read the input order definition file (script) 173 (see FIG. 2) in which the script is described, and determine the execution procedure of the command sequence definition file (CSV) 174 based on the input order definition file (script) 173 (S22). .. Then, the process proceeds to step S26.

In step S26, the command conversion / sequence control unit 152 (see FIG. 2) has not executed the command sequence definition file (CSV) 174 among the command sequence definition files (CSV) 174 shown in the input sequence definition file (CSV) 172. Check if exists.
When the unexecuted command sequence definition file (CSV) 174 exists (step S26: Yes), the command conversion / sequence control unit 152 in step S27 inputs the unexecuted command sequence definition file (CSV) 174 in the input order. Number = Specify the youngest file.

Then, in step S28, the command conversion / sequence control unit 152 reads the specified input sequence number = youngest command sequence definition file (CSV) 174.
In step S29, the command conversion / sequence control unit 152 executes one line from the top for the unexecuted line.
In step S30, the command conversion / sequence control unit 152 determines whether or not the last line of the command sequence definition file (CSV) 174 has been reached.
When the last line of the file has been reached (step S30: Yes), the process returns to step S26. If the last line of the file has not been reached (step S30: No), the process returns to step S29.

On the other hand, in step S26, when the command conversion / sequence control unit 152 executes all the command sequence definition files (CSV) 174 shown in the input sequence definition file (CSV) 172 (step S26: No), in step S31. The command conversion / sequence control unit 152 returns a response to that effect to the abstraction unit 130. By this return, the process shifts to the processing of the abstraction unit 130 (see FIG. 4).

Then, based on the execution result of the command sequence definition file (CSV) 174, the command conversion / sequence control unit 152 transfers to NE30 or a logical NE (set of disagreement devices 31) via communication processing units 153 to 155. Input a device command.

[Functional block (monitoring system)]
Next, the processing of the monitoring system of the operation system 100 will be described.
FIG. 7 is a diagram illustrating a functional block of the monitoring system of the operation system 100. The same components as those in FIG. 1 are designated by the same reference numerals.
The case where the device interface unit 150 receives the event notification from the NE 30A will be described as an example. Note that the common unit 110, the abstraction unit 130, the request reception unit 151 of the device interface unit 150, and the command conversion / sequence control unit 152 in FIG. 1 are not shown here.
As shown in FIG. 7, the device interface unit 150 of the operation system 100 includes an alarm / event notification conversion unit 156 and communication processing units 153 to 155.
The DB 120 (storage unit) includes an alarm / event notification definition file (CSV) 181, an alarm / event notification definition file (script) 182, an alarm / event notification type definition file (CSV) 183, and a device list file 184. And remember. The device list file 184 stores the vendor type / component device information (see FIG. 2).
The alarm / event notification type definition file (CSV) 183 is a notification type definition file of the definition file 20 (see FIG. 2) relating to the vendor name and model name of NE30 (for example, NE30A).

The alarm / event notification conversion unit 156 discriminates between the all-in-one device and the disagreement device, and assembles the alarm generation point according to the following rules (1) and (2). That is, (1) In the case of the all-in-one device, the alarm generation points are the NE name (physical) and the alarm generation site information. (2) In the case of the disagreement configuration, the alarm generation points are the NE name (logic), the component device name, and the alarm generation site information.

In the above configuration, the alarm / event notification conversion unit 156 of the device interface unit 150 receives the alarm / event notification from the NE 30A via the communication processing units 153 to 155. Then, the alarm / event notification conversion unit 156 refers to the device list file 184 and acquires a logical NE name (for example, AA) and a model name (for example, aa) using the IP address as a key (reference numeral i in FIG. 7). reference).
Next, as shown by reference numeral j in FIG. 7, the alarm / event notification conversion unit 156 identifies and reads the alarm / event notification type definition file 183 using the NE name and the model name as keys.

Then, as shown by the reference numeral k in FIG. 7, the alarm / event notification conversion unit 156 identifies and reads the alarm / event notification definition file 181 to be read next, which is shown in the alarm / event notification type definition file 183. The alarm / event notification conversion unit 156 refers to the alarm / event notification definition file (CSV) 181 or the alarm / event notification definition file (script) 182, and transmits the received alarm / event notification to the common unit 110 (see FIG. 1). Convert to a data model that can be processed by and output. That is, the alarm / event notification conversion unit 156 outputs the event notification independent of the vendor or model of the NE 30 to the common unit 110. After that, the common unit 110 outputs the content of this alarm / event notification to the operator terminal 1 (see FIG. 1) or the like.

The process when the alarm / event notification conversion unit 156 shown in FIG. 7 receives the alarm / event notification from the NE 30 will be described in detail with reference to FIG.
[Details of operation of alarm / event notification conversion unit 156]
FIG. 8 is a flowchart showing the operation of the alarm / event notification conversion unit 156 of the device interface unit 150.
The alarm / event notification conversion unit 156 of the device interface unit 150 receives the alarm / event notification from the NE 30 via the communication processing units 153 to 155 (step S40).
In step S41, the alarm / event notification conversion unit 156 identifies the vendor name and model name of the NE30 from the session information with the NE30 when the NE30 receives the alarm / event notification, and the identified vendor The alarm / event notification type definition file 183 to be called is specified from the name and model name.
In step S42, the alarm / event notification conversion unit 156 reads the called alarm / event notification type definition file 183 and identifies the alarm / event notification definition file (CSV) 181 related to the alarm / event notification received from NE30.

That is, first, the alarm / event notification conversion unit 156 refers to the identification information of NE30, which is the source of the event notification included in the session information, and the device list file 184 (vendor type / configuration device information), and causes an alarm / event notification. Specify the vendor name and model name of NE30, which is the source of the event notification. Then, the alarm / event notification conversion unit 156 starts with the alarm / event notification type definition file 183 of NE30 having the specified vendor name and model name, and the alarm / event notification definition file (CSV) 181 related to the alarm / event notification type. To identify.

In step S43, the alarm / event notification conversion unit 156 reads the identified alarm / event notification definition file (CSV) 181 and changes the event notification from NE30 to a common data model (a data model that can be processed by the common unit 110). To do.
Here, the alarm / event notification conversion unit 156 converts the "alarm occurrence point" information into information indicating a logical NE when the transmission source is the disagreement device 31. Specifically, the alarm / event notification conversion unit 156 assigns a logical NE name to the "NE name" when the transmission source is the disagreement device 31. Further, in "rackNo" and "shelfNo", rules are described in the alarm / event notification definition file (CSV) 181 for each disagreement device constituting the logical NE, so that the common unit 110 can be used. Notify as a logical NE component.
In step S44, the alarm / event notification conversion unit 156 returns a response (alarm / event notification changed to the common data model) to the common unit 110.

By doing so, the device interface unit 150 can display the alarm / event notification type definition file 183 and the alarm / event notification definition file (CSV) 181 even when receiving event notifications from NE30 of various vendors and models. By referring to this, the content of this alarm / event notification can be output to the operator terminal 1 of FIG. 1 via the common unit 110 and the input / output unit 210.

[Key information (device registration)]
Next, the processing of the key information (device registration) of the operation system 100 will be described.
FIG. 9 is a diagram illustrating key information (device registration) of the operation system 100. The same components as those in FIG. 1 are designated by the same reference numerals.
As shown by reference numeral l in FIG. 9, the operator terminal 1 performs a device registration process for registering the managed device in the operation system 100.

10A and 10B are diagrams showing an example of information input by the operator terminal 1 at the time of device registration, FIG. 10A is an example in the case of an all-in-one device, and FIG. 10B is an example in the case of a disagreement device.
First, in the device registration shown in FIG. 9, the management information of the all-in-one device shown in FIG. 10A is registered. For example, in the case of an all-in-one device, NE name = BB, vendor name = company X, model name = yy, IP address = 444.444.444.444, component device name =-, and other information are registered.
In addition, the management information of the disagri device shown in FIG. 10B is registered. For example, in the case of a disagreement device, NE name = AA, vendor name = multi, model name = multi, as component device name ・ Component device name = aa, IP address = 111.111.111.111
-Component name = bb, IP address = 222.222.222.222
-Component name = cc, IP address = 333.333.333.333
, Register other information.

In this way, in the device registration of the disaggregate device, the device name (logic) and each device information (name, IP address) included therein are input.
By the above device registration, the management information of the all-in-one device and the disagri device is registered in the DB 120 of the common unit 110 of FIG. FIG. 2 shows vendor type / constituent device information registered in the DB 120 of the common unit 110 at the time of device registration.
As shown in FIG. 2, in the case of the disagreement configuration, the NE name stores the logical NE names “AA” and “CC”, and the vendor name and the model name store “mult”. The component device name stores the name of each disaggregate device (aa, bb, ...), And the connection destination IP address stores "111. 111. 111. 111", "222. 222. 222. 222", and so on. ..
In this way, for the logical NE name, the vendor name and model name "mult", the component device names (aa, bb, cc), and the connection destination IP addresses "111. 111. 111. 111" and "222. 222. 222. 222 "and" 333. 333. 333. 333 "are registered at 1: N.

[Key information (control system)]
Next, the processing of the key information (control system) of the operation system 100 will be described.
FIG. 11 is a diagram illustrating key information (control system) of the operation system 100. The same components as those in FIG. 1 are designated by the same reference numerals.
As shown by the reference numeral m in FIG. 11, the operator terminal 1 performs a path registration process for registering a control order in the operation system 100.
Here, the control order is various registration / deletion / reference / update processes such as package registration and path registration.

FIG. 12 is a diagram showing an example of information input by the operator terminal 1 at the time of path registration.
At the time of path registration, the operator terminal 1 inputs the device name (logic) to be controlled, the target operation (function name), and various accompanying parameters.
In the information example of FIG. 12, various parameters required for the path registration process are input as NE name = AA, function name = path registration, and other information.

FIG. 13 is a diagram showing an example of distribution data from the common unit 110 to the abstraction unit 130.
As shown by reference numeral n in FIG. 11, the abstraction unit 130 acquires the vendor name and model name from the DB 120 of the common unit 110 and distributes them to the lower part.
In the distribution data example of FIG. 13, various parameters required for the path registration process are acquired as NE name = AA, vendor name = multi, model name = multi, function name = path registration, and other information.
As shown in FIG. 13, in the case of the disagreement configuration, “multi” is registered for both the vendor name and the model name.

FIG. 3 is a diagram showing an example of the multi-vendor control definition file 140.
As shown in FIG. 3, in the multi-vendor control definition file 140, for each # file name (setne.csv), the # vendor name (company A, company B, company C ...) and the name of each component device (aa, bb, cc, ...) Is memorized.
As shown by reference numeral o in FIG. 11, when the vendor name = “multi”, the abstraction unit 130 specifies the multi-vendor control definition file 140 using the function name = “path registration (setne)” as a key.

FIG. 11 is a diagram showing an example of distribution data from the abstraction unit 130 to the device interface unit 150.
As shown by reference numeral p in FIG. 11, the abstraction unit 130 overwrites the vendor name / model name with the value acquired from the multi-vendor control definition file 140 and distributes the product to the device interface unit 150.
In the distribution data example of FIG. 11, various parameters required for the path registration process are distributed as NE name = AA, vendor name = company A, model name = aa, function name = path registration, and other information.

[Key information (monitoring system)]
Next, the processing of the key information (monitoring system) of the operation system 100 will be described.
FIG. 15 is a diagram illustrating key information (monitoring system) of the operation system 100. The same components as those in FIG. 1 are designated by the same reference numerals. The abstraction unit 130, the request reception unit 151 of the device interface unit 150, the command conversion / sequence control unit 152, and the communication processing units 153 to 155 of FIG. 1 are not shown.
As shown by reference numeral q in FIG. 15, the device interface unit 150 receives an alarm / event notification from the NE 30A.

FIG. 16 is a diagram showing an example of alarm / event information notified from the network device (NE) 30A or the like.
As shown in FIG. 16, the alarm / event information has an IP layer and an SNMP layer. The IP layer has a source IP, a destination IP, and the like. In addition, the SNMP layer has various headers and VariableBindings, and the VariableBindings include an alarm generation point (for example, CONT), a time (for example, 2017: 06: 06), a trap type (for example, eqpt-arm), and so on. It has a disability level (eg, sa), a sensing importance (eg, critical), and the like.

As shown by reference numeral r in FIG. 15, the device interface unit 150 (alarm / event notification conversion unit 156 in FIG. 7) processes the received alarm / event information (see FIG. 16) by the common unit 110 (see FIG. 1). Convert to a possible data model.
At that time, in the case of a disagreement device, the "alarm generation point" information is converted into information indicating a logical NE. For example, a logical NE name is given to the "NE name". In addition, in "rackNo" and "shelfNo", rules are described in the definition file for each disaggregation device that constitutes a logical NE. Then, the common unit 110 is notified as a logical NE component.

FIG. 17 is a diagram showing an example of distribution data from the device interface unit 150 to the common unit 110.
As shown in FIG. 17, the data to the common unit 110 includes various headers that can be processed by the common unit 110, a notification type (for example, AlarmNotification), an alarm generation point (for example, NE name / rackNo / shelfNo / slotNo), and a time. (Eg, 2017: 06: 06), trap type (eg eqpt-arm), fault level (eg sa), perceived importance (eg critical). In this example, the "alarm generation point (CONT)" shown in FIG. 16 is rewritten to the "alarm generation point (NE name / rackNo / shelfNo / slotNo)" shown in FIG. 17, and the data can be processed by the common unit 110. Become.

As described above, the operation system 100 according to the present embodiment is information indicating the vendor type of the NE and the component device name of each abstract device for each logical NE identification information. -For the component device information and the control request for the logical NE, the multi-vendor control definition file 140 that defines each abstract device to be called and the calling order thereof, and the NE and the abstract device are discriminated from each other, and the abstract device is identified. In the case of, the abstraction unit 130 is provided with reference to the multi-vendor control definition file 120, which is decomposed into access requests for individual logic devices and the requests are transmitted. The abstraction unit 130 accepts the control order from the operator terminal 1 (see FIG. 1) with the logical network device as a single NE, and treats each physical disagreement device as a single NE. , Sends a command that transforms and maps a logical NE and a physical NE.

With this configuration, the operator of the operator terminal 1 does not have to be aware of each disagreement device, so that efficient operation and reduction of erroneous operations are possible. As a result, it is possible to efficiently manage the operation of the NE and the disagreement device while reducing the erroneous operation of the operator terminal 1.

Of the processes described in the above embodiments, all or part of the processes described as being automatically performed may be manually performed, or the processes described as being manually performed may be performed. All or part of it can be done automatically by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-mentioned document and drawings can be arbitrarily changed unless otherwise specified.
Further, each component of each of the illustrated devices is a functional concept, and does not necessarily have to be physically configured as shown in the figure. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or part of the device is functionally or physically distributed / physically in arbitrary units according to various loads and usage conditions. It can be integrated and configured.

Further, each of the above configurations, functions, processing units, processing means and the like may be realized by hardware by designing a part or all of them by, for example, an integrated circuit. In addition, each of the above configurations, functions, and the like may be realized by software for the processor to interpret and execute a program that realizes each function. Information such as programs, tables, and files that realize each function can be stored in memory, hard disks, recording devices such as SSDs (Solid State Drives), IC (Integrated Circuit) cards, SD (Secure Digital) cards, optical disks, etc. It can be held on a recording medium.

1 Operator terminal 20 Definition file 30 Network device (NE)
31 Disaggregation equipment (disaggregation equipment)
100 Operation system 110 Common part 120 Database (DB) (Storage part)
130 Abstraction unit 140 Multi-vendor control definition file 150 Device interface unit 151 Request reception unit 152 Command conversion / sequence control unit 153 to 155 Communication processing unit 156 Alarm / event notification conversion unit 171 Input order selection definition file (CSV)
172 Input order definition file (CSV)
173 Input order definition file (script)
174 Command sequence definition file (CSV)
175 Parameter conversion / sequence control definition file (script)
181 Alarm / event notification definition file (CSV)
182 Alarm / event notification definition file (script)
183 Alarm / event notification type definition file 184 Device list file 310 Logical NE

Claims (3)

It is an operation system for monitoring and controlling a network device and a disaggregation device in which the network device is separated and divided into small particles.
For each logical network device identification information, the vendor type / component device information, which is information indicating the vendor type of the network device and the component device name of each disaggregation device, and control for the logical network device. In response to a request, a multi-vendor control definition file that defines each of the disaggregation devices that make up the logical network device and its calling order, and a command sequence used to input commands to the network device of the vendor type and device type. The command sequence definition file showing the above, the input order definition file showing the application order of the command sequence definition file, and the input order definition file applied to realize the function for each function used at the time of command input. A storage unit that stores a definition file that includes a input order selection definition file that shows identification information,
The command is received by receiving the input of the control order to the network device, and the command is referred to by referring to the vendor type / configuration device information using the identification information of the network device to which the command included in the input control order is input as a key. A common part that specifies the vendor type and device type of the network device to which the input destination is
An abstraction that distinguishes between the network device and the disaggregation device, and in the case of the disaggregation device, decomposes the request into an access request for each of the disaggregation devices by referring to the multi-vendor control definition file. Department and
With reference to the specified vendor type and device type definition file, the input order selection definition file of the network device or the disaggregation device is specified, and the specified input order selection definition file and the input control order are specified. With reference to the identification information of the function required for inputting the command to the network device included in the above, the request receiving unit for specifying the input order definition file necessary for realizing the function, and
With reference to the specified input sequence definition file, the command sequence definition file is sequentially called in the order shown in the input sequence definition file, and based on the called command sequence definition file, the network device or the disaggregation device is sent. An operation system characterized by having a command conversion unit that sequentially executes command input. The abstraction part
While accepting a control order from the operator terminal with the logical network device as a single network device,
The request for the logical network device is changed to the individual request for each physical disaggregation device so that the individual physical disaggregation devices constituting the logical network device are treated as the single network device. The operation system according to claim 1, wherein the operation system is divided and the requests are executed in the order described in the multi-vendor control definition file. The definition file further
A notification information definition file showing definition information for converting event notifications from the network device into data used in the common part, and a notification type definition file showing the notification information definition file for each type of event notification. Is included for each vendor type and device type of the network device.
The operating system further
When the event notification from the network device is received, the vendor type / device type of the network device is specified by referring to the vendor type / configuration device information and the identification information of the network device that is the source of the event notification. , Refer to the notification type definition file in the specified vendor type and device type definition file, specify the notification information definition file related to the event notification type from the network device, and refer to the specified notification information definition file. Then, the event notification conversion unit that converts the event notification from the network device into the data used in the common unit and outputs it to the common unit is further provided.
The event notification conversion unit
The network device and the disaggregation device are discriminated from each other, and in the case of the disaggregation device, the alarm generation point information is converted into information indicating a logical network device and output to the common unit. The operation system according to claim 1.

Images