パケット通信方法
【課題】アプリケーション層の負荷を増大させることなく、高速で信頼性の高いパケット通信方法を提供する。
【解決手段】MAC層の上位にIP層が位置し、その上位にUDP層が位置し、その上位にUECP(Unique Error Control Protocol)が位置している。UECPヘッダはUDPパケットのデータフィールドの上位１２バイトの領域に確保され、シーケンス番号フィールド、確認応答番号フィールド、コードビットフィールドおよびウインドウサイズフィールドを含む。UECPのMSSは1398バイト以下に設定され、MTUは1438バイト以下に設定されている。
【解決手段】MAC層の上位にIP層が位置し、その上位にUDP層が位置し、その上位にUECP(Unique Error Control Protocol)が位置している。UECPヘッダはUDPパケットのデータフィールドの上位１２バイトの領域に確保され、シーケンス番号フィールド、確認応答番号フィールド、コードビットフィールドおよびウインドウサイズフィールドを含む。UECPのMSSは1398バイト以下に設定され、MTUは1438バイト以下に設定されている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパケット通信方法に係り、特に、高速で信頼性の高いパケット通信を可能にするパケット通信方法に関する。
【背景技術】
【０００２】
IPネットワークで利用される代表的なトランスポート層プロトコルとしてTCP(Transmission Control Protocol)およびUDP(User Datagram Protocol)が知られている。TCP(RFC1122およびRFC1123)はコネクション型プロトコルであり、パケット喪失によるデータ通信エラーを回避し、信頼性を保証するために、送信元がデータ送信後、一定時間だけ受信先からの確認応答信号(ACK)の到着を待ち、タイムアウトした場合は再度同じデータを送信する(再送制御)。このタイムアウト時間は再送タイムアウト時間(RTO：Retransmission Timeout)と呼ばれる。また、応答が続けてない場合には再送を繰り返すが、その場合の再送間隔は再送回数によって指数関数的に増やす方法が採られている。送信パケットの喪失が繰り返し発生する場合には、再送信タイムアウト時間を長くすることによって送信を抑制し、パケット喪失の確率を低くするように制御（輻輳制御）している。受信側では、正規に受信できたパケットのシーケンス番号および確認応答番号をACKにセットして返送することでパケットの到着順序が保証される（順序制御）。
【０００３】
これに対して、UDPはコネクションレス型プロトコルであり、上記のような再送制御、輻輳制御、順序制御などが行われない。このため、速度よりもデータ品質が要求されるWWW、メール、FTPなどにはTCPが用いられ、データ品質よりも速度(リアルタイム性)が優先される音声通話や映像配信にはUDPが用いられる。従来のTCPおよびUDPに関しては、例えば特許文献１に開示されている。
【特許文献１】特開２００１−１３６２０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
RFC2988では、TCPのRTOに関して、再送タイムアウトが１秒未満の場合は１秒に繰り上げるように勧告されている。したがって、TCPパケットに欠落が生じると、その再送に最低でも１秒はかかるため、通信のリアルタイム性が損なわれてしまう。
【０００５】
さらに、TCPにはkeepalive 機能が付与されている。これは実際のデータ送信がある無しに関わらず、そのコネクションにおいて一定時間ごとにパケットを送信して応答を監視し、TCP コネクションが有効でなければ切断される。しかしながら、keepalive 時間のデフォルトは２時間なので、通信相手ごとに無通信監視を所望の間隔で行おうとすれば、TCPよりも上位のアプリケーション層で無通信監視を行わなければならず、監視間隔が短くなるほどアプリケーション層における監視負荷が増大するという技術課題があった。
【０００６】
本発明の目的は、上記の従来技術の課題を解決し、アプリケーション層の負荷を増大させることなく、高速で信頼性の高いパケット通信方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために、本発明は、UDPの上位層でパケット交換を制御するパケット通信方法において、以下のような手順を含むことを特徴とする。
【０００８】
(1)UDPパケットのデータフィールドにプロトコルヘッダおよびデータの各フィールドを確保し、プロトコルヘッダが、少なくともシーケンス番号フィールド、確認応答番号フィールドおよびパケット識別用のコードビットフィールドを含み、前記シーケンス番号フィールドおよび確認応答番号フィールドに登録された番号に基づいて再送制御および順序制御を行うことを特徴とする。
【０００９】
(2)プロトコルヘッダがウインドウサイズフィールドを含むことを特徴とする。
【００１０】
(3)キープアライブ要求に対するキープアライブ応答のタイムアウトを規定するタイムアウト値を記憶し、キープアライブ応答を前記第４のタイムアウト値の経過後も受信できないとセッションをクローズし、この第４のタイムアウト値T4を設定する手順を含むことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、以下のような効果が達成される。
(1)TCPと同等の信頼性で、かつ実使用上はUDPと同等の転送速度が得られるパケット通信が可能になる。
(2)プロトコルがUDPのデータフィールドに実装されるので、下位に位置する従来のレイヤを活用できる。
(3)ウインドウサイズを指定できるので、効率の良いデータ転送が可能になる。
(4)キープアライブの送信間隔を自由に設定できるので、これを適宜の短時間に設定すれば、LANケーブルの引き抜きや通信相手の電源断をトランスポート層において素早く検知でき、その結果、上位のアプリケーション層における頻繁な監視が不要となってアプリケーションの負荷を軽減できる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の最良の実施形態について詳細に説明する。図１は、本発明が適用されるIPボタン電話装置１００の主要部の構成を示したブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００１３】
IPボタン電話装置１００は、外線としてアナログ回線、ナンバーディスプレイ契約回線、網番号ダイヤルイン回線、アナログ専用線、デジタル専用線およびISDN回線などのレガシー（従来型・旧型）外線のみならず、VoIP回線やNGN 回線を利用できる。また、内線端末として一般アナログ端末、ISDN端末、ホテルフォン、デジタルボタン電話機およびFAXなどのレガシー内線端末のみならず、ソフトフォンやIP電話機などのIP内線端末を収容し、各外線と各内線端末との間の通信を制御する。
【００１４】
IPボタン電話装置１００において、主制御ユニットCCU (Central Control Unit)１は、主制御プログラムに従ってシステム全体を制御する。TDM制御ユニットTCCU２は、各レガシー内線端末とIP網との間および各レガシー外線とIP内線端末との間で時分割多重化通信(TDM)を制御する。
【００１５】
カスタマエッジユニットCEU (Customer Edge Unit)３は、音声データと制御データとを多重化してIP通信を行う高速ブロードバンドルータとしての機能を備えると共に、保留音として高音質（帯域が約５０〜７０００Hz）の楽音データおよび標準音質（帯域が約３００〜４０００Hz）の楽音データを保持する。そして、内線端末と外線端末との通話が内線端末側の操作で保留された際、被保留側の外線端末へ、通話確立時のメディア能力に応じて高音質または標準音質の保留音を送出する。
【００１６】
音声変換ユニットVCU (Voice Conversion Unit)４は、通話の音声パケットを高音質から標準音質に変換し、その逆の変換を行うと共に、保留音として高音質の楽音データおよび標準音質の楽音データを保持する。そして、内線端末間の通話が一方の内線端末の操作で保留された際、保留音を持たない他方の被保留側の内線端末へ、通話確立時のメディア能力に応じて高音質または標準音質の保留音を送出する。
【００１７】
前記TCCU２には、ファックス端末８１、ホテルフォン端末８２、デジタルボタン電話機８３、単体電話機８４などのレガシー内線端末、および一般外線、ISDNネット回線、デジタル専用線、アナログ専用線などのレガシー外線が、各種の専用インターフェースおよびTDM通信用のTDMバス５を介して接続されている。前記TDMバス５は、制御信号を送受信するDチャネルおよびPCM変換された音声信号を送受信するBチャネルを備える。
【００１８】
前記CCU１とTCCU２とは音声用LAN８および制御用LAN９の２本のLANで接続されている。CCU１とCEU３およびVCU４とは制御用LANで接続されている。前記CCU１には更に、保守用LAN１０を介して保守用コンピュータ９５が接続されると共に、IP内線LAN６を介してHUB（ハブ）７が接続されている。前記HUB７には、専用インターフェースを介してIPボタン電話機９１や音声会議装置９２が接続され、無線アクセスポイント(AP)にはIPコードレスフォン９３が収容され、さらにソフトフォン９４のアプリケーションが実装されたコンピュータが接続されている。
【００１９】
前記CCU１は、CPU１１、DDRメモリ（RAM）１２、フラッシュメモリ１３、パケット転送の制御に特化した専用チップ１４、挿抜自在のコンパクトフラッシュ(登録商標)（CF）メモリ１５およびレイヤ２(L2)スイッチ１６を主要な構成としている。CCU１がパワーオンあるいはリセットされると、まず、フラッシュメモリ１３にあるブートローダ(ソフトウエア)が動作し、CFメモリ１５のファイルシステムに格納されているOSがDDRメモリ１２にロードされて起動される。次いで、OSがCFメモリ１５のアプリケーション(本体ソフトウエア)をDDRメモリ１２にロードして起動することで主制御プログラムが動作を開始する。
【００２０】
前記TCCU２は、CPU２１、DDRメモリ２２、フラッシュメモリ２３、ファイ(PHY)２４、前記Bチャネルを制御するハイウエイスイッチ２５、前記Dチャネル用の制御信号通信チップ２６およびDSP２７を主要な構成としている。前記PHY２４は、Ethernet(登録商標)(図示せず)の物理層を制御するLSIである。
【００２１】
前記CEU３は、CPU３１、DDRメモリ３２、フラッシュメモリ３３、パケット転送の制御に特化した専用チップ３４およびL2スイッチ３５を主要な構成としている。専用チップ３４は、前記CCU１の専用チップ１４と同様のものである。
【００２２】
VCU４は、CPU４１、DDRメモリ４２、フラッシュメモリ４３、L2スイッチ４４およびDSP４５を主要な構成としている。DSP４５は、例えば高音質の通話が標準音質のみに対応したレガシー内線端末へ転送された場合に、高音質の音声パケットを標準音質に変換してレガシー内線端末へ送出する一方、レガシー内線端末から送出される標準音質の音声を高音質用の音声パケットに変換して通話相手に送出する。
【００２３】
本実施形態ではCCU１、TCCU２、CEU３およびVCU４のそれぞれにCPU１１、２１、３１、４１を分散配置することで負荷分散を実現すると共に、CCU１およびCEU３には更に、パケット転送に特化した専用チップ１４、３４を搭載することでCPU１１、３１におけるパケット転送の処理を軽減し、更なる負荷分散を実現している。
【００２４】
このような構成において、レガシー内線端末（例えば、単体電話機８４）がNGN経由で発着信した場合、レガシー内線端末とTCCU２との間ではPCM変換された音声信号がTDMバス５上でTDM通信により送受信される。TCCU２とCCU１との間には通信セッションが確立され、この通信セッションにおいて音声信号および制御信号のデータパケットが交換される。CEU３は前記L2スイッチ３５経由でNGNに接続されており、CCU１およびCEU３は、それぞれの専用チップ１４、３４を利用してパケットを交換する。
【００２５】
また、IP内線端末がレガシー外線（例えば、ISDNネット）経由で発着信した場合は、TDMバス５、TCCU２、CCU１およびHUB７を介して制御情報、音声情報または音声パケットが送受信される。さらに、IP内線端末がNGN経由で発着信した場合は、CEU３、CCU１およびHUB７を介して、SIPメッセージ、制御情報または音声パケットが送受信される。
【００２６】
次いで、前記CCU１およびTCCU２間、CCU１およびCEU３間ならびにCCU１およびVCU４間など、CCU１と各IPユニット間での通信に採用される、本発明の固有のパケット通信プロトコルについて説明する。なお、CCU１およびTCCU２間では制御用LAN９による制御信号の通信にのみ適用され、音声用LAN８による音声信号の通信には適用されない。
【００２７】
図２は、本発明に係るパケット通信方法が適用されるプロトコルの階層を示した図であり、MAC層の上位にIP層が位置し、その上位にUDP層が位置し、その上位に本発明に固有の誤り制御プロトコル(以下、UECP：Unique Error Control Protocolと表現する)が位置している。
【００２８】
図３は、前記UECPヘッダの構造を示した図である。UECPヘッダはUDPパケットのデータフィールドの上位１２バイトの領域に確保され、シーケンス番号フィールド、確認応答番号フィールド、コードビットフィールドおよびウインドウサイズフィールドを含む。本実施形態では、UECPのMSS(Maximum Segment Size)が1398バイト以下に設定され、MTU(Maximum Transmission Unit)は1438バイト以下に設定されている。これらは、代表的なISPサービスであるBフレッツやフレッツADSL(いずれも登録商標)のMTUが1454バイト以下であり、フレッツ光プレミアム(登録商標)のMTUが1438バイト以下であることに基づく。
【００２９】
UECPヘッダのシーケンス番号フィールドには、このUECPの送受信単位(セグメント)の先頭のデータオクテットのシーケンス番号が登録される。初期シーケンス番号(ISN)はセッションをオープンしたときに「０」とされる。シーケンス番号の算術は、２３２のモジュロで実行する。
【００３０】
確認応答番号フィールドには、確認応答(ACK)パケットを受信した際、そのセグメントの送信側が次に受信することを想定しているシーケンス番号の値が登録される。確認応答番号の算術も２３２のモジュロで実行される。ウインドウフィールドには、確認応答番号で示しているバイト数を始点として、このセグメントの受信側が確認応答(ACK)なしで受け入れ可能なデータのバイト数が登録される。コードビットフィールドには、図４に示したように、パケットを識別するための各種のフラグが設定される。
【００３１】
NAK (Negative Acknowledgement)フラグは、受信パケットのシーケンス番号が受信可能なシーケンス番号と異なるときに送信元に対して再送を要求するNAKパケットにおいてセットされる。KPA(Keep Alive)フラグは、キープアライブの要求・応答に使われる。ACK (Acknowledgement)フラグは、確認応答番号が有効であるきに返信するACKパケットにおいてセットされる。PSH(Push)フラグは、受信したデータを直ちに上位アプリケーションに渡すか否かを表し、このビットがセットされている受信データは直ちに上位アプリケーションに渡さなければならない。RST(Reset)フラグは、セッションを強制的に切断する際にセットされる。SYN(Synchronize)フラグは、セッションを確立（オープン）する際にセットされる。FIN (Fin)フラグは、セッションを切断（クローズ）する際にセットされる。
【００３２】
図５は、UECPにおける待ち受けポート番号(CCU１がセッションオープン要求を待つポート番号およびIPユニットがセッションオープン要求を出すポート番号)の実装例を示した図であり、UDPのポート番号を用いるものとし、宛先ポート番号は任意の固定ポート番号であり、送信元ポート番号はエフェメラル（短命）ポート番号である。
【００３３】
図６は、UECPにおける通信ポート番号（セッション確立後にデータを送受信するポート番号）の実装例を示した図であり、UDPのポート番号を用いるものとし、通信方向にかかわらず、宛先ポート番号および送信元ポート番号のいずれにもエフェメラル（短命）ポート番号が用いられる。なお、CCU１側のポート番号に関しては、図７に示したように、TCPと同様に待ち受けポート番号を用いても良い。
【００３４】
図８は、UECPによるセッションオープンのシーケンスを示した図であり、ここでは、IPユニットからCCU１へセッションオープンを要求する場合を例にして説明する。
【００３５】
IPユニットはセッションオープン要求パケット(SYN)の送信後、第１のタイムアウト値T1以内にCCUからセッションオープン応答パケット(SYN+ACK)を受信できないと、セッションオープン失敗としてRSTパケットを送信し、セッションオープン要求パケットの送信から手順をやり直す。CCUは、セッションオープン応答パケットの送信後、タイムアウト値T1以内にIPユニットから確認応答(ACK)パケットを受信できないと、セッションオープン失敗としてRSTパケットを送信し、セッションオープン要求パケットの受信待ちから手順をやり直す。IPユニットは、確認応答パケットを送信した時点でセッション確立状態となり、CCUは、確認応答パケットを受信した時点でセッション確立状態となる。
【００３６】
図９、１０は、セッションクローズのシーケンスを示した図である。本実施形態では、CCUおよびIPユニットのいずれからでもセッションをクローズできる。図９は、IPユニットからセッションクローズを要求する手順を示し、図１０は、CCUからセッションクローズを要求する手順を示している。
【００３７】
セッションクローズ要求パケットの送信側は、その送信後にセッションクローズ応答パケットを第２のタイムアウト値T2以内に受信できなければ、手順上はセッションクローズ完了とはならないものの、セッションクローズ要求パケットを再送することなくセッションクローズ扱いとする。なお、後に詳述するように、本実施形態では送信側および受信側が互いに一定時間キープアライブ要求・応答を送信しないとセッションクローズになるので、セッションクローズ応答パケットを受信できない場合にセッションクローズ扱いしても問題はない。
【００３８】
図１１、１２、１３は、データ送信の基本シーケンスを示した図であり、図１１はCCUからIPユニットへの送信シーケンス、図１２はIPユニットからCCUへの送信シーケンス、図１３は双方向同時送信のシーケンスを示している。
【００３９】
送信側が、シーケンス番号nでmバイトのデータを送信すると、これを正規に受信した受信側は、確認応答番号が(n+m)の確認応答(ACK)を返信する。
【００４０】
図１４は、確認応答のシーケンスを示した図である。UECPでは送信側から送信されたデータが受信側で受信されたとき、受信側が確認応答(ACK)を送信側に送信することにより送信データの受信を通知する。送信データや確認応答がロストした場合は、その送信側がデータを再送する。確認応答パケットとデータ送信パケットとは分けてもよいし、ひとつのパケットで送信してもよい。
【００４１】
図１５は、ウインドウ制御のシーケンスを示した図である。UECPにおけるセッション確立状態でのデータ送信では、データ送信ごとにACK受信を待つ必要はなく、ウインドウサイズ(固定値)以内であれば続けてデータを送信できる。受信側はデータ受信ごとにACKを送信できるが、ウインドウサイズ以内であれば複数回のデータ受信に対してまとめてACKを送信しても良い。
【００４２】
図１６は、順序制御のシーケンスを示した図である。従来のUDPでは送信側でのデータ送信順に受信側がデータを受信できない場合があるが、本発明のUECPではシーケンス番号および確認応答番号を使用し、シーケンス番号通りのデータのみを受け取り、シーケンス番号通りでないデータは廃棄することにより、クロスしたデータ受信の場合でも順序通りのデータ受信が可能になる。
【００４３】
図１７、１８は、再送制御のシーケンスを示した図である。本発明のUECPでは、(1)データ送信パケットがロストした(ACKを受信タイムアウト値T3以内に受信できない)、(2)ACKがロストした(ACKをT3以内に受信できない)、(3)無効な確認応答番号のACKを受信した、(4)NAKを受信した、の４つの場合に再送が行われる。図１７は前記(2)の場合のシーケンスであり、図１８は前記(4)の場合のシーケンスである。
【００４４】
ACK受信タイムアウトの場合、最初の再送はT3経過後、２回目の再送は(T3×２)経過後、３回目の再送は(T3×３)経過後…となる。再送回数は制限されていないがキープアライブ監視があるため無限回数になることはない。この受信タイムアウト値T3は保守用コンピュータ９５からの操作あるいはアプリケーションの設定で任意に調整できるが、５００ms程度またはそれ以下に設定することが望ましい。
【００４５】
図１９、２０、２１は、キープアライブ(keepalive)のシーケンスを示した図である。図１９は、CCUおよびIPユニットの間で送信データが無い場合のシーケンスであり、セッション確立と同時にキープアライブ間隔のタイマがスタートしている。図２０は、CCUからIPユニットへの送信データがある場合のシーケンスであり、図２１は、IPユニットからCCUへの送信データがある場合のシーケンスである。送信データがある場合は、最後の送信タイミングあるいは受信タイミングからキープアライブ間隔のタイマがスタートしている。
【００４６】
本発明のUECPでは、プロトコルレベルでセッションごとにキープアライブを行い、互いに通信相手の生死およびLANケーブル(途中のHUBやルータなどのIP機器も含む)の接続状態を確認する。キープアライブ要求の送信間隔T5はポート番号毎に設定でき、本実施形態では５０〜６５５００msの範囲であれば５０ms刻みで任意に設定でき、ここでは初期値の３秒に設定されている。
【００４７】
また、キープアライブ要求に対する応答のタイムアウト値T4もポート番号毎に設定でき、本実施形態ではキープアライブ回数が１〜６５５３５の範囲で任意に設定でき、ここでは初期値の４回に設定されている。したがって、タイムアウト値T4は、IPユニット側が１２秒(＝T5×４)秒となり、CCU側はキープアライブ要求の送信時間を考慮して１４秒(＝T5×４＋２)秒となる。前記送信間隔T5およびキープアライブ回数は保守用コンピュータ９５からの操作あるいはアプリケーションの設定で任意に調整できるが、タイムアウト値T4が１２〜１４秒程度またはそれ以下となるようにすることが望ましい。
【００４８】
CCUおよびIPユニットから送信されるデータパケットでは、PSH、KPAおよびACKが同時に「１」にセットされ、送信するデータがない場合だけ、KPAおよびACKが「１」にセットされる。ただし、CCUからIPユニットへ送信するキープアライブ要求パケットではPSHが「１」にセットされる。「CCUが送信する単独のキープアライブ要求パケット」はデータサイズが「０」のパケットであり、「IPユニットが送信するキープアライブ応答パケット」はKPAが「１」の確認応答(ACK)パケットなので、データサイズが「０」のパケットはUECPレベルでは再送しないことになる。
【図面の簡単な説明】
【００４９】
【図１】本発明が適用されるIPボタン電話装置のブロック図である。
【図２】本発明に係るパケット通信方法(UECP)の構造を示した図である。
【図３】UECPヘッダの構造を示した図である。
【図４】UECPヘッダのコードビットフィールドの内容を示した図である。
【図５】UEPCにおける待ち受けポート番号の実装例を示した図である。
【図６】UEPCにおける通信ポート番号の実装例（その１）を示した図である。
【図７】UEPCにおける通信ポート番号の実装例（その２）を示した図である。
【図８】UECPのセッションオープンシーケンスを示した図である。
【図９】UECPのセッションクローズシーケンス（その１）を示した図である。
【図１０】UECPのセッションクローズシーケンス（その２）を示した図である。
【図１１】UECPのデータ送信の基本シーケンス（その１）を示した図である。
【図１２】UECPのデータ送信の基本シーケンス（その２）を示した図である。
【図１３】UECPのデータ送信の基本シーケンス（その３）を示した図である。
【図１４】UECPの確認応答のシーケンスを示した図である。
【図１５】UECPのウインドウ制御のシーケンスを示した図である。
【図１６】UECPの順序制御のシーケンスを示した図である。
【図１７】UECPの再送制御のシーケンス（その１）を示した図である。
【図１８】UECPの再送制御のシーケンス（その２）を示した図である。
【図１９】UECPのキープアライブのシーケンス（その１）を示した図である。
【図２０】UECPのキープアライブのシーケンス（その２）を示した図である。
【図２１】UECPのキープアライブのシーケンス（その３）を示した図である。
【符号の説明】
【００５０】
１…主制御ユニット(CCU)、２…TDM制御ユニット(TCCU)、３…カスタマエッジユニット(CEU)、４…音声変換ユニット(VCU)、１００…IPボタン電話装置
【技術分野】
【０００１】
本発明はパケット通信方法に係り、特に、高速で信頼性の高いパケット通信を可能にするパケット通信方法に関する。
【背景技術】
【０００２】
IPネットワークで利用される代表的なトランスポート層プロトコルとしてTCP(Transmission Control Protocol)およびUDP(User Datagram Protocol)が知られている。TCP(RFC1122およびRFC1123)はコネクション型プロトコルであり、パケット喪失によるデータ通信エラーを回避し、信頼性を保証するために、送信元がデータ送信後、一定時間だけ受信先からの確認応答信号(ACK)の到着を待ち、タイムアウトした場合は再度同じデータを送信する(再送制御)。このタイムアウト時間は再送タイムアウト時間(RTO：Retransmission Timeout)と呼ばれる。また、応答が続けてない場合には再送を繰り返すが、その場合の再送間隔は再送回数によって指数関数的に増やす方法が採られている。送信パケットの喪失が繰り返し発生する場合には、再送信タイムアウト時間を長くすることによって送信を抑制し、パケット喪失の確率を低くするように制御（輻輳制御）している。受信側では、正規に受信できたパケットのシーケンス番号および確認応答番号をACKにセットして返送することでパケットの到着順序が保証される（順序制御）。
【０００３】
これに対して、UDPはコネクションレス型プロトコルであり、上記のような再送制御、輻輳制御、順序制御などが行われない。このため、速度よりもデータ品質が要求されるWWW、メール、FTPなどにはTCPが用いられ、データ品質よりも速度(リアルタイム性)が優先される音声通話や映像配信にはUDPが用いられる。従来のTCPおよびUDPに関しては、例えば特許文献１に開示されている。
【特許文献１】特開２００１−１３６２０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
RFC2988では、TCPのRTOに関して、再送タイムアウトが１秒未満の場合は１秒に繰り上げるように勧告されている。したがって、TCPパケットに欠落が生じると、その再送に最低でも１秒はかかるため、通信のリアルタイム性が損なわれてしまう。
【０００５】
さらに、TCPにはkeepalive 機能が付与されている。これは実際のデータ送信がある無しに関わらず、そのコネクションにおいて一定時間ごとにパケットを送信して応答を監視し、TCP コネクションが有効でなければ切断される。しかしながら、keepalive 時間のデフォルトは２時間なので、通信相手ごとに無通信監視を所望の間隔で行おうとすれば、TCPよりも上位のアプリケーション層で無通信監視を行わなければならず、監視間隔が短くなるほどアプリケーション層における監視負荷が増大するという技術課題があった。
【０００６】
本発明の目的は、上記の従来技術の課題を解決し、アプリケーション層の負荷を増大させることなく、高速で信頼性の高いパケット通信方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記の目的を達成するために、本発明は、UDPの上位層でパケット交換を制御するパケット通信方法において、以下のような手順を含むことを特徴とする。
【０００８】
(1)UDPパケットのデータフィールドにプロトコルヘッダおよびデータの各フィールドを確保し、プロトコルヘッダが、少なくともシーケンス番号フィールド、確認応答番号フィールドおよびパケット識別用のコードビットフィールドを含み、前記シーケンス番号フィールドおよび確認応答番号フィールドに登録された番号に基づいて再送制御および順序制御を行うことを特徴とする。
【０００９】
(2)プロトコルヘッダがウインドウサイズフィールドを含むことを特徴とする。
【００１０】
(3)キープアライブ要求に対するキープアライブ応答のタイムアウトを規定するタイムアウト値を記憶し、キープアライブ応答を前記第４のタイムアウト値の経過後も受信できないとセッションをクローズし、この第４のタイムアウト値T4を設定する手順を含むことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、以下のような効果が達成される。
(1)TCPと同等の信頼性で、かつ実使用上はUDPと同等の転送速度が得られるパケット通信が可能になる。
(2)プロトコルがUDPのデータフィールドに実装されるので、下位に位置する従来のレイヤを活用できる。
(3)ウインドウサイズを指定できるので、効率の良いデータ転送が可能になる。
(4)キープアライブの送信間隔を自由に設定できるので、これを適宜の短時間に設定すれば、LANケーブルの引き抜きや通信相手の電源断をトランスポート層において素早く検知でき、その結果、上位のアプリケーション層における頻繁な監視が不要となってアプリケーションの負荷を軽減できる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の最良の実施形態について詳細に説明する。図１は、本発明が適用されるIPボタン電話装置１００の主要部の構成を示したブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００１３】
IPボタン電話装置１００は、外線としてアナログ回線、ナンバーディスプレイ契約回線、網番号ダイヤルイン回線、アナログ専用線、デジタル専用線およびISDN回線などのレガシー（従来型・旧型）外線のみならず、VoIP回線やNGN 回線を利用できる。また、内線端末として一般アナログ端末、ISDN端末、ホテルフォン、デジタルボタン電話機およびFAXなどのレガシー内線端末のみならず、ソフトフォンやIP電話機などのIP内線端末を収容し、各外線と各内線端末との間の通信を制御する。
【００１４】
IPボタン電話装置１００において、主制御ユニットCCU (Central Control Unit)１は、主制御プログラムに従ってシステム全体を制御する。TDM制御ユニットTCCU２は、各レガシー内線端末とIP網との間および各レガシー外線とIP内線端末との間で時分割多重化通信(TDM)を制御する。
【００１５】
カスタマエッジユニットCEU (Customer Edge Unit)３は、音声データと制御データとを多重化してIP通信を行う高速ブロードバンドルータとしての機能を備えると共に、保留音として高音質（帯域が約５０〜７０００Hz）の楽音データおよび標準音質（帯域が約３００〜４０００Hz）の楽音データを保持する。そして、内線端末と外線端末との通話が内線端末側の操作で保留された際、被保留側の外線端末へ、通話確立時のメディア能力に応じて高音質または標準音質の保留音を送出する。
【００１６】
音声変換ユニットVCU (Voice Conversion Unit)４は、通話の音声パケットを高音質から標準音質に変換し、その逆の変換を行うと共に、保留音として高音質の楽音データおよび標準音質の楽音データを保持する。そして、内線端末間の通話が一方の内線端末の操作で保留された際、保留音を持たない他方の被保留側の内線端末へ、通話確立時のメディア能力に応じて高音質または標準音質の保留音を送出する。
【００１７】
前記TCCU２には、ファックス端末８１、ホテルフォン端末８２、デジタルボタン電話機８３、単体電話機８４などのレガシー内線端末、および一般外線、ISDNネット回線、デジタル専用線、アナログ専用線などのレガシー外線が、各種の専用インターフェースおよびTDM通信用のTDMバス５を介して接続されている。前記TDMバス５は、制御信号を送受信するDチャネルおよびPCM変換された音声信号を送受信するBチャネルを備える。
【００１８】
前記CCU１とTCCU２とは音声用LAN８および制御用LAN９の２本のLANで接続されている。CCU１とCEU３およびVCU４とは制御用LANで接続されている。前記CCU１には更に、保守用LAN１０を介して保守用コンピュータ９５が接続されると共に、IP内線LAN６を介してHUB（ハブ）７が接続されている。前記HUB７には、専用インターフェースを介してIPボタン電話機９１や音声会議装置９２が接続され、無線アクセスポイント(AP)にはIPコードレスフォン９３が収容され、さらにソフトフォン９４のアプリケーションが実装されたコンピュータが接続されている。
【００１９】
前記CCU１は、CPU１１、DDRメモリ（RAM）１２、フラッシュメモリ１３、パケット転送の制御に特化した専用チップ１４、挿抜自在のコンパクトフラッシュ(登録商標)（CF）メモリ１５およびレイヤ２(L2)スイッチ１６を主要な構成としている。CCU１がパワーオンあるいはリセットされると、まず、フラッシュメモリ１３にあるブートローダ(ソフトウエア)が動作し、CFメモリ１５のファイルシステムに格納されているOSがDDRメモリ１２にロードされて起動される。次いで、OSがCFメモリ１５のアプリケーション(本体ソフトウエア)をDDRメモリ１２にロードして起動することで主制御プログラムが動作を開始する。
【００２０】
前記TCCU２は、CPU２１、DDRメモリ２２、フラッシュメモリ２３、ファイ(PHY)２４、前記Bチャネルを制御するハイウエイスイッチ２５、前記Dチャネル用の制御信号通信チップ２６およびDSP２７を主要な構成としている。前記PHY２４は、Ethernet(登録商標)(図示せず)の物理層を制御するLSIである。
【００２１】
前記CEU３は、CPU３１、DDRメモリ３２、フラッシュメモリ３３、パケット転送の制御に特化した専用チップ３４およびL2スイッチ３５を主要な構成としている。専用チップ３４は、前記CCU１の専用チップ１４と同様のものである。
【００２２】
VCU４は、CPU４１、DDRメモリ４２、フラッシュメモリ４３、L2スイッチ４４およびDSP４５を主要な構成としている。DSP４５は、例えば高音質の通話が標準音質のみに対応したレガシー内線端末へ転送された場合に、高音質の音声パケットを標準音質に変換してレガシー内線端末へ送出する一方、レガシー内線端末から送出される標準音質の音声を高音質用の音声パケットに変換して通話相手に送出する。
【００２３】
本実施形態ではCCU１、TCCU２、CEU３およびVCU４のそれぞれにCPU１１、２１、３１、４１を分散配置することで負荷分散を実現すると共に、CCU１およびCEU３には更に、パケット転送に特化した専用チップ１４、３４を搭載することでCPU１１、３１におけるパケット転送の処理を軽減し、更なる負荷分散を実現している。
【００２４】
このような構成において、レガシー内線端末（例えば、単体電話機８４）がNGN経由で発着信した場合、レガシー内線端末とTCCU２との間ではPCM変換された音声信号がTDMバス５上でTDM通信により送受信される。TCCU２とCCU１との間には通信セッションが確立され、この通信セッションにおいて音声信号および制御信号のデータパケットが交換される。CEU３は前記L2スイッチ３５経由でNGNに接続されており、CCU１およびCEU３は、それぞれの専用チップ１４、３４を利用してパケットを交換する。
【００２５】
また、IP内線端末がレガシー外線（例えば、ISDNネット）経由で発着信した場合は、TDMバス５、TCCU２、CCU１およびHUB７を介して制御情報、音声情報または音声パケットが送受信される。さらに、IP内線端末がNGN経由で発着信した場合は、CEU３、CCU１およびHUB７を介して、SIPメッセージ、制御情報または音声パケットが送受信される。
【００２６】
次いで、前記CCU１およびTCCU２間、CCU１およびCEU３間ならびにCCU１およびVCU４間など、CCU１と各IPユニット間での通信に採用される、本発明の固有のパケット通信プロトコルについて説明する。なお、CCU１およびTCCU２間では制御用LAN９による制御信号の通信にのみ適用され、音声用LAN８による音声信号の通信には適用されない。
【００２７】
図２は、本発明に係るパケット通信方法が適用されるプロトコルの階層を示した図であり、MAC層の上位にIP層が位置し、その上位にUDP層が位置し、その上位に本発明に固有の誤り制御プロトコル(以下、UECP：Unique Error Control Protocolと表現する)が位置している。
【００２８】
図３は、前記UECPヘッダの構造を示した図である。UECPヘッダはUDPパケットのデータフィールドの上位１２バイトの領域に確保され、シーケンス番号フィールド、確認応答番号フィールド、コードビットフィールドおよびウインドウサイズフィールドを含む。本実施形態では、UECPのMSS(Maximum Segment Size)が1398バイト以下に設定され、MTU(Maximum Transmission Unit)は1438バイト以下に設定されている。これらは、代表的なISPサービスであるBフレッツやフレッツADSL(いずれも登録商標)のMTUが1454バイト以下であり、フレッツ光プレミアム(登録商標)のMTUが1438バイト以下であることに基づく。
【００２９】
UECPヘッダのシーケンス番号フィールドには、このUECPの送受信単位(セグメント)の先頭のデータオクテットのシーケンス番号が登録される。初期シーケンス番号(ISN)はセッションをオープンしたときに「０」とされる。シーケンス番号の算術は、２３２のモジュロで実行する。
【００３０】
確認応答番号フィールドには、確認応答(ACK)パケットを受信した際、そのセグメントの送信側が次に受信することを想定しているシーケンス番号の値が登録される。確認応答番号の算術も２３２のモジュロで実行される。ウインドウフィールドには、確認応答番号で示しているバイト数を始点として、このセグメントの受信側が確認応答(ACK)なしで受け入れ可能なデータのバイト数が登録される。コードビットフィールドには、図４に示したように、パケットを識別するための各種のフラグが設定される。
【００３１】
NAK (Negative Acknowledgement)フラグは、受信パケットのシーケンス番号が受信可能なシーケンス番号と異なるときに送信元に対して再送を要求するNAKパケットにおいてセットされる。KPA(Keep Alive)フラグは、キープアライブの要求・応答に使われる。ACK (Acknowledgement)フラグは、確認応答番号が有効であるきに返信するACKパケットにおいてセットされる。PSH(Push)フラグは、受信したデータを直ちに上位アプリケーションに渡すか否かを表し、このビットがセットされている受信データは直ちに上位アプリケーションに渡さなければならない。RST(Reset)フラグは、セッションを強制的に切断する際にセットされる。SYN(Synchronize)フラグは、セッションを確立（オープン）する際にセットされる。FIN (Fin)フラグは、セッションを切断（クローズ）する際にセットされる。
【００３２】
図５は、UECPにおける待ち受けポート番号(CCU１がセッションオープン要求を待つポート番号およびIPユニットがセッションオープン要求を出すポート番号)の実装例を示した図であり、UDPのポート番号を用いるものとし、宛先ポート番号は任意の固定ポート番号であり、送信元ポート番号はエフェメラル（短命）ポート番号である。
【００３３】
図６は、UECPにおける通信ポート番号（セッション確立後にデータを送受信するポート番号）の実装例を示した図であり、UDPのポート番号を用いるものとし、通信方向にかかわらず、宛先ポート番号および送信元ポート番号のいずれにもエフェメラル（短命）ポート番号が用いられる。なお、CCU１側のポート番号に関しては、図７に示したように、TCPと同様に待ち受けポート番号を用いても良い。
【００３４】
図８は、UECPによるセッションオープンのシーケンスを示した図であり、ここでは、IPユニットからCCU１へセッションオープンを要求する場合を例にして説明する。
【００３５】
IPユニットはセッションオープン要求パケット(SYN)の送信後、第１のタイムアウト値T1以内にCCUからセッションオープン応答パケット(SYN+ACK)を受信できないと、セッションオープン失敗としてRSTパケットを送信し、セッションオープン要求パケットの送信から手順をやり直す。CCUは、セッションオープン応答パケットの送信後、タイムアウト値T1以内にIPユニットから確認応答(ACK)パケットを受信できないと、セッションオープン失敗としてRSTパケットを送信し、セッションオープン要求パケットの受信待ちから手順をやり直す。IPユニットは、確認応答パケットを送信した時点でセッション確立状態となり、CCUは、確認応答パケットを受信した時点でセッション確立状態となる。
【００３６】
図９、１０は、セッションクローズのシーケンスを示した図である。本実施形態では、CCUおよびIPユニットのいずれからでもセッションをクローズできる。図９は、IPユニットからセッションクローズを要求する手順を示し、図１０は、CCUからセッションクローズを要求する手順を示している。
【００３７】
セッションクローズ要求パケットの送信側は、その送信後にセッションクローズ応答パケットを第２のタイムアウト値T2以内に受信できなければ、手順上はセッションクローズ完了とはならないものの、セッションクローズ要求パケットを再送することなくセッションクローズ扱いとする。なお、後に詳述するように、本実施形態では送信側および受信側が互いに一定時間キープアライブ要求・応答を送信しないとセッションクローズになるので、セッションクローズ応答パケットを受信できない場合にセッションクローズ扱いしても問題はない。
【００３８】
図１１、１２、１３は、データ送信の基本シーケンスを示した図であり、図１１はCCUからIPユニットへの送信シーケンス、図１２はIPユニットからCCUへの送信シーケンス、図１３は双方向同時送信のシーケンスを示している。
【００３９】
送信側が、シーケンス番号nでmバイトのデータを送信すると、これを正規に受信した受信側は、確認応答番号が(n+m)の確認応答(ACK)を返信する。
【００４０】
図１４は、確認応答のシーケンスを示した図である。UECPでは送信側から送信されたデータが受信側で受信されたとき、受信側が確認応答(ACK)を送信側に送信することにより送信データの受信を通知する。送信データや確認応答がロストした場合は、その送信側がデータを再送する。確認応答パケットとデータ送信パケットとは分けてもよいし、ひとつのパケットで送信してもよい。
【００４１】
図１５は、ウインドウ制御のシーケンスを示した図である。UECPにおけるセッション確立状態でのデータ送信では、データ送信ごとにACK受信を待つ必要はなく、ウインドウサイズ(固定値)以内であれば続けてデータを送信できる。受信側はデータ受信ごとにACKを送信できるが、ウインドウサイズ以内であれば複数回のデータ受信に対してまとめてACKを送信しても良い。
【００４２】
図１６は、順序制御のシーケンスを示した図である。従来のUDPでは送信側でのデータ送信順に受信側がデータを受信できない場合があるが、本発明のUECPではシーケンス番号および確認応答番号を使用し、シーケンス番号通りのデータのみを受け取り、シーケンス番号通りでないデータは廃棄することにより、クロスしたデータ受信の場合でも順序通りのデータ受信が可能になる。
【００４３】
図１７、１８は、再送制御のシーケンスを示した図である。本発明のUECPでは、(1)データ送信パケットがロストした(ACKを受信タイムアウト値T3以内に受信できない)、(2)ACKがロストした(ACKをT3以内に受信できない)、(3)無効な確認応答番号のACKを受信した、(4)NAKを受信した、の４つの場合に再送が行われる。図１７は前記(2)の場合のシーケンスであり、図１８は前記(4)の場合のシーケンスである。
【００４４】
ACK受信タイムアウトの場合、最初の再送はT3経過後、２回目の再送は(T3×２)経過後、３回目の再送は(T3×３)経過後…となる。再送回数は制限されていないがキープアライブ監視があるため無限回数になることはない。この受信タイムアウト値T3は保守用コンピュータ９５からの操作あるいはアプリケーションの設定で任意に調整できるが、５００ms程度またはそれ以下に設定することが望ましい。
【００４５】
図１９、２０、２１は、キープアライブ(keepalive)のシーケンスを示した図である。図１９は、CCUおよびIPユニットの間で送信データが無い場合のシーケンスであり、セッション確立と同時にキープアライブ間隔のタイマがスタートしている。図２０は、CCUからIPユニットへの送信データがある場合のシーケンスであり、図２１は、IPユニットからCCUへの送信データがある場合のシーケンスである。送信データがある場合は、最後の送信タイミングあるいは受信タイミングからキープアライブ間隔のタイマがスタートしている。
【００４６】
本発明のUECPでは、プロトコルレベルでセッションごとにキープアライブを行い、互いに通信相手の生死およびLANケーブル(途中のHUBやルータなどのIP機器も含む)の接続状態を確認する。キープアライブ要求の送信間隔T5はポート番号毎に設定でき、本実施形態では５０〜６５５００msの範囲であれば５０ms刻みで任意に設定でき、ここでは初期値の３秒に設定されている。
【００４７】
また、キープアライブ要求に対する応答のタイムアウト値T4もポート番号毎に設定でき、本実施形態ではキープアライブ回数が１〜６５５３５の範囲で任意に設定でき、ここでは初期値の４回に設定されている。したがって、タイムアウト値T4は、IPユニット側が１２秒(＝T5×４)秒となり、CCU側はキープアライブ要求の送信時間を考慮して１４秒(＝T5×４＋２)秒となる。前記送信間隔T5およびキープアライブ回数は保守用コンピュータ９５からの操作あるいはアプリケーションの設定で任意に調整できるが、タイムアウト値T4が１２〜１４秒程度またはそれ以下となるようにすることが望ましい。
【００４８】
CCUおよびIPユニットから送信されるデータパケットでは、PSH、KPAおよびACKが同時に「１」にセットされ、送信するデータがない場合だけ、KPAおよびACKが「１」にセットされる。ただし、CCUからIPユニットへ送信するキープアライブ要求パケットではPSHが「１」にセットされる。「CCUが送信する単独のキープアライブ要求パケット」はデータサイズが「０」のパケットであり、「IPユニットが送信するキープアライブ応答パケット」はKPAが「１」の確認応答(ACK)パケットなので、データサイズが「０」のパケットはUECPレベルでは再送しないことになる。
【図面の簡単な説明】
【００４９】
【図１】本発明が適用されるIPボタン電話装置のブロック図である。
【図２】本発明に係るパケット通信方法(UECP)の構造を示した図である。
【図３】UECPヘッダの構造を示した図である。
【図４】UECPヘッダのコードビットフィールドの内容を示した図である。
【図５】UEPCにおける待ち受けポート番号の実装例を示した図である。
【図６】UEPCにおける通信ポート番号の実装例（その１）を示した図である。
【図７】UEPCにおける通信ポート番号の実装例（その２）を示した図である。
【図８】UECPのセッションオープンシーケンスを示した図である。
【図９】UECPのセッションクローズシーケンス（その１）を示した図である。
【図１０】UECPのセッションクローズシーケンス（その２）を示した図である。
【図１１】UECPのデータ送信の基本シーケンス（その１）を示した図である。
【図１２】UECPのデータ送信の基本シーケンス（その２）を示した図である。
【図１３】UECPのデータ送信の基本シーケンス（その３）を示した図である。
【図１４】UECPの確認応答のシーケンスを示した図である。
【図１５】UECPのウインドウ制御のシーケンスを示した図である。
【図１６】UECPの順序制御のシーケンスを示した図である。
【図１７】UECPの再送制御のシーケンス（その１）を示した図である。
【図１８】UECPの再送制御のシーケンス（その２）を示した図である。
【図１９】UECPのキープアライブのシーケンス（その１）を示した図である。
【図２０】UECPのキープアライブのシーケンス（その２）を示した図である。
【図２１】UECPのキープアライブのシーケンス（その３）を示した図である。
【符号の説明】
【００５０】
１…主制御ユニット(CCU)、２…TDM制御ユニット(TCCU)、３…カスタマエッジユニット(CEU)、４…音声変換ユニット(VCU)、１００…IPボタン電話装置
【特許請求の範囲】
【請求項１】
UDPの上位層でパケット交換を制御するパケット通信方法において、
UDPパケットのデータフィールドにプロトコルヘッダおよびデータの各フィールドを確保し、
前記プロトコルヘッダが、少なくともシーケンス番号フィールド、確認応答番号フィールドおよびパケット識別用のコードビットフィールドを含み、
前記シーケンス番号フィールドおよび確認応答番号フィールドに登録された番号に基づいて再送制御および順序制御を行うことを特徴とするパケット通信方法。
【請求項２】
前記プロトコルヘッダがウインドウサイズフィールドを含むことを特徴とする請求項１に記載のパケット通信方法。
【請求項３】
セッションオープン要求に対するセッションオープン応答、および当該セッションオープン応答に対する確認応答のタイムアウトを規定する第１のタイムアウト値T1を記憶し、前記セッションオープン応答または確認応答を前記第１のタイムアウト値T1の経過後も受信できないと、セッションオープンの手順をやり直すことを特徴とする請求項１または２に記載のパケット通信方法。
【請求項４】
セッションクローズ要求に対するセッションクローズ応答のタイムアウトを規定する第２のタイムアウト値T2を記憶し、前記セッションクローズ応答を前記第２のタイムアウト値T2の経過後も受信できないと、セッションクローズ要求を再送することなくセッションクローズ扱いとすることを特徴とする請求項１または２に記載のパケット通信方法。
【請求項５】
データ送信に対する確認応答のタイムアウトを規定する第３のタイムアウト値T3を記憶し、確認応答を前記第３のタイムアウト値T3の経過後も受信できないとデータを再送することを特徴とする請求項１または２に記載のパケット通信方法。
【請求項６】
前記第３のタイムアウト値T3が略５００ミリ秒以下であることを特徴とする請求項５に記載のパケット通信方法。
【請求項７】
キープアライブ要求に対するキープアライブ応答のタイムアウトを規定する第４のタイムアウト値T4を記憶し、キープアライブ応答を前記第４のタイムアウト値T4の経過後も受信できないとセッションをクローズし、
前記第４のタイムアウト値T4を設定する手順を含むことを特徴とする請求項１または２に記載のパケット通信方法。
【請求項８】
前記第４のタイムアウト値T4が１２ないし１４秒以下であることを特徴とする請求項７に記載のパケット通信方法。
【請求項１】
UDPの上位層でパケット交換を制御するパケット通信方法において、
UDPパケットのデータフィールドにプロトコルヘッダおよびデータの各フィールドを確保し、
前記プロトコルヘッダが、少なくともシーケンス番号フィールド、確認応答番号フィールドおよびパケット識別用のコードビットフィールドを含み、
前記シーケンス番号フィールドおよび確認応答番号フィールドに登録された番号に基づいて再送制御および順序制御を行うことを特徴とするパケット通信方法。
【請求項２】
前記プロトコルヘッダがウインドウサイズフィールドを含むことを特徴とする請求項１に記載のパケット通信方法。
【請求項３】
セッションオープン要求に対するセッションオープン応答、および当該セッションオープン応答に対する確認応答のタイムアウトを規定する第１のタイムアウト値T1を記憶し、前記セッションオープン応答または確認応答を前記第１のタイムアウト値T1の経過後も受信できないと、セッションオープンの手順をやり直すことを特徴とする請求項１または２に記載のパケット通信方法。
【請求項４】
セッションクローズ要求に対するセッションクローズ応答のタイムアウトを規定する第２のタイムアウト値T2を記憶し、前記セッションクローズ応答を前記第２のタイムアウト値T2の経過後も受信できないと、セッションクローズ要求を再送することなくセッションクローズ扱いとすることを特徴とする請求項１または２に記載のパケット通信方法。
【請求項５】
データ送信に対する確認応答のタイムアウトを規定する第３のタイムアウト値T3を記憶し、確認応答を前記第３のタイムアウト値T3の経過後も受信できないとデータを再送することを特徴とする請求項１または２に記載のパケット通信方法。
【請求項６】
前記第３のタイムアウト値T3が略５００ミリ秒以下であることを特徴とする請求項５に記載のパケット通信方法。
【請求項７】
キープアライブ要求に対するキープアライブ応答のタイムアウトを規定する第４のタイムアウト値T4を記憶し、キープアライブ応答を前記第４のタイムアウト値T4の経過後も受信できないとセッションをクローズし、
前記第４のタイムアウト値T4を設定する手順を含むことを特徴とする請求項１または２に記載のパケット通信方法。
【請求項８】
前記第４のタイムアウト値T4が１２ないし１４秒以下であることを特徴とする請求項７に記載のパケット通信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１０−１０９７３３（Ｐ２０１０−１０９７３３Ａ）
【公開日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願番号】特願２００８−２８０１２３（Ｐ２００８−２８０１２３）
【出願日】平成２０年１０月３０日（２００８．１０．３０）
【出願人】（００００００１８１）岩崎通信機株式会社 (133)
【出願人】（３９９０４０４０５）東日本電信電話株式会社 (286)
【出願人】（３９９０４１１５８）西日本電信電話株式会社 (215)
【Ｆターム（参考）】
【公開日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願日】平成２０年１０月３０日（２００８．１０．３０）
【出願人】（００００００１８１）岩崎通信機株式会社 (133)
【出願人】（３９９０４０４０５）東日本電信電話株式会社 (286)
【出願人】（３９９０４１１５８）西日本電信電話株式会社 (215)
【Ｆターム（参考）】
[ Back to top ]