JP5790420B2 - Communication device, failure detection method, and failure detection program - Google Patents

Description

  The present invention relates to a communication device, a failure detection method, and a failure detection program.

  Conventionally, when a communication failure occurs between communication apparatuses, a communication path with a connection destination apparatus is secured by switching to a backup communication path or selecting a bypass path. In such a method, the failure is not restored, and it is left unattended. Therefore, if a communication failure occurs when there is no spare route, neither route switching nor detour route selection can be performed, and communication cannot be performed. .

  On the other hand, in a network where a communication network has been developed as in the present situation and a plurality of devices are connected to the connection destination device, the failure location is identified as the own device, the connection destination device, the communication path, or another location. It is difficult. For this reason, a technique is known in which a device that detects a failure performs recovery control such as restart on a connection destination device.

JP 2007-49336 A Japanese Patent Application Laid-Open No. 07-250125

  However, in the prior art, since the recovery operation is performed in a state where the failure location is uncertain, there is a problem that the failure may be deteriorated by the recovery operation. This problem is not limited to the communication device, but also exists in the relay card that is mounted on the chassis and executes the signal transmission unit and the signal reception unit.

  For example, even if the cause of the failure is the local device, recovery control is performed on the connection destination device. Therefore, the failure continues even if the recovery operation is continued, and the recovery operation becomes an obstacle to identify the cause of the failure. There is also a fear. In addition, since the restoration work is repeatedly performed on the connection destination device that normally operates, it is possible that the failure of the connection destination device is induced and the failure is worsened.

  The disclosed technology has been made in view of the above, and an object thereof is to provide a communication device, a failure detection method, and a failure detection program that can narrow down a failure location.

  In one aspect, the communication device disclosed in the present application includes a detection unit that detects a communication failure, and the number of messages that pass through the processing part for each processing part that is provided in the apparatus and that executes each process. And a counting unit for counting The communication device includes a comparison unit that compares the number of messages of each processing site counted by the counting unit when a failure is detected by the detection unit. When there is a difference in the number of messages that have passed through each processing site as a result of the comparison by the comparison unit, the communication device identifies the inside of the device as a failure location, and the number of messages is different. If not, a specifying unit for specifying the outside of the device as a failure point is provided.

  According to one aspect of the communication device, the failure detection method, and the failure detection program disclosed in the present application, it is possible to narrow down the failure location.

FIG. 1 is a diagram illustrating a configuration example of a control device according to the first embodiment. FIG. 2 is a diagram illustrating a hardware configuration example of the FB card according to the first embodiment. FIG. 3 is a diagram illustrating functional blocks of the FB card according to the first embodiment. FIG. 4 is a diagram illustrating an example of information stored in the signal type table. FIG. 5 is a diagram illustrating an example of information stored in the passage number table. FIG. 6 is a diagram illustrating an example of information stored in the port setting table. FIG. 7 is a diagram illustrating an example of messages transmitted and received in the card. FIG. 8 is a diagram illustrating a processing sequence executed by the FB card according to the first embodiment. FIG. 9 is a flowchart illustrating the failure location specifying process executed by the FB card according to the first embodiment. FIG. 10 is a diagram illustrating a processing sequence for fault detection using a notification signal. FIG. 11 is a diagram illustrating a processing sequence for failure detection using request signal transmission processing. FIG. 12 is a diagram illustrating an example of a hardware configuration of a computer that executes a failure identification program.

  Embodiments of a communication device, a failure detection method, and a failure detection program disclosed in the present application will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

[overall structure]
FIG. 1 is a diagram illustrating a configuration example of a control device according to the first embodiment. As shown in FIG. 1, the control device 1 is a device having a management device 2 and a chassis 3, for example, a device such as a base station control device (RNC: Radio Network Controller). In the chassis 3, an FB (Function Block) card 10 and an FB card 30 are connected via an SW (Switch) card 5. Note that the number of chassis, the type of card, and the number of FB cards and SW cards shown here are merely examples, and are not limited to those illustrated.

  The management device 2 is a management device that manages processing executed by the control device 1, and is connected to the FB card 10 and the FB card 30 via the SW card 5. For example, the management device 2 receives an instruction operation from the administrator, and executes processing such as power control and start / end control of data processing for the FB card 10 and the FB card 30.

  The SW card 5 holds switching information including connection paths of the respective cards, and connects the FB card 10, the FB card 30, and the management device 2 to each other. In the example of FIG. 1, the SW card 5 connects the FB card 10 and the FB card 30 with two paths to make the paths redundant.

  The FB card 10 and the FB card 30 are examples of communication devices, and transmit and receive data to other cards and the like. In the example of FIG. 1, the FB card 10 and the FB card 30 are connected by two physical ports. For example, the FB card 10 outputs data received from another card or the like to the connected FB card 30 or to another card or the like that executes modulation processing. Note that the connection destination of each FB card is not limited to the FB card as illustrated, and may be, for example, a card that performs modulation, a card that performs coating, a card that transmits data to a wireless terminal, or the like. .

  Such FB card 10 or FB card 30 detects a communication failure. In addition, the FB card 10 or the FB card 30 counts the number of messages that have passed through the processing portion for each processing portion that is provided inside the card and that executes each processing. Further, when a failure is detected, the FB card 10 or the FB card 30 compares the counted number of messages of each processing part. Then, in the FB card 10 or the FB card 30, if there is a difference in the number of messages that have passed through each processing site in the result of comparison, the inside of the card is identified as a failure location, and the difference in the number of messages If it does not occur, identify the outside of the card as the failure location.

  Thus, the FB card 10 or the FB card 30 can determine whether a message is normally transmitted / received in the own card when a failure occurs with the opposite device. As a result, the FB card 10 or the FB card 30 can specify whether the failure location is inside or outside the card. Therefore, the failure location can be narrowed down.

[Hardware configuration of FB card]
FIG. 2 is a diagram illustrating a hardware configuration example of the FB card according to the first embodiment. Since the FB card 10 and the FB card 30 shown in FIG. 1 have the same configuration, the hardware configuration and the functional block diagram will be described using the FB card 10 as an example.

  As shown in FIG. 2, the FB card 10 includes a connector 10a, a PHY (Physical Layer) 10b, a PHY 10c, a connector 10d, and a PHY 10e. The FB card 10 further includes an FPGA (Field-Programmable Gate Array) 11, a network processor 12, a memory 13, a memory controller 14, and a CPU (Central Processing Unit) 15. Note that the hardware shown here is merely an example, and hardware other than the illustrated hardware may be included.

  The connector 10 a is an Ethernet connector or the like provided on the back side of the FB card 10, and is connected to a cable connecting the other FB card and the management device 2. The PHY 10b and the PHY 10c are hardware such as a circuit for connecting the connector 10a and the FPGA 11 and control communication exchanged between the connector 10a and the FPGA 11 at a physical layer level.

  The connector 10d is an Ethernet connector or the like provided on the front side of the FB card 10, and is connected to a cable or the like that is connected to a computer device that operates the FB card 10. The PHY 10e is hardware such as a circuit for connecting the connector 10d and the memory controller 14, and controls communication exchanged between the connector 10d and the memory controller 14 at a physical layer level.

  The FPGA 11 includes an MAC (Media Access Control) 11a, a MAC 11b, and a switch 11c, and is an integrated circuit that switches data transfer using these. The MAC 11a is hardware such as a circuit that connects the PHY 10b and the switch 11c, and controls communication exchanged between the PHY 10b and the switch 11c at the data link layer level. Similarly, the MAC 11b is hardware such as a circuit for connecting the PHY 10c and the switch 11c, and controls communication exchanged between the PHY 10c and the switch 11c at the data link layer level.

  The switch 11c is a switching circuit that connects between the MAC 11a and the network processor 12, and is similarly a switching circuit that connects between the MAC 11b and the network processor 12. The switch 11c outputs a message such as a packet input from the network processor 12 to the MAC 11a or MAC 11b to which the destination is connected. The switch 11c outputs a message such as a packet input from the MAC 11a or MAC 11b to the network processor 12.

  The network processor 12 is an electronic circuit such as a processor specialized for packet processing such as packet transfer, and controls packet transfer between the FPGA 11 and the memory controller 14. The memory 13 is a storage device that stores data, programs, and the like used in each process executed by the FB card 10.

  The memory controller 14 is an integrated circuit that controls data writing to the memory 13 and data reading from the memory 13. The memory controller 14 controls data writing or data reading between the network processor 12 and the memory 13. Similarly, the memory controller 14 controls data writing or data reading between the CPU 15 and the memory 13. Similarly, the memory controller 14 controls data writing or data reading between the device connected to the connector 10d and the memory 13.

  The CPU 15 is an electronic circuit that has an internal memory and the like and controls the entire FB card. The CPU 15 executes various processes such as communication failure detection, failure location identification, and failure location recovery control.

[FB card functional block diagram]
FIG. 3 is a diagram illustrating functional blocks of the FB card according to the first embodiment. As shown in FIG. 3, the FB card 10 includes a signal type table 20a, a passing number table 20b, and a port setting table 20c. The FB card 10 also includes a transmission / reception processing unit 21, a counting unit 22, a signal type determination unit 23, a confirmation management unit 24, a failure detection unit 25, a comparison unit 26, a specification unit 27, and a recovery control unit 28.

  The signal type table 20a, the passage number table 20b, and the port setting table 20c are provided in the memory 13, for example. The transmission / reception processing unit 21, the counting unit 22, the signal type determination unit 23, the confirmation management unit 24, the failure detection unit 25, the comparison unit 26, the identification unit 27, and the recovery control unit 28 are processing units executed by the CPU 15.

  The signal type table 20a is a table that stores timer values set for each signal type. The information stored here is updated by an administrator or the like. FIG. 4 is a diagram illustrating an example of information stored in the signal type table. As shown in FIG. 4, the signal type table 20a stores “MsgID, signal type, response / confirmation wait timer value, failure detection wait timer value” in association with each other.

  The “MsgID” stored here is an identifier for identifying the type of message, and is included in messages transmitted and received between FB cards. “Signal type” is the type of message specified by MsgID. The “response / confirmation wait timer value” is a timer value used in normal message transmission, and is a timer value from when a message is transmitted until a response is received. The “failure detection wait timer value” is a timer value used in the same application as the retransmission signal wait timer, and is a timer value from when a response message is transmitted until the response is requested to be retransmitted.

  In the case of FIG. 4, it indicates that a failure is determined when a response to the request message is not received before “400 ms” has elapsed since the transmission of the request message with “MsgID” “1029”. . In addition, it indicates that a failure is determined when a retransmission request for the transmitted response message is received by the time “600 ms” elapses after the response message with “MsgID” “1030” is transmitted. Further, the periodic report message whose “MsgID” is “1033” indicates that it is determined as a failure when it is not received at “8640000 ms” intervals.

  The passing number table 20b is a table that stores the number of passing messages for each processing part counted by the counting unit 22. The information stored here is updated by the counting unit 22. FIG. 5 is a diagram illustrating an example of information stored in the passage number table. As illustrated in FIG. 5, the passing number table 20 b stores “UDP (User Datagram Protocol) port number, passing number” in association with each processing part. The “UDP port number” stored here is a port number used by the passed message, and can be obtained from the message. The “number of passages” is the number of messages that have passed. Further, the passing number table 20b may be provided in the order of connection of processing parts in accordance with connection information and a preset message transmission / reception route.

  In the case of FIG. 5, the CPU 15, the memory controller 14, and the network processor 12 are connected in this order, indicating that the number of passing messages is counted for each processing part. For example, the CPU 15 indicates that “42” messages have passed through the UDP port number “1024” and “35” messages have passed through the UDP port number “1025”. Further, the CPU 15 indicates that “29” messages have passed through the UDP port number “1026” and “42” messages have passed through the UDP port number “1040”.

  The port setting table 20c is a table that stores associations between UDP port numbers and processing functions. The information stored here is set by an administrator or the like. FIG. 6 is a diagram illustrating an example of information stored in the port setting table. As illustrated in FIG. 6, the port setting table 20 c stores “UDP port number, processing function unit name” in association with each other. The “UDP port number” stored here indicates the UDP port number used by the message. The “processing function part name” indicates a function or process for transmitting / receiving a message.

  In the case of FIG. 6, the message using the UDP port number “1024” indicates that it is a message necessary for the synchronous processing exchanged by PFIF (Platform Interface). Similarly, a message using the UDP port number “1040” indicates a transfer message exchanged between subordinate cards or Mates. Note that the Mate has a redundant configuration, for example, one system is an N system, the other is an E system, one of which is an ACT system (a system operating in ACTIVE), and an STBY system (Standby). Retract system). For example, the exchange between Mates is the exchange of data between the ACT system and the STBY system.

  The transmission / reception processing unit 21 is a processing unit that receives a message from another card or the like or transmits a message to another card. For example, when the transmission / reception processing unit 21 receives a message, the transmission / reception processing unit 21 outputs the received message to the signal type determination unit 23. Further, the transmission / reception processing unit 21 transmits the message instructed from the signal type determination unit 23 to the instructed destination.

  The counting unit 22 is a processing unit that is provided inside the FB card 10 and counts the number of messages that have passed through the processing site for each processing site that executes each process. For example, the counting unit 22 monitors each hardware function in the FB card 10 or each processing function executed by the CPU 15 via the transmission / reception processing unit 21 and counts messages that have passed.

  Here, an example of a message passing through the FB card 10 will be described. FIG. 7 is a diagram illustrating an example of messages transmitted and received in the card. As shown in FIG. 7, the message is “transmission source information, transmission destination information, transmission source address, transmission destination address, transmission source UDP port number, transmission destination UDP port number, transmission source physical port number, transmission destination physical port number. Message number ".

  For example, “transmission source information” is information that identifies a card that has transmitted a message, such as a machine name or a card name. The “transmission destination information” is information for specifying a card that is a transmission destination of a message, such as a machine name or a card name. The “transmission source address” is address information of the card that transmitted the message, and the “transmission destination address” is address information of the card that is the transmission destination of the message. Note that an IP (Internet Protocol) address or a MAC address can be used as the address information.

  The “transmission source UDP port number” and “transmission destination UDP port number” are port numbers designated by the transmission source device, and are UDP port numbers used in message transmission / reception. The “transmission source physical port number” and the “destination physical port number” are physical port numbers that are transmission paths designated by the transmission source device, and are numbers of physical interfaces used by the message. “Message number” corresponds to “MsgID” in FIG. 4 and is an identifier for identifying the type of message.

  For example, the counting unit 22 monitors the CPU 15 and, when a message described in the format shown in FIG. 7 is output from the CPU 15, the “transmission source UDP port number” or “transmission destination UDP”. The UDP port number is extracted from “Port Number”. Then, the counting unit 22 increments the number of passages of the extracted “UDP port number” in the table associated with the CPU 15 among the tables held by the passage number table 20b.

  Returning to FIG. 3, the signal type determination unit 23 is a processing unit that determines the type of message received by the transmission / reception processing unit 21 and notifies the confirmation management unit 24 of the type. The signal type determination unit 23 is a processing unit that determines the type of the message transmitted by the transmission / reception processing unit 21 and notifies the confirmation management unit 24 of the type.

  For example, when a received message is input from the transmission / reception processing unit 21, the signal type determination unit 23 extracts a “message number” included in the received message. Then, the signal type determination unit 23 specifies the “signal type” corresponding to the extracted “message number” from the signal type table 20 a and notifies the confirmation management unit 24 of it. For example, when “1029” is extracted as the “message number” from the received message, the signal type determination unit 23 sets the “request” corresponding to “1029” as the signal type of the received message to the confirmation management unit 24. Notice.

  In addition, when a message is transmitted from the transmission / reception processing unit 21, the signal type determination unit 23 extracts a “message number” included in the transmission message. Then, the signal type determination unit 23 specifies the “signal type” corresponding to the extracted “message number” from the signal type table 20 a and notifies the confirmation management unit 24 of it. For example, when “1030” is extracted as the “message number” from the transmission message, the signal type determination unit 23 sets the “response” corresponding to “1030” as the signal type of the received message to the confirmation management unit 24. Notice.

  The confirmation management unit 24 is a processing unit that starts a timer corresponding to the signal type notified from the signal type determination unit 23. For example, the confirmation management unit 24 starts the timer when notified from the signal type determination unit 23 that the “signal type” is “request”. Then, the confirmation management unit 24 notifies the failure detection unit 25 of the start of the timer, the signal type of the started timer, the start time, and the like. The confirmation management unit 24 initializes the timer when a message is normally transmitted / received or when instructed by the failure detection unit 25 or the like.

  The failure detection unit 25 is a processing unit that detects a communication failure. For example, the failure detection unit 25 detects that a failure has occurred when a predetermined message cannot be received after the timer is started by the confirmation management unit 24 until the set timer value is reached.

  For example, it is assumed that the failure detection unit 25 is notified from the confirmation management unit 24 that the timer corresponding to “signal type = request” has been started. In this case, the failure detection unit 25 specifies the timer value at the time when the signal type determination unit 23 is notified to the confirmation management unit 24 that the response of the request message has been received. That is, the failure detection unit 25 specifies the timer value at the time when the request message is received by the transmission / reception processing unit 21. Then, when the value of the specified timer is less than the timer value “400 ms” of “signal type = request”, the failure detection unit 25 resets the timer, assuming that the message is normally transmitted and received. On the other hand, the failure detection unit 25 detects that a failure has occurred and notifies the comparison unit 26 when the specified timer value is equal to or greater than the timer value “400 ms” of “signal type = request”.

  As another example, it is assumed that the failure detection unit 25 is notified from the confirmation management unit 24 that the timer corresponding to “signal type = response” has been started. In this case, the failure detection unit 25 notifies that a response message retransmission request is received from the signal type determination unit 23 to the confirmation management unit 24 before the timer value “600 ms” of “signal type = response” elapses. If it has been detected, it is detected that a failure has occurred, and the comparison unit 26 is notified. That is, the failure detection unit 25 detects that a failure has occurred when a retransmission request is received before the timer value “600 ms” elapses.

  The comparison unit 26 is a processing unit that compares the number of messages of each processing region counted by the counting unit 22 when a failure is detected by the failure detection unit 25. For example, the comparison unit 26 refers to the passage number table 20b and compares the passage numbers counted for each processing site.

  In the case of FIG. 5, the comparison unit 26 compares the number of passages of each UDP port number stored in the table of the CPU 15 with the number of passages of each UDP port number stored in the table of the memory controller 14. Similarly, the comparison unit 26 compares the number of passages of each UDP port number stored in the table of the memory controller 14 with the number of passages of each UDP port number stored in the table of the network processor 12. Similarly, the comparison unit 26 compares the number of passages of each UDP port number stored in the table of the CPU 15 with the number of passages of each UDP port number stored in the table of the network processor 12. Then, the comparing unit 26 outputs the comparison result to the specifying unit 27.

  The identifying unit 27 is a processing unit that identifies the inside of the FB card 10 as a failure location when there is a difference in the number of messages that have passed through each processing site as a result of the comparison performed by the comparison unit 26. The specifying unit 27 is a processing unit that specifies the outside of the FB card 10 as a failure location when there is no difference in the number of messages. The identifying unit 27 outputs the identified failure information to the recovery control unit 28.

  For example, in the case of FIG. 5, the specifying unit 27 has “42” as the number that has passed the UDP port number “1040” in the CPU 15, and “0” as the number that has passed the UDP port number “1040” in the memory controller 14. Therefore, it is determined that there is a difference in the number of passes. In this case, the specifying unit 27 specifies that a failure has occurred in the path between the CPU 15 and the memory controller 14 or in the memory controller 14. Further, the identifying unit 27 refers to the port setting table 20c and identifies that the processing function corresponding to the UDP port number “1040” in which the failure has been detected is “transfer message between subordinate cards or between mates”. On the other hand, when there is no difference in the number of messages that have passed through each processing part, the specifying unit 27 has a failure in the route connected to the FB card 10 or the FB card 30 that is the connection destination of the FB card 10. Identify that you are doing.

  The recovery control unit 28 is a processing unit that performs recovery control on the processing site that is the cause of the failure specified by the specifying unit 27 or the connection destination device connected to the FB card 10. For example, when the recovery control unit 28 is notified by the specifying unit 27 that the failure location is the memory controller 14, the recovery control unit 28 performs processing such as reset processing, restart processing, and a predetermined recovery command on the memory controller 14. Run. Similarly, when the recovery control unit 28 is notified from the specifying unit 27 that the failure point is the FB card 30, the recovery control unit 28 performs processing such as reset processing, restart processing, and a predetermined recovery command for the FB card 30. Execute.

  Further, it is assumed that the recovery control unit 28 is notified from the specifying unit 27 that the function in which the failure has occurred is “a transfer message between subordinate cards or between mates”. In this case, the recovery control unit 28 can also request the CPU 15 to restart an application that provides this function. That is, the recovery control unit 28 can also execute recovery control in units of processing executed by the CPU 15.

[Process flow]
Next, the flow of processing executed by the FB card 10 according to the first embodiment will be described with reference to FIGS. 8 and 9. Here, the overall processing sequence and the fault location specifying process will be described by taking communication between the FB card 10 and the FB card 30 as an example.

(Overall processing sequence)
FIG. 8 is a diagram illustrating a processing sequence executed by the FB card according to the first embodiment. As illustrated in FIG. 8, the FB card 30 transmits a message whose signal type is “request” to the FB card 10 (S101 and S102).

  The transmission / reception processing unit 21 of the FB card 10 receives a message whose signal type is “request” (S103). Subsequently, the signal type determination unit 23 specifies that the signal type of the received message is “request”, and the transmission / reception processing unit 21 selects a message whose signal type is “response” as a message corresponding to “request”. It transmits to the FB card 30 (S104 and S105).

  Then, the confirmation management unit 24 of the FB card 10 refers to the signal type table 20a and starts a timer corresponding to the “response” that is the signal type of the transmission message specified by the signal type determination unit 23 (S106). In this case, the timer value is “600 ms”.

  Thereafter, before the timer value elapses, the FB card 30 retransmits a message whose signal type is “request” to the FB card 10 (S107 and S108). The signal type determination unit 23 of the FB card 10 specifies that the signal type of the message received by the transmission / reception processing unit 21 is “request” (S109).

  Then, the failure detection unit 25 of the FB card 10 detects that a failure has occurred since the retransmission of the request signal that should have transmitted the response signal has been received before the timer value “600 ms” elapses (S110). Then, the failure detection unit 25 transmits a timer reset instruction to the confirmation management unit 24, and the confirmation management unit 24 resets the timer (S111). Note that the resetting of the timer is not limited to the timing shown in the figure, and may be performed after the fault location is specified or after recovery.

  Subsequently, the comparison unit 26 and the specifying unit 27 of the FB card 10 execute a failure location specifying process to specify the failure location (S112). Then, the recovery control unit 28 executes recovery control on the identified failure location (S113). At this time, the recovery control unit 28 also executes recovery control for the FB card 30 as necessary (S114).

  Thereafter, when the failure is recovered by the recovery control, the transmission / reception processing unit 21 of the FB card 10 executes a communication report from the physical port connecting the FB card 10 and the FB card 30 to confirm that the connection state is normal. (S115 and S116). The FB card 30 transmits a communication report confirmation indicating that the communication report has been normally received from the FB card 10 to the FB card 10 (S117 and S118). In this way, communication can be confirmed for each FB card.

(Fault location identification process)
FIG. 9 is a flowchart illustrating the failure location specifying process executed by the FB card according to the first embodiment. This process is executed in S112 of FIG.

  As shown in FIG. 9, the counting unit 22 of the FB card 10 monitors each hardware function in the FB card 10 or each processing function executed by the CPU 15, and extracts an input message for each processing part (S201). ). Subsequently, when the input message is extracted (Yes in S202), the counting unit 22 extracts the output message for each processing part (S203). Then, the counting unit 22 counts up the number of passages of the processing part for the processing part in which both the input message and the output message are detected (Yes in S204) (S205).

  On the other hand, the counting unit 22 executes S205 without counting up the number of passages for a processing part for which no input message or output message has been detected (No in S202 or S204). Although FIG. 9 illustrates an example in which the fault detection process from S206 to S210 is performed after the count process from S201 to S205 is performed, the present invention is not limited to this. For example, the counting process and the failure detection process may be executed asynchronously.

  Thereafter, when the failure detection unit 25 detects a failure (Yes at S206), the comparison unit 26 refers to the passage number table 20b and compares the number of passages of each processing site (S207). Then, if the specifying unit 27 determines that there is a difference in the number of passages based on the comparison result (Yes in S208), the specifying unit 27 specifies the processing site of the fault location based on the comparison result (S209). On the other hand, when it is determined that there is no difference in the number of passages based on the comparison result (No at S208), the specifying unit 27 specifies the fault location as the outside (S210).

[effect]
As described above, the FB card 10 can set the timer based on the signal type of the message exchanged with the FB card 30, and can detect a failure using the set timer. That is, the FB card 10 can detect a failure using the signal type when the sequence does not continue with the FB card 30. Further, the FB card 10 can specify whether the failure part is inside the card or outside the card by counting the messages that have passed through the processing parts in the card. Furthermore, the FB card 10 can also identify the processing site and function where the failure has occurred. Therefore, the FB card 10 can narrow down the location of failure, and can reduce the risk of recovery control.

  In addition, the identification of the failure part due to the own card failure is enhanced, and even if a failure occurs, it is possible to detect and recover a silent failure, which is a failure in which the presence or absence cannot be determined. Further, since the control to the wrong partner path is reduced, the signal transmission / reception signal on the line is reduced, and the line use efficiency is increased. In addition, failure recovery control is possible even if communication with the host device cannot be secured temporarily. In addition, even when a fault occurs in a remote area such as an earthquake, a minimum number of lines can be secured and services can be provided.

  Next, another example of failure detection performed by the FB card 10 will be described with reference to FIGS. 10 and 11. FIG. 10 illustrates a method for detecting a failure using an example in which a notification signal is received, and FIG. 11 illustrates an example in which a request signal is transmitted.

(Notification signal)
FIG. 10 is a diagram illustrating a processing sequence for fault detection using a notification signal. As shown in FIG. 10, the FB card 30 transmits a message whose signal type is “notification” to the FB card 10 (S301 and S302).

  The transmission / reception processing unit 21 of the FB card 10 receives a message whose signal type is “notification” (S303). Subsequently, the signal type determination unit 23 specifies that the signal type of the received message is “notification”, and the transmission / reception processing unit 21 selects a message whose signal type is “confirmation” as a message corresponding to “notification”. The data is transmitted to the FB card 30 (S304 and S305).

  Then, the confirmation management unit 24 of the FB card 10 refers to the signal type table 20a and starts a timer corresponding to “confirmation” that is the signal type of the transmission message specified by the signal type determination unit 23 (S306). In this case, the timer value is “200 ms”.

  Thereafter, the FB card 10 suspends processing such as failure detection until the timer value elapses (S307). During this time, it is assumed that the FB card 10 receives a retransmission of a message whose signal type is “notification” from the FB card 30 (S308 to S310). That is, it is assumed that the FB card 30 has not received a confirmation signal from the FB card 10.

  Then, after the timer value has elapsed, the failure detection unit 25 of the FB card 10 detects that a failure has occurred because it has received a retransmission of the notification signal that should have transmitted the confirmation signal before the timer value “200 ms” has elapsed. (S311). Thereafter, the processing from S312 to S319 executed by the FB card 10 or the FB card 30 is the same as the processing from S111 to S118 described in FIG.

(Request signal)
FIG. 11 is a diagram illustrating a processing sequence for failure detection using request signal transmission processing. As shown in FIG. 11, the transmission / reception processing unit 21 of the FB card 10 transmits a message whose signal type is “request” to the FB card 30 (S401 and S402).

  Subsequently, the confirmation management unit 24 of the FB card 10 refers to the signal type table 20a and starts a timer corresponding to the “request” that is the signal type of the transmission message specified by the signal type determination unit 23 (S403). In this case, the timer value is “400 ms”. Thereafter, it is assumed that the FB card 10 has not received a “response” from the FB card 30 until the timer value elapses (S404).

  Then, after the timer elapses, the failure detection unit 25 of the FB card 10 detects that a failure has occurred since the response signal has not been received before the timer value “400 ms” elapses (S405). Thereafter, the processing from S406 to S413 executed by the FB card 10 or the FB card 30 is the same as the processing from S111 to S118 described in FIG.

(Other methods)
In addition to the above example, a failure can be detected using various signal types. For example, the FB card 10 can use a periodic report periodically transmitted from the FB card 30. In this case, the FB card 10 can also detect that a failure has occurred when the periodic report is not received at an interval of 8640000 ms.

  In another method, the comparison unit 26 of the FB card 10 periodically compares the number of passes for each processing region stored in the number-of-passes table 20b, and a comparison result is obtained that there is a difference in the number of passes. At the time, the occurrence of a failure can also be detected. In this way, the FB card 10 can detect a failure not only from the signal type but also from the message passing state in the own device. Therefore, the FB card 10 can quickly detect an internal failure without being influenced by the timer.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above. Therefore, different embodiments will be described below.

(Applicable equipment)
In the above embodiment, the FB card has been described as an example. However, the present application is not limited to this, and can be applied to a communication apparatus such as a server or a base station. For example, by providing a function similar to that shown in FIG. 3 in a general application server or the like, the failure location can be narrowed down when a failure occurs in communication with another server or client.

(Signal type)
The signal type, MsgID, timer value, port number, and the like exemplified in the above embodiment are merely examples, and are not limited to the above embodiment, and can be arbitrarily set by an administrator or the like. Further, by storing the setting contents in the port setting table, the same processing as in the above embodiment can be executed. In the above-described embodiment, the description has been made using expressions such as a message and a signal. However, the present invention is not limited to these, and the present invention can be applied to various data exchanged between devices such as a packet and a frame.

(Recovery control)
In the above-described embodiment, an example in which restart or reset is executed as recovery control has been described, but the present invention is not limited to this. For example, the FB card 10 may report the occurrence of a failure to the management device 2 that is a host device of the own card. At this time, the FB card 10 can also notify the specified failure location and function. In addition, the FB card 10 may display a failure content on a display or the like connected to the front side, and can notify an administrator or the like by e-mail or the like.

(system)
In addition, among the processes described in the present embodiment, all or a part of the processes described as being automatically performed can be manually performed. Alternatively, all or part of the processing described as being performed manually can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-described document and drawings can be arbitrarily changed unless otherwise specified.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device is not limited to that shown in the figure. That is, all or a part of them can be configured to be functionally or physically distributed / integrated in arbitrary units according to various loads or usage conditions. For example, the confirmation management unit 24 may execute each process executed by the failure detection unit 25, the comparison unit 26, and the specification unit 27. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

(program)
By the way, the various processes described in the above embodiments can be realized by executing a program prepared in advance on a computer system such as a personal computer or a workstation. Therefore, in the following, an example of a computer system that executes a program having the same function as in the above embodiment will be described.

  FIG. 12 is a diagram illustrating an example of a hardware configuration of a computer that executes a failure identification program. As illustrated in FIG. 12, the computer 100 includes a CPU 102, an input device 103, an output device 104, a communication interface 105, a medium reading device 106, an HDD (Hard Disk Drive) 107, and a RAM (Random Access Memory) 108. 12 are connected to each other by a bus 101.

  The input device 103 is a mouse or a keyboard, the output device 104 is a display or the like, and the communication interface 105 is an interface such as a NIC. The HDD 107 stores the tables shown in FIGS. 4 to 6 and the like together with the failure identification program 107a. As an example of the recording medium, the HDD 107 is taken as an example. However, various programs are stored in other computer-readable recording media such as a ROM (Read Only Memory), a RAM, and a CD-ROM, and are read by the computer. Also good. Note that the recording medium may be arranged at a remote place, and the computer may acquire and use the program by accessing the storage medium. At that time, the acquired program may be stored in a recording medium of the computer itself and used.

  The CPU 102 operates the failure identification process 108a that executes each function described with reference to FIG. 3 and the like by reading the failure identification program 107a and developing it in the RAM 108. That is, the failure identification process 108a includes the transmission / reception processing unit 21, the counting unit 22, the signal type determination unit 23, the confirmation management unit 24, the failure detection unit 25, the comparison unit 26, the identification unit 27, and the recovery control unit 28 illustrated in FIG. Performs the same function as As described above, the computer 100 operates as an information processing apparatus that executes the fault identification method by reading and executing the program.

  The computer 100 can also realize the same function as the above-described embodiment by reading the failure identification program from the recording medium by the medium reader 106 and executing the read failure identification program. Note that the program referred to in the other embodiments is not limited to being executed by the computer 100. For example, the present invention can be similarly applied to a case where another computer or server executes the program or a case where these programs cooperate to execute the program.

DESCRIPTION OF SYMBOLS 1 Control apparatus 2 Management apparatus 3 Chassis 5 SW card 10, 30 FB card 10a, 10d Connector 10b, 10c, 10e PHY
11 FPGA
11a, 11b MAC
11c switch 12 network processor 13 memory 14 memory controller 15 CPU
20a Signal type table 20b Pass number table 20c Port setting table 21 Transmission / reception processing unit 22 Count unit 23 Signal type determination unit 24 Confirmation management unit 25 Failure detection unit 26 Comparison unit 27 Identification unit 28 Recovery control unit

Claims (7)

A storage unit that stores a processing function and a port number used by the processing function in association with each other;
A detection unit for detecting a communication failure;
A counting unit provided inside the apparatus for counting the number of messages passing through the processing part for each port number, for each processing part for executing each process;
When a failure is detected by the detection unit, a comparison unit that compares the number of messages of each processing site counted by the counting unit;
In the result of comparison by the comparison unit, when there is a difference in the number of messages that have passed through each processing part, the inside of the device is specified as a failure part, and the processing part in which the difference occurs is specified, When there is no difference in the number of messages, a specifying unit that identifies the outside of the device as a failure location ;
When the processing part is specified as the failure part by the specifying unit, the processing function in which the failure has occurred in the processing part based on the port number in which the difference has occurred and the type of the message that has passed the port number And an execution unit that executes a recovery operation for the processing function .   The detection unit does not receive a response to the message from the connection destination device within a predetermined time corresponding to the signal type of the message transmitted to the connection destination device connected to the device, or The communication apparatus according to claim 1, wherein the communication apparatus detects that the communication failure has occurred when a retransmission request for the message is received from a connection destination apparatus. The comparison unit periodically compares the number of messages for each processing site,
The said specific | specification part specifies the inside of the said apparatus as a failure location, when the comparison result in which the difference has arisen in the number of the messages which passed through each said process site | part is obtained. Communication equipment.   The specifying unit, when specifying the inside of the device as a failure location, specifies a processing site that has caused the failure by using connection information inside the device or a transmission / reception path of the message, The communication device according to claim 1.   The apparatus further comprises a recovery control unit that executes recovery control for a processing site that is specified as a cause of the failure specified by the specifying unit or a connection destination device connected to the device. Item 5. The communication device according to Item 4. Computer
Detect communication failures,
For each processing site that is provided inside the computer and executes each process, the number of messages that have passed through the processing site is counted for each port number ,
When a failure is detected, compare the number of messages of each processing site counted,
As a result of the comparison, if there is a difference in the number of messages that have passed through each processing part, the inside of the computer is specified as a faulty part, the processing part in which the difference occurs is specified, and the number of messages If the difference is not generated in the outside of the computer to identify the failure location in,
When the processing site is specified as the failure location, the storage unit that stores the processing function and the port number used by the processing function in association with each other is referred to, and the port number and the port number where the difference has occurred are stored. A failure detection method comprising: processing for identifying the processing function in which a failure has occurred in the processing site based on the type of message that has passed, and executing recovery work for the processing function . On the computer,
Detect communication failures,
For each processing site that is provided inside the computer and executes each process, the number of messages that have passed through the processing site is counted for each port number ,
When a failure is detected, compare the number of messages of each processing site counted,
As a result of the comparison, if there is a difference in the number of messages that have passed through each processing part, the inside of the computer is specified as a faulty part, the processing part in which the difference occurs is specified, and the number of messages If the difference is not generated in the outside of the computer to identify the failure location in,
When the processing site is specified as the failure location, the storage unit that stores the processing function and the port number used by the processing function in association with each other is referred to, and the port number and the port number where the difference has occurred are stored. A failure detection program that identifies the processing function in which a failure has occurred in the processing site based on the type of message that has passed, and causes the processing function to execute a recovery operation .

Images