JP3637389B2 - パケット通信方法及び提案ノード - Google Patents
パケット通信方法及び提案ノード Download PDFInfo
- Publication number
- JP3637389B2 JP3637389B2 JP2001356498A JP2001356498A JP3637389B2 JP 3637389 B2 JP3637389 B2 JP 3637389B2 JP 2001356498 A JP2001356498 A JP 2001356498A JP 2001356498 A JP2001356498 A JP 2001356498A JP 3637389 B2 JP3637389 B2 JP 3637389B2
- Authority
- JP
- Japan
- Prior art keywords
- communication
- node
- window size
- advertised
- reception window
- 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.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1832—Details of sliding window management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1858—Transmission or retransmission of more than one copy of acknowledgement message
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＴＣＰを用いた無線通信におけるパケット通信方法に関する。特に、通信遮断が生じた際に、高速に正常通信状態に回復できる手法を提案するものである。
【０００２】
【従来の技術】
近年の携帯電話やインターネットの普及に伴い、高速な無線通信技術の開発が急がれている。本件出願人らによっても、構内系や屋外系のシステムとして高速な無線アクセスシステムが開発されており、すでに１５６Ｍｂｐｓの伝送速度が実現されている。
【０００３】
しかし、無線通信では通信遮断により伝送速度が低下する場合があり、特にこれからの周波数資源として注目されるミリ波帯によるシステムでは、人体等によっても容易に遮蔽されてしまうため、遮蔽による切断を防ぐ技術だけではなく、切断した場合にその影響を最小限にとどめることが必要である。
インターネットでも用いられるＴＣＰは、完璧な誤り制御とフロー制御を行うため、遮断によるパケットロスが発生した場合、遮断からの回復後に再送を行う。
【０００４】
従来のＴＣＰの再送では、パケットロスが輻輳により発生するという前提であるために、遮断時に起こりやすい複数の連続したパケットロスに対しては、再送に長い時間を要することが多い。この結果、遮断時間に比べて著しく長い時間、ＴＣＰによる通信が不能になってしまう問題があった。
【０００５】
この対処としては、無線環境に対応したＴＣＰに関する研究があり、例えば参考文献１に挙げるｓｎｏｏｐプロトコルでは、基地局にエージェントを配してコネクションを監視し、無線端末が再送要求を出したときにエージェントが吸収・代理応答することで、再送動作による伝送速度低下を防ぐ方法が提案されている。
【０００６】
【参考文献１】
H.Balakrishnan, S.Seehan, and R.H.Katz,
"Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks", ACM Wireless Networks 1(4), 1995年12月
【０００７】
しかし、このような従来の方法では、通信遮断における一定時間以上継続しておこるエラーに対して有効に対応できていない。また、エージェントを設けたり、サーバー側とクライアント側とを共に変更したりする構成は、汎用性に乏しく、コスト高を招くことになる。
従来の技術では、これらの問題点を解決する有効な方法が提供されておらず、上述した高速な無線通信技術における障害となっていた。
【０００８】
【発明が解決しようとする課題】
本発明は、上記従来技術の有する問題点に鑑みて創出されたものであり、その目的は、通信遮断による連続したパケットロスに対して、遮断からの回復後、すみやかに通信が再開できると共に、既存のシステムに大きな変更を加えず、簡易な構成で低コスト化に寄与するパケット通信方法及び提案ノードを提供することである。
【０００９】
【課題を解決するための手段】
上記課題の解決を図るため、本発明では次のようなパケット通信方法を提供する。本パケット通信方法は、少なくとも一部に無線通信区間を有するネットワークにおいて用いられるものである。
本発明におけるパケット通信方法は、一般ノードと、提案ノードとの間でＴＣＰを用いた通信中に通信遮断によるパケットロスが生じた後、通信遮断から回復したときに、提案ノードが、擬似的に重複した確認応答を複数送信する。このとき、プロトコルスタックにおけるＴＣＰ層では、疑似重複確認応答を送るために、各コネクションが最後に送信した確認応答を記憶しておく。
【００１０】
提案ノードが、重複した確認応答にて、一般ノードに広告する広告受信ウィンドウサイズを増加させて一般ノードに送信する。
一般ノードは、重複した確認応答を複数受信した場合に、該確認応答に基づいて、一般ノードが提案ノードに向けて該増加分に対応する新パケットを送信する。
【００１１】
正常通信時には、広告受信ウィンドウサイズを過小に広告する一方、通信遮断から回復した時に広告受信ウィンドウサイズとして実際の受信バッファ値を広告する構成でもよい。
【００１２】
本発明においては、上述のように擬似的に重複して確認応答を送信するが、その送信回数は次の式によって求めることもできる。
Ｄ＝ｃｅｉｌ（ａｗｎｄ／ＭＳＳ）
ここで、一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、最大セグメントサイズをＭＳＳとしている。
確認応答は重複数を大きくすることで新しいデータの送信を促すことができるが、一定数を超えると意味をなさない。上記はすみやかなデータの再送を促し、かつ有効に作用する確認応答の送信回数である。
【００１３】
前記パケット通信方法において、正常通信時に広告受信ウィンドウサイズを過小に広告する際、サイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、過小に広告する広告受信ウィンドウサイズをａｗｎｄ'、最大セグメントサイズをＭＳＳとしたとき、
２＞ａｗｎｄ／ＭＳＳ＋（６−ｎ（ｎ＋１）／２）と、
ｎ＝（ａｗｎｄ−ａｗｎｄ'）／ＭＳＳと
の２式を共に満たすａｗｎｄ'を算出し、その最大値を広告することにより、正常通信時に最適な広告受信ウィンドウサイズを得ることもできる。
【００１４】
また、本発明は次のような提案ノードを提供することも出来る。
すなわち、ＴＣＰを用いて無線通信を行う提案ノードであって、下り信号の信号電力を検知し所定の閾値を超えたのを確認することで通信遮断から回復したことを検知する通信回復検知手段と、擬似的に重複した確認応答を送信する疑似重複信号送信手段と、一般ノードに広告する広告受信ウィンドウサイズを変化させ、一般ノードに送信するサイズ適応広告手段とを備える。
【００１５】
そして、正常通信時には、広告受信ウィンドウサイズを過小に広告する一方、通信遮断が生じた場合、通信遮断状態からの通信回復を通信回復検知手段が検知し、前記疑似重複信号送信手段による確認応答の送信後、前記サイズ増加広告手段が、広告受信ウィンドウサイズを実際の受信バッファ値に増加して一般ノードに送信することを特徴とする。
【００１６】
前記提案ノードが、一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、最大セグメントサイズをＭＳＳとしたとき、
Ｄ＝ｃｅｉｌ（ａｗｎｄ／ＭＳＳ）
によって計算されるＤ回重複した確認応答を、擬似的に重複して送信する構成でもよい。
【００１７】
正常通信時に広告受信ウィンドウサイズを過小に広告する際、一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、過小に広告する広告受信ウィンドウサイズをａｗｎｄ'、最大セグメントサイズをＭＳＳとしたとき、次の２式を共に満たすａｗｎｄ'を求めてもよい。
２＞ａｗｎｄ／ＭＳＳ＋（６−ｎ（ｎ＋１）／２）
ｎ＝（ａｗｎｄ−ａｗｎｄ'）／ＭＳＳ
そして、ａｗｎｄ'の最大値を広告することにより、正常通信時に最適な広告受信ウィンドウサイズを得ることもできる。
【００１８】
【発明の実施の形態】
以下、本発明の実施方法を図面に示した実施例に基づいて説明する。なお、本発明の実施形態は以下に限定されず、適宜変更可能である。
無線通信チャネルの状態は常に変動し、場合によっては一時的な切断（以下、通信遮断）も発生する。通信の高速化に伴い、一瞬の通信遮断が通信パフォーマンスに与える影響も大きくなっている。特に上位層がＴＣＰの場合には、通信遮断によって大きくパフォーマンスが低下することが問題となっている。
本発明は、このような通信遮断後に、速やかに通信性能が回復するパケット通信方法を提供するものである。
【００１９】
通信遮断の要因としては、ハンドオーバやシャドウイングなどが考えられる。特に5GHz帯無線LAN、22/26/38GHz帯の加入者系無線アクセス(FWA)、60GHz帯等の各種無線通信システムなどのような高周波利用システムでは、通常はスポットサービスが中心となるが、将来は既存セルラーのように複数セルによる移動通信をサポートしたいという要求もある。その場合にはハンドオーバが必要となるが、従来のような計画的なセル配置は困難であり、ハンドオーバ時に瞬間的な遮断が生じることが考えられる。
一方のシャドウイングは、主に高周波帯の電波伝播の直進性に起因する問題である。特にミリ波帯では顕著であり、オフィス環境での実験によると、平均遮断継続時間は０．３秒、平均遮蔽発生間隔は１０分程度との結果が得られている。
【００２０】
このように、無線通信において物理層レベルの遮断が問題となるが、この遮断が上位のＴＣＰ層に大きな影響を与えることが明らかになってきた。ＴＣＰはインターネットでもっともよく使われているトランスポートプロトコルであり、ネットワーク帯域を公平に共有するためのスロースタート・輻輳制御と、輻輳時のルータでのバッファ溢れによるパケットロスを補償するための再送制御に特徴がある。
伝送エラーの少ない有線ネットワークを前提に設計されているＴＣＰは、パケットロス＝輻輳と判断し、パケット送出レートを低下させて輻輳回避を試みる。
【００２１】
しかしながら、無線伝送エラーによるパケットロスが発生するネットワーク上でＴＣＰを利用すると、この輻輳回避アルゴリズムがスループットを大きく低下させてしまう。すなわち、いくつかのパケットロスが発生した直後に回線が元の良好な状態に回復したにも拘らず、輻輳と認識したＴＣＰが輻輳回避のためにしばらくの間パケット送出レートを下げてしまうことにより、スループットが低下してしまう。これが高周波無線通信時に起こるＴＣＰの問題点である。
【００２２】
特に、送信側のバッファが一杯になるような通信遮断が発生したときには、fast recovery（以下、FRCと呼ぶ。）やSelective Acknowledgement（以下、ＳＡＣＫと呼ぶ。）といった現状の再送対策の手法は機能しない。
これらの機能は、受信側からの確認応答（本実施例では、ＡＣＫとする。）が引き金としてアクションを起こすため、通信遮断時にはそのＡＣＫも到達しないために再送ができず、かつ新たなデータも送れないという、２つの問題が生じる。
【００２３】
ＴＣＰは送受両方で協調動作することで信頼性の高いデータ転送を実現しているために、一定時間接続が途切れたりバースト的なエラーが発生した場合、どちらかが何らかの送信を行わない限りタイムアウトを待つしかないというところに大きな問題がある。
従来の対策としては、有線サーバー側も含めて、ＴＣＰプロトコルを全て無線対応型に改めるという試みもあるが、インターネット上の全てのサーバーに変更を強いるのは現実性がなく、限られたネットワークで実施するとしてもコスト高、汎用性の乏しさが問題である。
そこで、本発明は、無線区間はいわゆるファーストホップ／ラストホップとして使用され、有線で構成された基幹部分(インターネットなど)を介し、他ノードと通信する図１に示すネットワーク環境を例に、上記問題点の解決を図るものである。
【００２４】
通信遮断が発生した場合、提案ノード（１）がデータの受信を行っている場合は通信遮断が終わると同時に受信を再開できるのが望ましいが、図示のような環境では一般ノード（２）は無線区間（３）の通信遮断を知るすべが無いため、即座に再送のデータが送ることはない。
これに対する有効な方法として、通信遮断から回復した時に、下位層がＴＣＰ層に信号を送るという手法を導入する。通信遮断終了時に早期の伝送速度の回復を図るためには、ＴＣＰ層が通信遮断に関する情報を知る必要がある。
提案ノード側は、下位層にて下り信号の受信状況を検知することで通信遮断の検出が可能である。すなわち、受信信号電力が一定時間所定の閾値以下であるときに通信遮断と認識し、その後受信信号電力が所定の閾値を超えて大きくなったときに、通信遮断から回復したと検出する。
例えば、提案ノード（１）に、下位層からＴＣＰ層に信号を伝えられるようなドライバ、もしくはミドルウェア等を導入し、レイヤ間（下位層・ＴＣＰ層間）通信を行う。
【００２５】
この仕組みによって知り得た通信遮断の終了は、提案ノード（１）で持っているだけでは役に立たない。そこで、通信相手先のＴＣＰにもそれを伝える必要があるので、提案ノード（１）側で、擬似的に重複したＡＣＫ（以下、重複ＡＣＫと呼ぶ。）を送信する機構を導入する。
本実施例で用いる、一般ノード（２）が再送を行うためには、タイムアウトが発生するか、重複ＡＣＫを３つ以上受けてFast retransmit（以下、FRTと呼ぶ。）状態になる必要がある。この実装により、通信遮断回復と同時に再送を開始させることができるようになる。
【００２６】
そこで、本発明では、再送を開始させるために提案ノード（１）側のＴＣＰ層では重複ＡＣＫを送信できるように変更するとともに、送信する重複ＡＣＫの元データとなる最新の送信したＡＣＫを各コネクションが保持しておくよう変更を加えることを特徴とする。
これらの変更を加えることで、速やかなデータの再送を受け取れないという上記問題を解決できるようになる。
【００２７】
もう１つの改善点として、ＳＡＣＫ再送の仕組みが有効に働くようにしなくてはならない。提案ノードがＳＡＣＫブロックを送信するためには、通信遮断終了後に再送ではない新しいパケットを受信し、到着パケットのシーケンス番号に欠けを生じさせなくてはならない。
しかし、ＳＡＣＫを用いた従来の手法では、一般ノードのＴＣＰのバッファが一杯になり、新しいパケットを送出できなくなる問題がある。
【００２８】
本発明は、この点の解決方法として、通常状態時は、ａｗｎｄ(advertised receive window : 広告受信ウインドウ)を実際のバッファサイズより小さく広告すると共に、通信遮断からの回復時のみに、実バッファサイズに基づいたａｗｎｄ値を広告するように変更する。
ＴＣＰでは送信が可能かどうかの判断を２種のウインドウの大きさに基づいて行う。１つはｃｗｎｄ(congestion window : 輻輳ウインドウ)である。ｃｗｎｄは、自分の送信の様子を反映し、正常にＡＣＫが返ってきた時に大きく、再送が発生したときに値が小さく更新される。
もう１つがこのａｗｎｄであり、通常は受信側の空きバッファ量を示すことで送信側に過剰な送信を行わないように伝える役割を持つ。
【００２９】
送信側ＴＣＰは、この２つのウィンドウサイズのうちより条件の厳しい、すなわち値の小さいほうの条件に従って送信制御を行う。よって、送信側がバッファを一杯にしないためには、通常時にこのｃｗｎｄかａｗｎｄのいずれかを小さく設定しておき、通信遮断からの回復時に新しいパケットを送信できる余裕を残しておけばよい。
本発明では、既存のネットワークになるべく改変を加えずに済む構成をとるため、提案ノードで制御できるａｗｎｄサイズを小さく設定することで問題の解決を図る。以下、実バッファサイズに基づく従来の広告受信ウィンドウサイズをａｗｎｄ、本発明で小さく設定した時のサイズをａｗｎｄ'とする。
【００３０】
以上の３点の特徴を実現する、提案ノードの構成図を図２に示す。提案ノード（１）は、無線通信のアンテナ・送受信機能を有する無線通信アダプタ（２０）と、ＣＰＵ（２１）と、メモリ（２２）と、外部記憶装置（２３）とから構成され、ＣＰＵ（２１）によって、諸機能を実現する。本提案ノードは、一般に用いられるパーソナルコンピュータ等にプログラムすることでも実現可能である。
【００３１】
ＣＰＵ（２１）は、無線通信アダプタ（２０）から受信されたデータを処理するデータ受信部（２４）、正常に受信された場合にＡＣＫを送信するＡＣＫ送信部（２５）を備え、正常通信時は、データ受信部（２４）で受信されたデータはアプリケーション層（インターネットにおけるｆｔｐやｔｅｌｎｅｔなど）によって処理され、メモリ（２２）や、外部記憶装置（２３）、図示しない表示装置などに蓄積・表示される。
【００３２】
本提案ノード（１）は、同時に受信信号電力検知部（２６）を備え、受信中の信号電力を検知する。そして、データ受信部（２４）と連携或いは一体的に、信号電力が小さく、データが受信出来ない状態（信号遮断時）から、一定の閾値を超えてデータ受信が可能な状態に回復したときに、通信遮断回復検知部（２７）がこれを検知し、本発明による速やかな通信の回復を図る。
【００３３】
演算部（２８）では、上記に示した重複ＡＣＫの送信回数や、ａｗｎｄ・ａｗｎｄ'の適正な値を演算し、ＡＣＫ送信部（２５）から送信する。演算部（２８）の演算処理については、後述する。
以上の処理は、本発明の実施において最低限必要な処理であって、実施時に他の機能を設けることを妨げるものではない。また、データ受信部（２４）と受信信号電力測定部（２６）の構成は、機能的に分離して表示したものであり、同一の回路・プログラムによって実現することも可能である。
【００３４】
以上に示した通信方法における、提案ノード（１）と一般ノード（２）とのデータ送信の様子を図３に示す。
図中、正常通信時（３０）、通信遮断時（３１）、通信回復時（３２）である。正常通信時（３０）のＡＣＫ（３３）は、ａｗｎｄ'を広告する。そして、通信遮断（３１）が発生して、データの送受信が出来ない状態を経て、通信が回復した瞬間（３２ａ）に、通信遮断回復検知部（２７）によって回復を検知し、重複ＡＣＫ（３４）（３５）を送信する。ここでは、重複ＡＣＫ（３４）は４パケット必要であり、重複ＡＣＫ（３５）は演算部（２８）で必要と判断した数だけ数送信する。（図中では４パケットとして示す。）
【００３５】
そして、前者の重複ＡＣＫ（３４）ではａｗｎｄ'を広告し、後者（３５）では本来のサイズであるａｗｎｄを広告する。
これによって、前者（３４）によってFRT状態になり、最初の１パケット（３６）の再送が行われる。そして、合計８パケットの重複ＡＣＫを受信したために一般ノードのｃｗｎｄのサイズも大きくなって、新パケットが送信するのに十分な大きさであるが、ｃｗｎｄが大きくなってもａｗｎｄに変化がないと、ＡＣＫを受信せずに送信出来るデータの最大量がａｗｎｄの制限によって増えず、新パケットが送信できなかった。
【００３６】
これを回避するために、上記のように通常は過小にａｗｎｄ'と設定し、後者（３５）でａｗｎｄに一時的に増加させて広告する。これにより、新たに送信できるデータの最大量が増し、新パケット（３７）が送信できるようになる。
新パケット（３７）の受信後、提案ノード（１）側では正常に受信できなかったパケット（の番号）が判明するため、この情報をオプションフィールドに付加して送信（３８）する。
一般ノード（２）においてもこれで正常に受信できていないパケットを確定でき、以降、ＳＡＣＫ再送（３９）が可能となる。
【００３７】
以上に示したように、本発明によれば、提案ノードだけの変更で、FRTによる再送、FRCによる新しいパケットの送信、それを受けてのＳＡＣＫ再送が正しく機能していることが確認できる。
次に、上記重複ＡＣＫで送信する回数と、最適なａｗｎｄ'の設定について説述し、さらに好適な伝送効率の実現を図る。
【００３８】
まず、重複ＡＣＫの個数について検討する。通信遮断終了と同時に、提案ノード（１）側ＴＣＰ層(の各コネクション)は擬似ＡＣＫを複数送信する。この時、少なくとも４つの重複ＡＣＫを送ることで、送信側にFRTによる再送を行わせることができた。
４個よりさらに増やした場合、例えばＴＣＰ RenoではFRC状態になり、重複ＡＣＫが到着するごとにｃｗｎｄが1 MSS(maximum segment size : 最大セグメントサイズ)分だけ大きくなる。よって、送信する重複ＡＣＫを増やすことで新しいデータの送信を促すことが期待できる。通信遮断中にタイムアウトが発生した場合は、ｃｗｎｄが最小値(1MSS)に設定更新されているため特に有効である。
【００３９】
しかし、上述のように、重複ＡＣＫが一定数(Ｄmaxとする)を超えると
(式１)
ｃｗｎｄ＞ａｗｎｄ
となったところで送信できるデータの最大量はａｗｎｄの大きさに制限され、それ以上の重複ＡＣＫの送信は意味がない。
次に、Ｄmaxの求め方を示す。それには、ｃｗｎｄとssthresh(slow-start threshold : スロースタートと輻輳回避の閾値)の大きさの変化について考える必要がある。重複ＡＣＫを３つ受信し、FRT / FRC状態に入るとき、ssthreshは2MSSにセットされ、ｃｗｎｄはssthreshサイズに受信した重複ＡＣＫ数分のMSSを足した値となる。つまり、受信した重複ＡＣＫ数をＤとすると、
(式２)
ｃｗｎｄ＝（Ｄ＋２）ＭＳＳ
となる。ここで、(式１)より、
(式３)
（Ｄ＋２）ＭＳＳ＞ａｗｎｄ
【式４】
となる。このＤのうち取りうる最小の整数値が、有効な重複ＡＣＫの最大値Ｄ0となる。
【式５】
【００４０】
ただし、通信遮断回復時に重複ＡＣＫを送信した場合、はじめの一つが重複とはならない場合も考えられる。(例えば、コピーされていたＡＣＫが、本来の送信時に通信遮断され届かなかった場合などに起こる。) また、５個目の擬似ＡＣＫにて広告受信ウインドウサイズをａｗｎｄ' からａｗｎｄに更新するが、これはウインドウサイズの更新が起こった場合はそのＡＣＫは重複ＡＣＫには数えないからである。
よって、送信が有効である擬似ＡＣＫの送信数の最大値Ｄmaxは、有効な重複ＡＣＫの最大値＋２となるので、
【式６】
となる。
例えば、ＭＳＳが1,460 Bytesであり、ａｗｎｄサイズが65,536 Bytesとした場合、Ｄmaxは上式より４５と求めることができる。
【００４１】
次に、ａｗｎｄ'の最適値を求める。すべてのパケットを再送するためには、図３中のＳＡＣＫ再送を起こす必要がある。
ＳＡＣＫ再送では、ｃｗｎｄとｐｉｐｅというパラメータの比較し、ＳＡＣＫ再送が可能になったとき、
(式７)
ｃｗｎｄ＞ｐｉｐｅ
であれば、その差分だけデータを再送する。よって、この条件を満たすようにａｗｎｄ' 値を決めればよい。あらゆる条件で機能させるために、ｃｗｎｄが最小となる最も厳しい条件でも成立するａｗｎｄ' 値でなくてはならない。
【００４２】
まず、取りうる最小のｃｗｎｄ値を求める。通信遮断中に２回以上のＴＣＰのタイムアウトが発生した場合、slow startの発生によりｃｗｎｄは1MSS、ssthreshは2MSSに設定される。その後ssthresh値は変化せず、ＳＡＣＫ再送可能時、すなわち図３における２回目のFRT時（４０）にＳＡＣＫ - ＴＣＰの定義により、
(式８)
ｃｗｎｄ＝ssthresh
とされ、最小のｃｗｎｄは2MSSとなる。
【００４３】
同様に、ｐｉｐｅの取りうる最大値についても検討する。ｐｉｐｅとは、送信データのうち、ＡＣＫまたはＳＡＣＫにより受信確認されていない量を示す変数であり、
(式９)
pipe=HighData-HighAck-AmountSacked
と定義されている。HighDataとHighAckはそれぞれ、送信した最大シーケンス番号と、ＡＣＫを受け取った最大シーケンス番号であり、AmountSackedはＳＡＣＫ確認されたオクテット数である。以下、簡単のためセグメント数を元に概算する。
【００４４】
このｐｉｐｅ値は、ＳＡＣＫオプションを受け取っていて、FRT状態に入ったときに計算される。よって、送信側は前述の重複ＡＣＫによって送信ウインドウサイズ最大までパケットを送信しているので、
【式１０】
である。ここで、FRTに入るために４つのＳＡＣＫオプションつきのＡＣＫを受け取るため、最大で、AmountSackedは４となり、ｐｉｐｅの初期値pipeINITは
【式１１】
となる。その後、ＳＡＣＫブロックが届くたびにｐｉｐｅは減算されていき、ＳＡＣＫがｎ個届いたとき、
【式１２】
となる。
【００４５】
以上より得たｃｗｎｄとｐｉｐｅnから、
【式１３】
とおける。また、ｎ個のＳＡＣＫは、その前に重複ＡＣＫによって同じ個数の新しいパケットを送信することで得られる。新しいパケットは、ａｗｎｄとａｗｎｄ' の差により送信数が決まるので、結局、
【式１４】
とできる。ここで、ａｗｎｄとＭＳＳは環境によって既知なので、それを代入することでａｗｎｄ' を変数とする不等式になり、これを満たすようなａｗｎｄ' のうち最大サイズが最適値となる。
【００４６】
以上の諸式によって、本発明では、最適なａｗｎｄ'のサイズを決定することができるので、好適な通信方法を提供することができる。
本発明の効果を示す実験として、通信遮断からの早期回復が図れることを確認し、かつ通常時のａｗｎｄの過小広告によってどれだけ伝送能力が悪化するかを評価する評価実験を行った。
０．５秒間の通信遮断を行った場合の伝送の様子を図４に示す。ここで、上記の算出方法に基づき、通常時のａｗｎｄを50,000Bytes、回復時のａｗｎｄ'を実際のバッファサイズである、65,536Bytesとし、重複ＡＣＫは４５回とした。
【００４７】
結果から明らかなように、本発明の手法を用いた場合は長時間通信遮断（５０）が発生した場合にも、通信遮断終了と同時にパケットの送信が始まり（５１）、0.5秒程度で再送を終える（５２）とほぼ通信遮断前の伝送速度を取り戻せる（５３）ことが確認できる。
【００４８】
本発明が対象とする実施形態は、以上に限定されず、無線通信区間を含む様々なネットワークにおいて実施することができる。例えば、図１に示されるような提案ノードと、無線通信を実現するアンテナとの間にＬＡＮ等のネットワークが存在する場合に限らず、提案ノードとアンテナが一体化した構成でもよい。同様に、一般ノードとインターネット等の基幹ネットワークとの関係も任意に変更可能である。
【００４９】
【発明の効果】
本発明は、以上の構成を備えるので、次の効果を奏する。
すなわち、通信遮断による連続したパケットロスに対して、ごく短時間の遮断の場合と匹敵する速やかな通信の回復が可能であり、従来からの問題であった回復の遅延を解消することができる。
とくに、ミリ波帯を用いた通信において本発明によるパケット通信方法や提案ノードを用いると、高品質な回線で高速通信に途を開くとともに、ミリ波帯で問題となる通信遮断に対しても有効な対処法として提供することができる。
【００５０】
さらに、本発明の方法は、提案ノードの改良によって従来からの問題を解決することができるので、ネットワークの構成を変更することなく、高性能で低コストな通信方法を実現できる。
【図面の簡単な説明】
【図１】 本実施例における無線通信区間を含むネットワーク環境の説明図である。
【図２】 本発明に係る提案ノードの構成図である。
【図３】 本発明におけるパケットの流れを示す説明図である。
【図４】 本発明による０．５秒通信遮断時の伝送の様子を示す図である。
【符号の説明】
１ 提案ノード
２０ 無線通信アダプタ
２１ ＣＰＵ
２２ メモリ
２３ 外部記憶装置
２４ データ受信部
２５ ＡＣＫ送信部
２６ 受信信号電力検知部
２７ 通信遮断回復検知部
２８ 演算部
【発明の属する技術分野】
本発明は、ＴＣＰを用いた無線通信におけるパケット通信方法に関する。特に、通信遮断が生じた際に、高速に正常通信状態に回復できる手法を提案するものである。
【０００２】
【従来の技術】
近年の携帯電話やインターネットの普及に伴い、高速な無線通信技術の開発が急がれている。本件出願人らによっても、構内系や屋外系のシステムとして高速な無線アクセスシステムが開発されており、すでに１５６Ｍｂｐｓの伝送速度が実現されている。
【０００３】
しかし、無線通信では通信遮断により伝送速度が低下する場合があり、特にこれからの周波数資源として注目されるミリ波帯によるシステムでは、人体等によっても容易に遮蔽されてしまうため、遮蔽による切断を防ぐ技術だけではなく、切断した場合にその影響を最小限にとどめることが必要である。
インターネットでも用いられるＴＣＰは、完璧な誤り制御とフロー制御を行うため、遮断によるパケットロスが発生した場合、遮断からの回復後に再送を行う。
【０００４】
従来のＴＣＰの再送では、パケットロスが輻輳により発生するという前提であるために、遮断時に起こりやすい複数の連続したパケットロスに対しては、再送に長い時間を要することが多い。この結果、遮断時間に比べて著しく長い時間、ＴＣＰによる通信が不能になってしまう問題があった。
【０００５】
この対処としては、無線環境に対応したＴＣＰに関する研究があり、例えば参考文献１に挙げるｓｎｏｏｐプロトコルでは、基地局にエージェントを配してコネクションを監視し、無線端末が再送要求を出したときにエージェントが吸収・代理応答することで、再送動作による伝送速度低下を防ぐ方法が提案されている。
【０００６】
【参考文献１】
H.Balakrishnan, S.Seehan, and R.H.Katz,
"Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks", ACM Wireless Networks 1(4), 1995年12月
【０００７】
しかし、このような従来の方法では、通信遮断における一定時間以上継続しておこるエラーに対して有効に対応できていない。また、エージェントを設けたり、サーバー側とクライアント側とを共に変更したりする構成は、汎用性に乏しく、コスト高を招くことになる。
従来の技術では、これらの問題点を解決する有効な方法が提供されておらず、上述した高速な無線通信技術における障害となっていた。
【０００８】
【発明が解決しようとする課題】
本発明は、上記従来技術の有する問題点に鑑みて創出されたものであり、その目的は、通信遮断による連続したパケットロスに対して、遮断からの回復後、すみやかに通信が再開できると共に、既存のシステムに大きな変更を加えず、簡易な構成で低コスト化に寄与するパケット通信方法及び提案ノードを提供することである。
【０００９】
【課題を解決するための手段】
上記課題の解決を図るため、本発明では次のようなパケット通信方法を提供する。本パケット通信方法は、少なくとも一部に無線通信区間を有するネットワークにおいて用いられるものである。
本発明におけるパケット通信方法は、一般ノードと、提案ノードとの間でＴＣＰを用いた通信中に通信遮断によるパケットロスが生じた後、通信遮断から回復したときに、提案ノードが、擬似的に重複した確認応答を複数送信する。このとき、プロトコルスタックにおけるＴＣＰ層では、疑似重複確認応答を送るために、各コネクションが最後に送信した確認応答を記憶しておく。
【００１０】
提案ノードが、重複した確認応答にて、一般ノードに広告する広告受信ウィンドウサイズを増加させて一般ノードに送信する。
一般ノードは、重複した確認応答を複数受信した場合に、該確認応答に基づいて、一般ノードが提案ノードに向けて該増加分に対応する新パケットを送信する。
【００１１】
正常通信時には、広告受信ウィンドウサイズを過小に広告する一方、通信遮断から回復した時に広告受信ウィンドウサイズとして実際の受信バッファ値を広告する構成でもよい。
【００１２】
本発明においては、上述のように擬似的に重複して確認応答を送信するが、その送信回数は次の式によって求めることもできる。
Ｄ＝ｃｅｉｌ（ａｗｎｄ／ＭＳＳ）
ここで、一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、最大セグメントサイズをＭＳＳとしている。
確認応答は重複数を大きくすることで新しいデータの送信を促すことができるが、一定数を超えると意味をなさない。上記はすみやかなデータの再送を促し、かつ有効に作用する確認応答の送信回数である。
【００１３】
前記パケット通信方法において、正常通信時に広告受信ウィンドウサイズを過小に広告する際、サイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、過小に広告する広告受信ウィンドウサイズをａｗｎｄ'、最大セグメントサイズをＭＳＳとしたとき、
２＞ａｗｎｄ／ＭＳＳ＋（６−ｎ（ｎ＋１）／２）と、
ｎ＝（ａｗｎｄ−ａｗｎｄ'）／ＭＳＳと
の２式を共に満たすａｗｎｄ'を算出し、その最大値を広告することにより、正常通信時に最適な広告受信ウィンドウサイズを得ることもできる。
【００１４】
また、本発明は次のような提案ノードを提供することも出来る。
すなわち、ＴＣＰを用いて無線通信を行う提案ノードであって、下り信号の信号電力を検知し所定の閾値を超えたのを確認することで通信遮断から回復したことを検知する通信回復検知手段と、擬似的に重複した確認応答を送信する疑似重複信号送信手段と、一般ノードに広告する広告受信ウィンドウサイズを変化させ、一般ノードに送信するサイズ適応広告手段とを備える。
【００１５】
そして、正常通信時には、広告受信ウィンドウサイズを過小に広告する一方、通信遮断が生じた場合、通信遮断状態からの通信回復を通信回復検知手段が検知し、前記疑似重複信号送信手段による確認応答の送信後、前記サイズ増加広告手段が、広告受信ウィンドウサイズを実際の受信バッファ値に増加して一般ノードに送信することを特徴とする。
【００１６】
前記提案ノードが、一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、最大セグメントサイズをＭＳＳとしたとき、
Ｄ＝ｃｅｉｌ（ａｗｎｄ／ＭＳＳ）
によって計算されるＤ回重複した確認応答を、擬似的に重複して送信する構成でもよい。
【００１７】
正常通信時に広告受信ウィンドウサイズを過小に広告する際、一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、過小に広告する広告受信ウィンドウサイズをａｗｎｄ'、最大セグメントサイズをＭＳＳとしたとき、次の２式を共に満たすａｗｎｄ'を求めてもよい。
２＞ａｗｎｄ／ＭＳＳ＋（６−ｎ（ｎ＋１）／２）
ｎ＝（ａｗｎｄ−ａｗｎｄ'）／ＭＳＳ
そして、ａｗｎｄ'の最大値を広告することにより、正常通信時に最適な広告受信ウィンドウサイズを得ることもできる。
【００１８】
【発明の実施の形態】
以下、本発明の実施方法を図面に示した実施例に基づいて説明する。なお、本発明の実施形態は以下に限定されず、適宜変更可能である。
無線通信チャネルの状態は常に変動し、場合によっては一時的な切断（以下、通信遮断）も発生する。通信の高速化に伴い、一瞬の通信遮断が通信パフォーマンスに与える影響も大きくなっている。特に上位層がＴＣＰの場合には、通信遮断によって大きくパフォーマンスが低下することが問題となっている。
本発明は、このような通信遮断後に、速やかに通信性能が回復するパケット通信方法を提供するものである。
【００１９】
通信遮断の要因としては、ハンドオーバやシャドウイングなどが考えられる。特に5GHz帯無線LAN、22/26/38GHz帯の加入者系無線アクセス(FWA)、60GHz帯等の各種無線通信システムなどのような高周波利用システムでは、通常はスポットサービスが中心となるが、将来は既存セルラーのように複数セルによる移動通信をサポートしたいという要求もある。その場合にはハンドオーバが必要となるが、従来のような計画的なセル配置は困難であり、ハンドオーバ時に瞬間的な遮断が生じることが考えられる。
一方のシャドウイングは、主に高周波帯の電波伝播の直進性に起因する問題である。特にミリ波帯では顕著であり、オフィス環境での実験によると、平均遮断継続時間は０．３秒、平均遮蔽発生間隔は１０分程度との結果が得られている。
【００２０】
このように、無線通信において物理層レベルの遮断が問題となるが、この遮断が上位のＴＣＰ層に大きな影響を与えることが明らかになってきた。ＴＣＰはインターネットでもっともよく使われているトランスポートプロトコルであり、ネットワーク帯域を公平に共有するためのスロースタート・輻輳制御と、輻輳時のルータでのバッファ溢れによるパケットロスを補償するための再送制御に特徴がある。
伝送エラーの少ない有線ネットワークを前提に設計されているＴＣＰは、パケットロス＝輻輳と判断し、パケット送出レートを低下させて輻輳回避を試みる。
【００２１】
しかしながら、無線伝送エラーによるパケットロスが発生するネットワーク上でＴＣＰを利用すると、この輻輳回避アルゴリズムがスループットを大きく低下させてしまう。すなわち、いくつかのパケットロスが発生した直後に回線が元の良好な状態に回復したにも拘らず、輻輳と認識したＴＣＰが輻輳回避のためにしばらくの間パケット送出レートを下げてしまうことにより、スループットが低下してしまう。これが高周波無線通信時に起こるＴＣＰの問題点である。
【００２２】
特に、送信側のバッファが一杯になるような通信遮断が発生したときには、fast recovery（以下、FRCと呼ぶ。）やSelective Acknowledgement（以下、ＳＡＣＫと呼ぶ。）といった現状の再送対策の手法は機能しない。
これらの機能は、受信側からの確認応答（本実施例では、ＡＣＫとする。）が引き金としてアクションを起こすため、通信遮断時にはそのＡＣＫも到達しないために再送ができず、かつ新たなデータも送れないという、２つの問題が生じる。
【００２３】
ＴＣＰは送受両方で協調動作することで信頼性の高いデータ転送を実現しているために、一定時間接続が途切れたりバースト的なエラーが発生した場合、どちらかが何らかの送信を行わない限りタイムアウトを待つしかないというところに大きな問題がある。
従来の対策としては、有線サーバー側も含めて、ＴＣＰプロトコルを全て無線対応型に改めるという試みもあるが、インターネット上の全てのサーバーに変更を強いるのは現実性がなく、限られたネットワークで実施するとしてもコスト高、汎用性の乏しさが問題である。
そこで、本発明は、無線区間はいわゆるファーストホップ／ラストホップとして使用され、有線で構成された基幹部分(インターネットなど)を介し、他ノードと通信する図１に示すネットワーク環境を例に、上記問題点の解決を図るものである。
【００２４】
通信遮断が発生した場合、提案ノード（１）がデータの受信を行っている場合は通信遮断が終わると同時に受信を再開できるのが望ましいが、図示のような環境では一般ノード（２）は無線区間（３）の通信遮断を知るすべが無いため、即座に再送のデータが送ることはない。
これに対する有効な方法として、通信遮断から回復した時に、下位層がＴＣＰ層に信号を送るという手法を導入する。通信遮断終了時に早期の伝送速度の回復を図るためには、ＴＣＰ層が通信遮断に関する情報を知る必要がある。
提案ノード側は、下位層にて下り信号の受信状況を検知することで通信遮断の検出が可能である。すなわち、受信信号電力が一定時間所定の閾値以下であるときに通信遮断と認識し、その後受信信号電力が所定の閾値を超えて大きくなったときに、通信遮断から回復したと検出する。
例えば、提案ノード（１）に、下位層からＴＣＰ層に信号を伝えられるようなドライバ、もしくはミドルウェア等を導入し、レイヤ間（下位層・ＴＣＰ層間）通信を行う。
【００２５】
この仕組みによって知り得た通信遮断の終了は、提案ノード（１）で持っているだけでは役に立たない。そこで、通信相手先のＴＣＰにもそれを伝える必要があるので、提案ノード（１）側で、擬似的に重複したＡＣＫ（以下、重複ＡＣＫと呼ぶ。）を送信する機構を導入する。
本実施例で用いる、一般ノード（２）が再送を行うためには、タイムアウトが発生するか、重複ＡＣＫを３つ以上受けてFast retransmit（以下、FRTと呼ぶ。）状態になる必要がある。この実装により、通信遮断回復と同時に再送を開始させることができるようになる。
【００２６】
そこで、本発明では、再送を開始させるために提案ノード（１）側のＴＣＰ層では重複ＡＣＫを送信できるように変更するとともに、送信する重複ＡＣＫの元データとなる最新の送信したＡＣＫを各コネクションが保持しておくよう変更を加えることを特徴とする。
これらの変更を加えることで、速やかなデータの再送を受け取れないという上記問題を解決できるようになる。
【００２７】
もう１つの改善点として、ＳＡＣＫ再送の仕組みが有効に働くようにしなくてはならない。提案ノードがＳＡＣＫブロックを送信するためには、通信遮断終了後に再送ではない新しいパケットを受信し、到着パケットのシーケンス番号に欠けを生じさせなくてはならない。
しかし、ＳＡＣＫを用いた従来の手法では、一般ノードのＴＣＰのバッファが一杯になり、新しいパケットを送出できなくなる問題がある。
【００２８】
本発明は、この点の解決方法として、通常状態時は、ａｗｎｄ(advertised receive window : 広告受信ウインドウ)を実際のバッファサイズより小さく広告すると共に、通信遮断からの回復時のみに、実バッファサイズに基づいたａｗｎｄ値を広告するように変更する。
ＴＣＰでは送信が可能かどうかの判断を２種のウインドウの大きさに基づいて行う。１つはｃｗｎｄ(congestion window : 輻輳ウインドウ)である。ｃｗｎｄは、自分の送信の様子を反映し、正常にＡＣＫが返ってきた時に大きく、再送が発生したときに値が小さく更新される。
もう１つがこのａｗｎｄであり、通常は受信側の空きバッファ量を示すことで送信側に過剰な送信を行わないように伝える役割を持つ。
【００２９】
送信側ＴＣＰは、この２つのウィンドウサイズのうちより条件の厳しい、すなわち値の小さいほうの条件に従って送信制御を行う。よって、送信側がバッファを一杯にしないためには、通常時にこのｃｗｎｄかａｗｎｄのいずれかを小さく設定しておき、通信遮断からの回復時に新しいパケットを送信できる余裕を残しておけばよい。
本発明では、既存のネットワークになるべく改変を加えずに済む構成をとるため、提案ノードで制御できるａｗｎｄサイズを小さく設定することで問題の解決を図る。以下、実バッファサイズに基づく従来の広告受信ウィンドウサイズをａｗｎｄ、本発明で小さく設定した時のサイズをａｗｎｄ'とする。
【００３０】
以上の３点の特徴を実現する、提案ノードの構成図を図２に示す。提案ノード（１）は、無線通信のアンテナ・送受信機能を有する無線通信アダプタ（２０）と、ＣＰＵ（２１）と、メモリ（２２）と、外部記憶装置（２３）とから構成され、ＣＰＵ（２１）によって、諸機能を実現する。本提案ノードは、一般に用いられるパーソナルコンピュータ等にプログラムすることでも実現可能である。
【００３１】
ＣＰＵ（２１）は、無線通信アダプタ（２０）から受信されたデータを処理するデータ受信部（２４）、正常に受信された場合にＡＣＫを送信するＡＣＫ送信部（２５）を備え、正常通信時は、データ受信部（２４）で受信されたデータはアプリケーション層（インターネットにおけるｆｔｐやｔｅｌｎｅｔなど）によって処理され、メモリ（２２）や、外部記憶装置（２３）、図示しない表示装置などに蓄積・表示される。
【００３２】
本提案ノード（１）は、同時に受信信号電力検知部（２６）を備え、受信中の信号電力を検知する。そして、データ受信部（２４）と連携或いは一体的に、信号電力が小さく、データが受信出来ない状態（信号遮断時）から、一定の閾値を超えてデータ受信が可能な状態に回復したときに、通信遮断回復検知部（２７）がこれを検知し、本発明による速やかな通信の回復を図る。
【００３３】
演算部（２８）では、上記に示した重複ＡＣＫの送信回数や、ａｗｎｄ・ａｗｎｄ'の適正な値を演算し、ＡＣＫ送信部（２５）から送信する。演算部（２８）の演算処理については、後述する。
以上の処理は、本発明の実施において最低限必要な処理であって、実施時に他の機能を設けることを妨げるものではない。また、データ受信部（２４）と受信信号電力測定部（２６）の構成は、機能的に分離して表示したものであり、同一の回路・プログラムによって実現することも可能である。
【００３４】
以上に示した通信方法における、提案ノード（１）と一般ノード（２）とのデータ送信の様子を図３に示す。
図中、正常通信時（３０）、通信遮断時（３１）、通信回復時（３２）である。正常通信時（３０）のＡＣＫ（３３）は、ａｗｎｄ'を広告する。そして、通信遮断（３１）が発生して、データの送受信が出来ない状態を経て、通信が回復した瞬間（３２ａ）に、通信遮断回復検知部（２７）によって回復を検知し、重複ＡＣＫ（３４）（３５）を送信する。ここでは、重複ＡＣＫ（３４）は４パケット必要であり、重複ＡＣＫ（３５）は演算部（２８）で必要と判断した数だけ数送信する。（図中では４パケットとして示す。）
【００３５】
そして、前者の重複ＡＣＫ（３４）ではａｗｎｄ'を広告し、後者（３５）では本来のサイズであるａｗｎｄを広告する。
これによって、前者（３４）によってFRT状態になり、最初の１パケット（３６）の再送が行われる。そして、合計８パケットの重複ＡＣＫを受信したために一般ノードのｃｗｎｄのサイズも大きくなって、新パケットが送信するのに十分な大きさであるが、ｃｗｎｄが大きくなってもａｗｎｄに変化がないと、ＡＣＫを受信せずに送信出来るデータの最大量がａｗｎｄの制限によって増えず、新パケットが送信できなかった。
【００３６】
これを回避するために、上記のように通常は過小にａｗｎｄ'と設定し、後者（３５）でａｗｎｄに一時的に増加させて広告する。これにより、新たに送信できるデータの最大量が増し、新パケット（３７）が送信できるようになる。
新パケット（３７）の受信後、提案ノード（１）側では正常に受信できなかったパケット（の番号）が判明するため、この情報をオプションフィールドに付加して送信（３８）する。
一般ノード（２）においてもこれで正常に受信できていないパケットを確定でき、以降、ＳＡＣＫ再送（３９）が可能となる。
【００３７】
以上に示したように、本発明によれば、提案ノードだけの変更で、FRTによる再送、FRCによる新しいパケットの送信、それを受けてのＳＡＣＫ再送が正しく機能していることが確認できる。
次に、上記重複ＡＣＫで送信する回数と、最適なａｗｎｄ'の設定について説述し、さらに好適な伝送効率の実現を図る。
【００３８】
まず、重複ＡＣＫの個数について検討する。通信遮断終了と同時に、提案ノード（１）側ＴＣＰ層(の各コネクション)は擬似ＡＣＫを複数送信する。この時、少なくとも４つの重複ＡＣＫを送ることで、送信側にFRTによる再送を行わせることができた。
４個よりさらに増やした場合、例えばＴＣＰ RenoではFRC状態になり、重複ＡＣＫが到着するごとにｃｗｎｄが1 MSS(maximum segment size : 最大セグメントサイズ)分だけ大きくなる。よって、送信する重複ＡＣＫを増やすことで新しいデータの送信を促すことが期待できる。通信遮断中にタイムアウトが発生した場合は、ｃｗｎｄが最小値(1MSS)に設定更新されているため特に有効である。
【００３９】
しかし、上述のように、重複ＡＣＫが一定数(Ｄmaxとする)を超えると
(式１)
ｃｗｎｄ＞ａｗｎｄ
となったところで送信できるデータの最大量はａｗｎｄの大きさに制限され、それ以上の重複ＡＣＫの送信は意味がない。
次に、Ｄmaxの求め方を示す。それには、ｃｗｎｄとssthresh(slow-start threshold : スロースタートと輻輳回避の閾値)の大きさの変化について考える必要がある。重複ＡＣＫを３つ受信し、FRT / FRC状態に入るとき、ssthreshは2MSSにセットされ、ｃｗｎｄはssthreshサイズに受信した重複ＡＣＫ数分のMSSを足した値となる。つまり、受信した重複ＡＣＫ数をＤとすると、
(式２)
ｃｗｎｄ＝（Ｄ＋２）ＭＳＳ
となる。ここで、(式１)より、
(式３)
（Ｄ＋２）ＭＳＳ＞ａｗｎｄ
【式４】
【式５】
ただし、通信遮断回復時に重複ＡＣＫを送信した場合、はじめの一つが重複とはならない場合も考えられる。(例えば、コピーされていたＡＣＫが、本来の送信時に通信遮断され届かなかった場合などに起こる。) また、５個目の擬似ＡＣＫにて広告受信ウインドウサイズをａｗｎｄ' からａｗｎｄに更新するが、これはウインドウサイズの更新が起こった場合はそのＡＣＫは重複ＡＣＫには数えないからである。
よって、送信が有効である擬似ＡＣＫの送信数の最大値Ｄmaxは、有効な重複ＡＣＫの最大値＋２となるので、
【式６】
例えば、ＭＳＳが1,460 Bytesであり、ａｗｎｄサイズが65,536 Bytesとした場合、Ｄmaxは上式より４５と求めることができる。
【００４１】
次に、ａｗｎｄ'の最適値を求める。すべてのパケットを再送するためには、図３中のＳＡＣＫ再送を起こす必要がある。
ＳＡＣＫ再送では、ｃｗｎｄとｐｉｐｅというパラメータの比較し、ＳＡＣＫ再送が可能になったとき、
(式７)
ｃｗｎｄ＞ｐｉｐｅ
であれば、その差分だけデータを再送する。よって、この条件を満たすようにａｗｎｄ' 値を決めればよい。あらゆる条件で機能させるために、ｃｗｎｄが最小となる最も厳しい条件でも成立するａｗｎｄ' 値でなくてはならない。
【００４２】
まず、取りうる最小のｃｗｎｄ値を求める。通信遮断中に２回以上のＴＣＰのタイムアウトが発生した場合、slow startの発生によりｃｗｎｄは1MSS、ssthreshは2MSSに設定される。その後ssthresh値は変化せず、ＳＡＣＫ再送可能時、すなわち図３における２回目のFRT時（４０）にＳＡＣＫ - ＴＣＰの定義により、
(式８)
ｃｗｎｄ＝ssthresh
とされ、最小のｃｗｎｄは2MSSとなる。
【００４３】
同様に、ｐｉｐｅの取りうる最大値についても検討する。ｐｉｐｅとは、送信データのうち、ＡＣＫまたはＳＡＣＫにより受信確認されていない量を示す変数であり、
(式９)
pipe=HighData-HighAck-AmountSacked
と定義されている。HighDataとHighAckはそれぞれ、送信した最大シーケンス番号と、ＡＣＫを受け取った最大シーケンス番号であり、AmountSackedはＳＡＣＫ確認されたオクテット数である。以下、簡単のためセグメント数を元に概算する。
【００４４】
このｐｉｐｅ値は、ＳＡＣＫオプションを受け取っていて、FRT状態に入ったときに計算される。よって、送信側は前述の重複ＡＣＫによって送信ウインドウサイズ最大までパケットを送信しているので、
【式１０】
【式１１】
【式１２】
【００４５】
以上より得たｃｗｎｄとｐｉｐｅnから、
【式１３】
【式１４】
【００４６】
以上の諸式によって、本発明では、最適なａｗｎｄ'のサイズを決定することができるので、好適な通信方法を提供することができる。
本発明の効果を示す実験として、通信遮断からの早期回復が図れることを確認し、かつ通常時のａｗｎｄの過小広告によってどれだけ伝送能力が悪化するかを評価する評価実験を行った。
０．５秒間の通信遮断を行った場合の伝送の様子を図４に示す。ここで、上記の算出方法に基づき、通常時のａｗｎｄを50,000Bytes、回復時のａｗｎｄ'を実際のバッファサイズである、65,536Bytesとし、重複ＡＣＫは４５回とした。
【００４７】
結果から明らかなように、本発明の手法を用いた場合は長時間通信遮断（５０）が発生した場合にも、通信遮断終了と同時にパケットの送信が始まり（５１）、0.5秒程度で再送を終える（５２）とほぼ通信遮断前の伝送速度を取り戻せる（５３）ことが確認できる。
【００４８】
本発明が対象とする実施形態は、以上に限定されず、無線通信区間を含む様々なネットワークにおいて実施することができる。例えば、図１に示されるような提案ノードと、無線通信を実現するアンテナとの間にＬＡＮ等のネットワークが存在する場合に限らず、提案ノードとアンテナが一体化した構成でもよい。同様に、一般ノードとインターネット等の基幹ネットワークとの関係も任意に変更可能である。
【００４９】
【発明の効果】
本発明は、以上の構成を備えるので、次の効果を奏する。
すなわち、通信遮断による連続したパケットロスに対して、ごく短時間の遮断の場合と匹敵する速やかな通信の回復が可能であり、従来からの問題であった回復の遅延を解消することができる。
とくに、ミリ波帯を用いた通信において本発明によるパケット通信方法や提案ノードを用いると、高品質な回線で高速通信に途を開くとともに、ミリ波帯で問題となる通信遮断に対しても有効な対処法として提供することができる。
【００５０】
さらに、本発明の方法は、提案ノードの改良によって従来からの問題を解決することができるので、ネットワークの構成を変更することなく、高性能で低コストな通信方法を実現できる。
【図面の簡単な説明】
【図１】 本実施例における無線通信区間を含むネットワーク環境の説明図である。
【図２】 本発明に係る提案ノードの構成図である。
【図３】 本発明におけるパケットの流れを示す説明図である。
【図４】 本発明による０．５秒通信遮断時の伝送の様子を示す図である。
【符号の説明】
１ 提案ノード
２０ 無線通信アダプタ
２１ ＣＰＵ
２２ メモリ
２３ 外部記憶装置
２４ データ受信部
２５ ＡＣＫ送信部
２６ 受信信号電力検知部
２７ 通信遮断回復検知部
２８ 演算部
Claims (8)
- 少なくとも一部に無線通信区間を有するネットワークにおけるパケット通信方法であって、
ＴＣＰを用いて無線通信を行う提案ノードと、ネットワーク上に存在する標準的なＴＣＰ通信が可能な機器である一般ノードとの間で通信中に通信遮断によるパケットロスが生じた後、
該提案ノードが通信遮断の回復を検出する回復検出ステップと共に、
通信遮断から回復したときに、提案ノードが、擬似的に重複した確認応答を送信する通知ステップ、
一般ノードが重複した確認応答を複数受信した場合に、該確認応答に基づいてパケットを再送するステップ、
の各ステップを含む通信再開ステップと
から構成されることを特徴とするパケット通信方法。 - 前記通信再開ステップが、前記各ステップの後に、
提案ノードが、一般ノードに広告する広告受信ウィンドウサイズを増加させて一般ノードに送信するステップ、
一般ノードが提案ノードに向けて該増加分に対応する新パケットを送信するステップ
の各ステップを含むことを特徴とする請求項１に記載のパケット通信方法。 - 前記パケット通信方法において、
正常通信時には、広告受信ウィンドウサイズを過小に広告する一方、
通信遮断から回復した時に広告受信ウィンドウサイズとして実際の受信バッファ値を広告する
請求項１又は２に記載のパケット通信方法。 - 前記パケット通信方法において、
前記提案ノードが、前記一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、最大セグメントサイズをＭＳＳとしたとき、該提案ノードが擬似的に
Ｄ＝ｃｅｉｌ（ａｗｎｄ／ＭＳＳ）
によって計算されるＤ回重複した確認応答送信する
請求項１ないし３に記載のパケット通信方法。 - 前記パケット通信方法において、
正常通信時に広告受信ウィンドウサイズを過小に広告する際、
前記一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、過小に広告する広告受信ウィンドウサイズをａｗｎｄ'、最大セグメントサイズをＭＳＳとしたとき、
２＞ａｗｎｄ／ＭＳＳ＋（６−ｎ（ｎ＋１）／２）と、
ｎ＝（ａｗｎｄ−ａｗｎｄ'）／ＭＳＳと
の２式を共に満たすａｗｎｄ'を算出し、その最大値を広告する
請求項１ないし４に記載のパケット通信方法。 - ＴＣＰを用いて無線通信を行う提案ノードであって、
下り信号の信号電力を検知し所定の閾値を超えたのを確認することで通信遮断から回復したことを検知する通信回復検知手段と、
擬似的に重複した確認応答を送信する疑似重複信号送信手段と、
一般ノードに広告する広告受信ウィンドウサイズを変化させ、一般ノードに送信するサイズ適応広告手段と
を備え、
正常通信時には、広告受信ウィンドウサイズを過小に広告する一方、
通信遮断状態からの通信回復を通信回復検知手段が検知し、
前記疑似重複信号送信手段による確認応答の送信後、
前記サイズ増加広告手段が、
広告受信ウィンドウサイズを実際の受信バッファ値に増加して一般ノードに送信する
ことを特徴とする提案ノード。 - 前記提案ノードが、
一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、最大セグメントサイズをＭＳＳとしたとき、
Ｄ＝ｃｅｉｌ（ａｗｎｄ／ＭＳＳ）
によって計算されるＤ回重複した確認応答を、擬似的に重複して送信する
請求項６に記載の提案ノード。 - 前記提案ノードが、
正常通信時に広告受信ウィンドウサイズを過小に広告する際、
一般ノードに広告する広告受信ウィンドウサイズを増加させた後の広告受信ウィンドウサイズをａｗｎｄ、過小に広告する広告受信ウィンドウサイズをａｗｎｄ'、最大セグメントサイズをＭＳＳとしたとき、
２＞ａｗｎｄ／ＭＳＳ＋６−ｎ（ｎ＋１）／２と、
ｎ＝（ａｗｎｄ−ａｗｎｄ'）／ＭＳＳと
の２式を共に満たすａｗｎｄ'を算出し、その最大値を広告する
請求項６又は７に記載の提案ノード。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001356498A JP3637389B2 (ja) | 2001-11-21 | 2001-11-21 | パケット通信方法及び提案ノード |
| CA 2387289 CA2387289C (en) | 2001-11-21 | 2002-05-23 | Packet communication method and proposal node |
| US10/153,799 US7177300B2 (en) | 2001-11-21 | 2002-05-24 | Packet communication method and proposal node |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001356498A JP3637389B2 (ja) | 2001-11-21 | 2001-11-21 | パケット通信方法及び提案ノード |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003158558A JP2003158558A (ja) | 2003-05-30 |
| JP3637389B2 true JP3637389B2 (ja) | 2005-04-13 |
Family
ID=19168008
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001356498A Expired - Lifetime JP3637389B2 (ja) | 2001-11-21 | 2001-11-21 | パケット通信方法及び提案ノード |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7177300B2 (ja) |
| JP (1) | JP3637389B2 (ja) |
| CA (1) | CA2387289C (ja) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7061856B2 (en) * | 2001-02-05 | 2006-06-13 | The Board Of Trustees Of The Leland Stanford Junior University | Data throughput over lossy communication links |
| US7313121B2 (en) | 2003-05-09 | 2007-12-25 | Conexant, Inc. | Acknowledging data transmissions in the presence of multiple shared-communications channels |
| DE10339497A1 (de) * | 2003-08-27 | 2005-03-31 | Siemens Ag | Verfahren zur Übertragung von Daten in einem Datennetz |
| JP2005151007A (ja) * | 2003-11-13 | 2005-06-09 | Matsushita Electric Ind Co Ltd | 無線伝送方法とそれに用いる送信装置および受信装置 |
| JP4639603B2 (ja) * | 2004-02-24 | 2011-02-23 | パナソニック株式会社 | 無線伝送装置および無線伝送装置の省電力駆動方法 |
| CN104301079A (zh) * | 2004-12-22 | 2015-01-21 | 艾利森电话股份有限公司 | 使用重复确认的数据流控制 |
| DE602004017526D1 (de) | 2004-12-22 | 2008-12-11 | Ericsson Telefon Ab L M | Datenflusssteuerung mit doppelter quittierung |
| US7889654B2 (en) | 2005-03-30 | 2011-02-15 | At&T Intellectual Property Ii, L.P. | Loss tolerant transmission control protocol |
| US7366132B2 (en) * | 2005-03-30 | 2008-04-29 | At&T Corp. | Loss tolerant transmission control protocol |
| JP2008099171A (ja) * | 2006-10-16 | 2008-04-24 | Nec Infrontia Corp | 無線データ通信装置 |
| KR100842281B1 (ko) * | 2006-12-08 | 2008-06-30 | 한국전자통신연구원 | 무선 네트워크상에서 경로 회복 알림을 통하여 전송 제어 프로토콜의 성능을 관리하는 장치 및 그 방법 |
| DE102007011071B4 (de) * | 2007-03-07 | 2009-06-18 | T-Mobile Internationale Ag | Verfahren zur Verbesserung eines TCP Datenübertragungsprozesses im Fall einer Unterbrechung des physikalischen Übertragungsmediums |
| JP5146693B2 (ja) | 2007-03-08 | 2013-02-20 | 日本電気株式会社 | 擬似的応答フレーム通信システム、擬似的応答フレーム通信方法及び擬似的応答フレーム送信装置 |
| JP5014879B2 (ja) * | 2007-05-21 | 2012-08-29 | 株式会社エヌ・ティ・ティ・ドコモ | 移動通信端末、移動通信システム及び移動通信方法 |
| US7821937B1 (en) * | 2007-06-29 | 2010-10-26 | Symantec Corporation | Network protocol with damage loss resilient congestion control algorithm |
| JP4623087B2 (ja) * | 2007-11-30 | 2011-02-02 | 日本電気株式会社 | パケット通信装置及びパケット通信方法及びパケット通信プログラム |
| BRPI0822703A2 (pt) * | 2008-05-15 | 2015-07-07 | Ressource Österreich Gmbh E | Conjunto adaptador para lâmpadas fluorescentes para remanejamento para tubos fluorescentes com evg (reator eletrônico). |
| US8406126B1 (en) * | 2010-08-31 | 2013-03-26 | Siklu Communication ltd. | Ring-like communication architecture |
| US10027508B2 (en) | 2010-08-31 | 2018-07-17 | Siklu Communication ltd. | Extended ring-like communication architecture |
| US9398103B2 (en) | 2011-04-15 | 2016-07-19 | Qualcomm Incorporated | Methods and apparatus for enhancing device performance through flow control |
| JP5801175B2 (ja) | 2011-12-16 | 2015-10-28 | 株式会社日立製作所 | パケット通信装置および方法 |
| US9451497B2 (en) | 2012-08-13 | 2016-09-20 | Apple Inc. | Reducing packet loss at a wireless communication device due to a connection interruption |
| JP6409558B2 (ja) * | 2014-12-19 | 2018-10-24 | 富士通株式会社 | 通信装置、中継装置、および、通信制御方法 |
| CN108307384A (zh) * | 2016-08-18 | 2018-07-20 | 百度在线网络技术（北京）有限公司 | 一种信息展现方法和装置 |
| CN115426317B (zh) * | 2022-11-03 | 2023-03-24 | 新华三信息技术有限公司 | 数据传输速率控制方法、装置及电子设备 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07312610A (ja) | 1994-05-18 | 1995-11-28 | Oki Electric Ind Co Ltd | 無線通信制御システム |
| US5963551A (en) * | 1996-09-30 | 1999-10-05 | Innomedia Pte Ltd. | System and method for dynamically reconfigurable packet transmission |
| JP2853701B2 (ja) * | 1997-03-18 | 1999-02-03 | 日本電気株式会社 | Ａｔｍ網における端末間フロー制御方法 |
| SE519523C2 (sv) | 1998-06-30 | 2003-03-11 | Ericsson Telefon Ab L M | Mobilt LAN där värddatorer anslutna till LANet kan genomföra paketdatakommunikation med värddatorer i externa nät |
| JP3003095B1 (ja) | 1998-10-22 | 2000-01-24 | 株式会社超高速ネットワーク・コンピュータ技術研究所 | フロー制御方法 |
| US6611495B1 (en) * | 1999-02-22 | 2003-08-26 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for improved data transfer in packet-switched communication networks |
| JP2000253447A (ja) | 1999-02-26 | 2000-09-14 | Nec Commun Syst Ltd | 電波品質劣化による呼切断発生時の端末呼出抑制方式及び端末呼出抑制方法 |
| US6208620B1 (en) * | 1999-08-02 | 2001-03-27 | Nortel Networks Corporation | TCP-aware agent sublayer (TAS) for robust TCP over wireless |
| US6687227B1 (en) * | 2000-03-13 | 2004-02-03 | Nortel Networks Limited | Systems and methods for requesting packets for transmission over a wirless channel having a dynamically changing capacity due to a highly varibale delay |
| US6687846B1 (en) * | 2000-03-30 | 2004-02-03 | Intel Corporation | System and method for error handling and recovery |
| US6757248B1 (en) * | 2000-06-14 | 2004-06-29 | Nokia Internet Communications Inc. | Performance enhancement of transmission control protocol (TCP) for wireless network applications |
| US6772334B1 (en) * | 2000-08-31 | 2004-08-03 | Networks Associates, Inc. | System and method for preventing a spoofed denial of service attack in a networked computing environment |
| US20030022628A1 (en) * | 2001-01-09 | 2003-01-30 | Chiyo Mamiya | Data communication system and wireless communication device |
| US6934257B2 (en) * | 2001-04-04 | 2005-08-23 | Intel Corporation | Transferring transmission control protocol packets |
| WO2002096021A2 (en) * | 2001-05-18 | 2002-11-28 | Bytemobile, Inc. | Quality of service management for multiple connections within a network communication system |
| US7089312B2 (en) * | 2001-09-20 | 2006-08-08 | Intel Corporation | System and method for reducing retransmissions due to tunneled TCP-in-TCP communication in a network |
-
2001
- 2001-11-21 JP JP2001356498A patent/JP3637389B2/ja not_active Expired - Lifetime
-
2002
- 2002-05-23 CA CA 2387289 patent/CA2387289C/en not_active Expired - Fee Related
- 2002-05-24 US US10/153,799 patent/US7177300B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2387289A1 (en) | 2003-05-21 |
| US20030095537A1 (en) | 2003-05-22 |
| JP2003158558A (ja) | 2003-05-30 |
| CA2387289C (en) | 2010-12-21 |
| US7177300B2 (en) | 2007-02-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3637389B2 (ja) | パケット通信方法及び提案ノード | |
| EP2296313B1 (en) | Control method and device for wireless multi-hopping network congestion | |
| EP1841118B1 (en) | Communication terminal and retransmission control method | |
| US7460472B2 (en) | System and method for transmitting information in a communication network | |
| US20050088972A1 (en) | Method, system and device for controlling a transmission window size | |
| US9456377B2 (en) | System and method for transmission control protocol service delivery in wireless communications systems | |
| US7593338B2 (en) | Congestion control method and system for reducing a retransmission timeout count in a transmission control protocol | |
| WO2010108144A1 (en) | Systems and methods for improved wireless interface aggregation | |
| EP1798913B1 (en) | Transport control method in wireless communication system | |
| Cheng et al. | A cross-layer design for TCP end-to-end performance improvement in multi-hop wireless networks | |
| Dalal et al. | Improving TCP performance over wireless network with frequent disconnections | |
| EP1278348A1 (en) | Long-lived TCP connection using ICMP messages in wireless mobile communications | |
| Dalal et al. | Link layer correction techniques and impact on TCP’s performance in IEEE 802.11 wireless networks | |
| Song et al. | Rate-control snoop: a reliable transport protocol for heterogeneous networks with wired and wireless links | |
| CN110912831B (zh) | Tcp传输方法、装置及存储介质 | |
| Khurshid et al. | Modified TCP newreno for wireless networks | |
| Filali | Link-layer fragmentation and retransmission impact on TCP Performance in 802.11-based networks | |
| KR100913897B1 (ko) | 재전송 타임아웃 수를 줄이기 위한 전송 제어 프로토콜혼잡제어방법 | |
| Rani et al. | Cross layer based schemes for improving the performance of TCP in wireless networks | |
| WO2019193448A1 (en) | Method and apparatus for multi‑hop arq | |
| Chim et al. | End-To-End acknowledgments for indirect TCP over wireless internetworks | |
| Chawhan et al. | TCP performance enhancement using ECN and snoop protocol for Wi-Fi network | |
| Ahmed et al. | Performance evaluation of transmission control protocol in mobile ad hoc networks | |
| Bajeja et al. | Performance evaluation of traditional TCP variants in wireless multihop networks | |
| Aaron et al. | Techniques to improve TCP over wireless links |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040121 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040127 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040329 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20040416 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040907 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041104 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20041109 |
|
| 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: 20041207 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3637389 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |