JP5334293B2 - パケット通信方法 - Google Patents

パケット通信方法 Download PDF

Info

Publication number
JP5334293B2
JP5334293B2 JP2008280123A JP2008280123A JP5334293B2 JP 5334293 B2 JP5334293 B2 JP 5334293B2 JP 2008280123 A JP2008280123 A JP 2008280123A JP 2008280123 A JP2008280123 A JP 2008280123A JP 5334293 B2 JP5334293 B2 JP 5334293B2
Authority
JP
Japan
Prior art keywords
data
received
session
packet
communication method
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2008280123A
Other languages
English (en)
Other versions
JP2010109733A (ja
Inventor
正治 宍戸
隆弘 和里
隆徳 染井
謙一 小山
圭一 中山
靖之 古川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Iwatsu Electric Co Ltd
Nippon Telegraph and Telephone West Corp
Nippon Telegraph and Telephone East Corp
Original Assignee
Iwatsu Electric Co Ltd
Nippon Telegraph and Telephone West Corp
Nippon Telegraph and Telephone East Corp
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 Iwatsu Electric Co Ltd, Nippon Telegraph and Telephone West Corp, Nippon Telegraph and Telephone East Corp filed Critical Iwatsu Electric Co Ltd
Priority to JP2008280123A priority Critical patent/JP5334293B2/ja
Publication of JP2010109733A publication Critical patent/JP2010109733A/ja
Application granted granted Critical
Publication of JP5334293B2 publication Critical patent/JP5334293B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Description

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

Claims (8)

  1. UDPの上位層でパケット交換を制御するパケット通信方法において、
    UDPパケットのデータフィールドにプロトコルヘッダおよびデータの各フィールドを確保し、
    前記プロトコルヘッダが、少なくともシーケンス番号フィールド、確認応答番号フィールドおよびパケット識別用のコードビットフィールドを含み、
    前記シーケンス番号フィールドに登録されたシーケンス番号および確認応答番号フィールドに登録された確認応答番号に基づいて、データ受信側は、データ送信側から送信されてきたデータが、自側が次に受信を想定しているシーケンス番号のデータであれば該データを受信してACKを送信し、そうでなければ該データを受信せずに廃棄するとともに、自側が次に受信を想定しているデータを再送するように促すためにNAKを直ちに送信し、データ送信側は、データ送信ごとにACK受信を待つことなくシーケンス番号に従ってデータを順次送信し、NAKを受信したら再送が促されたデータから該データの送信以降に既に送信したデータまでのデータをシーケンス番号の順序通りに再送し、データ受信側は、データ送信側から再送されてきたデータの内、それまでに受信していないシーケンス番号のデータのみを受信し、それまでに受信したシーケンス番号のデータは廃棄するとともに、受信したデータを受信した旨のACKを送信することを特徴とするパケット通信方法。
  2. 前記プロトコルヘッダがウインドウサイズフィールドを含み、該ウインドウサイズフィールドにはデータ受信側が確認応答なしで受け入れ可能なデータのバイト数が登録されることを特徴とする請求項1に記載のパケット通信方法。
  3. セッションオープン要求に対するセッションオープン応答、および当該セッションオープン応答に対する確認応答のタイムアウトを規定する第1のタイムアウト値T1を記憶し、前記セッションオープン応答または確認応答を前記第1のタイムアウト値T1の経過後も受信できないと、セッションオープンの手順をやり直すことを特徴とする請求項1または
    に記載のパケット通信方法。
  4. セッションクローズ要求に対するセッションクローズ応答のタイムアウトを規定する第2のタイムアウト値T2を記憶し、前記セッションクローズ応答を前記第2のタイムアウト値T2の経過後も受信できないと、セッションクローズ要求を再送することなくセッションクローズ扱いとすることを特徴とする請求項1または2に記載のパケット通信方法。
  5. データ送信に対する確認応答のタイムアウトを規定する第3のタイムアウト値T3を記憶し、確認応答を前記第3のタイムアウト値T3の経過後も受信できないとデータを再送することを特徴とする請求項1または2に記載のパケット通信方法。
  6. 前記第3のタイムアウト値T3が略500ミリ秒以下であることを特徴とする請求項5に記載のパケット通信方法。
  7. キープアライブ要求に対するキープアライブ応答のタイムアウトを規定する第4のタイムアウト値T4を記憶し、キープアライブ応答を前記第4のタイムアウト値T4の経過後も受信できないとセッションをクローズし、
    前記第4のタイムアウト値T4を設定する手順を含むことを特徴とする請求項1または2に記載のパケット通信方法。
  8. 前記第4のタイムアウト値T4が12ないし14秒以下であることを特徴とする請求項7に記載のパケット通信方法。
JP2008280123A 2008-10-30 2008-10-30 パケット通信方法 Active JP5334293B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008280123A JP5334293B2 (ja) 2008-10-30 2008-10-30 パケット通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008280123A JP5334293B2 (ja) 2008-10-30 2008-10-30 パケット通信方法

Publications (2)

Publication Number Publication Date
JP2010109733A JP2010109733A (ja) 2010-05-13
JP5334293B2 true JP5334293B2 (ja) 2013-11-06

Family

ID=42298720

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008280123A Active JP5334293B2 (ja) 2008-10-30 2008-10-30 パケット通信方法

Country Status (1)

Country Link
JP (1) JP5334293B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8478890B2 (en) * 2011-07-15 2013-07-02 Damaka, Inc. System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
US8307234B2 (en) * 2012-01-14 2012-11-06 Intel Corporation Maintaining connectivity during low power operation
CN102789187B (zh) * 2012-07-05 2014-12-10 华为技术有限公司 云台设备识别方法、云台设备、摄像机及云台设备控制系统
JP5813835B2 (ja) * 2014-07-31 2015-11-17 エヌ・ティ・ティ・コミュニケーションズ株式会社 クライアント装置、及び通信システム
CN109428683B (zh) * 2017-08-24 2021-06-08 福建省华渔教育科技有限公司 基于位图的分组确认方法及终端
JP7143609B2 (ja) * 2018-03-28 2022-09-29 日本電気株式会社 通信装置、通信方法、プログラム
JP7102361B2 (ja) * 2019-02-18 2022-07-19 株式会社日立製作所 通信方法及び通信装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3031008B2 (ja) * 1991-12-06 2000-04-10 松下電器産業株式会社 データ伝送方法
JPH10247901A (ja) * 1997-03-04 1998-09-14 Matsushita Electric Ind Co Ltd 再送制御方法
US6161123A (en) * 1997-05-06 2000-12-12 Intermec Ip Corporation Providing reliable communication over an unreliable transport layer in a hand-held device using a persistent session
JP2001524290A (ja) * 1997-05-06 2001-11-27 インターメック テクノロジーズ コーポレイション 設定可能なタイマを使用するハンドヘルド装置で、低信頼度のトランスポート層を利用した高信頼性のデータ処理方法及びその装置
JP3107041B2 (ja) * 1998-04-28 2000-11-06 日本電気株式会社 無線データ通信方法及び装置
JP4015773B2 (ja) * 1999-03-10 2007-11-28 松下電器産業株式会社 送受信装置
JP3929969B2 (ja) * 2003-12-17 2007-06-13 ティー・ティー・ティー株式会社 通信システム、サーバ、端末装置、通信方法、プログラムおよび記憶媒体

Also Published As

Publication number Publication date
JP2010109733A (ja) 2010-05-13

Similar Documents

Publication Publication Date Title
JP5334293B2 (ja) パケット通信方法
US9590821B2 (en) Communication system for transmitting data under a tunnel protocol between at least two data computers via a wide area network and a method for running such a communication system
US20020118671A1 (en) Extending office telephony and network data services to a remote client through the internet
US8077624B2 (en) Method and system for out-of-band signaling for TCP connection setup
JP5014281B2 (ja) Tcp送信制御装置及びtcp送信制御方法
US20080298349A1 (en) System for transmitting high quality speech signals on a voice over internet protocol network
US8484331B2 (en) Real time protocol packet tunneling
JP2000224261A (ja) ネットワ―ク層プロトコルを直接サポ―トするデ―タリンク制御プロトコルおよび方法
JP5020076B2 (ja) 低頻度ackのシステムに適した高性能tcp
KR20100053625A (ko) 무선 통신 시스템에서의 핸드오버 동안 데이터의 계층 2 터널링
WO2009039754A1 (en) Method, media gateway and system for controlling redundant data packets transport
EP1709781A1 (en) Congestion handling in a packet communication system
CN101146100B (zh) 一种基于传输协议sctp和dccp的sip网络电话实现方法
BRPI0707861A2 (pt) dispositivos relacionados a computador e tÉcnicas para facilitaÇço de uma chamada de emergÊncia
WO2020154872A1 (zh) 一种传输控制协议加速方法和装置
CN100542132C (zh) 基于传输控制协议的语音传输方法
JP4546114B2 (ja) 音声パケット転送方法及びそれに用いる端末
Cisco X.25 and LAPB Commands
JP4275265B2 (ja) 呼制御サーバおよび音声データ通信方法
WO2002025880A2 (en) Dynamic tcp configuration for low latency voice/data traffic
JP2009260719A (ja) データ伝送端末装置およびデータ伝送方法
CN114339133B (zh) 一种连接不同视频会议终端的网络加速方法、设备及存储介质
WO2013097611A1 (zh) 一种数据处理方法、装置及系统
JP4757576B2 (ja) 無線lanにおける伝送誤り改善方式およびアクセスポイントならびに無線lan端末
JP3759465B2 (ja) 端末装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20111003

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120905

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120912

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121102

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130116

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130313

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130724

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130729

R150 Certificate of patent or registration of utility model

Ref document number: 5334293

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150