WO2022044190A1

WO2022044190A1 - Generating device, generating method, and generating program

Info

Publication number: WO2022044190A1
Application number: PCT/JP2020/032322
Authority: WO
Inventors: 剛史山田
Original assignee: 日本電信電話株式会社
Priority date: 2020-08-27
Filing date: 2020-08-27
Publication date: 2022-03-03

Abstract

A normalizing unit 152 of a generating device 100 generates first normalized data obtained by shaping, on the basis of a certain description order for each protocol, data transmitted and received over a network between a network appliance and a terminal device which carries out verification with respect to the network appliance. An evaluating unit 153 of the generating device 100 evaluates a degree of similarity between the first normalized data and a plurality of items of second normalized data obtained by shaping the data transmitted and received between the network appliance and the terminal device in a past verification time for the network appliance, in such a way that the certain description order is maintained. On the basis of the evaluation results obtained by the evaluating unit, a generating unit 154 of the generating device 100 generates scenario data corresponding to the first normalized data on the basis of scenario data of the second normalized data that are similar to the first normalized data.

Description

Generator, generation method and generation program

The present invention relates to a generator, a generator, and a generator.

There are various network devices such as MG (Media Gateway) in the core network of NGN (Next Generation Network) compliant with IMS (IP Multimedia Subsystem). Not all of these network devices are verified on the actual machine, and in many test cases, a pseudo terminal device that imitates a terminal is used to improve the efficiency of the verification work.

16 and 17 are diagrams for explaining the verification environment of the network device. FIG. 16 will be described. The terminal device 10A and the terminal device 10B transmit and receive a specified signal to and from the NW (Network) device 5a by a protocol such as SIP (Session Initiation Protocol) or RTP (Real time Transport Protocol), and the NW device 5a. Perform verification.

FIG. 17 will be described. The pseudo terminal device 15A is a device that can reproduce the operation of the terminal device 10A or the like by adjusting the confing 15A-1. The pseudo terminal device 15B is a device that can reproduce the operation of the terminal device 10B or the like by adjusting the confing 15B-1. The pseudo terminal device 15A and the pseudo terminal device 15B transmit and receive a specified signal to the NW device 5b by a protocol such as SIP or RTP to verify the NW device 5b.

Conventionally, telecom operators and communication equipment manufacturers have independently developed and operated pseudo-terminal devices, but nowadays, OSS (Open Source Software) terminal pseudo-devices are often used. For example, a typical OSS is software called "SIPp". By using SIPp, it is possible to edit operation standard information called a scenario, and it is possible to reproduce various operations in a terminal simulated device.

In the case of SIPp, there is also an OSS (scenario generation tool) called "pcap2sipp" that reproduces the scenario from the actual capture data. In pcap2sipp, it is used to reproduce an event that occurred in a commercial environment.

FIG. 18 is a diagram for explaining a conventional scenario generation tool. In a commercial environment, the terminal device 10A and the terminal device 10B verify the NW device 5a by transmitting and receiving a specified signal to the NW device 5a by a protocol such as SIP or RTP.

The scenario generation tool (pcap2sipp) 25 uses the captured data. The captured data captures data transmitted and received between the terminal device 10A (terminal device 10B) and the NW device 5a at the time of verification. The data transmitted / received between the terminal device 10A and the NW device 5a is referred to as capture data 11A. The scenario generation tool 25 generates a scenario (confing) 15A-2 based on the capture data 11A. The pseudo terminal device 15A reproduces the operation of the terminal device 10A based on the scenario 15A-2, and verifies the NW device 5b.

The data transmitted / received between the terminal device 10B and the NW device 5b is referred to as capture data 11B. The scenario generation tool 25 generates a scenario (confing) 15B-2 based on the capture data 11B. The pseudo terminal device 15B reproduces the operation of the terminal device 10B based on the scenario 15B-2, and verifies the NW device 5b.

However, with the conventional technology, there is a problem that scenarios cannot be automatically generated for the unique headers and complicated processing of telecommunications carriers.

For example, if the operation of the terminal device is simple, the scenario can be easily created by using the conventional scenario generation tool (pcap2sipp) 25, but it is complicated including the header and the service unique to the telecom operator. It is not possible to automatically create a scenario corresponding to various call processing, and a large operation is required to create the scenario. If it takes a lot of operation to create a scenario, it is not possible to quickly verify the problem event that occurred in the commercial environment in the verification environment.

The present invention has been made in view of the above, and an object of the present invention is to automatically generate a scenario for a telecommunications carrier's original header and complicated processing.

In order to solve the above-mentioned problems and achieve the object, the generator according to the present invention is transmitted and received between the network device and the terminal device that performs verification against the network device via the network. The normalization unit that generates the first normalized data in which the data is shaped based on the order of the description for each protocol, the network device, and the terminal device at the time of past verification of the network device. An evaluation unit that evaluates the degree of similarity between a plurality of second normalized data in which the data sent and received between the two is shaped so that a certain order of description is maintained, and the first normalized data, and the above. Based on the evaluation result of the evaluation unit, the generation unit that generates the scenario data corresponding to the first normalization data based on the scenario data of the second normalization data similar to the first normalization data. It is characterized by being prepared.

According to the present invention, it is possible to automatically generate a scenario for a telecom operator's own header and complicated processing.

FIG. 1 is a diagram showing an example of a system according to this embodiment. FIG. 2 is a diagram (1) for explaining a processing outline of the generator according to the present embodiment. FIG. 3 is a diagram (2) for explaining a processing outline of the generator according to the present embodiment. FIG. 4 is a schematic diagram illustrating a schematic configuration of the generator of the present embodiment. FIG. 5 is a diagram for explaining an example of a change in CALL-ID in a certain transfer service. FIG. 6 is a diagram showing an example of a data structure of data derived from a commercial event. FIG. 7 is a diagram showing an example of the data structure of the normalized data. FIG. 8 is a diagram showing an example of the data structure of the verification result-derived data table. FIG. 9 is a diagram (1) for explaining the processing of the normalization unit. FIG. 10 is a diagram (2) for explaining the processing of the normalization unit. FIG. 11 is a diagram (1) for explaining the processing of the generation unit. FIG. 12 is a diagram (2) for explaining the processing of the generation unit. FIG. 13 is a flowchart showing a processing procedure for normalizing the captured data. FIG. 14 is a flowchart showing a processing procedure for generating scenario data. FIG. 15 is a diagram showing an example of a computer that executes a generation program. FIG. 16 is a diagram for explaining a verification environment of network equipment. FIG. 17 is a diagram (1) for explaining a conventional scenario generation tool. FIG. 18 is a diagram (2) for explaining a conventional scenario generation tool.

Hereinafter, examples of the generator, the generation method, and the generation program disclosed in the present application will be described in detail with reference to the drawings. The present invention is not limited to this embodiment.

FIG. 1 is a diagram showing an example of a system according to this embodiment. As shown in FIG. 1, this system 1 includes a NW device 5,

terminal devices

10A and 10B, pseudo terminal devices 20A and 20B, and a generation device 100. The NW device 5, the

terminal devices

10A and 10B, the pseudo terminal devices 20A and 20B, and the generation device 100 are connected to each other via the network N.

The NW device 5 is compatible with various network devices such as MG. The NW device 5 is verified by the

terminal devices

10A and 10B and the pseudo terminal devices 20A and 20B. Here, the NW device 5 is shown, but the system 1 may have another NW device.

The

terminal devices

10A and 10B transmit and receive a specified signal to and from the NW device 5 based on a protocol such as SIP or RTP, and verify the NW device 5. Here, the

terminal devices

10A and 10B are shown, but the system 1 may include other terminal devices. In the following description, the

terminal devices

10A and 10B are collectively referred to as the terminal device 10. The captured data, which is the data transmitted / received between the terminal device 10 and the NW device 5, is referred to as “captured data”.

The pseudo terminal devices 20A and 20B reproduce the operation of the terminal device 10 using the scenario data generated by the generation device 100, and verify the NW device 5. The pseudo terminal devices 20A and 20B correspond to SIPp and the like. For example, the pseudo terminal devices 20A and 20B are realized by a computer or the like that executes a program of the pseudo terminal devices 20A and 20B. One computer may execute the programs of the pseudo terminal devices 20A and 20B to realize the pseudo terminal devices 20A and 20B, or a plurality of computers may execute the programs of the pseudo terminal devices 20A and 20B. Pseudo-terminal devices 20A and 20B may be realized.

Here, the pseudo terminal devices 20A and 20B are shown, but the system 1 may include other pseudo terminal devices. In the following description, the pseudo terminal devices 20A and 20B are collectively referred to as a pseudo terminal device 20.

The generation device 100 is a device that generates scenario data based on the capture data transmitted / received between the NW device 5 and the terminal device 10. The generation device 100 transmits the generated scenario data to the pseudo terminal device 20, and causes the pseudo terminal device 20 to reproduce the operation of the terminal device 10 to execute the verification of the NW device 5.

2 and 3 are diagrams for explaining the processing outline of the generator according to the present embodiment. FIG. 2 will be described. The capture data 141 includes an operation rule in which there is no rule of order (order regarding description) in RFC (Request For Comments) or the like. For example, the description order of the TO header and the FROM header in the INVITE header of SIP has no provision regarding the order.

The generation device 100 shapes the capture data 141 for each protocol so that a certain order of description is maintained, and converts it into data. For example, the generation device 100 generates the normalized data 30a by shaping (normalizing) the data related to SIP among the captured data 141. The generation device 100 generates the normalized data 30b by shaping the data related to RTP among the captured data 141. The generation device 100 generates the normalized data 30c by shaping the data related to the protocols other than SIP and RTP among the captured data 141. The normalized

data

30a, 30b, and 30c are collectively referred to as commercial event-derived data 142.

Move on to the explanation in Fig. 3. The generation device 100 has a plurality of verification result-derived

data

40, 41, 42. Here, the verification result-derived data 40 to 42 are shown, but the generation device 100 may have other verification result-derived data.

The verification result-derived data 40 to 42 are data used in the past verification for the NW device 5, and have normalized data formatted for each protocol so that a certain order of description is maintained. For example, the verification result-derived data 40 has normalized

data

40a, 40b, 40c. The verification result-derived data 41 has normalized

data

41a, 41b, 41c. The verification result-derived data 42 has normalized

data

42a, 42b, 42c.

For example, the normalized

data

40a, 41a, 42a are shaped data related to SIP. The normalized

data

40b, 41b, 42b are formatted data related to RTP. The normalized

data

40c, 41c, 42c are formatted data related to protocols other than SIP and RTP.

The verification result-derived data 40 is associated with the scenario data 40-0. The scenario data 40-0 is information that defines the operation when the terminal device that has transmitted / received the verification result-derived data 40 before shaping performs the verification of the NW device 5.

The verification result-derived data 41 is associated with the scenario data 41-1. The scenario data 41-1 is information that defines the operation when the terminal device that has transmitted / received the verification result-derived data 41 before shaping performs the verification of the NW device 5.

The verification result-derived data 42 is associated with the scenario data 42-2. The scenario data 42-2 is information that defines the operation when the terminal device that has transmitted / received the verification result-derived data 42 before shaping performs the verification of the NW device 5.

The generator 100 evaluates the degree of similarity between the characteristics of the verification result-derived data 40 to 42 and the characteristics of the commercial event-derived data 142. The generation device 100 generates scenario data 144 based on the evaluation result of the similarity.

When the characteristics of the data derived from a certain verification result and the characteristics of the data 142 derived from a commercial event match, the generation device 100 generates the scenario data 144 using the scenario data corresponding to the data derived from a certain verification result. For example, in the generator 100, when the verification result-derived data 40 and the commercial event-derived data 142 are the same except for a predetermined variable, the verification result-derived data 40 and the commercial event-derived data 142 match ( Exact match). In this case, the generation device 100 generates the scenario data 144 by replacing the variable of the scenario data 40-0 corresponding to the verification result-derived data 40 with the variable of the commercial event-derived data 142.

When the characteristics of the data derived from the plurality of verification results and the characteristics of the data 142 derived from the commercial event partially match, the generator 100 combines a plurality of scenario data corresponding to the data derived from the plurality of verification results to create a scenario. Generate data 144.

For example, the normalized data 30a of the commercial event-derived data 142 and the normalized data 40a of the verification result-derived data 40 match, and the normalized data 30b of the commercial event-derived data 142 and the normalized data of the verification result-derived data 41 are matched. When 41b matches and the normalized data 30c of the commercial event-derived data 142 and the normalized data 40c of the verification result-derived data 42 match, the commercial event-derived data 142 and the plurality of verification result-derived data 40 to It is evaluated that 42 is a partial match.

In this case, the generation device 100 includes the data corresponding to the normalized data 40a in the scenario data 40-0, the data corresponding to the normalized data 41b in the scenario data 40-1, and the scenario data 40-. Of 2, the scenario data 144 is generated by combining the data corresponding to the normalized data 42c and replacing the combined scenario variables with the variables of the commercial event-derived data 142.

As described above, the generator 100 according to the present embodiment generates the commercial event-derived data 142 by shaping the capture data 141 for each protocol so that a certain order is maintained, and generates the commercial event-derived data 142. The degree of similarity between the derived data 142 and the derived data of each verification result is evaluated. The generation device 100 generates scenario data 144 for reproduction from the scenario data corresponding to the data derived from each verification result based on the evaluation result of the similarity. This makes it possible to automatically generate a scenario from the telecom operator's own header and the capture data 141 corresponding to complicated processing.

Next, a schematic configuration of the generator 100 according to this embodiment will be described. FIG. 4 is a schematic diagram illustrating a schematic configuration of the generator according to the present embodiment. As shown in FIG. 4, the generation device 100 includes a communication control unit 110, an input unit 120, an output unit 130, a storage unit 140, and a control unit 150. The generation device 100 is realized by a general-purpose computer such as a personal computer.

The communication control unit 110 is realized by a NIC (Network Interface Card) or the like, and controls communication between an external device and the control unit 150 via a telecommunication line such as a LAN (Local Area Network) or the Internet.

The input unit 120 is realized by using an input device such as a keyboard or a mouse, and inputs various instruction information such as processing start to the control unit 150 in response to an input operation by the operator. The output unit 130 is realized by a display device such as a liquid crystal display, a printing device such as a printer, or the like.

The storage unit 140 has capture data 141, commercial event-derived data 142, verification result-derived data table 143, and scenario data 144. The storage unit 140 is realized by a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory (Flash Memory), or a storage device such as a hard disk or an optical disk.

The capture data 141 is data transmitted / received between the terminal device 10 and the NW device 5 when the terminal device 10 (or another terminal device) verifies the NW device 5 in a commercial environment. A CALL-ID is set for each signal in the capture data 141. The CALL-ID is converted to the CALL-ID each time it is transferred.

FIG. 5 is a diagram for explaining an example of a change in CALL-ID in a certain transfer service. In FIG. 5, the outgoing terminal 11, the SIP server 12, and the incoming terminals 13A, 13B, and 13C will be used for explanation. The data transmission / reception in FIG. 5 is based on SIP.

In a certain transfer service, the calling terminal 11 transmits an INVITE signal (Call-ID (1)) to the SIP server 12 (step S10). The SIP server 12 transmits an INVITE signal (Call-ID (2)) to the incoming terminal 13A (step S11). The incoming terminal 13A transmits a 4xx response signal (Call-ID (2)) to the SIP server 12 (step S12).

The SIP server 12 transmits a transfer INVITE signal (Call-ID (3)) to the incoming terminal 13B (step S13). The incoming terminal 13B transmits a 4xx response signal (Call-ID (3)) to the SIP server 12 (step S14).

The SIP server 12 transmits a transfer INVITE signal (Call-ID (4)) to the incoming terminal 13C (step S15). The incoming terminal 13C transmits a 200 response signal (Call-ID (4)) to the SIP server 12 (step S16). The SIP server 12 transmits a 200 response signal (Call-ID (1)) to the calling terminal 11 (step S17).

Return to the explanation in Fig. 4. The commercial event-derived data 142 is data generated by normalizing the capture data 141. The commercial event-derived data 142 is formatted based on a certain order of description for each protocol. Further, the user information (electric number, domain, IP) and the like included in the capture data 141 are normalized as abstract information (electric number A, domain A, IP-A) that does not change for each call. The identification information for each call such as CALL-ID is also abstracted so that the fluctuations such as CALL-ID-A and CALL-ID-B can be understood in order to observe the fluctuations in the call.

FIG. 6 is a diagram showing an example of a data structure of data derived from a commercial event. As shown in FIG. 6, this commercial event-derived data associates the protocol with the normalized data. In FIG. 6, normalized data is associated with each of the protocols “SIP”, “RTP”, and “other protocols”. The normalized data corresponding to the protocols "SIP", "RTP", and "other protocols" are defined as normalized data 30a to 30c, respectively.

FIG. 7 is a diagram showing an example of the data structure of the normalized data. The normalized data has a plurality of elements, and data in which the operation of each communication (INVITE signal, response signal, etc.) is normalized is registered in each element. In FIG. 7, as an example, data (normalized data) obtained by normalizing the data transmitted / received in steps S11 to S15 of FIG. 5 will be described.

For example, the element E1 stores data obtained by normalizing the INVITE signal of step S11 in FIG. The data obtained by normalizing the 4xx response signal in step S12 in FIG. 5 is omitted as an example.

The element E2 stores the normalized data of the transfer INVITE signal in step S13 of FIG. The element E3 stores data obtained by normalizing the 4xx response signal of step S14 in FIG. The element E4 stores data obtained by normalizing the transfer INVITE signal in step S15 of FIG. The element E5 stores data obtained by normalizing the 200 response signal of step S16 in FIG.

The verification result-derived data table 143 is a table that holds a plurality of verification result-derived data. FIG. 8 is a diagram showing an example of the data structure of the verification result-derived data table. As shown in FIG. 8, the verification result-derived data table 143 associates the identification information, the protocol, the normalized data, and the scenario data.

The identification information is information that identifies the data derived from the verification result. The protocol indicates the protocol used in the verification. Normalized data is data in which the operation of communication is normalized. The scenario data is associated with the data derived from the verification result. The scenario data may be associated with each protocol. In FIG. 8, as an example, a case where scenario data is associated with each protocol will be described, but the present invention is not limited to this.

For example, the normalized data 40a to 40c are associated with the scenario data SC0a to SC0c, respectively. The normalized data 41a to 41c are associated with the scenario data SC1a to SC1c, respectively. The normalized data 42a to 42c are associated with the scenario data SC2a to SC2c, respectively.

In the following explanation, the normalized data of each protocol corresponding to the same identification information in FIG. 8 is collectively referred to as the verification result-derived data. For example, the normalized data 40a to 40c of each protocol included in the identification information “V40” are collectively referred to as the verification result-derived data 40. The normalized data 41a to 41c of each protocol included in the identification information "V41" are collectively referred to as the verification result-derived data 41. The normalized data 42a to 42c of each protocol included in the identification information "V42" are collectively referred to as the verification result-derived data 42.

Return to the explanation in Fig. 4. The scenario data 144 is scenario data corresponding to the commercial event-derived data 142. The scenario data 144 is generated by the generation unit 154 described later.

The control unit 150 has an acquisition unit 151, a normalization unit 152, an evaluation unit 153, a generation unit 154, and a notification unit 155. The control unit 150 corresponds to a CPU (Central Processing Unit) or the like.

The acquisition unit 151 captures data transmitted and received between devices in a commercial environment. For example, the acquisition unit 151 acquires data transmitted / received between the terminal device 10 and the NW device 5 as capture data 141. The acquisition unit 151 stores the acquired capture data 141 in the storage unit 140. The acquisition unit 151 may acquire the capture data 141 from an external device (capture device) or the like.

The normalization unit 152 generates data 142 derived from commercial events by shaping (normalizing) the capture data 141 for each protocol based on a certain order of description. For example, the normalization unit 152 performs normalization in which the description order of various headers included in the signal (INVITE signal, response signal) is rearranged in a predetermined order. The normalization unit 152 makes it easy to compare user information variables such as telephone numbers and IP addresses contained in signals from the data of the development environment and the data of the commercial environment from the unique values. Convert to a predetermined value, such as IP2.

9 and 10 are diagrams for explaining the processing of the normalization unit. FIG. 9 will be described. In the example shown in FIG. 9, a case where the initial INVITE signal 50A of a certain call A is normalized will be described. The description order of the header of the initial INVITE signal 50A is INVITE sip, Via, Max-Forwoards, Call-ID, From, To, Route, CSeq. The initial INVITE signal 50A includes user information variables in regions 1a to 1g. In the initial INVITE signal 50A, the identification information of CALL-ID is included in the region 1h.

The normalization unit 152 changes the description order of the header to a predetermined fixed description order. If the header description order is already a fixed description order, the header description order is left as it is. For example, if the fixed description order is INVITE sip, Via, Max-Forwoards, Call-ID, From, To, Route, CSeq, the description order of the header of the initial INVITE signal 50A is a fixed description order. Therefore, the normalization unit 152 keeps the description order of the header of the initial INVITE signal 50A as it is.

The normalization unit 152 abstracts the user information variables in the areas 1a to 1g into predetermined information. For example, the normalization unit 152 converts the user information variable "4002001@pbx.jp" in the area 1a into "telephone number A domain A". The normalization unit 152 converts the user information variable "192.168.10.8:20001" in the area 1b into "VIP-IP-A". The normalization unit 152 converts the user information variable "z9hG4bk-22306-1-0" in the area 1c into "VIABRA-A".

The normalization unit 152 converts the user information variable "gCJoW2002001@pbx.jp" in the area 1d into "telephone number B domain A". The normalization unit 152 converts the user information variable "22306 SIPpTag091" in the area 1e into "FROMTAG-A". The normalization unit 152 converts the user information variable "4002001@pbx.jp" in the area 1f into "telephone number A domain A". The normalization unit 152 converts the user information variable "sip: 192.168.10.123:35790;lr" in the area 1g into "ROUTE-IP-A". The normalization unit 152 converts the identification information "inv // / 1-22306@192.168.10.8" of the area 1h into "Call-ID-A".

When the normalization unit 152 executes the above process, the initial INVITE signal 50A is normalized to become a normalized signal 60A.

FIG. 10 will be described. In the example shown in FIG. 10, a case where the initial INVITE signal 51A of a certain call B is normalized will be described. The description order of the header of the initial INVITE signal 51A is INVITE sip, Via, Call-ID, Max-Forwoards, To, From, Route, CSeq. The initial INVITE signal 51A includes user information variables in regions 1a to 1g. In the initial INVITE signal 51A, the identification information of CALL-ID is included in the region 1h.

The normalization unit 152 changes the description order of the header to a certain description order. The normalization unit 152 changes the description order of the header of the initial INVITE signal 51A from "INVITE sip, Via, Call-ID, Max-Forwoards, To, From, Route, CSeq" to "INVITE sip, Via, Max-Forwoards," Convert to "Call-ID, From, To, Route, CSeq".

The normalization unit 152 abstracts the user information variables in the areas 1a to 1g into predetermined information. For example, the normalization unit 152 converts the user information variable “5002001@pbx.jp” in the area 1a into the “telephone number A domain A”. The normalization unit 152 converts the user information variable "192.168.10.8:20001" in the area 1b into "VIP-IP-A". The normalization unit 152 converts the user information variable "z9hG4bK-22306-1-0" in the area 1c into "VIABRA-A".

The normalization unit 152 converts the user information variable "gCJoW2002001@pbx.jp" in the area 1d into "telephone number B domain A". The normalization unit 152 converts the user information variable "22306 SIPpTag091" in the area 1e into "FROMTAG-A". The normalization unit 152 converts the user information variable "5002001@pbx.jp" in the area 1f into "telephone number A domain A". The normalization unit 152 converts the user information variable "sip: 192.168.10.123:35790;lr" in the area 1g into "ROUTE-IP-A". The normalization unit 152 converts the identification information "xxx // / 1-22306@192.168.10.8" of the area 1h into "Call-ID-A".

When the normalization unit 152 executes the above process, the initial INVITE signal 51A is normalized to become the normalized signal 61A.

The initial INVITE signal 50A before normalization and the initial INVITE signal 51A have different header information and cannot be determined as similar data. However, by normalizing, the normalized signal 60A and the normalized signal 61A can be compared. can. Since the normalized signal 60A and the normalized signal 61A completely match, it is determined that the INVITE signal is used for a call having the same operation.

The normalization unit 152 generates a normalization signal for each signal by repeatedly executing the above processing for a plurality of signals for each protocol included in the capture data 141. The normalization unit 152 generates the commercial event-derived data 142 by setting a normalization signal for each element constituting the normalization data in association with the protocol, and registers the data 142 in the storage unit 140. As described with reference to FIG. 6, the commercial event-derived data 142 has normalized data set for each protocol, and as described with FIG. 7, the normalized data has a normalized signal set for each element. And it is vectorized.

By the way, the normalization unit 152 executes the same process as the process of generating the commercial event-derived data 142 based on the capture data 141 to generate the normalized data of the verification result-derived data table 143. And. The normalization unit 152 obtains the captured data before normalization of the data derived from the verification result in advance, and formats (normalizes) the data derived from the verification result based on a certain order of description for each protocol to derive the verification result. Data normalization Data is generated and registered in the verification result-derived data table 143. The scenario data corresponding to each protocol of the verification result-derived data is set in advance.

Return to the explanation in Fig. 4. The evaluation unit 153 evaluates the similarity between the commercial event-derived data 142 and the plurality of verification result-derived data registered in the verification result-derived data table 143. Here, as an example, it is assumed that the verification result-derived data 40 to 42 are registered in the verification result-derived data table 143.

The evaluation unit 153 compares the commercial event-derived data 142 with the verification result-derived data 40 to 42, and determines whether or not they match. For example, the evaluation unit 153 matched when the normalized data of each protocol of the commercial event-derived data 142 and the normalized data of each protocol of the verification result-derived data 41 all matched (exactly matched). The identification information "V41" of the verification result-derived data 41 is output to the generation unit 154.

On the other hand, the evaluation unit 153 compares the commercial event-derived data 142 with the verification result-derived data 40 to 42, and if there is no matching verification result-derived data, does it match for each protocol normalized data? Judge whether or not (evaluate partial match).

For example, the normalized

data

30a and 30c of the commercial event-derived data 142 and the normalized data 41a and 41c of the verification result-derived data 40 match, and the normalized data 30b of the commercial event-derived data 142 and the verification result-derived data 41. It is assumed that the normalized data 42b of the above matches.

In this case, the evaluation unit 153 evaluates that the commercial event-derived data 142 and the verification result-derived data 40 to 42 partially match, and the identification information (protocol) “V41 (SIP, another protocol)”, “. "V42 (RTP)" is output to the generation unit 154.

The generation unit 154 generates scenario data 144 corresponding to the commercial event-derived data 142. 11 and 12 are diagrams for explaining the processing of the generation unit. FIG. 11 will be described. When the generation unit 154 acquires that the verification result-derived data 41 (identification information: V40) and the commercial event-derived data match (exact match), the generation unit 154 uses the scenario data 40-1 of the verification result-derived data 41. Divert. The scenario data 40-1 corresponds to the scenario data SC1a, SC1b, SC1c described with reference to FIG.

The generation unit 154 generates the scenario data 144 by replacing the variables of the verification event included in the scenario data 40-1 with the variables of the commercial event.

FIG. 12 will be described. FIG. 12 describes the processing of the generation unit 154 in the case of partial matching, and the generation unit 154 receives identification information (protocol) “V41 (SIP, other protocol)” and “V42 (V 42) from the evaluation unit 153. RTP) ”is assumed to have been acquired. This coincides with the normalized

data

30a and 30c of the commercial event-derived data 142 and the normalized data 41a and 41c of the verification result-derived data 41, and the normalized data 30b of the commercial event-derived data 142 and the verification result-derived data. It is shown that the normalized data 42b of 42 is matched.

In this case, the generation unit 154 diverts the scenario SC1a corresponding to the normalized data 41a, the scenario SC1c corresponding to the normalized data 41c, and the scenario SC2b corresponding to the normalized data 42b. The generation unit 154 combines the scenario data SC1a, SC1c, and SC2b, and replaces the variable of the verification event included in the combined scenario data with the variable of the commercial event to generate the scenario data 144.

Return to the explanation in Fig. 4. The notification unit 155 transmits the scenario data 144 generated by the generation unit 154 to the computer that executes the program of the pseudo terminal device 20. The pseudo terminal device 20 verifies the NW device 5 using the scenario data 144.

Next, an example of a processing procedure in which the generation device 100 according to this embodiment normalizes the capture data will be described. FIG. 13 is a flowchart showing a processing procedure for normalizing the captured data. As shown in FIG. 13, the acquisition unit 151 of the generation device 100 acquires the capture data 141 (step S101).

The generation device 100 specifies the operation of each communication corresponding to the unselected protocol (step S102). The normalization unit 152 of the generation device 100 generates a normalized signal for each operation by normalizing the operation (signal) of each communication included in the capture data 141 (step S103). The normalization unit 152 generates normalization data of the selected protocol by setting the normalization signal to the element of each vector (step S104).

If there is an unselected protocol (step S105, Yes), the normalization unit 152 shifts to step S102. If there is no unselected protocol (step S105, No), the normalization unit 152 ends the process.

Next, an example of a processing procedure in which the generation device 100 according to this embodiment generates scenario data will be described. FIG. 14 is a flowchart showing a processing procedure for generating scenario data. As shown in FIG. 14, the evaluation unit 153 of the generator 100 evaluates the similarity between the commercial event-derived data 142 and the plurality of verification result-derived data (step S201).

When the data derived from the verification result that completely matches exists (step S202, Yes), the generation unit 154 of the generation device 100 shifts to the process of step S203. On the other hand, if the data derived from the verification result that completely matches does not exist (step S202, No), the generation unit 154 shifts to the process of step S205.

Step S203 will be described. The generation unit 154 acquires the scenario data corresponding to the data derived from the verification result that completely matches (step S203). The generation unit 154 generates the scenario data 144 of the commercial event-derived data by replacing the variables included in the scenario data with the variables of the commercial event-derived data (step S204).

Step S205 will be described. If there is a partial match with the data derived from the plurality of verification results (steps S205, Yes), the generation unit 154 shifts to the process of step S206. On the other hand, if the data derived from the plurality of verification results do not partially match (steps S205, No), the generation unit 154 ends the process.

Step S206 will be described. The generation unit 154 acquires scenario data of a plurality of partially matched verification result-derived data (step S206). The generation unit 154 generates scenario data 144 of commercial event-derived data by combining each scenario data of a plurality of verification result-derived data (step S207).

Next, the effect of the generator 100 according to this embodiment will be described. The generation device 100 generates commercial event-derived data 142 by shaping the capture data 141 for each protocol so that a certain order of description is maintained, and the commercial event-derived data 142 and each verification result. Evaluate the degree of similarity with the origin data. The generation device 100 generates scenario data 144 for reproduction from the scenario data corresponding to the data derived from each verification result based on the evaluation result of the similarity. This makes it possible to automatically generate a scenario from the telecom operator's own header and the capture data 141 corresponding to complicated processing.

The generator 100 evaluates the degree of similarity between the data derived from the commercial event 142 and the data derived from each verification result, and if there is data derived from the verification result that completely matches, the data derived from the verification result that exactly matches corresponds to the data derived from the verification result. Scenario data 144 is generated by replacing the variables of the scenario data with the variables of the data derived from the commercial event. Therefore, the scenario data 144 can be efficiently generated by diverting the scenario data corresponding to the data derived from the verification result that completely matches.

The generation device 100 combines the commercial event-derived data 142 and each scenario data of the partially matched verification result-derived data when there are a plurality of partially matched verification result-derived data to generate the scenario data 144. Generate. Therefore, the scenario data 144 can be generated even when there is no data derived from the verification result that completely matches.

The generation device 100 normalizes a plurality of verification result-derived data included in the verification result-derived data table 143. This makes it possible to compare the data derived from the commercial event 142 with the data derived from the verification result.

The generation device 100 transmits the generated scenario data 144 to the pseudo terminal device 20 to execute the verification of the NW device 5. As a result, after the capture data 141 is given to the generation device 100, the verification can be executed promptly.

It is also possible to create a program in which the processing executed by the generation device 100 according to the above embodiment is described in a language that can be executed by a computer. As one embodiment, the generation device 100 can be implemented by installing a generation program that executes the above selection process as package software or online software on a desired computer. For example, by causing the information processing device to execute the above generation program, the information processing device can be made to function as the generation device 100. The information processing device referred to here includes a desktop type or notebook type personal computer. In addition, information processing devices include smartphones, mobile communication terminals such as mobile phones and PHS (Personal Handyphone System), and slate terminals such as PDAs (Personal Digital Assistants). Further, the function of the generation device 100 may be implemented in the cloud server.

FIG. 15 is a diagram showing an example of a computer that executes a generation program. The computer 1000 has, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these parts is connected by a bus 1080.

The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1031. The disk drive interface 1040 is connected to the disk drive 1041. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1041. For example, a mouse 1051 and a keyboard 1052 are connected to the serial port interface 1050. For example, a display 1061 is connected to the video adapter 1060.

Here, the hard disk drive 1031 stores, for example, the OS 1091, the application program 1092, the program module 1093, and the program data 1094. Each of the information described in the above embodiment is stored in, for example, the hard disk drive 1031 or the memory 1010.

Further, the generated program is stored in the hard disk drive 1031 as, for example, a program module 1093 in which a command executed by the computer 1000 is described. Specifically, the program module 1093 in which each process executed by the generation device 100 described in the above embodiment is described is stored in the hard disk drive 1031.

Further, the data used for information processing by the generation program is stored as program data 1094 in, for example, the hard disk drive 1031. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the hard disk drive 1031 into the RAM 1012 as needed, and executes each of the above-mentioned procedures.

The program module 1093 and the program data 1094 related to the generation program are not limited to the case where they are stored in the hard disk drive 1031. For example, they are stored in a removable storage medium and read by the CPU 1020 via the disk drive 1041 or the like. May be done. Alternatively, the program module 1093 and the program data 1094 related to the generated program are stored in another computer connected via a network such as a LAN or WAN (Wide Area Network), and are read out by the CPU 1020 via the network interface 1070. You may.

Although the embodiment to which the invention made by the present inventor is applied has been described above, the present invention is not limited by the description and the drawings which form a part of the disclosure of the present invention according to the present embodiment. That is, other embodiments, examples, operational techniques, and the like made by those skilled in the art based on the present embodiment are all included in the scope of the present invention.

100 Generator 110 Communication control unit 120 Input unit 130 Output unit 140 Storage unit 141 Capture data 142 Commercial event-derived data 143 Verification result-derived data table 144 Scenario data 150 Control unit 151 Acquisition unit 152 Normalization unit 153 Evaluation unit 154 Generation unit 155 Notification section

Claims

First normalization in which data transmitted and received between a network device and a terminal device that executes verification against the network device via the network is shaped based on a certain order of description for each protocol. The normalization part that generates the data and
At the time of past verification of the network device, a plurality of second normalized data obtained by shaping the data transmitted / received between the network device and the terminal device so as to maintain a certain order of description. , An evaluation unit that evaluates the degree of similarity to the first normalized data,
With a generation unit that generates scenario data corresponding to the first normalization data based on the scenario data of the second normalization data similar to the first normalization data based on the evaluation result of the evaluation unit. A generator characterized by comprising.
Based on the evaluation result of the evaluation unit, the generation unit is a variable of scenario data corresponding to the second normalization data when the first normalization data and the second normalization data match. The generation device according to claim 1, wherein the scenario data corresponding to the first normalization data is generated by replacing the above with a variable of the first normalization data.
The generation unit is based on the evaluation result of the evaluation unit, and when there are a plurality of second normalization data that partially match the first normalization data, the plurality of second normalization data that partially match. The generator according to claim 1 or 2, wherein the scenario data corresponding to the first normalization data is generated by combining a plurality of scenario data corresponding to the above.
The normalization unit shapes a plurality of data transmitted / received between the network device and the terminal device at the time of past verification so that a certain order of description is maintained for each protocol. The generator according to claim 1, wherein the plurality of second normalized data are generated.
The generation device according to claim 1, further comprising a transmission unit that transmits scenario data generated by the generation unit to a pseudo terminal device to execute verification against the network device.
First normalization in which data transmitted and received between a network device and a terminal device that executes verification against the network device via the network is shaped based on a certain order of description for each protocol. The normalization process to generate the data and
At the time of past verification of the network device, a plurality of second normalized data obtained by shaping the data transmitted / received between the network device and the terminal device so as to maintain a certain order of description. , An evaluation step for evaluating the degree of similarity with the first normalized data,
A generation step of generating scenario data corresponding to the first normalization data based on the scenario data of the second normalization data similar to the first normalization data based on the evaluation result of the evaluation process. A generation method characterized by having a computer execute.
First normalization in which data transmitted and received between a network device and a terminal device that executes verification against the network device via the network is shaped based on a certain order of description for each protocol. The normalization procedure to generate the data and
At the time of past verification of the network device, a plurality of second normalized data obtained by shaping the data transmitted / received between the network device and the terminal device so as to maintain a certain order of description. , The evaluation procedure for evaluating the similarity with the first normalized data, and
A generation procedure for generating scenario data corresponding to the first normalization data based on the scenario data of the second normalization data similar to the first normalization data based on the evaluation result of the evaluation procedure. A generator characterized by having a computer execute.