JPH04167737A - Protocol test equipment - Google Patents

Abstract

PURPOSE:To avoid occurrence of a trouble after installation of a terminal equipment by comparing all the received 2nd message data with a stored 1st message data one by one byte each to check the propriety of a received 2nd message data every time the 2nd message data is received from a terminal equipment. CONSTITUTION:A test equipment 1 testing a protocol of an ISDN terminal equipment consists of a personal computer 2 having a function of the ISDN layer 3 or over and trunk line boards 3, 4 having a function of layers 1, 2 at the network side of a point T interface. Then every time a 2nd message data is received from an ISDN terminal equipment 5 to be tested, all the received 2nd message data and a stored 1st message data are compared one by one byte each to check the propriety. Thus, a problem that a trouble due to parts not checked by the test equipment takes place at the installation of the equipment is avoided.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a protocol tester that tests the protocol of a terminal device connected to an ISDN network.

[Prior Art] Conventionally, a protocol tester that tests a terminal device connected to an ISDN network from the network side's perspective uses a "call setup" message when performing a confirmation test on message data sent from the terminal device. When receiving a layer 3 message such as a message or a "response" message, only the message data indicating the type of layer 3 message is checked, and if this matches the expected data, the terminal device is operating normally. It is determined that

[Problems to be Solved by the Invention] The conventional protocol tester described above checks only a part of the message data sent from the terminal device, and if this is normal, the entire operation of the terminal device is normal. Therefore, when this device is actually installed on the market, there will be problems caused by parts that are not checked by the testing machine.

There was a problem that occurred.

[Means for Solving the Problems] In order to solve such problems, a protocol tester according to the present invention includes a storage means for storing first message data to be transmitted from a terminal device, and a first message data for storing first message data to be transmitted from a terminal device. the second message data and the first message data stored in the storage means.
The second message data is compared with the second message data on a pie-by-pie basis to check whether all the second message data is correct or not.

[Operation] Every time the second message data is received from the terminal device,
All of the received second message data and all of the first message data stored in the storage means are compared and checked one by one.

[Example] Next, the present invention will be explained with reference to the drawings.

FIG. 1 is a block diagram showing an embodiment of the protocol tester of the present invention. In the figure, reference numeral 1 is a test device for testing the protocol of ISDN terminals, which includes a personal computer 2 that has functions of ISDN layer 3 or higher, and a central office line board that has functions of layers 1 and 2 on the network side of the T-point interface, which will be described later. It consists of 3 and 4. The personal computer 2 is composed of a CPU 2a, a display section 2b, a keyboard 1' 2c, a floppy disk (hereinafter referred to as FD) and a life 2d. , channel switch 3C
, a tone melody generator 3d, a personal computer interface 3e, 3f, and an 8-bin modular 3g.The 8-pin modular 3g is a T point (2B+D) shown by symbol 6, and the I SDN terminal under test is at this T point. 5 is connected.

Further, the office line hoard 4 is composed of a 1-interface line control circuit 4b, a personal computer interface 4e, and an 8-pin modular 4g, and the 8-pin modular 4g is a point T shown by symbol 7.

Test data is stored on this protocol testing machine, and based on this test data, the protocol for calling the SDN terminal 5 under test and the protocol for the call receiving function for incoming calls to this terminal 5 are determined. Each will be tested. That is, by displaying a message that arrives through the operation of the ISDN terminal 5 under test on the display section 2bfX, and by detecting a match between this message data and a pre-stored test take, a calling test of the terminal 5 can be performed. can. Also, by making a call to the terminal 5 based on the test data such as the "call setting" message stored in the protocol testing device 1 and having the call arrive at the terminal 5, the "response" message etc. sent from the terminal 5 is received. At the same time, by detecting a match between the received message data and pre-stored test data, it is possible to perform an incoming call test on the terminal 5.

Next, FIG. 2 is a perspective view of the testing machine shown in FIG. 1. As described above, the progress status of the test of the ISDN terminal under test connected to the tester 1 via the 8-bin modular 3g is displayed one by one on the display unit 2bl. Note that the keyboard 2C is not shown in FIG. 2. In addition, in the case of a call origination test and an incoming call test, the ISDN terminal under test 5 is placed at one T point.
It is sufficient to just connect the symbol 6.7 in case of exchange test.
It is necessary to connect the ISDN terminal under test to both T points shown in .

Next, FIGS. 3 to 8 are flowcharts of the CPU 2a that operates the protocol tester 1. First, the basic operation of this protocol test will be explained with reference to the flowchart shown in FIG.

Test data for testing the SDN terminal 5 under test I is created and stored in the FD, and this FD is transferred to the FD drive 2.
d, in step 30 this test data is read from the FD, the comment line is deleted, and it is saved in the test data buffer in the CPU 2a. Subsequent protocol tests are performed based on the test take saved in this test buffer. That is, step 31
Now read this saved test take, check its syntax, and if it is normal, proceed to step 33.
starts execution of command processing corresponding to each command. This command processing is performed by the ISD under test as described below.
By transmitting test data, that is, a transmission command, to the N terminal 5, a reception command corresponding to this transmission command is detected from the I SDN terminal under test 5, and test data such as a reception command in which this command is stored in advance is generated. It is determined by detecting whether or not it matches.

After that, the input of the ESC (escape) key in the keyboard 2c is determined, and if the ESC key is not operated, it is determined in step 35 that the command ends, that is, the end of the above command processing, and if this command processing does not end, The process returns to step 33 to continue the command processing, but if the command processing is completed and it is determined as YJ in step 35, the contents of the test result practical buffer in the CPU 2a in which test result data based on the test data are stored. F
D (step 36).Also, if it is determined that there is an abnormality in the syntax check of the test data (step 3).
Similarly, if an abnormality occurs during command processing and command processing is aborted due to the ESC key being operated ("Y" in step 34), the test results and practical use are performed in step 36. The contents of the buffer are recorded on the FD.

Next, the command processing shown in FIG. 4 will be explained. In step 40, one command is read from the test data buffer in which test data is stored, and in step 41 it is determined whether this command is a transmission command or not. If this command is a transmission command such as a "call setup" message, transmission command processing, which will be described later, is performed in step 42. Further, if the command read from the test data buffer is a received command such as a "Call Setup Accepted" message, the determination in step 43 is "Y", and in this case, the received command processing described later is performed in step 44. . Further, if the read command is a timer command, a determination of "Y" is made in step 45, and in this case, timer command processing, which will be described later, is performed in step 46.

Next, details of the timer command processing will be explained with reference to FIG. This timer command sets a wait time between test data transmission and reception of a command indicating a response from the ISDN terminal under test 5 in response to the test data transmission. First, in step 50, a display process is performed to display test data indicating timer processing contents stored in the test buffer on the display section 2b. Then, in step 51, the data of the timer processing contents are saved in the test result practical buffer, and the timer processing is started. And after that
In step 52, it is determined whether the ESC key is pressed. and E
If the S'C key is operated, it means that an error has occurred in the timer process and the process ends.
ESC key operation is not detected and "N" is returned in step 52.
If it is determined that the execution of the timer process is completed, it is determined in step 53 that the execution of the timer process is finished, and if this is determined to be "Y", the process is directly terminated.

Next, details of the transmission command processing for transmitting test data indicating the transmission command to the ISDN terminal under test 5 will be explained with reference to the flowchart of FIG.

For example, when an ISDN layer 3 "call setup" message is transmitted from the ISDN terminal under test 5 and received, the call reference value of this message is detected, and in step 60, if the call number is **, the call number is The latest call number value in the number storage area is used, and if there is no call number in the call number storage area, the call number value at this time is set to "1". If the call number is #n, processing is performed to use the call number value stored in the call number storage area n.

Also, when the ISDN layer 2 "link establishment" command is transmitted from the ISDN terminal under test 5 and received, the TEI value indicating the terminal identification number is detected from the command, and in step 61 this TEI is * *If so, TE
The latest TEI value in the I storage area is used, and if 'rEI does not exist in the TEI storage area, the TEI value at this time is set to "40" (HEX value). Further, if it is TEI or #n, processing is performed to use the TEI value stored in TEI storage area n.

Then, in step 62, a transmission process is performed in which these call numbers or TEI values to be used are inserted into a predetermined place in a message to be transmitted to the terminal 5, and then transmitted to the terminal 5. A display process is performed to display this transmitted message on the display section 2b. Thereafter, in step 64, this transmitted message is saved in the test output buffer.

In other words, the test machine is designed to insert the call reference value sent from the terminal 5 as is into the message to be sent to the terminal 5 and send it back so that continuous testing can be performed. be. Furthermore, the TEI value sent from the terminal 5 is inserted into the message to be sent to the terminal 5 and sent back.

Next, details of the reception command processing for receiving reception command data from the ISDN terminal under test 5 will be explained with reference to the flowchart of FIG.

When the ISDN terminal under test 5 is operated, transmission data from the terminal 5 will arrive at the test device 1. In step 70, first, it is determined whether the ESC key has been pressed. This ESC key is operated when an error or the like occurs during reception of transmission data from the terminal 5. If it is determined to be either this or "Y", it means that a reception error has occurred, and the process can be interrupted and terminated, or
If no ESC key operation is detected, step 71
If the data to be received arrives from the terminal 5 and the determination in step 71 is "Y", data reception processing is performed in step 72. Then, in step 73, this received data, that is, the received message, is safed in the test output buffer, and if the received message is a layer 3 "call setup" message, the call reference value of this "call setup" message is saved as the call number. Save in area (step 74). Note that this saved call number value is transmitted as is when the transmitted message is returned to the terminal 5, if necessary. Also, the message received from terminal 5 or "link establishment" indicating the establishment of a layer 2 link.
If it is a command, the TEI value is saved in the TET storage area in step 75, and received message matching confirmation processing, which will be described later, is performed in step 76. In addition,
This saved TEI value is transmitted as is when the transmitted message is returned to the terminal 5, if necessary.

Next, FIG. 8 is a flowchart showing details of the above-described received message matching confirmation process.

Conventionally, checking when receiving a message from the ISDN terminal under test 5 has been limited to checking the data of only the layer 3 message type, and since a complete check cannot be performed, all of the received message data is checked. This is how it was done.

In other words, the message data (test data) to be received
Check the number of bytes of , and this check number of bytes is rQ
It is determined in step 80 whether or not j, and this is "0".
In this case, it means that there is no received message data to be checked and the process ends immediately, or if the number of check bytes exists and it is not "0", then in step 80
Y" and -1,3-, then in step 81 it is determined whether the value of the test data is **, and if it is determined as "Y", the data related to that byte is not checked. , selects the received message data area to be checked next, and proceeds to step 88 to determine whether or not received message data exists in the selected area, that is, determine the end of the received message matching confirmation process. conduct.

Also, the test data is "N" at step 81 instead of **.
If the result is 1, one byte of the received message data is read out and displayed in step 82, and the received message data is compared with pre-stored test data in step 83.

When a match between the received message data and the test data is detected and the determination is "Y", the process moves to step 88, where it is determined whether or not there is the next received message data. If the received message matching confirmation process is determined to be "Y", the process ends directly, but if there is received message data, the process returns to step 81. In addition, if no match is detected between the received message and the test data, it is judged as "N" in step 84 and the process stops. In this case, if you want to end the process, press the ESC key or press the ESC key or press the next sequence. When migrating, use the return key.

That is, the detection of the ESC key or the return key is determined by the determination of "Y" for the input of the ESC key in step 85 or the manual input of the return key in step 86, respectively.
The process is terminated by a determination of ``Y'' or the process is moved to the next sequence, but if ES in step 85
If the input of the C key is "N" or the input of the return key in step 86 is "N", the input of the SP (space) key is determined in step 87, and this input is detected and "Y" is input. Once determined, processing will resume,
The next received message data is selected and its presence or absence is determined, and if there is no received message data to be tested next, the received message matching confirmation process is terminated.

In this way, this protocol tester 1
All the data bytes of the transmission message transmitted from the N terminal 5 are checked in detail one byte at a time to determine whether the message is correct or not.

Note that the test device in this example was configured to perform a protocol test of an ISDN network compatible terminal device by setting itself to network mode, but it
It is also possible to connect a PBX compatible with a DN network and test the PBX protocol.

[Effect of the invention] As explained above, the protocol tester according to the present invention has the following effects:
Every time the second message data is received from the terminal device, 1 for all of the received second message data and all of the first message data stored in the storage means. Since each byte is compared to check whether it is correct or not, all of the received message data is thoroughly checked, and as a result, there is an effect that no trouble occurs after the terminal device is installed.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing an embodiment of the protocol tester according to the present invention, FIG. 2 is a perspective view of the protocol tester, and FIGS. 3 to 8 are flowcharts explaining the operation. 1...Protocol tester, 2...PC, 2
a...CPU, 2b...Display section, 2C...
Keyboard, 2d... Floppy disk drive, 3, 4... Office line board, 3a... Clock generator, 3b, 4b... ■ Interface line control circuit, 3C... Channel Switching device, 3d... Tone melody generator, 3e, 3f, 4e... Personal computer interface, 3g, 4g... 8-pin module, 5... ISDN terminal under test, 6.7... ...T point.

Claims (1)

[Scope of Claims] In a protocol testing machine that tests the protocol of a terminal device connected to an ISDN network, a storage means for storing first message data to be transmitted from the terminal device, and a first message data received from the terminal device. 2 message data and the first message data stored in the storage means.
1. A protocol tester comprising: checking means for comparing the second message data byte by byte with the second message data to check whether all the second message data is correct or incorrect.