WO2019167984A1 - 障害検知装置、障害検知方法、および障害検知プログラム - Google Patents

障害検知装置、障害検知方法、および障害検知プログラム Download PDF

Info

Publication number
WO2019167984A1
WO2019167984A1 PCT/JP2019/007438 JP2019007438W WO2019167984A1 WO 2019167984 A1 WO2019167984 A1 WO 2019167984A1 JP 2019007438 W JP2019007438 W JP 2019007438W WO 2019167984 A1 WO2019167984 A1 WO 2019167984A1
Authority
WO
WIPO (PCT)
Prior art keywords
company
network
failure
failure detection
nni
Prior art date
Application number
PCT/JP2019/007438
Other languages
English (en)
French (fr)
Inventor
高大 山本
康司 谷田
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to US16/968,355 priority Critical patent/US11799840B2/en
Publication of WO2019167984A1 publication Critical patent/WO2019167984A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H04L63/306—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information intercepting packet switched data communications, e.g. Web, Internet or IMS communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]

Definitions

  • the present invention relates to a failure detection device, a failure detection method, and a failure detection program for detecting a failure in a network of another company.
  • NNI-GW Network-to-Network-Interface-Gateway
  • the company's own NNI-GW is connected to another company's network with multiple POIs, it may be possible to quickly avoid failures in the other company's network by switching the POI.
  • the cause of the failure of the other company network is not the other company network itself but the user terminal side.
  • the cause of the failure When the cause of the failure is on the user terminal side, the range of influence of the failure is limited, and even if the POI is switched, there is no effect of failure recovery.
  • the cause of the failure when the cause of the failure is the network of the other company itself, the affected range of the failure (failure range) is large, and there is a possibility that the failure can be avoided by switching the POI. Therefore, it is necessary to identify the cause of the failure of the other company's network.
  • the company's NNI-GW receives a 500 (Server Internal Error) response from the other company's network, but the cause of the failure cannot be identified with the 500 response.
  • 500 Server Internal Error
  • the present invention has been made in view of the above circumstances, and an object of the present invention is to specify the cause of a failure when a failure occurs in a network of another company.
  • the present invention is a failure detection device for detecting a failure of a network of another company, and transmits a request including the maximum number of transfers to the other company's network, thereby reducing the depth of the hierarchy of the other company's network.
  • a hierarchy detection unit that detects the number of layers shown, and when a failure of the other company's network is detected, by sending the request to the other company's network, a failure location specifying unit that identifies the hierarchy of the failure location of the other company's network;
  • a determination unit that determines a failure of the network core device of the other company's network when the hierarchy of the failure location is smaller than the number of layers of the other company's network.
  • the present invention relates to a failure detection method for detecting a failure in another company's network performed by the failure detection device, and transmits a request including the maximum number of transfers to the other company's network to indicate the depth of the other company's network.
  • a hierarchy detecting step for detecting the number of hierarchies; and when a failure in the other company's network is detected, by sending the request to the other company's network, a fault location identifying step for identifying the hierarchy of the fault location in the other company's network; In the case where the level of the fault location is lower than the number of layers of the other company's network, a determination step of determining a failure of the network core device of the other company's network is performed.
  • the present invention is a failure detection program characterized by causing a computer to function as the failure detection device.
  • the cause of a failure can be specified when a failure occurs in a network of another company.
  • FIG. 1 is a diagram illustrating an overall configuration of a communication system according to an embodiment of the present invention. It is a functional block diagram which shows the structure of the company NNI-GW.
  • FIG. 10 is a sequence diagram for detecting the number of layers of another company's network in a normal state. It is a sequence diagram which specifies the fault location of another company network at the time of a fault.
  • FIG. 1 is a system configuration diagram showing an entire communication system according to an embodiment of the present invention.
  • the communication system shown in the figure is a system in which IP interconnection is performed between different communication carriers.
  • the own network of the telecommunications carrier A which is the company
  • the other network of the telecommunications carrier B which is the other company
  • POIs Points Of Of Interfaces
  • the company network and other company networks are IP networks.
  • a user terminal 8 is connected to the other person's network.
  • the illustrated in-house network includes an in-house NNI-GW 1, an in-house SIP server 2, and a DNS server 3.
  • In-house NNI-GW1 is a gateway installed at the POI boundary with other companies' networks.
  • In-house NNI-GW1 converts the data format, communication method, etc., in order to connect the in-house network with the other company's network.
  • the in-house NNI-GW 1 of the present embodiment detects a failure of the other company's network.
  • the in-house SIP server 2 performs call processing (call control) such as outgoing and incoming calls.
  • DNS Domain Name System
  • the DNS server 3 resolves the name of the other company's NNI-GW 5 located in the other company's network.
  • the DNS server transmits a list of all the other NNI-GWs 5 arranged in the other company's network to the own NNI-GW 1 in response to a request from the own NNI-GW 1.
  • FIG. 1 since the other company NNI-GW 5 is arranged in the other company network, information on the three other company NNI-GW 5 is set in the list.
  • the other network shown in the figure is connected to its own network (our own NNI-GW1) via two POIs 9, a plurality of other companies' NNI-GW5, a plurality of other company's SIP servers 6A and 6B, and another company's HGW (Home Gateway) 7 With.
  • HGW Home Gateway
  • the other company NNI-GW5 is a gateway installed at the POI boundary with its own network.
  • the other company's NNI-GW5 converts the data format, communication method, etc. in order to connect the two networks to each other.
  • the other company's SIP server 6 performs call processing such as outgoing and incoming calls.
  • the other company's NNI-GW 5 and the other company's SIP server 6 are core network devices of the other company's network.
  • the other company's HGW 7 is a user side device for connecting the user terminal 8 to the other company's network.
  • a user terminal 8 is connected to the other company's HGW 7.
  • the user terminal 8 is a terminal having a telephone function, and for example, a SIP terminal can be used.
  • FIG. 1 one other company HGW 7 and one user terminal 8 are shown, but the other company network includes a plurality of other company HGWs 7 and a plurality of user terminals 8 are connected to the other company network. .
  • the other company network shown in the figure is, for example, a four-layer network of the other company NNI-GW 5, the other company SIP server 6, and the other company HGW 7 in order from the left, but is not limited thereto.
  • the NNI-GWs 1 and 5 are devices independent of the SIP servers 2 and 6, but the SIP servers 2 and 6 may have the functions of the NNI-GWs 1 and 5. .
  • FIG. 2 is a functional block diagram showing the configuration of the company's NNI-GW 1 (failure detection device) of the present embodiment.
  • the in-house NNI-GW 1 illustrated includes a hierarchy detection unit 11, a failure detection unit 12, a failure location identification unit 13, a determination unit 14, an interconnection unit 15, and a storage unit 16.
  • the hierarchy detecting unit 11 detects the number of layers indicating the depth of the other company's network by transmitting an OPTIONS request including the maximum transfer number to the other company's network. Specifically, the hierarchy detection unit 11 increases the maximum transfer number of requests by 1 from 0 and transmits it to the other company's network, and adds a value obtained by adding 1 to the maximum transfer number when a successful response is received from the other company's network.
  • the number of layers indicating the depth of the other company's network is specified.
  • the failure detection unit 12 starts a timer when sending an INVITE request to another company's network, and detects a failure in the other company's network when the timer times out without receiving an 18x response (provisional response) to the INVITE request. To do. Also, the failure detection unit 12 detects a failure of the other company's network when receiving a 500 error response (Server Internal Error) from the other company's NNI-GW5.
  • a 500 error response Server Internal Error
  • the failure location identifying unit 13 detects a failure in the other company's network, the failure location identifying unit 13 identifies the hierarchy of the failure location in the other company's network by sending an OPTIONS request to the other company's network.
  • the determination unit 14 determines that the failure is caused by a network core device (other company's NNI-GW5, other company's SIP server 6) of the other company's network when the hierarchy of the failure part is smaller than the number of other company's networks. Is equal to the number of layers of the other company network, it is determined that the failure is caused by the user side device (other company HGW 7) or the user terminal 8. If the determination unit 14 determines that the failure is caused by the network core device of the other company's network, the determination unit 14 transmits an OPTIONS request to another company NNI-GW5 other than the current company's other company NNI-GW5 and another company NNI-GW5. -After confirming communication with the other company's network via the route via GW5, switch to another NNI-GW5 route.
  • a network core device other company's NNI-GW5, other company's SIP server 6
  • the determination unit 14 transmits an OPTIONS request to another company NNI-GW5 other than the current company's other company N
  • the interconnection unit 15 converts a data format, a communication method, and the like in order to transmit / receive data to / from another company's network.
  • the storage unit 16 stores the number of other company networks detected by the layer detection unit 11.
  • the above-mentioned in-house NNI-GW1 includes, for example, a CPU (Central Processing Unit), memory, storage (HDD: Hard Disk Drive, SSD: Solid State Drive), communication device, input device, and output.
  • a general-purpose computer system including the apparatus can be used.
  • each function of the in-house NNI-GW1 is realized by the CPU executing a program for the in-house NNI-GW1 loaded on the memory.
  • In-house NNI-GW1 programs can be stored on computer-readable recording media such as HDDs, SSDs, USB memories, CD-ROMs, DVD-ROMs, and MOs, or distributed over a network. .
  • FIG. 3 is a sequence diagram showing the operation of the communication system in normal times.
  • the company's NNI-GW 1 detects the number of layers indicating the depth of the other company's network by sending an OPTIONS request to the other company's network.
  • the hierarchy detection unit 11 of the company's NNI-GW 1 sends an OPTIONS request to another company's network in a sampling manner. At that time, the hierarchy detecting unit 11 transmits the value of the Max-Forward header (hereinafter referred to as “MF”) indicating the maximum number of OPTIONS request transfers while increasing (incrementing) one by one from 0.
  • MF Max-Forward header
  • the OPTIONS request destination (Request-URI) is an arbitrary telephone number in the telephone number system of another company's network.
  • the hierarchy detection unit 11 transmits an OPTIONS request in which the MF value is set to 0 to the other company NNI-GW 5 of the other company network (S11). As shown in FIG. 1, when a plurality of other company NNI-GWs 5 exist in the other company network, the hierarchy detection unit 11 transmits an OPTIONS request to any other company NNI-GW 5 of any POI.
  • the NNI-GW5 of another company that received the OPTIONS request tries to subtract 1 from the MF value, but since the MF value of the received OPTIONS request is 0, a 483 error response (error response) is sent to its own NNI-GW1 ( S12). A 483 error is sent when the maximum hop count is exceeded.
  • the hierarchy detection unit 11 transmits an OPTIONS request in which the MF value is set to 1 to the other company's NNI-GW 5 (S13).
  • the other company's NNI-GW 5 subtracts 1 from the MF value of the OPTIONS request, and transmits the OPTIONS request having the MF value 0 to the next company's SIP server 6A as the next transfer destination (S14). Since the MF value of the received OPTIONS request is 0, the other company's SIP server 6A transmits a 483 error response to the company's NNI-GW 1 via the other company's NNI-GW 5 (S15).
  • the hierarchy detection unit 11 transmits an OPTIONS request with the MF value set to 2 to the other company's NNI-GW 5 (S16).
  • the other company's NNI-GW 5 subtracts 1 from the MF value of the OPTIONS request, and transmits the OPTIONS request having the MF value 1 to the next company's SIP server 6A as the next transfer destination (S17).
  • the other company's SIP server 6A subtracts 1 from the MF value of the OPTIONS request, and transmits the OPTIONS request with the MF value 0 to the next company's SIP server 6B as the next transfer destination (S18). Since the MF value of the received OPTIONS request is 0, the other company's SIP server 6B transmits a 483 error response to the company's NNI-GW 1 via the other company's NNI-GW 5 (S19).
  • the hierarchy detection unit 11 transmits an OPTIONS request with the MF value set to 3 to the other company's NNI-GW 5 (S20).
  • the other company's NNI-GW 5 subtracts 1 from the MF value of the OPTIONS request, and sends the OPTIONS request having the MF value 2 to the next company's SIP server 6A as the next transfer destination (S21).
  • the other company's SIP server 6A subtracts 1 from the MF value of the OPTIONS request, and transmits the OPTIONS request having the MF value of 1 to the other company's SIP server 6B as the next transfer destination (S22).
  • the other company's SIP server 6B subtracts 1 from the MF value of the OPTIONS request, and transmits an OPTIONS request having an MF value of 0 to the other company's HGW 7 as the next transfer destination (S23). Since the received OPTIONS request is its own destination, the other company's HGW 7 transmits a 200 OK response (success response) to the company's NNI-GW 1 via the other company's NNI-GW 5 (S24).
  • the hierarchy detection unit 11 of the company's NNI-GW1 detects (learns) that the value obtained by adding 1 to the MF value of the OPTIONS request when the 200 OK response is received is the number of layers indicating the depth of the other company's network. (S25). Then, the hierarchy detection unit 11 stores the detected number of hierarchies in the storage unit 16.
  • the other company NNI-GW 5 is the first hierarchy
  • the other company SIP server 6A is the second hierarchy
  • the other company SIP server 6B is the third hierarchy
  • the other company HGW 7 is the fourth hierarchy in the descending order of hierarchy.
  • the company's NNI-GW1 detects the depth of the other company's network by the operation shown in Fig. 3 for each carrier, and determines the number of layers. Store in the storage unit 16.
  • the depth of the other company's network is detected using the OPTIONS request.
  • the present invention is not limited to this, and any message other than the OPTIONS request may be used as long as the message includes MF. .
  • FIG. 4 is a sequence diagram showing the operation of the communication system at the time of failure.
  • INVITE request session establishment request
  • SIP server 2 results in an error.
  • the in-house SIP server 2 transmits an INVITE request to the in-house NNI-GW 1 (S31).
  • the interconnection unit 15 of the in-house NNI-GW 1 transmits the received INVITE request to the other company's NNI-GW 5 of the other company's network (S32), and transmits a 100 trying response (response during trial) to the own SIP server 2 (S33). .
  • the failure detection unit of the company's NNI-GW1 sends an INVITE request to the other company's NNI-GW5 in S32, and simultaneously starts an 18x reception timer and monitors a timeout.
  • the 18x reception timer is a timer for monitoring reception of an 18x response (for example, 180 Ringing, 181 Call is being forwarded, etc.).
  • the timer value of the 18x reception timer is set to a relatively short value in order to quickly detect a failure of another company's network.
  • the other company's NNI-GW 5 transmits an INVITE request to the other company's SIP server 6A of the next layer (S34), and transmits a 100-trying response to its own NNI-GW 1 (S35). Then, the other company's SIP server 6A transmits an INVITE request to the other company's SIP server 6B of the next layer (S36), and transmits a 100-trying response to the other company's NNI-GW 5 (S37).
  • the SIP server 6B of the other company cannot receive the INVITE request, or cannot process the request even if the INVITE request is received.
  • the company NNI-GW 1 cannot normally receive the 18x response transmitted from the other company's HGW 7 before the 18x reception timer activated in S32 expires. That is, before receiving the 18x response, the 18x reception timer started in S34 times out.
  • the failure detection unit 12 detects that a failure has occurred in the other company's network (S38).
  • the adjacent third party SIP server 6A detects the failure of the other company's SIP server 6B and sends a 503 error response (Service Unavailable) to the adjacent other company's NNI-GW5. (S41).
  • the other company's NNI-GW 5 interworks with the 500 error response (Server Internal Error) and sends it to the adjacent company NNI-GW 1 (S42).
  • the failure detection unit 12 of the company NNI-GW 1 detects that a failure has occurred in the other company's network (S43).
  • the failure detection unit 12 of the company's NNI-GW 1 detects a failure in another company's network by the timeout of the 18x reception timer in S38 or the reception of a 500 error response in S43.
  • the failure location specifying unit 13 of the company's NNI-GW 1 identifies the failure location in the other company's network. Specifically, as described with reference to FIG. 3, the failure location specifying unit 13 transmits the MF value indicating the maximum transfer number included in the OPTIONS request while increasing the value by 1 from 0, and implements the SIP trace route. And identify the fault location. Further, the failure location specifying unit 13 sets the telephone number specified in the INVITE request (S31, S32, etc.) as the destination (Request-URI) of the OPTIONS request.
  • each device of the normal other company's network sends a 483 error response. Therefore, the failure location identifying unit 13 activates the 483 reception timer at the same time as transmitting the OPTIONS request and monitors the timeout of the timer. If the failure location identification unit 13 cannot receive the 483 error response before the 483 reception timer expires, that is, if the 483 reception timer times out before receiving the 483 error response, the failure of the other company's network Specify the number of layers (how many hops ahead) the part is.
  • the failure location identifying unit 13 transmits an OPTIONS request in which the MF value is set to 0 to the other company's NNI-GW 5 and starts the 483 reception timer (S51). Since the MF value of the received OPTIONS request is 0, the other company's NNI-GW 5 transmits a 483 error response to its own NNI-GW 1 (S52).
  • the hierarchy detection unit 11 transmits an OPTIONS request with the MF value set to 1 to the other company's NNI-GW 5 and starts a 483 reception timer (S53).
  • the other company's NNI-GW 5 subtracts 1 from the MF value of the OPTIONS request, and transmits an OPTIONS request having an MF value of 0 to the other company's SIP server 6A (S54). Since the MF value of the received OPTIONS request is 0, the other company's SIP server 6A transmits a 483 error response to its own NNI-GW 1 (S55).
  • the hierarchy detecting unit 11 transmits an OPTIONS request with the MF value set to 2 to the other company's NNI-GW 5 and starts the 483 reception timer (S56).
  • the other company's NNI-GW 5 decrements the MF value of the OPTIONS request by 1, and transmits the OPTIONS request with the MF value 1 to the other company's SIP server 6A (S57).
  • the other company's SIP server 6A decrements the MF value of the OPTIONS request by 1, and transmits an OPTIONS request with an MF value of 0 to the other company's SIP server 6B (S58).
  • the failure location identifying unit 13 cannot receive the 483 error response before the 483 reception timer activated in S56 expires, and the 483 reception timer times out.
  • the fault location identifying unit 13 identifies the fault location in the other company's network. That is, the failure location specifying unit 13 specifies that the hierarchy (hop destination) of the value obtained by adding 1 to the MF value of the OPTIONS request when the 483 reception timer times out is the location where the failure has occurred (S59). .
  • the failure location identifying unit 13 determines that the third layer (other company's SIP server 6B) obtained by adding 1 to the MF value 2 of the OPTIONS request when the 483 reception timer times out is the failure location. Identify.
  • the determination unit 14 of the in-house NNI-GW 1 determines whether the failure is caused by the network core device of the other company's network or the failure caused by the user side device or the user terminal 8.
  • the determination unit 14 determines that the hierarchy of the failure location identified by the failure location identification unit 13 is smaller than the number of other companies' networks detected by the hierarchy detection unit 11 (shallow hierarchy, hierarchy close to own NNI-GW1). ), It is determined that the failure is caused by the network core device (other company NNI-GW5, other company SIP server 6A, 6B) of the other company's network.
  • the determination unit 14 determines that the failure is caused by the user side device (other company HGW7) or the user terminal 8 when the number of layers of the specified failure location is equal to the number of layers of the other company network (S59).
  • the determination unit 14 has a limited influence on the failure, and even when switching to another company NNI-GW5 different from the current company NNI-GW5. Judging that it is difficult to avoid the obstacle. For this reason, the determination unit 14 does not perform processing related to failure avoidance.
  • the determination unit 14 When it is determined that the failure of the network core device of the other company's network, the determination unit 14 is greatly affected by the failure, and there is a possibility that the failure can be avoided when the current other company's NNI-GW5 is switched to another company's NNI-GW5. Judge. Therefore, the determination unit 14 inspects the reachability of the SIP signal via the other company NNI-GW that is different from the current company NNI-GW 5 that is connected to the route of the other company SIP server 6B in which the failure point is specified. That is, according to the communication confirmation on the route of another competitor NNI-GW5, the competitor NNI-GW5 (route) of the switching destination of the competitor network is identified.
  • the determination unit 14 accesses the DNS server 3 and obtains an NNI-GW list in which information (for example, addresses such as URI, identification information, etc.) related to all other NNI-GWs 5 of the other company's network is set. To do. Then, the determination unit 14 transmits an OPTIONS request to another company NNI-GW other than the currently used company NNI-GW 5, which is the path (system) in which the failure is detected. At this time, the determination unit 14 transmits the OPTIONS request to other NNI-GWs of other companies while increasing the MF value indicating the maximum transfer number included in the OPTIONS request by 1 from 0 as in FIG.
  • information for example, addresses such as URI, identification information, etc.
  • the determination unit 14 sets the telephone number specified in the INVITE request (S31, S32, etc.) as the destination (Request-URI) of the OPTIONS request.
  • the other competitor NNI-GW 5 includes other competitor NNI-GW 5 of the same POI and other competitor NNI-GW 5 of different POI as shown in FIG.
  • the determination part 14 receives the 200-mm OK response with respect to OPTIONS request in the path
  • the route switching includes route switching to another competitor NNI-GW 5 with the same POI and route switching to another competitor NNI-GW 5 with a different POI.
  • this embodiment when it is determined that the network core device of another company's network is faulty, it is possible to identify the switching destination path and avoid the fault.
  • whether or not a failure can be avoided by switching the route is verified by transmitting an OPTIONS request and confirming communication. Thereby, only when the failure can be avoided, the route is switched, and when the route is not effective (the failure cannot be avoided), it is possible to avoid a wasteful process of switching the route.
  • the hierarchy of the fault location of the other company's network is specified, and when the hierarchy of the fault location is a hierarchy smaller than the number of layers of the other company's network, the network core device of the other company's network Judge as failure.
  • the impact range of the failure is large and there is a possibility that the failure can be avoided or the influence of the failure such as a user terminal failure is limited. Therefore, it is possible to grasp (distinguish) whether there is no possibility of avoiding a failure.
  • the present invention starts an 18x reception timer when sending an INVITE request to another company's network, and detects a failure in the other company's network when the 18x reception timer times out without receiving a provisional response to the INVITE request. To do.
  • the present embodiment it is possible to quickly detect a failure that has occurred in another company's network by shortening the timer value of the 18x reception timer.
  • the only way to detect a failure in another company's network is to disconnect the TCP connection with the other company's NNI-GW5 or wait for an INVITE timeout (SIP Timer B: 32 seconds).
  • SIP Timer B 32 seconds
  • the failure cannot be detected.
  • a failure can be detected because the adjacent competitor NNI-GW5 returns a 100trying response to the INVITE request. Can not.
  • the INVITE time may expire (SIP TimerTimeC: 180 seconds), but in this case, the failure detection in the other company's network is long. Time is spent, and many calls are lost during that time.
  • the timer value of the 18x reception timer is set to a relatively short time so that rapid failure detection can be performed.
  • the present embodiment since it can be realized only by implementing the own NNI-GW1, it is possible to actively detect the cause of the failure of the other company's network without depending on the implementation status of the device of the other company's network. In addition, since it is implemented in the company's own NNI-GW1, development is easy and trouble can be avoided by switching to another NNI-GW5 without any operator intervention.
  • NNI-GW 11 Hierarchy detection unit 12: Failure detection unit 13: Failure point identification unit 14: Determination unit 15: Interconnection unit 16: Storage unit 2: Own SIP server 3: DNS server 5: Other company NNI-GW 6: Other company's SIP server 7: Other company's HGW 8: User terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

他社網における障害発生時に、障害の原因を特定する。他社網の障害を検知する障害検知装置１であって、最大転送数を含むリクエストを前記他社網に送信することで、他社網の階層の深さを示す階層数を検出する階層検出部１１と、他社網の障害を検知した場合、他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部１３と、障害箇所の階層が他社網の階層数より小さい階層の場合、他社網の網コア装置の障害と判定する判定部１４と、を備える。

Description

障害検知装置、障害検知方法、および障害検知プログラム
　本発明は、他社網の障害を検知する障害検知装置、障害検知方法、および障害検知プログラムに関する。
　近年、各通信事業者（キャリア）間のIP相互接続に向け、相互接続性確認試験を実施しており、SIP信号条件、POI（Point Of Interface）構成等のルール作りを進めている（非特許文献１～３）。今後は、IP相互接続におけるネットワーク障害時のアクションについての検討が予定されている。
　自社網と他社網とのPOI境界に設置されるNNI-GW（Network to Network Interface - Gateway）では、他社網内の障害を検知することが困難であり、また、通信事業者間での障害伝達の標準化がなされていない。
　自社網の自社NNI-GWが、複数POIで他社網と接続されている場合、POIの切り替えを行うことで、他社網の障害を迅速に回避できる可能性がある。ただし、他社網の障害の原因が、他社網自体ではなく、ユーザ端末側にある可能性もある。
　障害の原因がユーザ端末側にある場合、障害の影響する範囲は限定的であり、また、POIを切り替えても障害復旧の効果はない。一方、障害の原因が他社網自体の場合は、障害の影響範囲（り障範囲）が大きく、POIの切り替えを行うことで、障害を回避できる可能性がある。そのため、他社網の障害の原因を特定する必要がある。
　現在、他社網で障害発生時に、自社NNI-GWは、500（Server Internal Error）レスポンスを他社網から受信するが、当該500レスポンスでは、障害の原因を特定することができない。
　また、他社網から障害の内容を伝達してもらう方法が考えられる。しかしながら、この場合、「エラーコード＋ワーニングコード」の組み合わせを標準化する必要があり、全ての通信事業者がこのような標準化を自社網で実装する必要があるため、現実的ではない。
　本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、他社網における障害発生時に、障害の原因を特定することにある。
　上記目的を達成するため、本発明は、他社網の障害を検知する障害検知装置であって、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出部と、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部と、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定部と、を備える。
　本発明は、障害検知装置が行う、他社網の障害を検知する障害検知方法であって、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出ステップと、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定ステップと、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定ステップと、を行う。
　本発明は、上記障害検知装置として、コンピュータを機能させること、を特徴とする障害検知プログラムである。
　本発明によれば、他社網における障害発生時に、障害の原因を特定することができる。
本発明の実施形態に係る通信システムの全体構成を示す図である。 自社NNI-GWの構成を示す機能ブロック図である。 平常時における、他社網の階層数を検出するシーケンス図である。 障害時における、他社網の障害箇所を特定するシーケンス図である。
　以下、本発明の実施の形態について、図面を参照して説明する。
　図１は、本発明の実施形態に係る通信システムの全体を示すシステム構成図である。図示する通信システムは、異なる通信事業者間でIP相互接続が行われるシステムである。
　本実施形態の通信システムでは、自社である通信事業者Ａの自社網と、他社である通信事業者Ｂの他者網とが、複数のPOI（Point Of Interface：相互接続点）９を介して接続されている。自社網および他社網は、IP網である。また、他者網にはユーザ端末８が接続されている。
　図示する自社網は、自社NNI-GW１と、自社SIPサーバ２と、DNSサーバ３とを含む。自社NNI-GW１は、他社網とのPOI境界に設置されるゲートウェイである。自社NNI-GW１は、自社網と他社網とを相互に接続するために、データ形式、通信方式などを変換する。また、本実施形態の自社NNI-GW１は、他社網の障害を検知する。自社SIPサーバ２は、発信および着信などの呼処理（呼制御）を行う。
　DNS（Domain Name System）サーバ３は、他社網に配置された他社NNI-GW５の名前解決を行う。ここでは、DNSサーバは、自社NNI-GW１からの要求に応じて、他社網に配置された全ての他社NNI-GW５のリストを自社NNI-GW１に送信する。図１では、他社網には３つの他社NNI-GW５が配置されているため、リストには３つの他社NNI-GW５に関する情報が設定されている。
　図示する他者網は、２つのPOI９を介して自社網（自社NNI-GW１）と接続され、複数の他社NNI-GW５と、複数の他社SIPサーバ６Ａ、６Ｂと、他社HGW（Home GateWay）７とを備える。現在のIP相互接続仕様の標準化（通信事業者の調整）において、複数のPOI９を介して２つの網を相互に接続すること、および、１つのPOI９に複数の他社NNI-GW５を接続することが検討されている。ここでは、第１のPOI９には、２つの他社NNI-GW５が接続され、第２のPOI９には、１つの他社NNI-GW５が接続されている。
　他社NNI-GW５は、自社網とのPOI境界に設置されるゲートウェイである。他社NNI-GW５は、２つの網を相互に接続するために、データ形式、通信方式などを変換する。他社SIPサーバ６は、発信および着信などの呼処理を行う。なお、他社NNI-GW５および他社SIPサーバ６は、他社網のコア網装置である。
　他社HGW７は、ユーザ端末８を他社網に接続するためのユーザ側装置である。他社HGW７にはユーザ端末８が接続される。ユーザ端末８は、電話機能を有する端末であって、例えばSIP端末などを用いることができる。なお、図１では、１つの他社HGW７および１つのユーザ端末８を記載しているが、他社網は複数の他社HGW７を備え、他社網には複数のユーザ端末８が接続されているものとする。
　図示する他社網は、一例として、左から順に他社NNI-GW５、２つの他社SIPサーバ６、および他社HGW７の４階層の網であるが、これに限定されるものではない。
　また、図１に示す通信システムでは、NNI-GW１、５は、SIPサーバ２、６とは独立した装置であるが、SIPサーバ２、６がNNI-GW１、５の機能を備えることとしてもよい。
　図２は、本実施形態の自社NNI-GW１（障害検知装置）の構成を示す機能ブロック図である。図示する自社NNI-GW１は、階層検出部１１と、障害検知部１２と、障害箇所特定部１３と、判定部１４と、相互接続部１５と、記憶部１６とを備える。
　階層検出部１１は、最大転送数を含むOPTIONSリクエストを他社網に送信することで、他社網の階層の深さを示す階層数を検出する。具体的には、階層検出部１１は、リクエストの最大転送数を、０から１ずつ増加させて他社網に送信し、他社網から成功応答を受信したときの最大転送数に１加算した値を、他社網の階層の深さを示す階層数と特定する。
　障害検知部１２は、INVITEリクエストを他社網に送信する際にタイマを起動し、INVITEリクエストに対する18xレスポンス（暫定レスポンス）を受信することなく、タイマがタイムアウトになった場合、他社網の障害を検知する。また、障害検知部１２は、他社NNI-GW５から500エラーレスポンス（Server Internal Error）を受信した場合、他社網の障害を検知する。
　障害箇所特定部１３は、他社網の障害を検知した場合、他社網にOPTIONSリクエストを送信することで、他社網の障害箇所の階層を特定する。
　判定部１４は、障害箇所の階層が他社網の階層数より小さい階層の場合、他社網の網コア装置（他社NNI-GW５、他社SIPサーバ６）に起因する障害と判定し、障害箇所の階層が他社網の階層数と等しい場合、ユーザ側装置（他社HGW７）またはユーザ端末８に起因する障害であると判定する。また、判定部１４は、他社網の網コア装置に起因する障害と判別した場合、他社網の現用の他社NNI-GW５とは別の他社NNI-GW５にOPTIONSリクエストを送信し、別の他社NNI-GW５を介した経路での他社網の疎通確認後に、別の他社NNI-GW５の経路へ切り替える。
　相互接続部１５は、他社網とデータを送受信するために、データ形式、通信方式などを変換する。記憶部１６には、階層検出部１１が検出した他社網の階層数などが記憶される。
　上記説明した自社NNI-GW１には、例えば、CPU（Central Processing Unit、プロセッサ）と、メモリと、ストレージ（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置と、入力装置と、出力装置とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされた自社NNI-GW１用のプログラムを実行することにより、自社NNI-GW１の各機能が実現される。また、自社NNI-GW１用のプログラムは、HDD、SSD、USBメモリ、CD-ROM、DVD-ROM、MOなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
　次に、本実施形態の通信システムにおける動作を説明する。
　図３は、平常時における通信システムの動作を示すシーケンス図である。平常時において、自社NNI-GW１は、OPTIONSリクエストを他社網に送信することで、他社網の階層の深さを示す階層数を検出する。
　具体的には、自社NNI-GW１の階層検出部１１は、サンプリング的にOPTIONSリクエストを他社網に送信する。その際、階層検出部１１は、OPTIONSリクエストの最大転送数を示すMax-Forwardヘッダ（以下、「MF」という。）の値を、０から１ずつ増加（インクリメント）させながら送信する。なお、OPTIONSリクエストの宛先（Request-URI）は、他社網の電話番号体系の任意の電話番号とする。
　図示する例では、階層検出部１１は、MF値に０を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１１）。図１に示すように、他社網に複数の他社NNI-GW５が存在する場合、階層検出部１１は、任意のPOIの任意の他社NNI-GW５にOPTIONSリクエストを送信する。
　OPTIONSリクエストを受信した他社NNI-GW５は、MF値を１減算しようとするが、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンス（エラー応答）を自社NNI-GW１に送信する（Ｓ１２）。483エラーは、最大ホップ数を超えた場合に送信される。
　そして、階層検出部１１は、MF値に１を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１３）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ１４）。他社SIPサーバ６Ａは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを、他社NNI-GW５を介して自社NNI-GW１に送信する（Ｓ１５）。
　そして、階層検出部１１は、MF値に２を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１６）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値１のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ１７）。他社ＳＩＰサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ｂに送信する（Ｓ１８）。他社ＳＩＰサーバ６Ｂは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを、他社NNI-GW５等を介して自社NNI-GW１に送信する（Ｓ１９）。
　そして、階層検出部１１は、MF値に３を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ２０）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値２のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ２１）。他社ＳＩＰサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値を１のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ｂに送信する（Ｓ２２）。他社ＳＩＰサーバ６Ｂは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社HGW７に送信する（Ｓ２３）。他社HGW７は、受信したOPTIONSリクエストが自分の宛先であるため、200 OKレスポンス（成功応答）を、他社NNI-GW５等を介して自社NNI-GW１に送信する（Ｓ２４）。
　自社NNI-GW１の階層検出部１１は、200 OKレスポンスを受信したときのOPTIONSリクエストのMF値に１加算した値が、他社網の階層の深さを示す階層数であると検出（学習）する（Ｓ２５）。そして、階層検出部１１は、検出した階層数を記憶部１６に記憶する。図３に示す例では、階層の浅い順に、他社NNI-GW５は１階層目、他社SIPサーバ６Ａが２階層目、他社SIPサーバ６Ｂが３階層目、他社HGW７が４階層目となる。
　なお、複数の通信事業者の他社網とIP相互接続を行う場合、自社NNI-GW１は、通信事業者毎に、図３に示す動作により他社網の階層の深さを検出し、階層数を記憶部１６に記憶する。
　また、本実施形態では、OPTIONSリクエストを用いて他社網の階層の深さを検出するが、これに限定されるものでなく、MFを含むメッセージであればOPTIONSリクエスト以外のメッセージであってもよい。
　図４は、障害時における通信システムの動作を示すシーケンス図である。ここでは、自社SIPサーバ２が送信したINVITEリクエスト（セッション確立要求）がエラーとなる場合を例に説明する。
　自社SIPサーバ２は、INVITEリクエストを自社NNI-GW１に送信する（Ｓ３１）。自社NNI-GW１の相互接続部１５は、受信したINVITEリクエストを他社網の他社NNI-GW５に送信するとともに（Ｓ３２）、100 tryingレスポンス（試行中応答）を自社SIPサーバ２に送信する（Ｓ３３）。
　また、自社NNI-GW１の故障検知部は、Ｓ３２でINVITEリクエストを他社NNI-GW５に送信すると同時に、18x受信タイマを起動し、タイムアウトを監視する。18x受信タイマは、18xレスポンス（例えば180 Ringing、181 Call is being forwardedなど）の受信を監視するためのタイマである。なお、18x受信タイマのタイマ値は、他社網の障害検知を迅速に行うために比較的短い値とする。
　他社NNI-GW５は、INVITEリクエストを次の階層の他社SIPサーバ６Ａに送信するとともに（Ｓ３４）、100 tryingレスポンスを自社NNI-GW１に送信する（Ｓ３５）。そして、他社SIPサーバ６Ａは、INVITEリクエストを次の階層の他社SIPサーバ６Ｂに送信するとともに（Ｓ３６）、100 tryingレスポンスを他社NNI-GW５に送信する（Ｓ３７）。
　ここで、他社SIPサーバ６Ｂに障害が発生している場合、他社SIPサーバ６Ｂは、INVITEリクエストを受信することができず、あるいは、INVITEリクエストを受信しても当該リクエストを処理することができない。これにより、自社NNI-GW１は、正常時においては他社HGW７から送信される18xレスポンスを、Ｓ３２で起動した18x受信タイマが満了する前に受信することができない。すなわち、18xレスポンスを受信する前に、Ｓ３４で起動した18x受信タイマがタイムアウトとなる。これにより、障害検知部１２は、他社網で障害が発生したことを検知する（Ｓ３８）。
　あるいは、他社SIPサーバ６Ｂに障害が発生している場合、隣接する他社SIPサーバ６Ａは、他社SIPサーバ６Ｂの障害を検知して、503エラーレスポンス（Service Unavailable）を隣接する他社NNI-GW５に送信する（Ｓ４１）。他社NNI-GW５は、503エラーレスポンスを受信すると、500エラーレスポンス（Server Internal Error）にインタワークして、隣接する自社NNI-GW１に送信する（Ｓ４２）。これにより、自社NNI-GW１の障害検知部１２は、他社網で障害が発生したと検知する（Ｓ４３）。
　本実施形態では、自社NNI-GW１の障害検知部１２は、Ｓ３８の18x受信タイマのタイムアウト、または、Ｓ４３の500エラーレスポンスの受信により、他社網での障害を検知する。
　障害検知部１２が他社網の障害を検知すると、自社NNI-GW１の障害箇所特定部１３は、他社網の障害箇所を特定する。具体的には、障害箇所特定部１３は、図３で説明したように、OPTIONSリクエストに含まれる最大転送数を示すMF値を、０から１ずつ増加させながら送信して、SIPトレースルートを実施し、障害箇所を特定する。また、障害箇所特定部１３は、OPTIONSリクエストの宛先（Request-URI）に、INVITEリクエスト（Ｓ３１、Ｓ３２等）で指定された電話番号を設定する。
　正常な他社網の各装置は、MF値が０になると483エラーレスポンスを送信する。そこで、障害箇所特定部１３は、OPTIONSリクエストを送信すると同時に483受信タイマを起動し、当該タイマのタイムアウトを監視する。障害箇所特定部１３は、483受信タイマが満了する前に483エラーレスポンスを受信することができない場合、すなわち、483エラーレスポンスを受信する前に483受信タイマがタイムアウトとなった場合、他社網の故障箇所が自分より何番目の階層か（何ホップ先か）を特定する。
　図示する例では、障害箇所特定部１３は、MF値に０を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５１）。他社NNI-GW５は、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを自社NNI-GW１に送信する（Ｓ５２）。
　そして、階層検出部１１は、MF値に１を設定したOPTIONSリクエストを、他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５３）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを他社SIPサーバ６Ａに送信する（Ｓ５４）。他社SIPサーバ６Ａは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを自社NNI-GW１に送信する（Ｓ５５）。
　そして、階層検出部１１は、MF値に２を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５６）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値１のOPTIONSリクエストを他社SIPサーバ６Ａに送信する（Ｓ５７）。他社SIPサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを他社SIPサーバ６Ｂに送信する（Ｓ５８）。
　ここで、他社ＳＩＰサーバ６Ｂで障害が発生しているため、他社SIPサーバ６Ｂは、MF値０のOPTIONSリクエストに対する483エラーレスポンスを送信することができない。これにより、障害箇所特定部１３は、483エラーレスポンスをＳ５６で起動した483受信タイマが満了する前に受信することができず、483受信タイマがタイムアウトとなる。
　これにより、障害箇所特定部１３は、他社網における故障箇所を特定する。すなわち、障害箇所特定部１３は、483受信タイマがタイムアウトとなったときのOPTIONSリクエストのMF値に１加算した値の階層（ホップ先）が、障害が発生した箇所であると特定する（Ｓ５９）。
　図４に示す例では、障害箇所特定部１３は、483受信タイマがタイムアウトとなったときのOPTIONSリクエストのMF値２に１加算した３階層目（他社SIPサーバ６Ｂ）が、障害箇所であると特定する。
　そして、自社NNI-GW１の判定部１４は、他社網の網コア装置に起因する障害であるのか、あるいは、ユーザ側装置またはユーザ端末８に起因する障害であるのか判定する。
　具体的には、判定部１４は、障害箇所特定部１３が特定した障害箇所の階層が、階層検出部１１が検出した他社網の階層数より小さい階層（浅い階層、自社NNI-GW1に近い階層）の場合は、他社網の網コア装置（他社NNI-GW５、他社SIPサーバ６Ａ、６Ｂ）に起因する障害と判定する。
　一方、判定部１４は、特定した障害箇所の階層が他社網の階層数と等しい場合、ユーザ側装置（他社HGW7）またはユーザ端末８に起因する障害であると判定する（Ｓ５９）。ユーザ側装置またはユーザ端末８に起因する障害と判定した場合、判定部１４は、障害の影響が限定的であり、また、現用の他社NNI-GW５とは別の他社NNI-GW５に切り替えても当該障害を回避することは難しいと判断する。このため、判定部１４は、障害回避に関する処理は行わない。
　他社網の網コア装置の障害と判定した場合、判定部１４は、障害の影響が大きく、現用の他社NNI-GW５を他の他社NNI-GW５に切り替えた場合、障害を回避できる可能性があると判断する。そのため、判定部１４は、障害箇所が特定された他社SIPサーバ６Ｂの経路に繋がる現用の他社NNI-GW５とは別の他社NNI-GWを経由したSIP信号の到達可能性を検査する。すなわち、別の他社NNI-GW５の経路での疎通確認に応じて、他社網の切替先の他社NNI-GW５（経路）を洗い出す。
　具体的には、判定部１４は、DNSサーバ３にアクセスし、他社網の全ての他社NNI-GW５に関する情報（例えば、URIなどのアドレス、識別情報など）が設定されたNNI-GWリストを取得する。そして、判定部１４は、障害が検知された経路（系）である、現用の他社NNI-GW５以外の他の他社NNI-GWにOPTIONSリクエストを送信する。このとき、判定部１４は、図３と同様に、OPTIONSリクエストに含まれる最大転送数を示すMF値を、０から１ずつ増加させながら、他の他社NNI-GWにOPTIONSリクエストを送信する。また、判定部１４は、OPTIONSリクエストの宛先（Request-URI）に、INVITEリクエスト（Ｓ３１、Ｓ３２等）で指定された電話番号を設定する。なお、他の他社NNI-GW５には、図１に示すように、同じPOIの他の他社NNI-GW５と、異なるPOIの他の他社NNI-GW５とが含まれる。
　そして、判定部１４は、いずれかの他の他社NNI-GW５の経路でOPTIONSリクエストに対する200 OKレスポンスを受信すると、他社NNI-GW５の切替で障害が回避できるケースであると判定し、当該他の他社NNI-GW５への経路切替を実施する。なお、経路切替には、同じPOIの他の他社NNI-GW５への経路切替と、異なるPOIの他の他社NNI-GW５への経路切替とがある。
　これにより、本実施形態では、他社網の網コア装置の障害と判定した場合に、切替先の経路を洗い出し、障害を回避することができる。また、本実施形態では、経路を切り替え前に、事前に、経路を切り替えることで障害が回避できるかを、OPTIONSリクエストを送信して疎通確認することで検証する。これにより、障害が回避できる場合にのみ、経路を切り替え、経路を切り替えても効果がない（障害が回避できない）場合に、経路を切り替えてしまう無駄な処理を回避することができる。
　以上説明した本実施形態では、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出し、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定し、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する。
　これにより、本実施形態では、他社網で障害が発生した場合、障害の影響範囲を大きいもので、障害を回避できる可能性があるケースか、あるいは、ユーザ端末障害などの障害の影響が限定的なもので、障害を回避できる可能性がないケースかを把握（区別）することができる。
　また、本願発明は、INVITEリクエストを他社網に送信する際に18x受信タイマを起動し、INVITEリクエストに対する暫定レスポンスを受信することなく、18x受信タイマがタイムアウトになった場合、他社網の障害を検知する。これにより、本実施形態では、18x受信タイマのタイマ値を短くすることで、他社網で発生した障害を迅速に検知することができる。
　従来、他社網の障害を検知するには、他社NNI-GW５とのTCPコネクションが切断されるか、INVITEタイムアウト（SIP　Timer B:32秒）を待つしかない。しかしながら、他社NNI-GW５とTCPコネクションを張らない場合は、障害を検知することができない。また、隣接する他社NNI-GW５の先の装置で障害が発生している場合であっても、隣接する他社NNI-GW５からはINVITEリクエストに対する100tryingレスポンスが返答されるため、障害を検知することができない。また、隣接する他社NNI-GW５の先の装置での障害を検知するには、INVITEタイム満了（SIP　Timer C:180秒）が考えらえるが、この場合、他社網での障害の検知が長時間化してしまい、その間に多数の呼損が生じる。
　これに対し、本実施形態では、NVITEリクエストを他社網に送信する際に、18x受信タイマを起動することで、他社網における障害検知が長期間化することを回避することができる。なお、18x受信タイマのタイマ値は、迅速な障害検知ができるように比較的、短い時間を設定する。
　また、本実施形態では、自社NNI-GW１の実装のみで実現できるため、他社網の装置の実装状況に依存せず、能動的に他社網の障害の原因を検知することができる。また、自社NNI-GW１内の実装であるため、開発が容易で、かつ、オペレータが介在することなく、他の他社NNI-GW５に切り替えることで障害を回避することができる。
　なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
　１　：自社NNI-GW
　１１：階層検出部 
　１２：障害検知部
　１３：障害箇所特定部
　１４：判定部
　１５：相互接続部
　１６：記憶部
　２　：自社SIPサーバ
　３　：DNSサーバ
　５　：他社NNI-GW
　６　：他社SIPサーバ
　７　：他社HGW
　８　：ユーザ端末

Claims (8)

  1. 　他社網の障害を検知する障害検知装置であって、
    　最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出部と、
    　前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部と、
    　前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定部と、を備えること
    　を特徴とする障害検知装置。
  2. 　請求項１記載の障害検知装置であって、
    　前記階層検出部は、前記リクエストの最大転送数を、０から１ずつ増加させて前記他社網に送信し、前記他社網から成功応答を受信したときの前記最大転送数に１加算した値を、前記他社網の階層の深さを示す階層数と特定すること
    　を特徴とする障害検知装置。
  3. 　請求項１または２記載の障害検知装置であって、
    　INVITEリクエストを前記他社網に送信する際にタイマを起動し、前記INVITEリクエストに対する暫定レスポンスを受信することなく、前記タイマがタイムアウトになった場合、前記他社網の障害を検知する障害検知部を、備えること
    　を特徴とする障害検知装置。
  4. 　請求項１から３のいずれか１項に記載の障害検知装置であって、
    　前記判定部は、記他社網の網コア装置の障害と判別した場合、前記他社網の現用のインタフェースサーバとは別のインタフェースサーバに前記リクエストを送信し、前記別のインタフェースサーバを介した経路での他社網の疎通確認後に、前記別のインタフェースサーバへ切り替えること
    　を特徴とする障害検知装置。
  5. 　障害検知装置が行う、他社網の障害を検知する障害検知方法であって、
    　最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出ステップと、
    　前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定ステップと、
    　前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定ステップと、を行うこと
    　を特徴とする障害検知方法。
  6. 　請求項５記載の障害検知方法であって、
    　前記階層検出ステップは、前記リクエストの最大転送数を、０から１ずつ増加させて前記他社網に送信し、前記他社網から成功応答を受信したときの前記最大転送数に１加算した値を、前記他社網の階層の深さを示す階層数と特定すること
    　を特徴とする障害検知方法。
  7. 　請求項５または６記載の障害検知方法であって、
    　INVITEリクエストを前記他社網に送信する際にタイマを起動し、前記INVITEリクエストに対する暫定レスポンスを受信することなく、前記タイマがタイムアウトになった場合、前記他社網の障害を検知する障害検知ステップを、行うこと
    　を特徴とする障害検知方法。
  8. 　請求項１から４のいずれか１項に記載の障害検知装置として、コンピュータを機能させること、を特徴とする障害検知プログラム。
PCT/JP2019/007438 2018-02-28 2019-02-27 障害検知装置、障害検知方法、および障害検知プログラム WO2019167984A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/968,355 US11799840B2 (en) 2018-02-28 2019-02-27 Failure detection device, failure detection method, and failure detection program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-034459 2018-02-28
JP2018034459A JP6985606B2 (ja) 2018-02-28 2018-02-28 障害検知装置、障害検知方法、および障害検知プログラム

Publications (1)

Publication Number Publication Date
WO2019167984A1 true WO2019167984A1 (ja) 2019-09-06

Family

ID=67806241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/007438 WO2019167984A1 (ja) 2018-02-28 2019-02-27 障害検知装置、障害検知方法、および障害検知プログラム

Country Status (3)

Country Link
US (1) US11799840B2 (ja)
JP (1) JP6985606B2 (ja)
WO (1) WO2019167984A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005076550A1 (ja) * 2004-02-09 2005-08-18 Kansai Technology Licensing Organization Co., Ltd. 中継装置、通信システム、制御回路、接続装置及びコンピュータプログラム
JP2011146920A (ja) * 2010-01-14 2011-07-28 Fujitsu Ltd トポロジーツリー作成装置、プログラム、及び方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5967601B2 (ja) * 2013-02-27 2016-08-10 国立研究開発法人情報通信研究機構 Ｉｄ／ロケータ分離に基づくネットワークのマルチホーミング環境におけるリンク障害検出および正常動作中のリンクへのセッション切り替えの方法
US9559985B1 (en) * 2014-01-28 2017-01-31 Google Inc. Weighted cost multipath routing with intra-node port weights and inter-node port weights
US9929930B2 (en) * 2016-01-19 2018-03-27 Netscout Systems Texas, Llc Reducing an amount of captured network traffic data to analyze

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005076550A1 (ja) * 2004-02-09 2005-08-18 Kansai Technology Licensing Organization Co., Ltd. 中継装置、通信システム、制御回路、接続装置及びコンピュータプログラム
JP2011146920A (ja) * 2010-01-14 2011-07-28 Fujitsu Ltd トポロジーツリー作成装置、プログラム、及び方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KODAI YAMAMOTO: "A Study on Failure Detection Method of Other Companies Network in NTNI-GW", PROCEEDINGS OF THE 2017 IEICE GENERAL CONFERENCE, vol. 2, 7 March 2017 (2017-03-07), pages 152, ISSN: 1349-1369 *

Also Published As

Publication number Publication date
US11799840B2 (en) 2023-10-24
JP2019149752A (ja) 2019-09-05
US20210119984A1 (en) 2021-04-22
JP6985606B2 (ja) 2021-12-22

Similar Documents

Publication Publication Date Title
US10771396B2 (en) Communications network failure detection and remediation
KR100728280B1 (ko) Ｓｉｐ를 이용한 통신 시스템에서 호 해제 요청/응답메시지를 이용한 네트워크 상태 관리 방법
US11171875B2 (en) Systems and methods of communications network failure detection and remediation utilizing link probes
JP4470934B2 (ja) プロキシ・サーバ、通信システム、通信方法及びプログラム
WO2007149330A2 (en) Method and apparatus for routing signaling message traffic over a communication network
EP2622812B1 (en) Method and network entity for checking, in an ip based communications network, a status of a destination network
WO2014049316A1 (en) Application layer session routing
US20090201802A1 (en) Method for redirecting network communication ports and network communication system thereof
US8050395B2 (en) Analog telephone adapter and emergency proxy
JP2009219058A (ja) 呼制御装置、呼制御システム、呼制御方法、及びコンピュータプログラム
WO2009049538A1 (fr) Procédé, dispositif et système de surveillance
US8879538B2 (en) Method and gateway for connecting IP communication entities via a residential gateway
WO2019208460A1 (ja) 障害監視装置及び障害監視方法
WO2019167984A1 (ja) 障害検知装置、障害検知方法、および障害検知プログラム
US10063495B2 (en) Method and apparatus for improved handling of IMS node blacklisting
JP6600326B2 (ja) 障害検知装置、通話制御システム、通話制御方法および障害検知プログラム
EP1906605A1 (en) IP telephone system and telephone exchange
JP5212363B2 (ja) 通信システム、通信装置および輻輳発生時の迂回制御方法
JP6303302B2 (ja) 通信制御システム、中継装置及び通信制御プログラム
JP2009239550A (ja) ＶｏＩＰネットワークの輻輳制御システム、、方法、及びプログラム
US8804498B2 (en) Methods for sending and processing an SIP response
CN103795878A (zh) 一种ip承载语音业务的保护方法、设备和系统
JP7269514B2 (ja) 呼制御システム、呼制御装置、呼制御方法及び呼制御プログラム
WO2011001062A1 (fr) Supervision de qualite de communication dans une passerelle d'un reseau de telecommunication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19761717

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19761717

Country of ref document: EP

Kind code of ref document: A1