(57)【要約】【課題】ネットワーク負荷を抑えた通信装置、通信装置の制御方法、プログラム、及び記録媒体を提供する。【解決手段】パケットを送信する前にpingコマンドを送信することでパケットロス率を計測して、それに応じたエラー訂正パケット数を設定することにより、ネットワークに過剰な負荷をかけることを防止できるので、ネットワーク負荷を抑えた通信装置、通信装置の制御方法、プログラム、及び記録媒体の提供を実現できる。【選択図】図１
2010114761.tif 000002
【特許請求の範囲】
【請求項１】
特定の相手機にpingコマンドを送信する送信手段と、
前記pingコマンドにより前記相手機から送り返されるICMPパケットを受信する受信手段と、
前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとからパケットロス率を算出する算出手段と、
UDPパケットを送信するときエラー訂正用パケットを本来送信すべきパケットに付加する付加手段と、を備えた通信装置であって、
前記pingコマンドを送信することで得ることができたパケットロス率を基に、UDP通信をするとき、前記UDPパケットに付加するエラー訂正用パケットの数を決定する制御手段を有することを特徴とする通信装置。
【請求項２】
請求項１記載の通信装置であって、
前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとから連続してパケットロスになった場合のICMPパケットを検出する検出手段を備え、
前記制御手段は、前記UDP通信に先立ち、前記相手機に前記pingコマンドを送信することによって得ることができた連続パケットロス数を検出することでエラー訂正用パケット数を決定することを特徴とする通信装置。
【請求項３】
請求項１記載の通信装置であって、
前記制御手段は、前記UDP通信の前に前記相手機に前記pingコマンドを送信して、パケットロス率を得るだけではなく、前記UDP通信中にも前記相手機に対して一定間隔で前記pingコマンドを送信することでパケットロス率を得て、前記パケットロス率に応じて前記UDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とする通信装置。
【請求項４】
請求項１記載の通信装置であって、
前記制御手段は、前記相手機と行うUDP通信とは別に、一定時間ごとにアドレス帳に登録されている相手機に対し、前記pingコマンドを送信し、時間帯ごとのパケットロス率を記録し、前記相手機と前記UDP通信するとき、前記相手機が記録された通信相手の中に存在するときは、対応するエラー訂正パケット数を読み出し、前記UDPパケットに付加するエラー訂正用パケット数を決定することを特徴とする通信端末。
【請求項５】
請求項１記載の通信端末であって、
付加したUDPパケットのサイズとMTUサイズとを比較する手段と、
比較した結果、前記UDPパケットが前記MTUサイズより長い場合、前記UDPパケットを、前記MTUサイズを越えないように短く調整する手段と、備え、
前記制御手段は、送信すべきUDPパケットが長く、パケットロス率により決定したエラー訂正用パケットを付加すると前記MTUサイズを越えてしまう場合は、パケット長が前記MTUサイズを越えないように付加するエラー訂正用パケットの数を変更することを特徴とする通信端末。
【請求項６】
請求項１記載の通信端末であって、
着信を検出する着信検出手段と、
前記相手機から送られてきたUDPパケットからエラー訂正パケット数を検出する手段と、を備え、
前記制御手段は、送信側から送られて来るパケットのエラー訂正用パケット数を読み取り、同じ通信の着呼側から発呼側へ送信するUDPパケットに読み取ったエラー訂正用パケット数と同一数のパケットのエラー訂正用パケットを付加して送信することを特徴とする通信端末。
【請求項７】
請求項１記載の通信端末であって、
前記制御手段は、自端末が着信側であるとき、着信に応答後、発呼側のアドレスが判明した時点で、前記pingコマンドを送信し、パケットロス率を得ることにより、前記着呼側から前記発呼側へ送信するUDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とする通信端末。
【請求項８】
特定の相手機にpingコマンドを送信し、
前記pingコマンドにより前記相手機から送り返されるICMPパケットを受信し、
前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとからパケットロス率を算出し、
UDPパケットを送信するときエラー訂正用パケットを本来送信すべきパケットに付加する通信装置の制御方法であって、
前記pingコマンドを送信することで得ることができたパケットロス率を基に、UDP通信をするとき、前記UDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とする通信装置の制御方法。
【請求項９】
コンピュータに、
送信手段が、特定の相手機にpingコマンドを送信する手順、
受信手段が、前記pingコマンドにより前記相手機から送り返されるICMPパケットを受信する手順、
算出手段が、前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとからパケットロス率を算出する手順、
付加手段が、UDPパケットを送信するときエラー訂正用パケットを本来送信すべきパケットに付加する手順、
を実行させ、
前記pingコマンドを送信することで得ることができたパケットロス率を基に、UDP通信をするとき、前記UDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とするプログラム。
【請求項１０】
請求項９に記載のプログラムを記録した、コンピュータが読み出し可能であることを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信装置の制御方法、プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
インターネットを利用して複数のファクシミリ装置間でデータを送受信するシステムが開発されている。
特許文献１にインターネットファクシミリ装置に関する技術が記載されている。
このインターネットファクシミリ装置は、ネットワークに接続する手段と、インターネットを介しパケット通信により画像データを送受信するリアルタイムファクシミリ通信手段とを有するインターネットファクシミリ装置において、リアルタイムファクシミリ通信手段により、リアルタイムファクシミリ通信を行ったときに発生する回線断回数を記憶する記憶手段と、記憶手段に回線断回数を記憶させる手段と、記憶手段に記憶されている回線断回数を用いて、リアルタイムファクシミリ通信手段が再発呼動作を行うときの発呼回数を設定する手段と、を設けたものである。
【０００３】
このインターネットファクシミリ装置によれば、ネットワーク負荷状況に応じて発呼回数が設定されるため、接続性等の通信品質を向上させることが可能となるとしている。
【特許文献１】特許第３７９２１６６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載の発明は、ping(packet internet groper：インターネットへの接続確認ツール)の応答時間の遅れ≠パケットロス率であるので、PING応答時間を計測することがパケットロス率を計測することにならない、つまり、「PING応答時間では、正確に冗長パケット数を調整することができない」。
従来のUDP(User Datagram Protocol：インターネット上でのデータ通信に使うプロトコル)通信方式で、エラー訂正用パケットを付加してエラー訂正する通信方式の場合、エラー訂正用パケット数を決定する適切な方法がなかった。
例えば、pingを送信してpingの応答時間が通常より長くかかる場合は、ネットワーク内に多くのパケットが存在すると予想できるので、パケットロスも発生しやすいという仮定の基に、冗長パケット数を増やすという方式や、過去の通信の宛先、エラー訂正用パケット数、通信結果（OK／NG）を記録しておき、同じ宛先で通信エラーが発生したときは、記録されているエラー訂正用パケット数より多いエラー訂正用パケットを付加するという方式が考えられてきた。
【０００５】
しかし、判断の基になっているping応答の遅延や過去の通信履歴から導き出すパケットロス率はあくまでも推測の値にすぎない。このような推測によるパケットロス率からエラー訂正用パケット数を決定することは無駄に長いUDPパケットをネットワークに送り出し、ネットワーク負荷を増加させることになる。
【０００６】
そこで、本発明の目的は、ネットワーク負荷を抑えた通信装置、通信装置の制御方法、プログラム、及び記録媒体を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、請求項１記載の発明は、特定の相手機にpingコマンドを送信する送信手段と、前記pingコマンドにより前記相手機から送り返されるICMPパケットを受信する受信手段と、前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとからパケットロス率を算出する算出手段と、UDPパケットを送信するときエラー訂正用パケットを本来送信すべきパケットに付加する付加手段と、を備えた通信装置であって、前記pingコマンドを送信することで得ることができたパケットロス率を基に、UDP通信をするとき、前記UDPパケットに付加するエラー訂正用パケットの数を決定する制御手段を有することを特徴とする。
【０００８】
請求項２記載の発明は、請求項１記載の通信装置であって、前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとから連続してパケットロスになった場合のICMPパケットを検出する検出手段を備え、前記制御手段は、前記UDP通信に先立ち、前記相手機に前記pingコマンドを送信することによって得ることができた連続パケットロス数を検出することでエラー訂正用パケット数を決定することを特徴とする。
【０００９】
請求項３記載の発明は、請求項１記載の通信装置であって、前記制御手段は、前記UDP通信の前に前記相手機に前記pingコマンドを送信して、パケットロス率を得るだけではなく、前記UDP通信中にも前記相手機に対して一定間隔で前記pingコマンドを送信することでパケットロス率を得て、前記パケットロス率に応じて前記UDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とする。
【００１０】
請求項４記載の発明は、請求項１記載の通信装置であって、前記制御手段は、前記相手機と行うUDP通信とは別に、一定時間ごとにアドレス帳に登録されている相手に対し、前記pingコマンドを送信し、時間帯ごとのパケットロス率を記録し、前記相手機と前記UDP通信するとき、前記相手機が記録された通信相手の中に存在するときは、対応するエラー訂正パケット数を読み出し、前記UDPパケットに付加するエラー訂正用パケット数を決定することを特徴とする。
【００１１】
請求項５記載の発明は、請求項１記載の通信端末であって、付加したUDPパケットのサイズとMTUサイズとを比較する手段と、比較した結果、前記UDPパケットが前記MTUサイズより長い場合、前記UDPパケットを、前記MTUサイズを越えないように短く調整する手段と、備え、前記制御手段は、送信すべきUDPパケットが長く、パケットロス率により決定したエラー訂正用パケットを付加すると前記MTUサイズを越えてしまう場合は、パケット長が前記MTUサイズを越えないように付加するエラー訂正用パケットの数を変更することを特徴とする。
【００１２】
請求項６記載の発明は、請求項１記載の通信端末であって、着信を検出する着信検出手段と、前記相手機から送られてきたUDPパケットからエラー訂正パケット数を検出する手段と、を備え、前記制御手段は、送信側から送られて来るパケットのエラー訂正用パケット数を読み取り、同じ通信の着呼側から発呼側へ送信するUDPパケットに読み取ったエラー訂正用パケット数と同一数のパケットのエラー訂正用パケットを付加して送信することを特徴とする。
【００１３】
請求項７記載の発明は、請求項１記載の通信端末であって、前記制御手段は、自端末が着信側であるとき、着信に応答後、発呼側のアドレスが判明した時点で、前記pingコマンドを送信し、パケットロス率を得ることにより、前記着呼側から前記発呼側へ送信するUDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とする。
【００１４】
請求項８記載の発明は、特定の相手機にpingコマンドを送信し、前記pingコマンドにより前記相手機から送り返されるICMPパケットを受信し、前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとからパケットロス率を算出し、UDPパケットを送信するときエラー訂正用パケットを本来送信すべきパケットに付加する通信装置の制御方法であって、前記pingコマンドを送信することで得ることができたパケットロス率を基に、UDP通信をするとき、前記UDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とする。
【００１５】
請求項９記載の発明は、コンピュータに、送信手段が、特定の相手機にpingコマンドを送信する手順、受信手段が、前記pingコマンドにより前記相手機から送り返されるICMPパケットを受信する手順、算出手段が、前記pingコマンドにより送信したICMPパケット数と前記相手機から送り返されてきたICMPパケットとからパケットロス率を算出する手順、付加手段が、UDPパケットを送信するときエラー訂正用パケットを本来送信すべきパケットに付加する手順、を実行させ、前記pingコマンドを送信することで得ることができたパケットロス率を基に、UDP通信をするとき、前記UDPパケットに付加するエラー訂正用パケットの数を決定することを特徴とする。
【００１６】
請求項１０記載の発明は、請求項９に記載のプログラムを記録した、コンピュータが読み出し可能な記録媒体であることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、パケットを送信する前にpingコマンドを送信することでパケットロス率を計測して、それに応じたエラー訂正パケット数を設定することにより、ネットワークに過剰な負荷をかけることを防止できるので、ネットワーク負荷を抑えた通信装置、通信装置の制御方法、プログラム、及び記録媒体の提供を実現できる。
【発明を実施するための最良の形態】
【００１８】
次に本発明にかかる通信装置の実施の形態について図面を参照して説明する。
＜実施の形態１＞
従来のUDP通信方式で、エラー訂正用パケットを付加してエラー訂正する通信方式の場合、エラー訂正用パケット数を決定する適切な方法がなかった。例えば、pingコマンドを送信してpingコマンドの応答時間が通常より長くかかる場合は、ネッットワーク内に多くのパケットが存在すると予想できるので、パケットロスも発生しやすいという過程の基に、冗長パケット数を増やすという方式や、過去の通信の宛先、エラー訂正用パケット数、通信結果（OK／NG）を記録しておき、同じ宛先で通信エラーが発生したときは、記録されているエラー訂正用パケット数より多いエラー訂正用パケットを付加する、という方式が考えられてきたが、判断の基になっているping応答の遅延や過去の通信履歴から導き出すパケットロス率はあくまでも推測の値にすぎない。このような推測によるパケットロス率からエラー訂正用パケット数を決定することは無駄に長いUDPパケットをネットワークに送り出し、ネットワーク負荷を増加させることになる。
【００１９】
＜構  成＞
図１は、本発明にかかる通信装置の一実施の形態を示すブロック図である。
同図に示す通信装置は、システム制御部10、システムメモリ11、パラメータ部12、時計回路13、スキャナ14、プロッタ15、操作表示部16、T.38符号化復号化部17、呼接続メッセージ符号化復号化部18、磁気ディスク部19、G3プロトコル情報制御部20、パケットロス率算出部21、G3プロトコル情報取出部22、G3プロトコル情報生成部23、Pingコマンド送信部24、Pingコマンド受信部25、ネットワーク通信制御部26、及びバスライン27で構成されている。
【００２０】
システム制御部10は、CPU(Central Processing Unit)を含むT.38端末全体を制御する。
システムメモリ11は、通信装置を動作させるためのプログラムを格納するためのメモリであり、例えばROM(Read Only Memory)が用いられる。
パラメータ部12は、パラメータT.38の動作を制御するパラメータを格納する。
時計回路13は、タイマー制御を行うための回路である。
スキャナ14は、原稿読み取りを行う。
プロッタ15は、受信した原稿のデータを用紙に印字する。
操作表示部16は、ユーザが操作するため、例えばスイッチ、キーボタン、ディスプレイ、スピーカ、入出力端子で構成される。
T.38符号化復号化部17は、T.38パケットのエンコード／デコードを行う。
呼接続メッセージ符号化復号化部18は、呼接続メッセージのエンコード／デコードを行う。
磁気ディスク部19は、読み込んだ原稿データ、受信した原稿データ等を蓄積する回路であり、例えば、RAM(Random Access Memory)、HDD(Hard Disk Drive)が用いられる。
【００２１】
G3プロトコル情報制御部20は、受信したT.38パケットを利用してG3プロトコルを制御する。
パケットロス率算出部21は、Pingコマンドの応答を受信してパケットロス率を算出する。
G3プロトコル情報取出部22は、T.38符号化復号化部17を使用して受信したT.38パケットからT.30信号情報を取り出す。
G3プロトコル情報生成部23は、T.38符号化復号化部17を使用してT.30信号情報からT.38パケットを生成して付加する。
Pingコマンド送信部24は、パケットロス率を算出するためにPingコマンドを送信する。
Pingコマンド受信部25は、パケットロス率を算出するためにPingコマンドの応答を受信する。
ネットワーク通信制御部26は、ネットワーク通信を制御する。
【００２２】
＜動  作＞
図２は、図１に示した通信装置の動作を説明するためのフローチャートの一例である。
システム制御部10は、発呼側の端末において宛先が入力された場合(ステップS101)、相手機と接続する前に相手機にPingコマンドを発行する(ステップS102)。
相手機は、Pingコマンドの応答(ICMPパケット)を受信し(ステップS103)、応答パケットの数と発行したPingコマンドの回数とからパケットロス率((Pingコマンド回数−応答パケット数)／(Pingコマンド回数)を算出する(ステップS104)。
システム制御部10は、パケットロス率から、送信するUDPパケットにいくつのエラー訂正用パケットを付加するかを決めるため、エラー訂正用パケットを決定する(ステップS105)。
システム制御部10は、エラー訂正用パケット数が決定した後、相手機と接続するために発呼接続（呼接続処理）する(ステップS106)。
【００２３】
システム制御部10は、呼接続処理が完了した後、送信すべきデータが有るか否かを判断する(ステップS107)。システム制御部10は、送信すべきデータが有る場合(ステップS107/Yes)、発呼前に決定したエラー訂正用パケットの数だけ、送信したいUDPパケット(プライマリ・パケット)を作成し(ステップS108)、算出したエラー訂正用パケットを付加して送信パケットを作成して送信準備を行う(ステップS109)。
システム制御部10は、UDPパケットの送信準備が完了したらUDPパケットを送信する(ステップS110)。
システム制御部10は、送信データが無い場合(ステップS107/No)、呼切断処理を行う(ステップS111)。
【００２４】
すなわち、システム制御部10は、送信するデータが存在する間エラー訂正用パケットを付加してパケット送信を繰り返す(ステップS107〜S110)。
尚、パケット受信処理は省略した。
【００２５】
UDP通信の場合、付加するエラー訂正パケット数を多く設定しすぎると、ネットワークに大きな負荷をかけることになる。本実施形態によれば、パケットを送信する前にpingコマンドを送信することでパケットロス率を計測して、それに応じたエラー訂正パケット数を設定することにより、ネットワークに過剰な負荷をかけることを防止できる。
【００２６】
＜実施の形態２＞
従来のエラー訂正用パケット数の決定方式では、推測によるパケットロス率を基にしているため、きめ細かなエラー訂正用パケット数の変更ができないため、無駄なエラー訂正用パケットを付加してネットワークに負荷を与えることになった。
【００２７】
本実施形態では、実施の形態１のように算出したパケットロス率をプライマリパケット(送りたいパケット)に付加するエラー訂正用パケット数に変換する場合に、連続してパケットロスが発生したpingコマンドの数に応じて、エラー訂正用パケットの数を決定することが挙げられる。例えば、連続して２つのpingコマンドの応答がパケットロスとなった場合、エラー訂正用パケット数を２にして、２つのUDPパケットにエラー訂正用パケットを付加して送信用UDPパケットを作成することである。
【００２８】
図３は、図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
システム制御部10は、実施の形態１において算出したパケットロス率をプライマリパケット（送信したいパケット）に付加する場合に、連続してパケットロスが発生したPingコマンドの数に応じて、エラー訂正用パケットの数を決定する。
【００２９】
すなわち、システム制御部10は、発呼側の端末において宛先が入力された場合(ステップS121)、相手機と接続する前に相手機にPingコマンドを発行する(ステップS202)。
相手機は、Pingコマンドの応答(ICMPパケット)を受信し(ステップS203)、応答パケットの数と発行したPingコマンドの回数とからパケットロス率を算出する。
システム制御部10は、連続パケットロス数が１であるか否かを判断する(ステップS204)。
システム制御部10は、連続パケットロス数が１であると判断した場合(ステップS204/Yes)、エラー訂正用パケット数を１にして終了し(ステップS205)、連続パケット数が１でないと判断した場合(ステップS204/No)、連続パケットロス数が２であるか否かを判断する(ステップS206)。
システム制御部10は、連続パケット数が２であると判断した場合(ステップS206/Yes)、エラー訂正用パケット数を２にして終了し(ステップS207)、連続パケット数が２でないと判断した場合（ステップS206/No）、エラー訂正用パケット数を５にして終了する(ステップS208)。
【００３０】
ここで、例えば、連続して２つのPingコマンドの応答がパケットロスとなった場合、システム制御部10は、エラー訂正用パケット数を２にし、２つのUDPパケットにエラー訂正用パケットを付加して送信用UDPパケットを作成する。システム制御部10は、連続して３つ以上のパケットがロスになった場合はエラー訂正用パケット数を５とする。
【００３１】
エラー訂正パケット数は、パケットロスがバースト的（連続してパケットロスが発生）に発生するときに関連する値である。
したがって、本実施形態によれば、不連続に発生するパケットロス率よりも、pingにより連続発生するパケットロスを計測することで、より最適な、エラー訂正パケット数を算出することができ、エラー訂正パケット数を最適化することができ、ネットワークに過剰な負荷をかけることを防止できる。
【００３２】
＜実施の形態３＞
従来のエラー訂正用パケット数の決定方式では、推測によるパケットロス率を基にしているため、通信中に刻々と変化するネットワークの状況に応じたリアルタイムのパケットロス率を測定しながらエラー訂正用パケット数変更ができないため、無駄なエラー訂正用パケットを付加してネットワークに負荷を与えることになった。
【００３３】
本実施形態では、実施の形態１のように、相手機のアドレスを入力後、子接続を完了して、送信すべきデータの有無を確認する。送信すべきデータがある場合は、送信の直前にpingコマンドを発呼相手に送信する。pingコマンドの応答を受信することでパケットロス率を算出し、パケットロス率に応じた数のエラー訂正用パケットをプライマリ・パケットに付加してパケット送信する。このようにパケットを送信するたびごとに、pingコマンドを送り、その時点でのパケットロス率を算出し、刻々と変化するネットワーク状況に応じた数のエラー訂正用パケットを付加して送信する。
【００３４】
図４は、図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
本実施形態では、実施の形態１のように相手機のアドレスを入力後、呼接続を完了して、送信すべきデータの有無を確認する。送信すべきデータがある場合は、送信の直前にPingコマンドを発呼相手に送信する。Pingコマンドのプライマリ・パケットでパケットロス率を算出し、パケットロス率に応じた数のエラー訂正用パケットをプライマリ・パケットに付加してパケット送信する。パケットを１個または数個送信するたび毎に、Pingコマンドを送信し、その時点でのパケットロス率を算出し、刻々と変化するネットワーク状況に応じた数のエラー訂正用パケットを付加して送信する。通信中もネットワークの状況に合わせて、冗長パケット数が次々に変化し、より適切なエラー訂正用パケット数を付加することができる。
【００３５】
すなわち、システム制御部10は、発呼側の端末において宛先が入力された場合(ステップS301)、相手機と接続する前に相手機にPingコマンドを発行する。
相手機は、Pingコマンドの応答(ICMPパケット)を受信し、応答パケットの数と発行したPingコマンドの回数とからパケットロス率を算出する。
システム制御部10は、パケットロス率から、送信するUDPパケットにいくつのエラー訂正用パケットを付加するかを決めるため、エラー訂正用パケットを決定する。
システム制御部10は、エラー訂正用パケット数が決定した後、相手機と接続するために発呼接続（呼接続処理）する(ステップS303)。
【００３６】
システム制御部10は、送信データが有るか否かを判断し(ステップS303)、送信データが有る登坂別した場合(ステップS303/Yes)、Pingコマンドを発行し(ステップS304)、送信データが無いと判断した場合(ステップS303/No)、呼切断処理を行う(ステップS311)。
システム制御部10は、Pingコマンドを発行すると、Pingコマンドの応答(ICMP)を受信し(ステップS305)、パケットロス率を算出する(ステップS306)。
システム制御部10は、パケットロス率を算出すると、パケットロス率からエラー訂正用パケット数を決定し(ステップS307)、UDPのプライマリ・パケットを作成し(ステップS308)、算出したエラー訂正用パケットを付加して送信パケットを作成する(ステップS309)。
システム制御部10は、送信パケットを作成すると、UDPパケットを送信し(ステップS310)、ステップS303に戻る。
【００３７】
本実施形態によれば、実施形態１の効果に加え、通信中もpingコマンドを送信することでパケットロス率を計測して、それに応じたエラー訂正パケット数を設定することにより、（pingコマンドによりネットワーク負荷が多少増加する可能性があるが）リアルタイムに変化するネットワーク状況に応じたエラー訂正パケット数を算出することができ、エラー訂正パケット数を最適化することができ、ネットワークに過剰な負荷をかけることを防止できる。
【００３８】
＜実施の形態４＞
従来のエラー訂正用パケット数の決定方式では、推測によるパケットロス率を基にしているため、朝、昼、夕、夜などの時間帯によるパケットロス率の変化に対応したエラー訂正用パケット数変更ができなかった。
【００３９】
本実施形態では、実際に行うUDP通信と別に例えば、アドレス帳に登録された宛先に一定間隔ごとにpingコマンドを送信する。pingコマンドの応答を受信し、パケットロス率を算出する。このパケットロス率の算出をアドレス帳に登録された宛先すべてに対して行い、この結果を、宛先をキーに時刻とパケットロス率に応じた、エラー訂正パケット数を記録しておく。アドレス帳を使用してUDPパケットを送信ときは登録してある情報の中から発呼時刻と一番近い時刻のエラー訂正用パケットデータを読み出し、その値と同じ数のエラー訂正用パケットを付加してUDPパケットを送信する。
【００４０】
図５、６は、図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
実際に行うUDP通信とは別に例えば、アドレス帳に登録された宛先に一定時間ごとにPingコマンドを送信する。Pingコマンドの応答を受信し、パケットロス率を算出する。
このパケットロス率の算出をアドレス帳に登録された宛先すべてに対して行い、この結果を、宛先をキーに時刻とパケットロス率に応じた、エラー訂正用パケット数を記録しておく。アドレス帳を使用してUDPパケットを送信したときは登録してある情報の中から発呼時刻と一番近い時刻のエラー訂正用パケットデータを読み出し、その値と同じ数のエラー訂正用パケットを付加してUDPパケットを送信する。
【００４１】
すなわち、システム制御部10は、所定の時間、例えば１分経過したか否かを判断し(ステップS401)、１分経過したと判断した場合(ステップS401/Yes)、アドレス帳データが有るか否かを判断する(ステップS402)。システム制御部10は、ステップS401で１分経過していないと判断した場合(ステップS401)には待機する。
システム制御部10は、アドレス帳データが有ると判断した場合(ステップS402/Yes)、宛先入力を行い(ステップS403)、Pingコマンドを発行し(ステップS404)、Pingコマンドの(ICMP)を受信し(ステップS406)、パケットロス率からエラー訂正用パケット数を決定し(ステップS407)、アドレス帳の中の宛先をキーにして、時刻とエラー訂正用パケット数を記録しステップS402に戻る(ステップS408)。システム制御部10は、ステップS402でアドレス帳データが無いと判断した場合（ステップS402/No）、ステップS401に戻る。
【００４２】
また、システム制御部10は、発呼側の端末において宛先が入力された場合(ステップS411)、記録された宛先データの中に該当宛先が有るか否かを判断し(ステップS412)、該当宛先が有ると判断した場合(ステップS412/Yes)、記録された宛先＋時刻＋訂正用パケット数のデータから現在の時刻に近いデータを取り出す(ステップS413)。
システム制御部10は、エラー訂正用パケット数を取り出すと、呼接続処理を行い(ステップS416、送信データが有るか否かを判断し(ステップS417)、送信データが有ると判断した場合(ステップS417/Yes)、UDPのプライマリ・パケットを作成する(ステップS418)。
システム制御部10は、記録された宛先データの中に該当宛先が無いと判断した場合(ステップS412/No)、固定値のエラー訂正用データを取り出し(ステップS415)、ステップS416に進む。
システム制御部10は、算出したエラー訂正用パケットを付加して送信パケットを作成し(ステップS417)、UDPパケットを送信し(ステップS418)、ステップS415に戻る。
システム制御部10は、送信データが無いと判断した場合(ステップS417/No)、呼切断処理を行う(ステップS421)。
【００４３】
ここで、宛先、時刻、及びエラー訂正パケット数の一例について、表１、２に示す。
【００４４】
【表１】
2010114761.tif 000003
【００４５】
【表２】
2010114761.tif 000004
【００４６】
本実施形態によれば、予め、アドレス帳に登録された宛先に対し、一定時間ごとにpingコマンドを送信し、この処理によって得られたエラー訂正パケット数とその時刻を記録し、通信するとき記録されたエラー訂正パケット数の情報の中に同じ宛先が存在する場合、同一時刻のエラー訂正パケット数を取り出して、送信すべきUDPパケットを生成することにより、実施の形態１、２、３のような通信毎にpingコマンドを発行する、ネットワークの負荷を増加させる処理をより少なくしつつ、適切なエラー訂正パケット数を算出することを可能とする。
【００４７】
＜実施の形態５＞
従来のエラー訂正用パケット数の決定方式では、一通信内では一つのエラー訂正用パケット数を決めて、UDPパケットを作っていたため、無駄に付加するエラー訂正用パケットによって、MTUを越えないように短いプライマリ・パケット(アプリケーションが本来送りたいUDPパケット)を作る必要があった。
【００４８】
本実施の形態は、実施の形態１のように発呼前に相手端末に送信したpingコマンドに対して受信したICMPパケットにより算出したパケットロス率から換算したエラー訂正用パケットの数を用いて送信用UDPパケットを作成する。
【００４９】
しかし、送信データは様々なサイズになり（プライマリ・パケットの）サイズが大きい場合、送信すべきUDPパケット（プライマリ・パケット＋エラー訂正用パケット）がネットワークで決められているMTUより大きくなってしまう場合がある。MTUサイズより大きくなったパケットは相手に届くまでの間でルーティングされるルータでMTUサイズに分割されてしまう。UDPパケットの仕様上、分割されたパケットはUDPヘッダがある方は相手に届くが、UDPヘッダが無い方は破棄されてしまう。パケットロス率から換算したエラー訂正用パケットの数により、エラー訂正用パケットの送信用UDPパケットがMTUサイズを越えてしまう場合は、MTUサイズ以内になるまでエラー訂正用パケットの数を１づつ減算し、送信用UDPパケットに収まる最長のサイズで送信する。
【００５０】
図７は、図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
本実施の形態は、実施の形態１のように発呼前に相手機に送信したPingコマンドに対して受信したICMPパケットにより算出したパケットロス率から換算したエラー訂正用パケットの数を用いて送信用UDPパケットを作成する。パケットロス率から換算したエラー訂正用パケットの数により、エラー訂正用パケットの送信用UDPパケットがMTUサイズを超えてしまう場合は、MTUサイズ以内になるまでエラー訂正用パケットの数を１つずつ減算し、送信用UDPパケットに収まる最長のサイズで送信する。
【００５１】
すなわち、システム制御部10は、発呼側の端末において宛先が入力された場合(ステップS501)、相手機と接続する前に相手機にPingコマンドを発行する(ステップS502)。
相手機は、Pingコマンドの応答(ICMPパケット)を受信し(ステップS503)、システム制御部10は、パケットロス率を算出し(ステップS504)、パケットロス率からエラー訂正用パケット数を決定し(ステップS505)、送信データが有るか否かを判断する(ステップS507)。
システム制御部10は、送信データが有ると判断した場合(ステップS507/Yes)、UDPのプライマリ・パケットを作成し(ステップS508)、算出したエラー訂正用パケットを付加して送信パケットを作成し(ステップS509)、送信パケットサイズがMTUサイズより大きいか否かを判断する(ステップS510)。
【００５２】
システム制御部10は、送信パケットサイズがMTUサイズより大きいと判断した場合(ステップS510/Yes)、エラー訂正用パケット数を１つ減算し(ステップS511)、ステップS509に戻る。
システム制御部10は、送信パケットサイズがMTUサイズより大きくないと判断した場合(ステップS510)、UDPパケット送信を行い(ステップS512)、切断するか否かを判断する(ステップS513)。
システム制御部10は、切断すると判断した場合(ステップS513/Yes)、呼切断処理を行い(ステップS514)、切断しないと判断した場合(ステップS513/No)、ステップS507に戻り、送信データ無しと判断した場合(ステップS507/No)、ステップS513に進む。
【００５３】
本実施の形態１〜４に於いて、算出したエラー訂正用パケット数は、UDPパケットを送信するアプリケーションソフトが送信したいデータ長とは無関係に算出される。従って、送信するプライマリ・パケットに対してエラー訂正パケットを付加するとMTUサイズを越えてしまい、このパケットを送信すると相手には、MTUサイズを越えた部分は切れてMTUサイズ内の部分のパケットが届くことなる。
本実施の形態により、プライマリ・パケットのサイズに応じて、MTUサイズを越えないように、付加するエラー訂正パケットの数を調整することで、アプリケーションソフトが送信したいデータを送信することができる。
【００５４】
＜実施の形態６＞
着呼側から発呼側にUDPパケットを送るときも、ネッワークの状況に応じて、UDPパケットに付加するエラー訂正パケットが調整できていなかった。
本実施の形態６は、実施の形態１のように、着信側端末で着信を検出した後、呼接続フェーズを経て、相手端末と接続する。接続後、発呼側から送られて来るUDPパケット内のエラー訂正用パケット数を読み取り、記録する。一般的に、UDP通信を含めて、IP通信では通信路は上り・下りが同一とは限らないが、同一になっているケースが多いと言われている。
【００５５】
そこで、着信側からUDPパケットを送信する場合は、ネットワーク負荷を増大させないようにpingコマンドを送信せず、発呼側から送られて来るUDPパケット内のエラー訂正用パケット数を読み取り、同じ数のエラー訂正用パケットを付加して、着呼側から発呼側へUDPパケットを送信する。着信側では、パケットを受信するたびごとにエラー訂正用パケット数を読み取り、着呼側から発呼側へ送信する利用するエラー訂正用パケット数とする。
【００５６】
図８は、図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
本実施の形態は、実施の形態１のように着信端末で着信を検出した後、呼接続処理を経て、相手機と接続する。接続後、発呼側から送られてくるUDPパケット内のエラー訂正用パケット数を読み取り、記録する。
一般的に、UDP通信を含めて、IP通信では通信路は上り・下りが同一とは限らないが、同一になっているケースが多いと言われている。
【００５７】
そこで、着信側からUDPパケットを送信する場合は、ネットワーク負荷を増大させないようにPingコマンドを送信せず、発呼側から送られてくるUDPパケット内のエラー訂正用パケット数を読み取り、同じ数のエラー訂正用パケットを付加して、着呼側から発呼側へUDPパケットを送信する。着信側では、パケットを受信するたびごとにエラー訂正用パケット数を読み取り、着呼側から発呼側へ送信する際に利用するエラー訂正用パケット数とする。
【００５８】
すなわち、システム制御部10は、着信ありか否かを判断し(ステップS601)、着信が無いと判断した場合には待機し(ステップS601/No)、着信が有りと判断した場合(ステップS601)、呼接続処理を行う(ステップS602)。
システム制御部10は、呼接続処理を行うと受信データが有るか否かを判断し(ステップS603)、受信データが有ると判断した場合(ステップS603/Yes)、UDPのエラー訂正用パケット数を読み出しECPNへ記録し(ステップS604)、受信パケット処理を行い(ステップS605)、送信データが有るか否かを判断する(ステップS606)。
【００５９】
システム制御部10は、受信データが無いと判断した場合(ステップS603/No)、ステップS606に進み、送信データが無いと判断した場合(ステップS606/No)、ステップS603に戻り、送信データが有ると判断した場合(ステップS606/Yes)、UDPのプライマリ・パケットを作成する(ステップS607)。
システム制御部10は、UDPのプライマリ・パケットを作成すると、ECPNから読み出した数のエラー訂正パケットを付加して送信パケットを作成し(ステップS608)、UDPパケットを送信し(ステップS609)、切断するか否かを判断する(ステップS610)。
システム制御部10は、切断すると判断した場合(ステップS610/Yes)、呼切断処理を行い(ステップS611)、切断しないと判断した場合(ステップS610/No)、ステップS603に戻る。
【００６０】
本実施形態によれば、着呼側から発呼側へのUDPパケット送信も、pingコマンドを送信してパケットロス率を計測することなく、適切なエラー訂正パケット数を得ることができる。
【００６１】
＜実施の形態７＞
実施の形態６と同様、ネッワークの状況に応じて、UDPパケットに付加するエラー訂正パケットが調整できていなかった。
【００６２】
図９は、図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
本実施の形態は、実施の形態１のように、着信側端末で着信を検出した後、呼接続フェーズを経て、相手端末と接続する。実施の形態６で説明した通り、一般的に、UDP通信を含めて、IP通信では通信路は上り・下りが同一とは限らない。着呼側から発呼側へ送信するUDPパケットのエラー訂正用パケット数を最適化するために、発呼側から着呼側への方向と道教に、着呼側から発呼側への方向に於いても、UDPパケットを送信する直前に、相手端末に対してpingコマンドを発行する。Pingコマンドの応答(ICMPパケット)を受信し、応答パケットの数と 発行したpingコマンドの回数からパケットロス率（(pingコマンド回数−応答パケット数)／pingコマンド回数）を算出する。
【００６３】
本実施の形態は、着信側端末で着信を検出した後、呼接続処理を行い、相手機と接続する。実施の形態６で説明した通り、一般的に、UDP通信を含めてIP通信では通信路は上り・下りが同一とは限らない(同一ネットを通らない。)。着呼側から発呼側へ送信するUDPパケットのエラー訂正用パケット数を最適化するために、発呼側から着呼側への方向と同様に、着呼側から発呼側への方向においても、UDPパケットを送信する直前に、相手機に対してPingコマンドを発行する。Pingコマンドの応答(ICMPパケット)を受信し、応答パケットの数と、発行したPingコマンドの回数からパケットロス率を算出する。
【００６４】
すなわち、システム制御部10は、着呼が有るか否かを判断し(ステップS701)、着呼が無いと判断した場合は待機し(ステップS701/No)、着呼が有ると判断した場合(ステップS701/Yes)、呼接続処理を行い(ステップS702)、受信データ処理を行うか否かを判断する(ステップS703)。
システム制御部10は、受信データ処理を行うと判断した場合(ステップS703/Yes)、UDPパケット受信処理を行い(ステップS704)、送信データが有るか否かを判断し(ステップS705)、送信データが有ると判断した場合(ステップS705/Yes)、UDPのプライマリ・パケットを作成し(ステップS706)、Pingコマンドを発行する(ステップS707)。
【００６５】
システム制御部10は、Pingコマンドを発行すると、Pingコマンドの応答(ICMP)を受信し(ステップS708)、パケットロス率を算出し(ステップS709)、パケットロス率からエラー訂正用パケット数を決定し、UDPパケットを送信する(ステップS711)。
システム制御部10は、UDPパケットを送信すると切断するか否かを判断し(ステップS712)、切断すると判断した場合(ステップS712/Yes)、呼切断処理を行う(ステップS713)。
システム制御部10は、受信データ処理を行わないと判断した場合(ステップS703/No)、ステップS705に進み、送信データが無いと判断した場合(ステップS705/No)、及び切断市内と判断した場合(ステップS712/No)、ステップS703に戻る。
【００６６】
本実施形態により、発呼側と着呼側とを結ぶ、上り方向と下り方向との経路が異なる場合であっても、着呼側から発呼側へのUDPパケット送信のエラー訂正パケットの数を、刻々と変化するネットワークの状況に応じて最適化して、通信することができる。
【００６７】
＜エラー訂正用パケット＞
図１０は、本発明にかかる通信装置に用いられるパケットの説明図である。
同図に示すように、プライマリ・パケット(例えば、[333])は、本来送信側800から受信側に送信したいパケットである。エラー訂正用パケット(111)は既に直前に送信したパケットをプライマリ・パケット(333)に付加して送信する。パケットロスが発生した場合は、このエラー訂正用パケット(111)を利用することで、紛失したパケットを補うことができる。
【００６８】
＜プログラム＞
以上で説明した本発明にかかる通信装置は、コンピュータで処理を実行させるプログラムによって実現されている。コンピュータとしては、例えばパーソナルコンピュータやワークステーションなどの汎用的なものが挙げられるが、本発明はこれに限定されるものではない。
【００６９】
プログラムとしては、例えば、
コンピュータに、
(1)送信手段が、特定の相手機にpingコマンドを送信する手順、
(2)受信手段が、pingコマンドにより前記相手機から送り返されるICMPパケットを受信する手順、
(3)算出手段が、pingコマンドにより送信したICMPパケット数と相手機から送り返されてきたICMPパケットとからパケットロス率を算出する手順、
(4)付加手段が、UDPパケットを送信するときエラー訂正用パケットを本来送信すべきパケットに付加する手順、
を実行させ、
pingコマンドを送信することで得ることができたパケットロス率を基に、UDP通信をするとき、UDPパケットに付加するエラー訂正用パケットの数を決定するプログラムが挙げられる。
これにより、プログラムが実行可能なコンピュータ環境さえあれば、どこにおいても本発明にかかる通信装置を実現することができる。
【００７０】
＜記録媒体＞
このようなプログラムは、コンピュータに読み取り可能な記録媒体に記憶されていてもよい。
ここで、記録媒体としては、例えば、CD-ROM(Compact Disc Read Only Memory)、フレキシブルディスク(FD)、CD-R(CD Recordable)などのコンピュータで読み取り可能な記憶媒体、フラッシュメモリ、RAM(Random Access Memory)、ROM(Read Only Memory)、FeRAM(強誘電体メモリ)等の半導体メモリやHDD(Hard Disc Drive)が挙げられる。
【００７１】
なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【図面の簡単な説明】
【００７２】
【図１】本発明にかかる通信装置の一実施の形態を示すブロック図である。
【図２】図１に示した通信装置の動作を説明するためのフローチャートの一例である。
【図３】図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
【図４】図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
【図５】図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
【図６】図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
【図７】図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
【図８】図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
【図９】図１に示した通信装置の動作を説明するためのフローチャートの他の一例である。
【図１０】本発明にかかる通信装置に用いられるパケットの説明図である。
【符号の説明】
【００７３】
１０    システム制御部
１１    システムメモリ
１２    パラメータ部
１３    時計回路
１４    スキャナ
１５    プロッタ
１６    操作表示部
１７    T38符号化復号化部
１８    G3プロトコル情報取出部
１９    磁気ディスク部
２０    G3プロトコル情報制御部
２１    パケットロス率算出部
２２    G3プロトコル情報取出部
２３    G3プロトコル情報生成部
２４    Pingコマンド送信部
２５    Pingコマンド受信部
２６    ネットワーク通信制御部
２７    バスライン
【図１】
2010114761.tif 000005
【図２】
2010114761.tif 000006
【図３】
2010114761.tif 000007
【図４】
2010114761.tif 000008
【図５】
2010114761.tif 000009
【図６】
2010114761.tif 000010
【図７】
2010114761.tif 000011
【図８】
2010114761.tif 000012
【図９】
2010114761.tif 000013
【図１０】
2010114761.tif 000014