WO2011052001A1 - 通信障害要因推定方法、およびその推定方法を備えた通信装置 - Google Patents

通信障害要因推定方法、およびその推定方法を備えた通信装置 Download PDF

Info

Publication number
WO2011052001A1
WO2011052001A1 PCT/JP2009/005657 JP2009005657W WO2011052001A1 WO 2011052001 A1 WO2011052001 A1 WO 2011052001A1 JP 2009005657 W JP2009005657 W JP 2009005657W WO 2011052001 A1 WO2011052001 A1 WO 2011052001A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
packet
communication device
failure factor
client terminal
Prior art date
Application number
PCT/JP2009/005657
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 JP2011538109A priority Critical patent/JP5362026B2/ja
Priority to PCT/JP2009/005657 priority patent/WO2011052001A1/ja
Publication of WO2011052001A1 publication Critical patent/WO2011052001A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H04L47/115—Identifying congestion using a dedicated packet

Definitions

  • the present invention relates to a communication failure factor estimation method and a communication apparatus including the estimation method.
  • Patent Document 1 discloses a technique for estimating the cause of a failure when a failure such as communication disconnection or quality degradation occurs between communication devices connected via a network. In the invention of Patent Document 1, it is estimated whether a failure factor exists in the network or the communication device by observing the load on the communication device and the network.
  • Patent Document 1 does not estimate the cause of a failure such as a logical connection or a packet being discarded by the packet filter software. Therefore, the user takes an appropriate response to the failure. I could't.
  • An object of the present invention is to provide a communication failure factor estimation method capable of estimating a factor in detail when a communication failure occurs, and a communication apparatus including the estimation method.
  • a communication failure factor estimation method of the present invention is a method for estimating a communication failure factor between a first communication device and a second communication device that communicate via a relay device, Transmitting a packet requesting a response packet to the second communication device, determining whether or not to receive the response packet from the second communication device within an arbitrary time after transmitting the packet; When the response packet is not received, a first check for checking whether or not the relay device is logically connected to the second communication device, and the relay device physically connected to the second communication device At least one of a second investigation for checking whether or not the first communication apparatus has a filter mechanism for discarding the received specific packet. From the first And judging a communication failure factors based on 3 investigation.
  • the cause of the failure when a communication failure occurs, the cause of the failure can be estimated in detail. Therefore, the cause of the communication failure can be detected quickly.
  • the flowchart which shows the procedure of the connectivity failure factor estimation which concerns on the same embodiment. 6 is an example of a screen for selecting communication quality in the client terminal according to the embodiment.
  • FIG. 1 is a diagram showing a communication system according to an embodiment of the present invention.
  • the communication system of this embodiment includes a communication device (hereinafter referred to as a client terminal) 100, a communication device (hereinafter referred to as a server terminal) 200, and a network 300.
  • the client terminal 100 and the communication device 200 are connected via the network 300.
  • the network 300 may be a large-scale wired network such as the Internet, or a small-scale network such as a LAN (Local Area Network). Further, it may be a wired network or a wireless network.
  • the network 300 includes a LAN 400, a HGW (Home GateGate) 500, and a WAN (Wide Area Network) 600.
  • the client terminal 100 is connected to the LAN 400
  • the server terminal 200 is connected to the WAN 600.
  • the LAN 400 and the WAN 600 are connected to the HGW 500. That is, the HGW 500 serves as a relay terminal that relays communication between the client terminal 100 and the server terminal 200.
  • the HGW 500 has two network interfaces for connecting to both the LAN 400 and the WAN 600.
  • the client terminal 100 and the server terminal 200 are, for example, a combination of a PC and a TV, a PC and a mobile phone, a TV and a mobile phone, or the like.
  • a TCP / IP protocol is assumed as a data communication method, but other protocols and communication methods may be used as long as the same can be implemented.
  • FIG. 2 is a flowchart showing the procedure of the communication failure factor estimation method in the present embodiment.
  • the client terminal 100 executes this communication failure factor estimation method.
  • the server terminal 200 may execute this communication failure factor estimation method.
  • the condition for the client terminal 100 to start executing the communication failure factor estimation method is, for example, that the user inputs a specific execution command at the client terminal 100. Alternatively, the user may instruct execution by clicking a specific button or icon. Alternatively, the client terminal 100 may automatically execute periodically. Alternatively, when a packet requesting a response such as TCP is transmitted from the client terminal 100, it is executed when a response is not received within an arbitrary time (a predetermined time or an appropriately changed time). It may be a thing.
  • the client terminal 100 checks whether it is connected to a connection target communication device (here, the server terminal 200) (step S1). Specifically, the client terminal 100 transmits a packet to the server terminal 200.
  • a connection target communication device here, the server terminal 200
  • the designation of the terminal (that is, the server device 200) that the client terminal 100 examines the connection may be input by the user as shown in FIG. 3, or may be a predetermined terminal.
  • the packet that the client terminal 100 transmits uses a packet that requests the server terminal 200 for a response signal. For example, it is a packet for establishing a TCP connection.
  • the client terminal 100 sets “1” in the SYN flag bit of the TCP header of the packet and transmits it.
  • the server terminal 200 that has received this packet returns a packet in which “1” is set in the SYN flag bit and the ACK flag bit of the TCP header to the client terminal 100 as a response in accordance with the TCP rules.
  • the client terminal 100 may transmit a “ICMP” ECHO “REQUEST packet (Ping) instead of the packet. In this case, a “ICMP” ECHO “REPLY” packet is returned from the server terminal 200 as a response signal.
  • the client terminal 100 determines that the client terminal 100 is connected to the server terminal 200 ("Yes” in step S1). On the other hand, if the response signal cannot be received even after a predetermined time has elapsed, it is determined that the server terminal 200 is not connected (“No” in step S1).
  • step S2 If it is determined that the server terminal 200 is not connected (“No” in step S1), the client terminal 100 performs connection failure factor estimation (step S2).
  • FIG. 4 is a flowchart showing a detailed procedure for estimating a connection failure factor.
  • the client terminal 100 confirms whether the HGW 500 has acquired an IP address in the WAN (step S2_1). Specifically, the client terminal 100 attaches a SOAP Action header to an XML file in which a Get External External IP address action is described, and transmits the HTTP action to the HGW 500 by HTTP POST. If the client terminal 100 receives an XML file (IP address is set) as a response signal from the HGW 500, the HGW 500 determines that the IP address in the WAN 600 has been acquired. On the other hand, if the client terminal 100 receives “SOAP ERROR” or “HTTP ERROR” as a response signal from the HGW 500, the HGW 500 determines that it does not have an IP address in the WAN 600.
  • IP address IP address is set
  • step S2_2 When the HGW 500 has already acquired the IP address in the WAN 600 (“Yes” in step S2_1), it is checked whether the client terminal 100 has packet filter software (a filter mechanism that discards the specific packet) (step S2_2). .
  • the client terminal 100 checks whether or not some common packet filter software names are included in the list of installed software by character string matching.
  • the packet filter software when the packet filter software is provided, it may be checked that the destination address of the packet (here, the server terminal 200) and the communication protocol are not registered in the setting file as a filter list that does not permit communication.
  • step S2_4 If the client terminal 100 has packet filter software (“Yes” in step S2_2), it is estimated that the packet filter software has a failure factor (step S2_4). That is, it is determined that the client terminal 100 and the server terminal 200 are not connected because the packet filter software discards the packet.
  • step S2_5 If the client terminal 100 does not include packet filter software (“No” in step S2_2), it is estimated that there is a failure factor between the server terminal 200 and the HGW 500 (in this case, the WAN 600) (step S2_5).
  • Step S2_1 the client terminal 100 is linked up between the HGW 500 and the server terminal 200 (here, the WAN 600). It is checked whether or not (step S2_3).
  • the client terminal 100 attaches a SOAP Action header to an XML file in which Get Link Layer Max Bit Rates action is described, and transmits it to the HGW 500 by HTTP POST. If the client terminal 100 receives an XML file (which describes the WAN maximum and downlink maximum link speeds) as a response signal from the HGW 500, it is determined that the HGW 500 is normally linked up to the WAN 600. . On the other hand, if the client terminal 100 receives “SOAP ERROR” or “HTTP ERROR” as a response signal from the HGW 500, it is determined that the HGW 500 is not linked up to the WAN 600.
  • step S2_6 If the HGA 500 is linked up to the WAN 600 (“Yes” in step S2_3), it is estimated that there is a failure factor in the setting of the HGW 500 (step S2_6). That is, since there is a problem in the setting of the HGW 500, the HGW 500 cannot acquire the IP address in the WAN, and it can be determined that the connection between the client terminal 100 and the server terminal 200 is not established.
  • step S2_7 it is estimated that there is a failure factor in the user interface with the WAN 600 in the HGW 500. For example, it is determined that the server terminal 200 is not connected because the cable is physically disconnected.
  • the client terminal 100 estimates the cause of the connection failure with the server terminal 200. Thereafter, the client terminal 100 outputs the estimated failure factor to a display unit or the like. For example, a message corresponding to the cause of the failure such as “Check the packet filter software setting” or “Check whether the HGW cable is disconnected” is displayed on the display unit 150 in FIG.
  • step S3 when it is determined in step S1 that the server terminal 200 is connected (“Yes” in step S1), the client terminal 100 checks the communication quality with the server terminal 200 (step S3).
  • the communication quality is, for example, a video disturbance state in streaming distribution of moving images.
  • the client terminal 100 receives streaming video data from the server terminal 200 and displays it on the display unit 150 of the client terminal 100. Then, the user selects and inputs whether or not the displayed video is disturbed. Alternatively, the user may select whether or not the communication quality is sufficient based on the viewing situation of the moving image as shown in FIG. In this case, it is assumed that the communication quality is recognized in advance.
  • the packet loss rate may be measured using ping or the like, and if the packet loss rate is higher than a predetermined threshold, it may be determined that the communication quality is low (“No” in step S3).
  • step S3 If it is determined in step S3 that the communication quality is low (“No” in step S3), the client terminal 100 performs quality failure factor estimation (step S4).
  • FIG. 6 is a flowchart showing a detailed procedure for estimating the quality failure factor.
  • a wireless section presence / absence determination it is determined whether or not a wireless section exists between the client terminal 100 and the server terminal 200 (a wireless section presence / absence determination) (step S4_1).
  • FIG. 7 is a flowchart showing a detailed procedure for determining whether or not there is a radio section.
  • the HGW 500 executes the wireless section presence / absence determination in accordance with a request from the client terminal 100.
  • a packet instructing the start of the wireless section presence / absence determination is transmitted from the client terminal 100 to the HGW 500.
  • the HGW 500 receives this packet and starts determining whether or not there is a wireless section (step S1001).
  • the HGW 500 unicasts an ICMP ECHO REQUEST packet (ping) to the client terminal 100 (step S1002).
  • Parameters used for unicast ping data size, packet interval, number of packet transmissions, etc.
  • the client terminal 100 receives the ICMP-ECHO-REQUEST packet, it returns an ICMP-ECHO-REPLY packet to the HGW 500.
  • the HGW 500 calculates a packet loss rate by using the number of ICMP ECHO REPLY packets received from the client terminal 100 and the number of ICMP ECHO REQUEST packets transmitted by the own device (step S1002). The calculated packet loss rate is stored in the internal memory of the HGW 500 or the like.
  • the HGW 500 broadcasts an ICMP “ECHO” REQUEST packet (ping) (step S1003).
  • Parameters used for broadcast ping (data size, packet interval, number of packet transmissions, etc.) use the same values as in unicast transmission in step S1002.
  • a broadcast address such as “255.255.255.255” is set as the destination IP address of the ICMP ⁇ ECHO REQUEST packet.
  • the HGW 500 calculates the packet loss rate by using the number of ICMP ECHO REPLY packets received from the client terminal 100 and the number of ICMP ECHO REQUEST packets transmitted by the own device. The calculated packet loss rate is stored in the internal memory of the HGW 500 or the like.
  • the HGW 500 obtains the packet loss rate during unicast transmission and broadcast transmission from the memory, and calculates the difference between the two. Then, the calculated packet loss rate difference is compared with a predetermined threshold value (step S1004).
  • the HGW 500 determines that there is no wireless section with the client terminal 100 (step S1005).
  • the HGW 500 determines that a wireless section exists between the client terminal 100 (step S1006).
  • the HGW 500 notifies the client terminal 100 of the determination result after the above-described wireless section presence / absence determination is completed.
  • step S4_3 when it is determined in step S4_2 that a wireless section exists (“Yes” in step S4_2), the client terminal 100 determines that the wireless section is a cause of communication failure (step S4_3). That is, the wireless section is more susceptible to packet loss than the wired section due to the propagation environment or the like, and the communication quality is deteriorated.
  • transmission control can be performed in consideration of the presence of the wireless section in subsequent communications.
  • a congestion control algorithm that takes into account packet loss peculiar to a wireless section is used.
  • an encoding method having high resistance to packet loss peculiar to a wireless section is adopted.
  • step S4_4 when it is determined that there is no wireless section between the HGW 500 and the client terminal 100 (“No” in step S4_2), the HGW 500 and the HGW 500 are generally connected by a wired line whose communication quality is higher than the wireless line. Assuming that the client terminal 100 is connected, data transmission / reception is performed by a method with higher communication efficiency (step S4_4). For example, in a communication method that performs flow control such as TCP, communication efficiency can be improved by more actively increasing or decreasing windows. In addition, an encoding method having a high bit rate can be employed for transferring multimedia data such as audio and video. With the above processing, the estimation processing is completed.
  • FIG. 8 shows the client terminal 100.
  • the client terminal 100 includes an estimation unit 110, a transmission unit 120, a reception unit 130, and a search unit 140.
  • the estimation unit 110 executes the above-described communication failure factor estimation method.
  • the transmission unit 120 is instructed to transmit the various packets described above according to the communication failure factor estimation method. After the packet transmission, information indicating whether or not a response packet for the transmitted packet has been received within an arbitrary time is received from the receiving unit 130. Further, when a response packet is received, the content of the response packet is received from the receiving unit 130.
  • the estimation unit 110 instructs the search unit 140 to investigate whether the packet filter software is installed according to the communication failure factor estimation method. Thereafter, the presence / absence of packet filter software is received from the search unit 140 as an investigation result.
  • the estimation unit 110 Based on the presence / absence of the response packet notified from the reception unit 130 and the content of the response packet and the presence / absence of the packet filter software notified from the search unit 140, the estimation unit 110 performs communication according to the procedure of the communication failure factor estimation method described above. Estimate the obstacle factor.
  • the transmission unit 120 transmits a packet in accordance with an instruction from the estimation unit 110.
  • the receiving unit 130 receives a packet transmitted by another communication device (here, the server terminal 200 or the HGW 500). Furthermore, the receiving unit 130 notifies the estimating unit 110 of whether or not a packet has been received and the content of the received packet.
  • another communication device here, the server terminal 200 or the HGW 500.
  • the search unit 140 investigates whether or not the packet filter software is installed in its own terminal according to the instruction from the estimation unit 110. Then, the search unit 140 notifies the estimation unit 110 of the presence / absence of packet filter software as an investigation result.
  • the search unit 140 may be included in the estimation unit 110.
  • the client terminal 100 may further include a display unit 150 for outputting the communication failure factor estimated by the estimation unit 110 and notifying the user.
  • the communication failure factor estimation method of the present embodiment when a communication failure occurs, the communication failure factor can be specifically estimated. In addition, by notifying the user of the estimated cause of communication failure, the user can take appropriate measures against the failure.
  • IPv4 is used as the network protocol
  • the network protocol may be IPv6.
  • a communication protocol other than TCP / IP may be used as long as the same procedures and effects as those described above can be obtained.
  • the communication failure factor estimation method of this embodiment may be implemented in a system in which the client terminal 100 and the server terminal 200 are connected to the same LAN.
  • the procedure related to the WAN 600 in the communication failure factor estimation method (step S2_1: confirmation of whether the HGW 500 has acquired an IP address in the WAN 600 and step S2_3: confirmation of whether the HGW 500 is linked up to the WLAN 600) is not performed. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

　HGW５００を介してサーバ端末２００と通信を行うクライアント端末１００の通信障害要因推定方法を提供する。前記通信障害要因推定方法は、サーバ端末２００に対して応答パケットを要求するパケットを送信し（ステップＳ１）、パケットを送信してから任意時間内に、応答パケットを受信するか否かを判定する。応答パケットが受信されない場合に、HGW５００が論理的にサーバ端末２００と接続されているか否かを調べる第１の調査（ステップＳ２_１）と、HGW５００が物理的にサーバ端末２００と接続されているか否かを調べる第２の調査（ステップＳ２_３）と、受信した特定のパケットを廃棄するフィルタ機構をクライアント端末１００が有しているか否かを調べる第３の調査（ステップＳ２_２）のうち少なくとも１つを実行する。

Description

通信障害要因推定方法、およびその推定方法を備えた通信装置
　本発明は、通信障害要因推定方法、およびその推定方法を備えた通信装置に関する。
　ネットワークを介して接続される通信装置間で、通信の切断もしくは品質劣化などの障害が発生した場合、障害の要因を推定する技術が特許文献１に開示されている。その特許文献１の発明では、通信装置とネットワークの負荷を観測することにより、障害要因がネットワークと通信装置のいずれに存在するかを推定している。
特開P2007-189615号公報
　特許文献１の推定方法では、論理的に接続されていない、パケットフィルタソフトによりパケットが廃棄されているなどの障害の要因を推定するものではないため、ユーザが障害に対して適切な対応をとることができなかった。
　本発明の目的は、通信障害が発生した場合に、要因を詳細に推定することができる通信障害要因推定方法、およびその推定方法を備えた通信装置を提供することにある。
　上記目的を達成するために、本発明の通信障害要因推定方法は、中継装置を介して通信を行う第１通信装置と第２通信装置との間の通信障害要因を推定する方法であって、前記第２通信装置に対して応答パケットを要求するパケットを送信し、前記パケットを送信してから任意時間内に、前記第２通信装置からの前記応答パケットを受信するか否かを判定し、前記応答パケットが受信されない場合に、前記中継装置が論理的に前記第２通信装置と接続されているか否かを調べる第１の調査と、前記中継装置が物理的に前記第２通信装置と接続されているか否かを調べる第２の調査と、受信した特定のパケットを廃棄するフィルタ機構を前記第１通信装置が有しているか否かを調べる第３の調査のうち少なくとも１つを実行し、前記第１から第３の調査に基づき通信障害要因を判定することを特徴とする。
　本発明によれば、通信障害が発生した場合に、障害の要因を詳細に推定することができる。そのため、通信障害の原因をいち早く検出することができる。
本発明の実施形態に係る通信システムを示す図。 同実施形態に係る通信障害要因推定の手順を示すフローチャート。 同実施形態に係るクライアント端末においてサーバ端末を指定する画面の例。 同実施形態に係る接続性障害要因推定の手順を示すフローチャート。 同実施形態に係るクライアント端末において通信品質を選択する画面の例。 同実施形態に係る品質障害要因推定の手順を示すフローチャート。 同実施形態に係る無線区間有無判定の手順を示すフローチャート。 同実施形態に係るクライアント端末の構成を示す図。
　以下、図面を参照しながら本発明の実施形態について詳細に説明する。
　図１は、本発明の実施形態に係る通信システムを示す図である。本実施形態の通信システムは、通信装置（以下、クライアント端末という）１００、通信装置（以下、サーバ端末という）２００、ネットワーク３００で構成される。クライアント端末１００と通信装置２００は、ネットワーク３００を介して接続される。ネットワーク３００はインターネットのような大規模な有線ネットワークでもよいし、ＬＡＮ（Local Area Network）のような小規模なネットワークでもよい。また、有線ネットワークでも、更には無線ネットワークでもよい。
　本実施形態では、ネットワーク３００はＬＡＮ４００、ＨＧＷ（Home GateWay）５００、ＷＡＮ（Wide Area Network）６００を含む。クライアント端末１００はＬＡＮ４００に接続し、サーバ端末２００はＷＡＮ６００に接続している。ＬＡＮ４００とＷＡＮ６００とは、ＨＧＷ５００に接続されている。すなわち、ＨＧＷ５００はクライアント端末１００とサーバ端末２００間の通信を中継する中継端末の役割を果たしている。ＨＧＷ５００はＬＡＮ４００とＷＡＮ６００の両方に接続するため、２つのネットワークインタフェースを有する。
　クライアント端末１００およびサーバ端末２００は、例えばＰＣとテレビ、又はＰＣと携帯電話、又はテレビと携帯電話などの組合せである。なお、以降の説明では、データの通信方式としてTCP/IP 関連プロトコルを想定するが、同等のことを実施できるならば他のプロトコルや通信方式でもよい。
　図２は、本実施形態における通信障害要因推定方法の手順を示すフローチャートである。ここでは、クライアント端末１００が、この通信障害要因推定方法を実行するものとする。しかし、クライアント端末１００ではなく、サーバ端末２００がこの通信障害要因推定方法を実行するものであってもよい。
　クライアント端末１００が通信障害要因推定方法の実行を開始する条件は、例えば、クライアント端末１００においてユーザが特定の実行コマンドを入力することである。または、ユーザが特定のボタンやアイコンをクリックして実行を指示するものでもよい。または、クライアント端末１００が、定期的に自動的に実行するものでもよい。あるいは、クライアント端末１００からＴＣＰのような応答を要求するパケットを送信した場合に、任意時間内（予め決めておいた時間でもよく、適宜変更した時間でもよい）に応答を受信しない場合に実行するものでもよい。
　図２において、まず、クライアント端末１００は、接続対象の通信装置（ここでは、サーバ端末２００）と接続されているかどうかを調べる（ステップＳ１）。具体的には、クライアント端末１００は、サーバ端末２００宛にパケットを送信する。なお、クライアント端末１００が接続を調べる対象とする端末（すなわち、サーバ装置２００）の指定は、図３に示すようにユーザがＵＲＬを入力してもよいし、あらかじめ定められた端末としてもよい。
　クライアント端末１００が送信するパケットは、サーバ端末２００に応答信号を要求するパケットを用いる。例えば、ＴＣＰのコネクションを確立するためのパケットである。この場合、クライアント端末１００は、パケットのＴＣＰヘッダのＳＹＮフラグビットに「１」を設定して送信する。このパケットを受信したサーバ端末２００は、ＴＣＰのルールに従って、ＴＣＰヘッダのＳＹＮフラグビットとＡＣＫフラグビットに「１」を設定したパケットを、応答としてクライアント端末１００宛に返信する。または、上記パケットの代わりに、クライアント端末１００は ICMP ECHO REQUESTパケット(Ping)を送信してもよい。この場合は、サーバ端末２００から応答信号として ICMP ECHO REPLYパケットが返信される。
　これらの方法において、クライアント端末１００は、サーバ端末２００から応答信号を受信すれば、サーバ端末２００と接続していると判定する（ステップＳ１の“Ｙｅｓ”）。一方、一定の時間が経過しても応答信号が受信できなければ、サーバ端末２００と接続されていないと判定する（ステップＳ１の“Ｎｏ”）。
　サーバ端末２００と接続されていないと判定した場合（ステップＳ１の“Ｎｏ”）、クライアント端末１００は、接続障害要因推定を行う（ステップＳ２）。
　図４は、接続障害要因推定の詳細な手順を示すフローチャートである。図４において、まず、クライアント端末１００は、ＨＧＷ５００がＷＡＮにおけるＩＰアドレスを取得しているかを確認する（ステップＳ２_１）。具体的には、クライアント端末１００は、Get External IP Addressアクションを記述した XML ファイルにSOAP Actionヘッダを付けて、HTTP POSTでＨＧＷ５００に送信する。ＨＧＷ５００からの応答信号として、クライアント端末１００がＸＭＬファイル（ＩＰアドレスが設定されている）を受信すれば、ＨＧＷ５００はＷＡＮ６００におけるＩＰアドレスを取得済みであると判定する。一方、ＨＧＷ５００からの応答信号として、クライアント端末１００が「SOAP ERROR」あるいは「HTTP ERROR」を受信すれば、ＨＧＷ５００はＷＡＮ６００におけるＩＰアドレスを有していないと判定する。
　ＨＧＷ５００がＷＡＮ６００におけるＩＰアドレスを取得済みである場合には（ステップＳ２_１の“Ｙｅｓ”）、クライアント端末１００がパケットフィルタソフト（特定パケットを廃棄するフィルタ機構）を備えているかどうかを調べる（ステップＳ２_２）。例えば、クライアント端末１００は、いくつかの一般的なパケットフィルタソフトの名称が、インストール済みソフトウェアのリストに含まれているかを文字列照合により調べる。あるいは、パケットフィルタソフトを備えている場合には、パケットの宛先アドレス（ここではサーバ端末２００）や通信プロトコルが、通信を許可しないフィルタリストとして設定ファイルに登録されていないことを調べてもよい。
　クライアント端末１００がパケットフィルタソフトを備えている場合には（ステップＳ２_２の“Ｙｅｓ”）、パケットフィルタソフトが障害要因があると推定する（ステップＳ２_４）。つまり、パケットフィルタソフトがパケットを廃棄しているために、クライアント端末１００とサーバ端末２００とが接続されないと判定する。
　クライアント端末１００がパケットフィルタソフトを備えていない場合には（ステップＳ２_２の“Ｎｏ”）、サーバ端末２００とＨＧＷ５００との間（ここではＷＡＮ６００）に障害要因があると推定する（ステップＳ２_５）。
　一方、ステップＳ２＿１で、ＨＧＷ５００がＷＡＮ６００におけるＩＰアドレスを取得していない場合には（ステップＳ２_１の“Ｎｏ”）、クライアント端末１００は、ＨＧＷ５００とサーバ端末２００間（ここではＷＡＮ６００）でリンクアップしているか否かを調べる（ステップＳ２_３）。すなわち、クライアント端末１００は、Get Link Layer Max Bit Ratesアクションを記述したXMLファイルにSOAP Actionヘッダを付けて、HTTP POSTでＨＧＷ５００に送信する。ＨＧＷ５００からの応答信号として、クライアント端末１００がＸＭＬファイル（ＷＡＮの上りリンクと下りリンクの最大リンク速度が記載されている）を受信すれば、ＨＧＷ５００は正常にＷＡＮ６００にリンクアップしていると判定する。一方、ＨＧＷ５００からの応答信号として、クライアント端末１００が「SOAP ERROR」あるいは「HTTP ERROR」を受信すれば、ＨＧＷ５００はＷＡＮ６００にリンクアップしていないと判定する。
　ＨＧＡ５００がＷＡＮ６００にリンクアップしている場合には（ステップＳ２_３の“Ｙｅｓ”）、ＨＧＷ５００の設定に障害要因があると推定する（ステップＳ２_６）。つまり、ＨＧＷ５００の設定に問題があるため、ＨＧＷ５００がＷＡＮにおけるＩＰアドレスを取得できず、クライアント端末１００とサーバ端末２００間の接続が確立されないと判定できる。
　一方、ＨＧＡ５００がＷＡＮ６００にリンクアップしていない場合には（ステップＳ２_３の“Ｎｏ”）、ＨＧＷ５００におけるＷＡＮ６００とのユーザインタフェースに障害要因があると推定する（ステップＳ２_７）。例えば、ケーブルが物理的に抜けているためにサーバ端末２００と接続されないと判定する。
　以上のステップＳ２_１～ステップＳ２_７により、クライアント端末１００は、サーバ端末２００との間の接続障害の要因を推定する。その後、クライアント端末１００は、推定した障害要因を表示部等に出力する。例えば、図８の表示部１５０に「パケットフィルタソフトの設定を確認してください」や「HGWのケーブルが抜けていないか確認してください」といった、障害要因に応じたメッセージを表示する。
　図２に戻り、ステップＳ１でサーバ端末２００と接続していると判定した場合（ステップＳ１の“Ｙｅｓ”）、クライアント端末１００は、サーバ端末２００との間の通信品質を調べる（ステップＳ３）。通信品質とは、例えば動画のストリーミング配信における映像の乱れ具合などである。通信品質を調べる方法として、例えば、クライアント端末１００がサーバ端末２００から動画データをストリーミング受信してクライアント端末１００の表示部１５０に表示する。そして、表示される映像が乱れているか否かをユーザに選択入力させる。または、ユーザが動画の視聴状況などから通信品質が十分であるか否かを、図５に示すようにユーザに選択させてもよい。この場合、あらかじめ通信品質を認識していることを前提とする。あるいは、ping等を用いてパケットロス率を測定し、あらかじめ定めた閾値よりもパケットロス率が高い場合に、通信品質が低いと判定してもよい（ステップＳ３の“Ｎｏ”）。
　ステップＳ３で、通信品質が低いと判定した場合（ステップＳ３の“Ｎｏ”）、クライアント端末１００は、品質障害要因推定を行う（ステップＳ４）。
　図６は、品質障害要因推定の詳細な手順を示すフローチャートを示す。図６において、まず、クライアント端末１００とサーバ端末２００との間に無線区間が存在するか否かの判定（無線区間有無判定）する（ステップＳ４_１）。
　図７は、無線区間有無判定の詳細な手順を示すフローチャートである。図７では、クライアント端末１００からの要求に従って、ＨＧＷ５００が無線区間有無判定を実行するものとする。
　図７において、まず、クライアント端末１００からＨＧＷ５００へ、無線区間有無判定の開始を指示するパケットを送信する。ＨＧＷ５００はこのパケットを受信し、無線区間有無の判定を開始する（ステップＳ１００１）。
　次に、ＨＧＷ５００は、クライアント端末１００宛に、ICMP ECHO REQUESTパケット（ping）をユニキャスト送信する（ステップＳ１００２）。ユニキャストのpingで使用するパラメータ（データサイズやパケット間隔、パケット送信回数など）は、事前に設定されているものとする。クライアント端末１００はICMP ECHO REQUESTパケットを受信すると、ICMP ECHO REPLYパケットをＨＧＷ５００に返信する。ＨＧＷ５００は、クライアント端末１００からのICMP ECHO REPLYパケットの受信数と、自装置が送信したICMP ECHO REQUESTパケットの送信数を用いて、パケットロス率を計算する（ステップＳ１００２）。計算したパケットロス率は、ＨＧＷ５００の内部メモリ等に記憶される。
　次に、ＨＧＷ５００は、ICMP ECHO REQUESTパケット（ping）をブロードキャスト送信する（ステップＳ１００３）。ブロードキャストのpingで使用するパラメータ（データサイズやパケット間隔、パケット送信回数など）は、ステップＳ１００２におけるユニキャスト送信時と同じ値を使用する。また、ブロードキャスト送信ではICMP ECHO REQUESTパケットの宛先ＩＰアドレスとして、例えば「２５５.２５５.２５５.２５５」などのブロードキャストアドレスを設定する。そして、ステップＳ１００２と同様に、ＨＧＷ５００は、クライアント端末１００からのICMP ECHO REPLYパケットの受信数と、自装置が送信したICMP ECHO REQUESTパケットの送信数を用いて、パケットロス率を計算する。計算したパケットロス率は、ＨＧＷ５００の内部メモリ等に記憶される。
　次に、ＨＧＷ５００は、ユニキャスト送信時とブロードキャスト送信時のパケットロス率をそれぞれメモリから取得し、両者の差を計算する。そして、計算したパケットロス率の差を、既定の閾値と比較する（ステップＳ１００４）。
　パケットロス率の差が閾値よりも小さい場合（ステップＳ１００４の“Ｎｏ”）、ＨＧＷ５００はクライアント端末１００との間に無線区間が存在しないと判定する（ステップＳ１００５）。
　一方、パケットロス率の差が閾値よりも大きい場合（ステップＳ１００４の“Ｙｅｓ”）、ＨＧＷ５００はクライアント端末１００との間に無線区間が存在すると判定する（ステップＳ１００６）。
　上記の無線区間有無判定の終了後、ＨＧＷ５００は、判定結果をクライアント端末１００に通知する。
　図６に戻り、ステップＳ４＿２で無線区間が存在すると判定された場合（ステップＳ４_２の“Ｙｅｓ”）、クライアント端末１００は、無線区間が通信障害要因であると判定する（ステップＳ４_３）。すなわち、無線区間は有線区間よりも伝播環境等によりパケットロスが発生しやすいので、通信品質が劣化している状況である。
　ＨＧＷ５００とクライアント端末１００との間に無線区間が存在すると判定された場合、以後の通信では無線区間の存在を考慮した送信制御を行うことができる。例えば、TCP (Transmission Control Protocol)のように輻輳制御を有する通信方式では、無線区間特有のパケットロスを考慮した輻輳制御アルゴリズムを使用する。また、例えば音声や映像などのマルチメディアデータの転送では、無線区間特有のパケットロスに対する耐性が高いエンコード方式を採用する。
　一方、ＨＧＷ５００とクライアント端末１００の間に無線区間が存在しないと判定された場合は（ステップＳ４＿２の“Ｎｏ”）、一般的には無線回線よりも通信品質が高いとされる有線回線によりＨＧＷ５００とクライアント端末１００が接続されていると想定し、より通信効率の高い方式でデータ送受信を行う（ステップＳ４＿４）。例えば、TCPのようなフロー制御を行う通信方式では、ウィンドウの増減をより積極的に行うことで通信効率を向上させることができる。また、音声や映像などのマルチメディアデータの転送ではビットレートの高いエンコード方式を採用することができる。以上の処理で、推定処理を終了する。
　次に、本実施形態におけるクライアント端末１００の構成を説明する。図８に、クライアント端末１００を示す。クライアント端末１００は、推定部１１０、送信部１２０、受信部１３０、探索部１４０を有する。
　推定部１１０は、上述の通信障害要因推定方法を実行する。通信障害要因推定方法に従って、前述した各種パケットの送信を送信部１２０に指示する。パケット送信後、送信したパケットに対する応答パケットを任意時間内に受信したか否かの情報を受信部１３０から受け取る。さらに応答パケットを受信した場合には、当該応答パケットの内容を、受信部１３０から受け取る。
　また、推定部１１０は、通信障害要因推定方法に従って、パケットフィルタソフトがインストールされているかの調査を、探索部１４０に指示する。その後、調査結果として、パケットフィルタソフトの有無を、探索部１４０から受け取る。
　推定部１１０は、受信部１３０から通知される応答パケットの有無と応答パケットの内容、および探索部１４０から通知されるパケットフィルタソフトの有無に基づいて、前述した通信障害要因推定方法の手順に従って通信障害要因を推定する。
　送信部１２０は、推定部１１０からの指示に従って、パケットを送信する。
　受信部１３０は、他の通信装置（ここでは、サーバ端末２００やHGW５００）が送信するパケットを受信する。さらに、受信部１３０は、パケット受信の有無や、受信したパケットの内容を推定部１１０に通知する。
　探索部１４０は、推定部１１０からの指示に従って、自端末にパケットフィルタソフトがインストールされているか否かを調査する。そして探索部１４０は、調査結果として、パケットフィルタソフトの有無を、推定部１１０に通知する。
　探索部１４０は、推定部１１０に含まれていてもよい。また、クライアント端末１００は、推定部１１０において推定した通信障害要因を出力して、ユーザに通知するための表示部１５０をさらに備えていてもよい。
　本実施形態の通信障害要因推定方法によれば、通信障害が発生した場合に、通信障害要因を具体的に推定することができる。また、推定した通信障害要因をユーザに通知することで、ユーザが障害に対して適切な対応をとることができる。
　尚、本実施形態ではネットワークプロトコルとしてIPv4を仮定して説明したが、ネットワークプロトコルはIPv6でもよい。さらには、以上で説明した内容と同等手順、効果が得られればTCP/IP以外の通信プロトコルを用いてもよい。
　また、本実施形態の通信障害要因推定方法は、クライアント端末１００とサーバ端末２００が同じLANに接続されているシステムにおいて、実施してもよい。この場合、通信障害要因推定方法におけるWAN６００に関する手順（ステップS２_１：HGW５００がWAN６００におけるIPアドレスを取得しているかどうかの確認及びステップS２_３：HGW５００がWLAN６００にリンクアップしているかどうかの確認）は行わない。
　尚、本発明は上記実施形態をそのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
１００・・・クライアント端末
２００・・・サーバ端末
３００・・・ネットワーク
４００・・・LAN
５００・・・HGW
６００・・・WAN
１１０・・・推定部
１２０・・・送信部
１３０・・・受信部
１４０・・・探索部
１５０・・・表示部

Claims (8)

  1. 　中継装置を介して通信を行う第１通信装置と第２通信装置との間の通信障害要因を推定する方法であって、
    　前記第２通信装置に対して応答パケットを要求するパケットを送信し、
    　前記パケットを送信してから任意時間内に、前記第２通信装置からの前記応答パケットを受信するか否かを判定し、
    　前記応答パケットが受信されない場合に、前記中継装置が論理的に前記第２通信装置と接続されているか否かを調べる第１の調査と、前記中継装置が物理的に前記第２通信装置と接続されているか否かを調べる第２の調査と、受信した特定のパケットを廃棄するフィルタ機構を前記第１通信装置が有しているか否かを調べる第３の調査のうち少なくとも１つを実行し、
    　前記第１から第３の調査に基づき通信障害要因を判定する
    ことを特徴とする通信障害要因推定方法。
  2. 　前記第１の調査は、
    　前記中継装置がネットワークアドレスを取得しているか否かを調べ、
    　前記ネットワークアドレスを取得していない場合に、前記中継装置が論理的に前記第２通信装置と接続されていないと判定する
    ことを特徴とする請求項１に記載の通信障害要因推定方法。
  3. 　前記第２の調査は、
    　前記中継装置と前記他の通信装置との間のリンクアップ状況を調べ、
    　前記リンクアップ状況がエラーを示す場合に、前記中継装置が物理的に前記第２通信装置と接続されていないと判定する
    ことを特徴とする請求項２に記載の通信障害要因推定方法。
  4. 　前記第３の調査は、
    　前記フィルタ機構を前記第１通信装置が有している場合に、前記フィルタ機構が通信障害要因であると判定することを特徴とする請求項３に記載の通信障害要因推定方法。
  5. 　前記応答パケットが受信された場合に、前記中継装置と前記第１通信装置との間に無線区間が存在するか否かを調査する第４の調査を実行することを特徴とする請求項４に記載の通信障害要因推定方法。
  6. 　前記第４の調査は、
    　前記中継装置と第１通信装置との間のユニキャスト通信における第１のパケットロス率と、
    　前記中継装置と第１通信装置との間のブロードキャスト通信における第２のパケットロス率と、を測定し、
    　前記第１のパケットロス率と前記第２のパケットロス率とを比較し、
    　前記第２のパケットロス率の方が高い場合に、前記無線区間が存在すると判定する

    ことを特徴とする請求項５に記載の通信障害要因推定方法。
  7. 　前記第４の調査は、
    　前記無線区間が存在する場合に、前記無線区間が通信障害要因であると判定し、パケットの送信方法を変更する
    ことを特徴とする請求項６に記載の通信障害要因推定方法。
  8. 　中継装置を介して他の通信装置と通信を行う通信装置であって、
    　前記他の通信装置との間の前記通信に障害が発生した場合に、障害要因を推定する推定部と、
    　前記推定部の指示に従ってパケットを前記他の通信装置に送信する送信部と、
    　前記他の通信装置からの応答パケットを受信する受信部と、
    　特定のパケットを廃棄するフィルタ機構の有無を、前記推定部の指示に従って検索する検索部と
    を備え、
    　前記推定部は、
    　前記受信部が前記他の通信装置から任意時間内に前記応答パケットを受信するか否かを判定し、
    　前記応答パケットが受信されない場合に、前記中継装置が論理的に前記他の通信装置と接続されているか否かを調べる第１の調査と、前記中継装置が物理的に前記他の通信装置と接続されているか否かを調べる第２の調査と、
    受信した特定のパケットを廃棄するフィルタ機構を自通信装置が有しているか否かを前記探索部に調べさせる第３の調査のうち少なくとも１つを実行し、前記第１から第３の調査に基づき通信障害要因を判定する
    ことを特徴とする通信装置。
PCT/JP2009/005657 2009-10-27 2009-10-27 通信障害要因推定方法、およびその推定方法を備えた通信装置 WO2011052001A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011538109A JP5362026B2 (ja) 2009-10-27 2009-10-27 通信障害要因推定方法、その推定方法を備えた通信装置およびプログラム
PCT/JP2009/005657 WO2011052001A1 (ja) 2009-10-27 2009-10-27 通信障害要因推定方法、およびその推定方法を備えた通信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/005657 WO2011052001A1 (ja) 2009-10-27 2009-10-27 通信障害要因推定方法、およびその推定方法を備えた通信装置

Publications (1)

Publication Number Publication Date
WO2011052001A1 true WO2011052001A1 (ja) 2011-05-05

Family

ID=43921448

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/005657 WO2011052001A1 (ja) 2009-10-27 2009-10-27 通信障害要因推定方法、およびその推定方法を備えた通信装置

Country Status (2)

Country Link
JP (1) JP5362026B2 (ja)
WO (1) WO2011052001A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016019230A (ja) * 2014-07-10 2016-02-01 Ｎｅｃプラットフォームズ株式会社 通信機器、及び回線障害の検出方法
JP2017135729A (ja) * 2017-03-03 2017-08-03 日本電気株式会社 通信回線形態判別装置、通信回線形態判別方法、及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63280538A (ja) * 1987-05-12 1988-11-17 Fujitsu Ltd 折返し試験方式
JP2002335259A (ja) * 2001-05-08 2002-11-22 Nec Corp ループ防止方法及びノード装置
WO2006006683A1 (ja) * 2004-07-15 2006-01-19 Matsushita Electric Industrial Co., Ltd. 中継情報設定方法、中継情報設定装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63280538A (ja) * 1987-05-12 1988-11-17 Fujitsu Ltd 折返し試験方式
JP2002335259A (ja) * 2001-05-08 2002-11-22 Nec Corp ループ防止方法及びノード装置
WO2006006683A1 (ja) * 2004-07-15 2006-01-19 Matsushita Electric Industrial Co., Ltd. 中継情報設定方法、中継情報設定装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016019230A (ja) * 2014-07-10 2016-02-01 Ｎｅｃプラットフォームズ株式会社 通信機器、及び回線障害の検出方法
JP2017135729A (ja) * 2017-03-03 2017-08-03 日本電気株式会社 通信回線形態判別装置、通信回線形態判別方法、及びプログラム

Also Published As

Publication number Publication date
JPWO2011052001A1 (ja) 2013-03-14
JP5362026B2 (ja) 2013-12-11

Similar Documents

Publication Publication Date Title
JP5020076B2 (ja) 低頻度ａｃｋのシステムに適した高性能ｔｃｐ
JP5867188B2 (ja) 情報処理装置、輻輳制御方法および輻輳制御プログラム
JP5867160B2 (ja) 通信制御装置、通信制御方法および通信制御プログラム
JP2005287045A (ja) Ｉｐネットワークに接続された装置の発見の方法、及び、この方法を実行する装置
JPWO2008023656A1 (ja) 通信装置
JP2009231975A (ja) 情報処理装置、情報処理方法、クライアント機器、情報処理システム
JP2012516084A5 (ja)
JP2009540663A (ja) ネットワーク上で遠隔で装置にアクセスする方法及びシステム
JP2009296084A (ja) マルチパス通信システム
US6965573B1 (en) Network system
CN112436924B (zh) 一种数据传输方法及电子设备
JP2006352259A (ja) ネットワーク障害検出装置及びネットワーク障害検出方法
CN111770140A (zh) 一种通信方法、用户设备及代理服务器集群
EP3386233A1 (en) Mobile device recording for troubleshooting assistance
JP3999785B2 (ja) 通信方法
US8711869B2 (en) Message transfer apparatus, output method, and computer program product
JP5127062B2 (ja) ネットワーク障害検出装置、データ中継装置、ネットワーク障害検出方法、ネットワーク障害検出システム及びネットワーク障害検出プログラム
TWI580226B (zh) 決定最大分段大小値之方法
CN113438180B (zh) Udp数据包的传输控制方法、装置、设备及可读存储介质
US7840686B2 (en) Method and system for conducting communications over a network
JP5362026B2 (ja) 通信障害要因推定方法、その推定方法を備えた通信装置およびプログラム
CN108270689B (zh) 一种实现业务连接的方法及装置
JP2009065404A (ja) 通信障害切り分け方法、通信障害切り分け機能を有する映像配信システムおよび受信端末
JP4063282B2 (ja) パケット通信装置及びパケット通信方法及びパケット通信プログラム
KR20160131532A (ko) 네트워크 시스템의 서비스 가용성을 최대로 보장하기 위한 적응형 bfd 프로토콜과 그 장치

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: 09850783

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011538109

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09850783

Country of ref document: EP

Kind code of ref document: A1