無線通信装置、無線通信方法およびプログラム
【課題】無線リンクエラーが発生した場合でも効率的な無線パケット通信が行える技術提供する。
【解決手段】ＴＣＰ送信部１１による通信中に通信エラーが発生した場合は、コントローラ１２はＵＤＰ送信部１３によっても通信を開始する。これによって、通信エラーによるウィンドウサイズの低下の結果として生じるデータ転送速度の低下を、ＵＤＰ通信によって補うことができるので、通信エラーが発生した場合でも効率的な通信を行うことが可能となる。なお、ＵＤＰによって通信を行っている最中もＴＣＰ通信は合わせて行われており、ＴＣＰ通信のウィンドウサイズが通信エラー発生時のウィンドウサイズまで回復した場合はＵＤＰによる通信を停止することが好ましい。
【解決手段】ＴＣＰ送信部１１による通信中に通信エラーが発生した場合は、コントローラ１２はＵＤＰ送信部１３によっても通信を開始する。これによって、通信エラーによるウィンドウサイズの低下の結果として生じるデータ転送速度の低下を、ＵＤＰ通信によって補うことができるので、通信エラーが発生した場合でも効率的な通信を行うことが可能となる。なお、ＵＤＰによって通信を行っている最中もＴＣＰ通信は合わせて行われており、ＴＣＰ通信のウィンドウサイズが通信エラー発生時のウィンドウサイズまで回復した場合はＵＤＰによる通信を停止することが好ましい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線パケット通信技術に関する。
【背景技術】
【０００２】
近年、最も普及している通信プロトコルの１つであるＴＣＰ（Transmission Control Protocol）では、通信の信頼性を確保するために送信したパケットが届けられたことを確
認するために、受信端末はＡＣＫ（Acknowledgement）を返すことにしている。１つのパ
ケットを送信するたびにＡＣＫを待っていては、ＡＣＫを待つ時間が多くなりスループットが向上しない。
【０００３】
そこで、ＡＣＫの到着を待つことなく、所定の数のパケットをまとめて送信できるようにしている。このパケットの数のことを、ウィンドウサイズという。ＴＣＰにおいては、通信開始時にはウィンドウサイズを小さな値（例えば１）として、通信エラーが発生せず正常に通信が完了した場合にはウィンドウサイズを大きくし、通信エラーが発生した場合にはウィンドウサイズを小さくする制御を行っている。このようなウィンドウ制御によって、送信データ量を適切な量に保っている。図９にウィンドウサイズが増加する様子を示した。図に示すように、ウィンドウサイズを増加させることで、１パケットあたりのＡＣＫを待つ時間が減少し単位時間あたりの送信できるデータ量（データ転送速度）が向上する。
【０００４】
ウィンドウ制御を具体的にどのように行うかについては、様々な研究がなされている。例えば、ウィンドウサイズを上げていく場合には、通信開始初期はウィンドウサイズを２倍にしていき、所定の閾値を超えた後は所定値（例えば１）ずつ上げていく手法が知られている。また、通信エラーが発生した場合も、ウィンドウサイズを１にする方法や、半分にする方法などが知られている。
【０００５】
さて、このようなＴＣＰのウィンドウ制御は、有線による通信を前提として設計されている。つまり、通信エラーの発生は輻輳によるものであることを前提としており、通信エラーが発生した場合にはウィンドウサイズを下げることで、データ流量を減らしている。
【０００６】
しかし、無線通信の場合には、電波環境の一時的な悪化（フェージングやシャドウイング）などによって、輻輳が生じていないにも拘わらず通信エラー（リンクエラー）が発生する。むしろ、無線通信における通信エラーのほとんどは、輻輳によるものではなく、このような電波環境の悪化によるリンクエラーである。つまり、通信エラーが発生するとウィンドウサイズを小さくするＴＣＰによれば、輻輳が生じていないにも拘わらず、スループットを下げてしまう。このように無線通信にＴＣＰを単に適用すると、効率的な通信を行うことができない。
【０００７】
図１０（ａ）（ｂ）にウィンドウサイズの変化する様子を示した。図１０（ａ）は通信エラーが輻輳によってのみ生じる場合のウィンドウサイズの変化であり、図１０（ｂ）は通信エラーがリンクエラーによっても生じる場合のウィンドウサイズの変化である。図１０（ｂ）の場合には、リンクエラーによって、ウィンドウサイズが比較的小さいなときにさらに小さくする制御が行われてしまい、スループットが低くなってしまう。
【０００８】
このようなリンクエラーによる悪影響を抑えるために、ネットワーク側の機器に修正を加える手法が提案されている（非特許文献１）。また、コネクションを携帯電話機から基地局までと，基地局から携帯電話機までの２つの部分に分割し、基地局から携帯電話まで
の間は無線環境に適合した通信プロトコルを用いる手法が提案されている（非特許文献２）。また、基地局にＴＣＰセグメントをキャッシングする機能を持たせ、ハンドオフ時に通信エラーが発生したパケットをキャッシングした基地局から再送する手法が提案されている（非特許文献３）。また、ウィンドウ制御をレート制御型にして、リンクエラーによるパケットロスの影響を受けにくくする手法も提案されている（非特許文献４）。
【非特許文献１】K. Xu, Y. Tian and N. Ansari, "TCP-Jersey for Wireless IP Communications", IEEE JSAC, Vol. 22, no. 4, pp.747-756, May 2004.
【非特許文献２】A. Bakre and B. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts", Proc. of 15th IEEE International Conference on Distributed Computing System (ICDCS '95), pp.136-143, Vancouver, Canada, May 1995.
【非特許文献３】H. Balakrishnan, S. Seshan and R. Katz, "Improving reliable transport and handoff performance in cellular wireless networks", ACM Wireless Networks, Vol. 1, Issue 4, pp.469-481, Feb. 1995.
【非特許文献４】P. Sinha, N. Venkitaraman, R. Sivakumar, V. Bharghavan, "WTCP: A Reliable Transport Protocol for Wireless Wide-Area Networks," Proc. ACM MOBICOM'99, pp.231-241, Aug. 1999.
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記従来技術の非特許文献１のようにネットワーク側の機器に修正を加えることは、コストや安定性の面から現実的に困難である。また、非特許文献２や３も同様に基地局に修正を加える必要がある。また、これらは携帯電話網という特定の無線媒体のみに適用できる技術である。
【００１０】
また、非特許文献４に記載の技術では、ＴＣＰのウィンドウ制御方式を変更しているため、ＴＣＰライブラリあるいはＯＳに変更を加える必要がある。ＴＣＰの実装方法を変更しユーザに配布することは、アプリケーションプログラム作成者としては困難であり、既存のＴＣＰ実装に変更を加えないことが好ましい。
【００１１】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、通信エラーが発生した場合でも効率的な無線パケット通信が行える技術を提供することにある。
【課題を解決するための手段】
【００１２】
上記目的を達成するために本発明に係る無線通信装置は、第１の送信手段と、第２の送信手段と、通信制御手段とを有し、これらの各手段を用いて無線パケット通信を行う。
【００１３】
第１の送信手段は、通信エラーを検知可能であり、通信エラーの有無に基づいてデータ転送速度（単位時間あたりに送信するデータの量）の制御を行うプロトコルにしたがってパケットの送信を行う。ここで、通信エラーは、送信したパケットが受信端末まで到達しなかった場合と、送信したパケットが受信端末まで到達したがパケットの中身が壊れている場合と、送信したパケットが受信端末まで到達したが確認応答が送信端末まで戻ってこなかった場合とを含む。第１の送信手段は、通信エラーの有無に基づいて、通信エラーが発生していない場合はデータ転送速度を増加させ、通信エラーが発生した場合はデータ転送速度を減少させる処理を行う。なお、通信エラーの発生は、送信したパケットが受信端末まで到達したことを所定の時間（再送待ち時間）内に確認できないことや、受信端末から明示的に再送要求を受けたことによって検知可能である。
【００１４】
第２の送信手段は、データ転送量の制御を行わないプロトコルにしたがってパケットを送信する。第２の送信手段のデータ転送速度は、通信エラーが発生した際の第１の送信手段におけるデータ転送速度よりも速いことが好ましい。
【００１５】
なお、第１の送信手段のプロトコルの具体例として、ＴＣＰ（Transmission Control Protocol）やＳＣＴＰ（Stream Control Transmission Protocol）を挙げることができる
。また、第２の送信手段のプロトコルの具体例として、ＵＤＰ（User Datagram Protocol）を挙げることができる。もっとも、第１および第２の送信手段のプロトコルとして、これら以外のプロトコルを用いることが可能である。
【００１６】
通信制御手段は、第１の送信手段がパケットを送信している際に通信エラーが発生した場合は、第１の送信手段が送信するパケットを、第２の送信手段によっても送信する制御を行う。ここで、第２の送信手段によって送信されるパケットは、第１の送信手段によって送信するべきパケットのうち、未送信のパケットおよび送信したが受信端末まで到達したか不明なパケットであることが好ましい。
【００１７】
このように、本発明に係る無線通信装置によれば、通信エラーが発生して第１の送信手段によるデータ転送速度が下がった場合であっても、通信制御手段が第２の送信手段を用いてデータの送信を行うため、通信エラーが発生した場合であっても、データ転送速度を下げずに効率的な無線パケット通信を行うことができる。
【００１８】
ここで、本発明における通信制御手段は、第２の送信手段によってパケットの送信を開始した後に、第１の送信手段によるデータ転送速度が所定のデータ転送速度まで回復した場合は、第２の送信手段によるパケットの送信を停止することが好適である。所定のデータ転送速度としては、通信エラーが発生した際の第１の送信手段におけるデータ転送速度を用いることが好適である。もっとも、所定のデータ転送速度としてその他の値を用いても良い。
【００１９】
また、本発明における通信制御手段は、第１の送信手段による送信における通信エラーが輻輳によるものであると判断した場合は、前記第２の送信手段によるパケットの送信を停止することが好適である。通信エラーが輻輳によるものである場合には、第２の送信手段によってパケットを送信すると、第１の送信手段がデータ転送速度を下げても輻輳を解消することが困難となる。そこで、輻輳が発生した場合には、通信制御手段は第２の送信手段によるパケットの送信を停止させる。通信エラーが輻輳によるものであるか否かは、第１の送信手段のデータ転送速度の変化に基づいて判断することができる。具体的には、第１の送信手段のデータ転送速度が所定の増加率以上で増加した場合は、通信エラーが輻輳によるものではないと判断することができる。
【００２０】
また、本発明に係る無線通信装置は、第２の送信手段が送信したパケットが送信先（受信端末）まで到達したことを確認する送達確認手段をさらに備えることが好適である。この場合、本発明に係る無線通信装置は、第２の送信手段が送信したパケットが送信先まで到達したことが確認できなかった場合には、このパケットを第２の送信手段によって再送することが好ましい。この送達確認手段および再送処理によって、確実なパケット送信を行うことができる。
【００２１】
なお、本発明は、上記手段の少なくとも一部を有する無線通信装置として捉えることができる。また、本発明は、上記処理の少なくとも一部を含む無線通信方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２２】
例えば、本発明の一態様としての無線通信方法は、通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、データ転送速度の制御を行わ
ないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置が行う無線通信方法であって、前記第１の送信手段によって、パケットの送信を開始するステップと、前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、を含むことを特徴とする。
【００２３】
また、本発明の一態様としてのプログラムは、通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置に対して無線通信を実行させるプログラムであって、前記第１の送信手段によって、パケットの送信を開始するステップと、前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、を実行させることを特徴とする。
【発明の効果】
【００２４】
本発明によれば、無線パケット通信において、通信エラーが発生した場合でも効率的な通信を行うことが可能となる。
【発明を実施するための最良の形態】
【００２５】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００２６】
図１は、本実施形態に係る無線通信装置の機能ブロックを示す図である。図１には、データを送信する無線通信装置（以下、送信端末ともいう）１０と、データを受信する無線通信装置（以下、受信端末ともいう）２０の機能ブロックが示されている。なお、本実施形態においては、各無線通信装置はデータの送受信の両方を行う。すなわち、本実施形態に係る無線通信装置は、図１における送信端末１０および受信端末２０としての機能の両方を有するが、以下では説明の簡略化のために、無線通信装置１０から無線通信装置２０への一方向の通信が行われるものとして説明する。
【００２７】
送信端末１０は、ＴＣＰ送信部１１とコントローラ１２とＵＤＰ送信部１３とアプリケーション１４とを有する。以下、各機能部について説明する。
【００２８】
ＴＣＰ送信部１１は、アプリケーション１４からの要求に応じて、送信データを分割して受信端末２０に送信する。ＴＣＰ送信部１１は、ＴＣＰプロトコルにしたがって、ＴＣＰパケットの送信を行う。背景技術の欄で説明したように、ＴＣＰではリンクエラーと輻輳とを区別せずに、通信エラー発生時にはウィンドウサイズを減少させてデータ転送速度を低下させる。
【００２９】
コントローラ１２は、ＴＣＰ送信部１１による通信の通信エラーを検知して、通信エラーが発生した場合にはＵＤＰ送信部１３によってもデータの送信を開始する制御を行う。コントローラ１２は、ＴＣＰによる通信エラーの発生を、ＴＣＰ送信部１１から通知を受けたり、端末間でやりとりされるパケットを見たりすることによって検知することができる。また、コントローラ１２は、ＵＤＰ送信部１３を用いたデータ送信を開始した後に、所定の条件を満たした場合にはＵＤＰによる送信を停止する処理を行う。送信停止の具体的条件などの処理の詳細については後述する。
【００３０】
ＵＤＰ送信部１３は、コントローラ１２からの指示に基づいて、受信端末２０へと送信するデータをＴＣＰ送信部１１から取得してＵＤＰプロトコルにしたがって送信する。
【００３１】
一方、受信端末２０は、ＴＣＰ受信部２１とコントローラ２２とＵＤＰ受信部２３とアプリケーション２４とを有する。ＴＣＰ受信部２１は、送信端末１０のＴＣＰ送信部１１からのＴＣＰパケットを受信する。ＵＤＰ受信部２３は、送信端末１０のＵＤＰ送信部１３からＵＤＰパケットが送信される場合に、これを受信する。コントローラ２２は、ＴＣＰ受信部２１とＵＤＰ受信部２３が受信したパケットの順序を適切な順序に並び替えて、アプリケーションバッファに格納して、アプリケーション２４へと渡す。
【００３２】
上記の無線通信装置は、ハードウェア構成としては、ＣＰＵ（中央演算処理装置）、ＲＡＭなどの主記憶装置、ハードディスク装置などの補助記憶装置から構成される。そして、補助記憶装置に格納されたプログラムが主記憶装置にロードされ、ＣＰＵによって実行されることによって、上記の各機能部が実現される。なお、各機能部の一部または全部は専用のチップによって構成されても良い。
【００３３】
＜処理フロー＞
次に、図面を用いて各機能部が行う処理について詳細に説明する。
【００３４】
１．受信端末の初期化処理
まず、受信端末２０が送信端末１０からのデータを受信できるようにするための初期化処理を行う。この受信端末２０の初期化処理を図２のフローチャートを用いて説明する。受信端末２０は、まず、ＴＣＰ受信部２１を起動し（Ｓ２０１）、ＴＣＰ送信部１１からのＴＣＰパケットを受信できるようにする。ＴＣＰ受信部２１は所定のポート番号でＴＣＰパケットを待つ。次に、コントローラ２２を起動し（Ｓ２０２）、さらにＵＤＰ受信部２３を起動する（Ｓ２０３）。ＵＤＰ受信部２３により、ＵＤＰ送信部１３からのＵＤＰパケットを受信できるようになる。また、コントローラ２２は、ＴＣＰ受信部２１とＵＤＰ受信部２３とから受信したパケットから送信端末１０が送信したデータを組み立てることができるようになる。
【００３５】
２．送信端末におけるＴＣＰ通信の監視処理
図３は、送信端末１０におけるＴＣＰ通信の監視処理を示すフローチャートである。送信端末１０において、コントローラ１２がＴＣＰ送信部１１から受信端末２０へのＴＣＰ通信の開始を検知すると、図３に示すＴＣＰ通信の監視処理を開始する。コントローラ２２は、ＴＣＰ送信部１１による受信端末２０へのＳＹＮパケットの送信に基づいてＴＣＰ通信の開始を判断しても良く、ＴＣＰ送信部１１からＴＣＰ通信の開始を通知されても良い。なお、ＴＣＰ送信部１１が複数のＴＣＰコネクションを有する場合には、コントローラ１２はＴＣＰコネクションそれぞれについて監視処理を行う。
【００３６】
ＴＣＰ送信部１１が受信端末２０に対してＴＣＰ通信を開始すると、コントローラ１２はそのＴＣＰコネクションに対応するＩＤを作成する（Ｓ３０１）。このＩＤのことを、以下では、コントローラコネクションＩＤ（ＣＣＩＤ）という。次に、コントローラ１２は、このＣＣＩＤとＴＣＰコネクションのポート番号をＵＤＰ送信部１３を用いて受信端末２０へ送信する（Ｓ３０２）。これにより、受信端末２０は、ＴＣＰコネクションに割り当てられたＣＣＩＤを認識することができるようになり、ＣＣＩＤからＴＣＰコネクションを特定できるようになる。
【００３７】
次に、コントローラ１２は、ＴＣＰ通信が終了したか判定し（Ｓ３０３）、終了した場合（Ｓ３０３−ＹＥＳ）には、このＴＣＰコネクションに対する監視処理を終了する。ＴＣＰ通信が継続している場合（Ｓ３０３−ＮＯ）は、このＴＣＰ通信で通信エラーが発生したか判定する（Ｓ３０４）。コントローラ１２は、ＴＣＰ送信部１１とＴＣＰ受信部２１との間でやりとりされるパケットを見ることによって通信エラーの発生を検知しても良く、また、ＴＣＰ送信部１１から通知されることで通信エラーの発生を検知しても良い。
通信エラーが発生していない場合（Ｓ３０４−ＮＯ）は、Ｓ３０３に戻りＴＣＰ通信が続いているかと通信エラーが発生したかを監視する。
【００３８】
ＴＣＰ通信で通信エラーが発生した場合（Ｓ３０４−ＹＥＳ）は、コントローラ１２は通信エラー発生直前の輻輳ウィンドウ値ｃｗｎｄをｃｗｎｄ＿ｇｏａｌとして記憶する（Ｓ３０５）。そして、コントローラ１２はＵＤＰ送信部１３に、ＴＣＰ送信部１１が送信すべきパケットを送信するように指示する。具体的には、ＵＤＰ送信部１３は、送信すべきパケットをＴＣＰ送信部１１から取得する（Ｓ３０６）。ＴＣＰ送信部１１は、未送信のパケットを送信バッファに、送信したがＡＣＫが返ってきていないパケットを再送バッファに格納しているので、ＵＤＰ送信部１３は再送バッファおよび送信バッファから送信すべきパケットを取得することができる。そして、ＵＤＰ送信部１３は、このパケットを送信する（Ｓ３０７）。なお、ＵＤＰ送信部１３が送信するパケットの構造は、図４に示すように、送信するデータ４４の前にＣＣＩＤ４２とシーケンス番号４３とを付加している。シーケンス番号４３はＴＣＰ送信部１１が用いるシーケンス番号と同じものであり、送信データの何バイト目に相当するかを示すものである。ＵＤＰ送信部１３は、ＣＣＩＤ４２とシーケンス番号４３を付加したデータ４４に、ＵＤＰヘッダ４１をさらに付加して送信する。
【００３９】
Ｓ３０６において、ＵＤＰ送信部１３がパケットを送信すると、送信したパケットを再送バッファに格納して到達確認処理を開始する。なお、この到達確認処理はＵＤＰ送信部１３によるパケット送信処理と並行して実行されるものであり、到達確認処理が開始されると、本ルーチンにおける処理はＳ３０８へと進む。到達確認処理については後述する。
【００４０】
さて、このようにＴＣＰ通信において通信エラーが発生した場合には、送信すべきデータをＵＤＰによって送信しているが、この間もＴＣＰ送信部１１はデータの送信を継続している。ただし、ＴＣＰ送信部１１は、通信エラーの発生によりｃｗｎｄを低下させて通信を継続している。このｃｗｎｄ値は、時間の経過とともに回復（増加）することが期待される。そこで、コントローラ１２は、現在のｃｗｎｄ値がＳ３０５で記憶したｃｗｎｄ＿ｇｏａｌ以上であるか判定する（Ｓ３０８）。ｃｗｎｄ値がｃｗｎｄ＿ｇｏａｌまで回復していない場合（Ｓ３０８−ＮＯ）には、Ｓ３０６に進みＵＤＰ送信部１３によるパケットの送信を継続する。ｃｗｎｄ値がｃｗｎｄ＿ｇｏａｌまで回復した場合（Ｓ３０９−ＹＥＳ）には、Ｓ３０３に進み、ＵＤＰによる送信を中止しＴＣＰ通信の終了および通信エラーの発生を監視する。
【００４１】
次に、先述したＳ３０７におけるＵＤＰ送信の到達確認処理を、図５のフローチャートを用いて説明する。この到達確認処理は、ＵＤＰの送信処理とは並行して動作するものであり、具体的には別スレッドとして実行される。到達確認処理が実行されると、まずタイマーを起動する（Ｓ５０１）。このタイマーのことをここではＡＣＫタイマーという。次に、ＵＤＰで送信したパケットに対するＡＣＫを受信端末２０から受け取ったかを判定する（Ｓ５０２）。ＵＤＰにはＡＣＫについての規定はないので、送信側のコントローラ１２と受信側のコントローラ２２とに独自に実装する。ＡＣＫを受信した場合（Ｓ５０２−ＹＥＳ）は、送信したパケットが受信端末２０まで到達したことが分かるので到達確認処理を終了する。ＡＣＫを受信していない場合（Ｓ５０２−ＮＯ）は、ＡＣＫタイマーがＲＴＴ（Round Trip Time：往復遅延時間）以上経過しているか判定する（Ｓ５０３）。Ｒ
ＴＴはＴＣＰ送信部１１が決定しているので、ＵＤＰ送信部１３はＴＣＰ送信部１１からＲＴＴを取得することができる。もっとも、ＡＣＫの待ち時間としてはＲＴＴではなくてその他の任意の値を用いることもできる。
【００４２】
待ち時間がＲＴＴ以上経過していない場合（Ｓ５０３−ＮＯ）は、Ｓ５０２に戻ってさらにＡＣＫを待つ。待ち時間がＲＴＴ以上経過した場合（Ｓ５０３−ＹＥＳ）は、パケッ
トの再送を行う（Ｓ５０４）。この際、再送したパケットに対しても到達確認処理を行う。
【００４３】
このようにして、ＵＤＰによる送信に対して到達確認処理を行うことで、本来信頼性の無いＵＤＰにおいて、信頼性（到達の保証）を得ることができる。本無線通信装置では、ＴＣＰ通信のスループット低下したときに、ＵＤＰを併用してデータの送信を行いスループットの低下を防止しているので、ＵＤＰ通信にも信頼性があることが好ましい。もっとも、ＴＣＰ通信自体は中止せずに続行しているので、信頼性はＴＣＰ通信によって担保できる。したがって、ＵＤＰ通信では到達確認処理を行わなくても構わない。
【００４４】
３．受信端末における受信処理
次に、受信端末２０における受信処理について説明する。ここでは、主にＵＤＰ受信部２３とコントローラ２２の処理について説明する。なお、ＴＣＰ受信部２１は、通常のＴＣＰプロトコルにしたがって受信処理を行っている。
【００４５】
ＵＤＰ受信部２３がＵＤＰパケットを受信する（Ｓ６０１）と、ＵＤＰ受信部２３は、このパケットの対する到達確認メッセージ（ＡＣＫ）を送信端末１０へ送信する（Ｓ６０２）。受信したパケットがどのＴＣＰコネクションに対応するものであるかは、ＵＤＰパケットに格納されているＣＣＩＤを調べることで判断することができる。
【００４６】
次に、コントローラ２２は、このパケットが既に受信したパケットが重複して送信されたものではないか判定する（Ｓ６０３）。ＴＣＰ受信部２１およびＵＤＰ受信部２３によって受信されたパケットは受信バッファに格納されており、それぞれのパケットはシーケンス番号によって識別することができる。受信したパケットが重複したものである場合（Ｓ６０３−ＹＥＳ）は、そのパケットを破棄し（Ｓ６０６）、次のパケットを受信する。受信したパケットが重複したものではない場合（Ｓ６０３−ＮＯ）は、パケットの順序制御をしてアプリケーションバッファに書き込む（Ｓ６０４）。すなわち、パケットの到達順序が入れ替わった場合には、コントローラ２２で正しい順序に直してからアプリケーションバッファに書き込むことで、パケットの順序を保証する。具体的には、ＴＣＰ受信部２１およびＵＤＰ受信部２３が受信したパケットを受信バッファに一旦格納し、次にアプリケーションバッファに書き込むパケットをコントローラ２２が受信バッファから取得すれば順序を保証することができる。そして、ＴＣＰコネクションが有効であるか判定し（Ｓ６０５）、有効であれば（Ｓ６０５−ＹＥＳ）ＵＤＰパケットの受信を継続し、無効であれば（Ｓ６０５−ＮＯ）処理を終了する。
【００４７】
＜実施形態の作用・効果＞
上記のような処理によって、ＴＣＰ通信で通信エラーが発生したときに、ＵＤＰでデータの送信を行うことが可能となる。ここで、ＴＣＰ通信は、通信エラーの発生によりウィンドウサイズを減少させ、データの転送速度が低下する。この転送速度が低下したときに、ＵＤＰ通信を行うことでデータ転送速度の低下を防ぐことが可能となる。
【００４８】
特に、電波環境の悪化などによりリンクエラーが発生した場合には、データの転送速度を落とす必要はない。そこで、ＴＣＰ通信のデータ転送速度が回復するまでの間ＵＤＰ通信も並行して行うことで、リンクエラーが発生した場合でも効率的な無線パケット通信を行うことができる。
【００４９】
なお、本実施形態に係る無線通信装置では、従来のＴＣＰプロトコルおよびＵＤＰプロトコルに修正を加えずそのまま利用している。そのため、無線媒体（例えば、携帯電話網や衛星通信）の種類に拘わらず、どのような無線媒体にも適用することが可能である。また、ネットワーク側の装置に修正を加える必要がない。すなわち、送受信端末のプログラ
ムのみによって、リンクエラーがあってもデータ転送速度が低下しない無線通信を実現することができる。
【００５０】
＜変形例１＞
上記の処理は、無線通信による通信エラーのほとんどがリンクエラーによるものであることを前提としている。したがって、ＴＣＰ通信において通信エラーが発生した場合は、ＵＤＰによっても同時に通信を開始していた。しかしながら、無線通信においても輻輳が発生することがあり得る。この場合、ＵＤＰによっても同時に通信を開始するとさらなる輻輳を招き好ましくない。
【００５１】
輻輳が発生することを考慮して、送信端末１０におけるＴＣＰ通信の監視処理を図７のフローチャートに示す処理に修正することが好ましい。図３と図７のフローチャートに示す処理の差は、図７のフローチャートにＳ３０５の後にＳ７０１が付け加えられた点のみである。Ｓ７０１では、輻輳ウィンドウ値ｃｗｎｄの増加Δｃｗｎｄが所定の値Δ以上であるか否か判定している。すなわち、輻輳ウィンドウ値が所定値以上回復したか否か判定している。そして、輻輳ウィンドウ値の回復が早い（Ｓ７０１−ＹＥＳ）場合はＵＤＰによる送信を続行し、回復が遅い（Ｓ７０１−ＮＯ）場合にはＵＤＰによる送信を停止している。これは、通信エラーがリンクエラーによるものである場合には輻輳ウィンドウ値は早期に増加するのに対して、通信エラーが輻輳によるものである場合には輻輳ウィンドウ値の増加に時間がかかるためである。
【００５２】
なお、図７のフローチャートでは輻輳ウィンドウ値の増加量Δｃｗｎｄを毎回調べているが、通信エラーの発生からの経過時間をタイマーによって計測し、所定時間後に１回または数回だけ調べるようにしても良い。
【００５３】
＜変形例２＞
上記の実施形態においては、通信エラーが発生した場合は、ＴＣＰ送信部１１とＵＤＰ送信部１３とで同じパケットを２回送信している。通信エラー発生時は、ＴＣＰ通信はウィンドウサイズを減少させるのでＵＤＰ通信の方が高速となる。ＵＤＰ通信によって送信され、受信端末２０への到達が確認されたパケットについてはＴＣＰ送信部１１で送信する必要がない。したがって、ＵＤＰ通信によって既に受信端末２０へ到達が確認されたパケットをＴＣＰ送信部１１は送信しなくても良い。
【００５４】
この処理は以下のようにして実現することができる。送信端末１０側では、コントローラ１２がＴＣＰ送信部１１に通知して、ＴＣＰ送信部１１がこのパケットを送信済みと見なせるようにすればよい。また、受信端末２０側では、コントローラ２２がＴＣＰ受信部２１に通知して、ＴＣＰ受信部２１がこのパケットを受信済みと見なせるようにすればよい。なお、この処理はＵＤＰパケットの到達が確認されるたびに行っても良く、送信端末１０がＵＤＰによる送信を停止するときのみ行っても良い。特に、送信端末１０がＵＤＰによる送信を停止するときに上記の処理を行うことで、ＵＤＰで既に送信したパケットを送り続けることが無くなるので、スループットが向上する。
【００５５】
＜変形例３＞
上記の実施形態においては、送信端末１０のアプリケーション１４は基本的にＴＣＰ送信部１１とやりとりを行い、受信端末２０のアプリケーション２４は基本的にＴＣＰ受信部２１とやりとりを行う構成を採っている。そして、コントローラ１２，２２は、基本的にアプリケーション１４，２４と直接やりとりをしていない。
【００５６】
しかしながら、コントローラがＴＣＰとＵＤＰによる通信をラップして、アプリケーションと直接やりとりをする構成を採用することもできる。図８は、このような構成による
無線通信装置の機能ブロック図である。送信端末３０のアプリケーション３４は、コントローラ３２に対してデータの送信を指示する。コントローラ３２は、まずＴＣＰ送信部３１によってデータの送信を行い、ＴＣＰで通信エラーを発生した場合にはＵＤＰ送信部３３も使ってデータの送信を行う。受信端末４０では、ＴＣＰ受信部４１とＵＤＰ受信部４３とによってデータの受信を行い、コントローラ４２がパケットの順序制御を行い、アプリケーション４４に受信データを渡す。具体的な処理の流れは上記の説明とほぼ同様であるため詳しい説明は省略する。
【００５７】
＜変形例４＞
上記の実施形態においては、プロトコルとしてＴＣＰとＵＤＰを利用している。しかしながら、ＴＣＰの代わりに、通信エラーの発生を検知してデータ転送速度を制御するプロトコルであればどのようなプロトコルを用いることもできる。そのようなプロトコルとしては、既存のものであれば、ＳＣＴＰを挙げることができる。
【００５８】
また、ＵＤＰの代わりにデータ転送速度の制御を行わないプロトコルであればどのようなプロトコルを用いることもできる。既存のプロトコルとしてはＵＤＰが最も適したものではあるが、その他のプロトコルの使用を妨げるものではない。
【図面の簡単な説明】
【００５９】
【図１】本実施形態に係る無線通信装置の機能ブロックを示す図である。
【図２】受信端末の初期化処理の流れを示すフローチャートである。
【図３】送信端末におけるＴＣＰ通信の監視処理の流れを示すフローチャートである。
【図４】ＵＤＰ送信部が送信するパケットの構造を示す図である。
【図５】送信端末におけるＵＤＰパケットに対する到達確認処理の流れを示すフローチャートである。
【図６】受信端末におけるＵＤＰパケット受信時の処理の流れを示すフローチャートである。
【図７】送信端末におけるＴＣＰ通信の監視処理の流れを示すフローチャートである。
【図８】変形例に係る無線通信装置の機能ブロックを示す図である。
【図９】ウィンドウ制御を説明する図である。
【図１０】（ａ）は通信エラーが輻輳のみによる場合のウィンドウサイズの変化を示す図であり、（ｂ）は通信エラーがリンクエラーによっても生じる場合のウィンドウサイズの変化を示す図である。
【符号の説明】
【００６０】
１０ 送信端末
１１ ＴＣＰ送信部
１２ コントローラ
１３ ＵＤＰ送信部
２０ 受信端末
２１ ＴＣＰ受信部
２２ コントローラ
２３ ＵＤＰ受信部
【技術分野】
【０００１】
本発明は、無線パケット通信技術に関する。
【背景技術】
【０００２】
近年、最も普及している通信プロトコルの１つであるＴＣＰ（Transmission Control Protocol）では、通信の信頼性を確保するために送信したパケットが届けられたことを確
認するために、受信端末はＡＣＫ（Acknowledgement）を返すことにしている。１つのパ
ケットを送信するたびにＡＣＫを待っていては、ＡＣＫを待つ時間が多くなりスループットが向上しない。
【０００３】
そこで、ＡＣＫの到着を待つことなく、所定の数のパケットをまとめて送信できるようにしている。このパケットの数のことを、ウィンドウサイズという。ＴＣＰにおいては、通信開始時にはウィンドウサイズを小さな値（例えば１）として、通信エラーが発生せず正常に通信が完了した場合にはウィンドウサイズを大きくし、通信エラーが発生した場合にはウィンドウサイズを小さくする制御を行っている。このようなウィンドウ制御によって、送信データ量を適切な量に保っている。図９にウィンドウサイズが増加する様子を示した。図に示すように、ウィンドウサイズを増加させることで、１パケットあたりのＡＣＫを待つ時間が減少し単位時間あたりの送信できるデータ量（データ転送速度）が向上する。
【０００４】
ウィンドウ制御を具体的にどのように行うかについては、様々な研究がなされている。例えば、ウィンドウサイズを上げていく場合には、通信開始初期はウィンドウサイズを２倍にしていき、所定の閾値を超えた後は所定値（例えば１）ずつ上げていく手法が知られている。また、通信エラーが発生した場合も、ウィンドウサイズを１にする方法や、半分にする方法などが知られている。
【０００５】
さて、このようなＴＣＰのウィンドウ制御は、有線による通信を前提として設計されている。つまり、通信エラーの発生は輻輳によるものであることを前提としており、通信エラーが発生した場合にはウィンドウサイズを下げることで、データ流量を減らしている。
【０００６】
しかし、無線通信の場合には、電波環境の一時的な悪化（フェージングやシャドウイング）などによって、輻輳が生じていないにも拘わらず通信エラー（リンクエラー）が発生する。むしろ、無線通信における通信エラーのほとんどは、輻輳によるものではなく、このような電波環境の悪化によるリンクエラーである。つまり、通信エラーが発生するとウィンドウサイズを小さくするＴＣＰによれば、輻輳が生じていないにも拘わらず、スループットを下げてしまう。このように無線通信にＴＣＰを単に適用すると、効率的な通信を行うことができない。
【０００７】
図１０（ａ）（ｂ）にウィンドウサイズの変化する様子を示した。図１０（ａ）は通信エラーが輻輳によってのみ生じる場合のウィンドウサイズの変化であり、図１０（ｂ）は通信エラーがリンクエラーによっても生じる場合のウィンドウサイズの変化である。図１０（ｂ）の場合には、リンクエラーによって、ウィンドウサイズが比較的小さいなときにさらに小さくする制御が行われてしまい、スループットが低くなってしまう。
【０００８】
このようなリンクエラーによる悪影響を抑えるために、ネットワーク側の機器に修正を加える手法が提案されている（非特許文献１）。また、コネクションを携帯電話機から基地局までと，基地局から携帯電話機までの２つの部分に分割し、基地局から携帯電話まで
の間は無線環境に適合した通信プロトコルを用いる手法が提案されている（非特許文献２）。また、基地局にＴＣＰセグメントをキャッシングする機能を持たせ、ハンドオフ時に通信エラーが発生したパケットをキャッシングした基地局から再送する手法が提案されている（非特許文献３）。また、ウィンドウ制御をレート制御型にして、リンクエラーによるパケットロスの影響を受けにくくする手法も提案されている（非特許文献４）。
【非特許文献１】K. Xu, Y. Tian and N. Ansari, "TCP-Jersey for Wireless IP Communications", IEEE JSAC, Vol. 22, no. 4, pp.747-756, May 2004.
【非特許文献２】A. Bakre and B. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts", Proc. of 15th IEEE International Conference on Distributed Computing System (ICDCS '95), pp.136-143, Vancouver, Canada, May 1995.
【非特許文献３】H. Balakrishnan, S. Seshan and R. Katz, "Improving reliable transport and handoff performance in cellular wireless networks", ACM Wireless Networks, Vol. 1, Issue 4, pp.469-481, Feb. 1995.
【非特許文献４】P. Sinha, N. Venkitaraman, R. Sivakumar, V. Bharghavan, "WTCP: A Reliable Transport Protocol for Wireless Wide-Area Networks," Proc. ACM MOBICOM'99, pp.231-241, Aug. 1999.
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記従来技術の非特許文献１のようにネットワーク側の機器に修正を加えることは、コストや安定性の面から現実的に困難である。また、非特許文献２や３も同様に基地局に修正を加える必要がある。また、これらは携帯電話網という特定の無線媒体のみに適用できる技術である。
【００１０】
また、非特許文献４に記載の技術では、ＴＣＰのウィンドウ制御方式を変更しているため、ＴＣＰライブラリあるいはＯＳに変更を加える必要がある。ＴＣＰの実装方法を変更しユーザに配布することは、アプリケーションプログラム作成者としては困難であり、既存のＴＣＰ実装に変更を加えないことが好ましい。
【００１１】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、通信エラーが発生した場合でも効率的な無線パケット通信が行える技術を提供することにある。
【課題を解決するための手段】
【００１２】
上記目的を達成するために本発明に係る無線通信装置は、第１の送信手段と、第２の送信手段と、通信制御手段とを有し、これらの各手段を用いて無線パケット通信を行う。
【００１３】
第１の送信手段は、通信エラーを検知可能であり、通信エラーの有無に基づいてデータ転送速度（単位時間あたりに送信するデータの量）の制御を行うプロトコルにしたがってパケットの送信を行う。ここで、通信エラーは、送信したパケットが受信端末まで到達しなかった場合と、送信したパケットが受信端末まで到達したがパケットの中身が壊れている場合と、送信したパケットが受信端末まで到達したが確認応答が送信端末まで戻ってこなかった場合とを含む。第１の送信手段は、通信エラーの有無に基づいて、通信エラーが発生していない場合はデータ転送速度を増加させ、通信エラーが発生した場合はデータ転送速度を減少させる処理を行う。なお、通信エラーの発生は、送信したパケットが受信端末まで到達したことを所定の時間（再送待ち時間）内に確認できないことや、受信端末から明示的に再送要求を受けたことによって検知可能である。
【００１４】
第２の送信手段は、データ転送量の制御を行わないプロトコルにしたがってパケットを送信する。第２の送信手段のデータ転送速度は、通信エラーが発生した際の第１の送信手段におけるデータ転送速度よりも速いことが好ましい。
【００１５】
なお、第１の送信手段のプロトコルの具体例として、ＴＣＰ（Transmission Control Protocol）やＳＣＴＰ（Stream Control Transmission Protocol）を挙げることができる
。また、第２の送信手段のプロトコルの具体例として、ＵＤＰ（User Datagram Protocol）を挙げることができる。もっとも、第１および第２の送信手段のプロトコルとして、これら以外のプロトコルを用いることが可能である。
【００１６】
通信制御手段は、第１の送信手段がパケットを送信している際に通信エラーが発生した場合は、第１の送信手段が送信するパケットを、第２の送信手段によっても送信する制御を行う。ここで、第２の送信手段によって送信されるパケットは、第１の送信手段によって送信するべきパケットのうち、未送信のパケットおよび送信したが受信端末まで到達したか不明なパケットであることが好ましい。
【００１７】
このように、本発明に係る無線通信装置によれば、通信エラーが発生して第１の送信手段によるデータ転送速度が下がった場合であっても、通信制御手段が第２の送信手段を用いてデータの送信を行うため、通信エラーが発生した場合であっても、データ転送速度を下げずに効率的な無線パケット通信を行うことができる。
【００１８】
ここで、本発明における通信制御手段は、第２の送信手段によってパケットの送信を開始した後に、第１の送信手段によるデータ転送速度が所定のデータ転送速度まで回復した場合は、第２の送信手段によるパケットの送信を停止することが好適である。所定のデータ転送速度としては、通信エラーが発生した際の第１の送信手段におけるデータ転送速度を用いることが好適である。もっとも、所定のデータ転送速度としてその他の値を用いても良い。
【００１９】
また、本発明における通信制御手段は、第１の送信手段による送信における通信エラーが輻輳によるものであると判断した場合は、前記第２の送信手段によるパケットの送信を停止することが好適である。通信エラーが輻輳によるものである場合には、第２の送信手段によってパケットを送信すると、第１の送信手段がデータ転送速度を下げても輻輳を解消することが困難となる。そこで、輻輳が発生した場合には、通信制御手段は第２の送信手段によるパケットの送信を停止させる。通信エラーが輻輳によるものであるか否かは、第１の送信手段のデータ転送速度の変化に基づいて判断することができる。具体的には、第１の送信手段のデータ転送速度が所定の増加率以上で増加した場合は、通信エラーが輻輳によるものではないと判断することができる。
【００２０】
また、本発明に係る無線通信装置は、第２の送信手段が送信したパケットが送信先（受信端末）まで到達したことを確認する送達確認手段をさらに備えることが好適である。この場合、本発明に係る無線通信装置は、第２の送信手段が送信したパケットが送信先まで到達したことが確認できなかった場合には、このパケットを第２の送信手段によって再送することが好ましい。この送達確認手段および再送処理によって、確実なパケット送信を行うことができる。
【００２１】
なお、本発明は、上記手段の少なくとも一部を有する無線通信装置として捉えることができる。また、本発明は、上記処理の少なくとも一部を含む無線通信方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２２】
例えば、本発明の一態様としての無線通信方法は、通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、データ転送速度の制御を行わ
ないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置が行う無線通信方法であって、前記第１の送信手段によって、パケットの送信を開始するステップと、前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、を含むことを特徴とする。
【００２３】
また、本発明の一態様としてのプログラムは、通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置に対して無線通信を実行させるプログラムであって、前記第１の送信手段によって、パケットの送信を開始するステップと、前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、を実行させることを特徴とする。
【発明の効果】
【００２４】
本発明によれば、無線パケット通信において、通信エラーが発生した場合でも効率的な通信を行うことが可能となる。
【発明を実施するための最良の形態】
【００２５】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００２６】
図１は、本実施形態に係る無線通信装置の機能ブロックを示す図である。図１には、データを送信する無線通信装置（以下、送信端末ともいう）１０と、データを受信する無線通信装置（以下、受信端末ともいう）２０の機能ブロックが示されている。なお、本実施形態においては、各無線通信装置はデータの送受信の両方を行う。すなわち、本実施形態に係る無線通信装置は、図１における送信端末１０および受信端末２０としての機能の両方を有するが、以下では説明の簡略化のために、無線通信装置１０から無線通信装置２０への一方向の通信が行われるものとして説明する。
【００２７】
送信端末１０は、ＴＣＰ送信部１１とコントローラ１２とＵＤＰ送信部１３とアプリケーション１４とを有する。以下、各機能部について説明する。
【００２８】
ＴＣＰ送信部１１は、アプリケーション１４からの要求に応じて、送信データを分割して受信端末２０に送信する。ＴＣＰ送信部１１は、ＴＣＰプロトコルにしたがって、ＴＣＰパケットの送信を行う。背景技術の欄で説明したように、ＴＣＰではリンクエラーと輻輳とを区別せずに、通信エラー発生時にはウィンドウサイズを減少させてデータ転送速度を低下させる。
【００２９】
コントローラ１２は、ＴＣＰ送信部１１による通信の通信エラーを検知して、通信エラーが発生した場合にはＵＤＰ送信部１３によってもデータの送信を開始する制御を行う。コントローラ１２は、ＴＣＰによる通信エラーの発生を、ＴＣＰ送信部１１から通知を受けたり、端末間でやりとりされるパケットを見たりすることによって検知することができる。また、コントローラ１２は、ＵＤＰ送信部１３を用いたデータ送信を開始した後に、所定の条件を満たした場合にはＵＤＰによる送信を停止する処理を行う。送信停止の具体的条件などの処理の詳細については後述する。
【００３０】
ＵＤＰ送信部１３は、コントローラ１２からの指示に基づいて、受信端末２０へと送信するデータをＴＣＰ送信部１１から取得してＵＤＰプロトコルにしたがって送信する。
【００３１】
一方、受信端末２０は、ＴＣＰ受信部２１とコントローラ２２とＵＤＰ受信部２３とアプリケーション２４とを有する。ＴＣＰ受信部２１は、送信端末１０のＴＣＰ送信部１１からのＴＣＰパケットを受信する。ＵＤＰ受信部２３は、送信端末１０のＵＤＰ送信部１３からＵＤＰパケットが送信される場合に、これを受信する。コントローラ２２は、ＴＣＰ受信部２１とＵＤＰ受信部２３が受信したパケットの順序を適切な順序に並び替えて、アプリケーションバッファに格納して、アプリケーション２４へと渡す。
【００３２】
上記の無線通信装置は、ハードウェア構成としては、ＣＰＵ（中央演算処理装置）、ＲＡＭなどの主記憶装置、ハードディスク装置などの補助記憶装置から構成される。そして、補助記憶装置に格納されたプログラムが主記憶装置にロードされ、ＣＰＵによって実行されることによって、上記の各機能部が実現される。なお、各機能部の一部または全部は専用のチップによって構成されても良い。
【００３３】
＜処理フロー＞
次に、図面を用いて各機能部が行う処理について詳細に説明する。
【００３４】
１．受信端末の初期化処理
まず、受信端末２０が送信端末１０からのデータを受信できるようにするための初期化処理を行う。この受信端末２０の初期化処理を図２のフローチャートを用いて説明する。受信端末２０は、まず、ＴＣＰ受信部２１を起動し（Ｓ２０１）、ＴＣＰ送信部１１からのＴＣＰパケットを受信できるようにする。ＴＣＰ受信部２１は所定のポート番号でＴＣＰパケットを待つ。次に、コントローラ２２を起動し（Ｓ２０２）、さらにＵＤＰ受信部２３を起動する（Ｓ２０３）。ＵＤＰ受信部２３により、ＵＤＰ送信部１３からのＵＤＰパケットを受信できるようになる。また、コントローラ２２は、ＴＣＰ受信部２１とＵＤＰ受信部２３とから受信したパケットから送信端末１０が送信したデータを組み立てることができるようになる。
【００３５】
２．送信端末におけるＴＣＰ通信の監視処理
図３は、送信端末１０におけるＴＣＰ通信の監視処理を示すフローチャートである。送信端末１０において、コントローラ１２がＴＣＰ送信部１１から受信端末２０へのＴＣＰ通信の開始を検知すると、図３に示すＴＣＰ通信の監視処理を開始する。コントローラ２２は、ＴＣＰ送信部１１による受信端末２０へのＳＹＮパケットの送信に基づいてＴＣＰ通信の開始を判断しても良く、ＴＣＰ送信部１１からＴＣＰ通信の開始を通知されても良い。なお、ＴＣＰ送信部１１が複数のＴＣＰコネクションを有する場合には、コントローラ１２はＴＣＰコネクションそれぞれについて監視処理を行う。
【００３６】
ＴＣＰ送信部１１が受信端末２０に対してＴＣＰ通信を開始すると、コントローラ１２はそのＴＣＰコネクションに対応するＩＤを作成する（Ｓ３０１）。このＩＤのことを、以下では、コントローラコネクションＩＤ（ＣＣＩＤ）という。次に、コントローラ１２は、このＣＣＩＤとＴＣＰコネクションのポート番号をＵＤＰ送信部１３を用いて受信端末２０へ送信する（Ｓ３０２）。これにより、受信端末２０は、ＴＣＰコネクションに割り当てられたＣＣＩＤを認識することができるようになり、ＣＣＩＤからＴＣＰコネクションを特定できるようになる。
【００３７】
次に、コントローラ１２は、ＴＣＰ通信が終了したか判定し（Ｓ３０３）、終了した場合（Ｓ３０３−ＹＥＳ）には、このＴＣＰコネクションに対する監視処理を終了する。ＴＣＰ通信が継続している場合（Ｓ３０３−ＮＯ）は、このＴＣＰ通信で通信エラーが発生したか判定する（Ｓ３０４）。コントローラ１２は、ＴＣＰ送信部１１とＴＣＰ受信部２１との間でやりとりされるパケットを見ることによって通信エラーの発生を検知しても良く、また、ＴＣＰ送信部１１から通知されることで通信エラーの発生を検知しても良い。
通信エラーが発生していない場合（Ｓ３０４−ＮＯ）は、Ｓ３０３に戻りＴＣＰ通信が続いているかと通信エラーが発生したかを監視する。
【００３８】
ＴＣＰ通信で通信エラーが発生した場合（Ｓ３０４−ＹＥＳ）は、コントローラ１２は通信エラー発生直前の輻輳ウィンドウ値ｃｗｎｄをｃｗｎｄ＿ｇｏａｌとして記憶する（Ｓ３０５）。そして、コントローラ１２はＵＤＰ送信部１３に、ＴＣＰ送信部１１が送信すべきパケットを送信するように指示する。具体的には、ＵＤＰ送信部１３は、送信すべきパケットをＴＣＰ送信部１１から取得する（Ｓ３０６）。ＴＣＰ送信部１１は、未送信のパケットを送信バッファに、送信したがＡＣＫが返ってきていないパケットを再送バッファに格納しているので、ＵＤＰ送信部１３は再送バッファおよび送信バッファから送信すべきパケットを取得することができる。そして、ＵＤＰ送信部１３は、このパケットを送信する（Ｓ３０７）。なお、ＵＤＰ送信部１３が送信するパケットの構造は、図４に示すように、送信するデータ４４の前にＣＣＩＤ４２とシーケンス番号４３とを付加している。シーケンス番号４３はＴＣＰ送信部１１が用いるシーケンス番号と同じものであり、送信データの何バイト目に相当するかを示すものである。ＵＤＰ送信部１３は、ＣＣＩＤ４２とシーケンス番号４３を付加したデータ４４に、ＵＤＰヘッダ４１をさらに付加して送信する。
【００３９】
Ｓ３０６において、ＵＤＰ送信部１３がパケットを送信すると、送信したパケットを再送バッファに格納して到達確認処理を開始する。なお、この到達確認処理はＵＤＰ送信部１３によるパケット送信処理と並行して実行されるものであり、到達確認処理が開始されると、本ルーチンにおける処理はＳ３０８へと進む。到達確認処理については後述する。
【００４０】
さて、このようにＴＣＰ通信において通信エラーが発生した場合には、送信すべきデータをＵＤＰによって送信しているが、この間もＴＣＰ送信部１１はデータの送信を継続している。ただし、ＴＣＰ送信部１１は、通信エラーの発生によりｃｗｎｄを低下させて通信を継続している。このｃｗｎｄ値は、時間の経過とともに回復（増加）することが期待される。そこで、コントローラ１２は、現在のｃｗｎｄ値がＳ３０５で記憶したｃｗｎｄ＿ｇｏａｌ以上であるか判定する（Ｓ３０８）。ｃｗｎｄ値がｃｗｎｄ＿ｇｏａｌまで回復していない場合（Ｓ３０８−ＮＯ）には、Ｓ３０６に進みＵＤＰ送信部１３によるパケットの送信を継続する。ｃｗｎｄ値がｃｗｎｄ＿ｇｏａｌまで回復した場合（Ｓ３０９−ＹＥＳ）には、Ｓ３０３に進み、ＵＤＰによる送信を中止しＴＣＰ通信の終了および通信エラーの発生を監視する。
【００４１】
次に、先述したＳ３０７におけるＵＤＰ送信の到達確認処理を、図５のフローチャートを用いて説明する。この到達確認処理は、ＵＤＰの送信処理とは並行して動作するものであり、具体的には別スレッドとして実行される。到達確認処理が実行されると、まずタイマーを起動する（Ｓ５０１）。このタイマーのことをここではＡＣＫタイマーという。次に、ＵＤＰで送信したパケットに対するＡＣＫを受信端末２０から受け取ったかを判定する（Ｓ５０２）。ＵＤＰにはＡＣＫについての規定はないので、送信側のコントローラ１２と受信側のコントローラ２２とに独自に実装する。ＡＣＫを受信した場合（Ｓ５０２−ＹＥＳ）は、送信したパケットが受信端末２０まで到達したことが分かるので到達確認処理を終了する。ＡＣＫを受信していない場合（Ｓ５０２−ＮＯ）は、ＡＣＫタイマーがＲＴＴ（Round Trip Time：往復遅延時間）以上経過しているか判定する（Ｓ５０３）。Ｒ
ＴＴはＴＣＰ送信部１１が決定しているので、ＵＤＰ送信部１３はＴＣＰ送信部１１からＲＴＴを取得することができる。もっとも、ＡＣＫの待ち時間としてはＲＴＴではなくてその他の任意の値を用いることもできる。
【００４２】
待ち時間がＲＴＴ以上経過していない場合（Ｓ５０３−ＮＯ）は、Ｓ５０２に戻ってさらにＡＣＫを待つ。待ち時間がＲＴＴ以上経過した場合（Ｓ５０３−ＹＥＳ）は、パケッ
トの再送を行う（Ｓ５０４）。この際、再送したパケットに対しても到達確認処理を行う。
【００４３】
このようにして、ＵＤＰによる送信に対して到達確認処理を行うことで、本来信頼性の無いＵＤＰにおいて、信頼性（到達の保証）を得ることができる。本無線通信装置では、ＴＣＰ通信のスループット低下したときに、ＵＤＰを併用してデータの送信を行いスループットの低下を防止しているので、ＵＤＰ通信にも信頼性があることが好ましい。もっとも、ＴＣＰ通信自体は中止せずに続行しているので、信頼性はＴＣＰ通信によって担保できる。したがって、ＵＤＰ通信では到達確認処理を行わなくても構わない。
【００４４】
３．受信端末における受信処理
次に、受信端末２０における受信処理について説明する。ここでは、主にＵＤＰ受信部２３とコントローラ２２の処理について説明する。なお、ＴＣＰ受信部２１は、通常のＴＣＰプロトコルにしたがって受信処理を行っている。
【００４５】
ＵＤＰ受信部２３がＵＤＰパケットを受信する（Ｓ６０１）と、ＵＤＰ受信部２３は、このパケットの対する到達確認メッセージ（ＡＣＫ）を送信端末１０へ送信する（Ｓ６０２）。受信したパケットがどのＴＣＰコネクションに対応するものであるかは、ＵＤＰパケットに格納されているＣＣＩＤを調べることで判断することができる。
【００４６】
次に、コントローラ２２は、このパケットが既に受信したパケットが重複して送信されたものではないか判定する（Ｓ６０３）。ＴＣＰ受信部２１およびＵＤＰ受信部２３によって受信されたパケットは受信バッファに格納されており、それぞれのパケットはシーケンス番号によって識別することができる。受信したパケットが重複したものである場合（Ｓ６０３−ＹＥＳ）は、そのパケットを破棄し（Ｓ６０６）、次のパケットを受信する。受信したパケットが重複したものではない場合（Ｓ６０３−ＮＯ）は、パケットの順序制御をしてアプリケーションバッファに書き込む（Ｓ６０４）。すなわち、パケットの到達順序が入れ替わった場合には、コントローラ２２で正しい順序に直してからアプリケーションバッファに書き込むことで、パケットの順序を保証する。具体的には、ＴＣＰ受信部２１およびＵＤＰ受信部２３が受信したパケットを受信バッファに一旦格納し、次にアプリケーションバッファに書き込むパケットをコントローラ２２が受信バッファから取得すれば順序を保証することができる。そして、ＴＣＰコネクションが有効であるか判定し（Ｓ６０５）、有効であれば（Ｓ６０５−ＹＥＳ）ＵＤＰパケットの受信を継続し、無効であれば（Ｓ６０５−ＮＯ）処理を終了する。
【００４７】
＜実施形態の作用・効果＞
上記のような処理によって、ＴＣＰ通信で通信エラーが発生したときに、ＵＤＰでデータの送信を行うことが可能となる。ここで、ＴＣＰ通信は、通信エラーの発生によりウィンドウサイズを減少させ、データの転送速度が低下する。この転送速度が低下したときに、ＵＤＰ通信を行うことでデータ転送速度の低下を防ぐことが可能となる。
【００４８】
特に、電波環境の悪化などによりリンクエラーが発生した場合には、データの転送速度を落とす必要はない。そこで、ＴＣＰ通信のデータ転送速度が回復するまでの間ＵＤＰ通信も並行して行うことで、リンクエラーが発生した場合でも効率的な無線パケット通信を行うことができる。
【００４９】
なお、本実施形態に係る無線通信装置では、従来のＴＣＰプロトコルおよびＵＤＰプロトコルに修正を加えずそのまま利用している。そのため、無線媒体（例えば、携帯電話網や衛星通信）の種類に拘わらず、どのような無線媒体にも適用することが可能である。また、ネットワーク側の装置に修正を加える必要がない。すなわち、送受信端末のプログラ
ムのみによって、リンクエラーがあってもデータ転送速度が低下しない無線通信を実現することができる。
【００５０】
＜変形例１＞
上記の処理は、無線通信による通信エラーのほとんどがリンクエラーによるものであることを前提としている。したがって、ＴＣＰ通信において通信エラーが発生した場合は、ＵＤＰによっても同時に通信を開始していた。しかしながら、無線通信においても輻輳が発生することがあり得る。この場合、ＵＤＰによっても同時に通信を開始するとさらなる輻輳を招き好ましくない。
【００５１】
輻輳が発生することを考慮して、送信端末１０におけるＴＣＰ通信の監視処理を図７のフローチャートに示す処理に修正することが好ましい。図３と図７のフローチャートに示す処理の差は、図７のフローチャートにＳ３０５の後にＳ７０１が付け加えられた点のみである。Ｓ７０１では、輻輳ウィンドウ値ｃｗｎｄの増加Δｃｗｎｄが所定の値Δ以上であるか否か判定している。すなわち、輻輳ウィンドウ値が所定値以上回復したか否か判定している。そして、輻輳ウィンドウ値の回復が早い（Ｓ７０１−ＹＥＳ）場合はＵＤＰによる送信を続行し、回復が遅い（Ｓ７０１−ＮＯ）場合にはＵＤＰによる送信を停止している。これは、通信エラーがリンクエラーによるものである場合には輻輳ウィンドウ値は早期に増加するのに対して、通信エラーが輻輳によるものである場合には輻輳ウィンドウ値の増加に時間がかかるためである。
【００５２】
なお、図７のフローチャートでは輻輳ウィンドウ値の増加量Δｃｗｎｄを毎回調べているが、通信エラーの発生からの経過時間をタイマーによって計測し、所定時間後に１回または数回だけ調べるようにしても良い。
【００５３】
＜変形例２＞
上記の実施形態においては、通信エラーが発生した場合は、ＴＣＰ送信部１１とＵＤＰ送信部１３とで同じパケットを２回送信している。通信エラー発生時は、ＴＣＰ通信はウィンドウサイズを減少させるのでＵＤＰ通信の方が高速となる。ＵＤＰ通信によって送信され、受信端末２０への到達が確認されたパケットについてはＴＣＰ送信部１１で送信する必要がない。したがって、ＵＤＰ通信によって既に受信端末２０へ到達が確認されたパケットをＴＣＰ送信部１１は送信しなくても良い。
【００５４】
この処理は以下のようにして実現することができる。送信端末１０側では、コントローラ１２がＴＣＰ送信部１１に通知して、ＴＣＰ送信部１１がこのパケットを送信済みと見なせるようにすればよい。また、受信端末２０側では、コントローラ２２がＴＣＰ受信部２１に通知して、ＴＣＰ受信部２１がこのパケットを受信済みと見なせるようにすればよい。なお、この処理はＵＤＰパケットの到達が確認されるたびに行っても良く、送信端末１０がＵＤＰによる送信を停止するときのみ行っても良い。特に、送信端末１０がＵＤＰによる送信を停止するときに上記の処理を行うことで、ＵＤＰで既に送信したパケットを送り続けることが無くなるので、スループットが向上する。
【００５５】
＜変形例３＞
上記の実施形態においては、送信端末１０のアプリケーション１４は基本的にＴＣＰ送信部１１とやりとりを行い、受信端末２０のアプリケーション２４は基本的にＴＣＰ受信部２１とやりとりを行う構成を採っている。そして、コントローラ１２，２２は、基本的にアプリケーション１４，２４と直接やりとりをしていない。
【００５６】
しかしながら、コントローラがＴＣＰとＵＤＰによる通信をラップして、アプリケーションと直接やりとりをする構成を採用することもできる。図８は、このような構成による
無線通信装置の機能ブロック図である。送信端末３０のアプリケーション３４は、コントローラ３２に対してデータの送信を指示する。コントローラ３２は、まずＴＣＰ送信部３１によってデータの送信を行い、ＴＣＰで通信エラーを発生した場合にはＵＤＰ送信部３３も使ってデータの送信を行う。受信端末４０では、ＴＣＰ受信部４１とＵＤＰ受信部４３とによってデータの受信を行い、コントローラ４２がパケットの順序制御を行い、アプリケーション４４に受信データを渡す。具体的な処理の流れは上記の説明とほぼ同様であるため詳しい説明は省略する。
【００５７】
＜変形例４＞
上記の実施形態においては、プロトコルとしてＴＣＰとＵＤＰを利用している。しかしながら、ＴＣＰの代わりに、通信エラーの発生を検知してデータ転送速度を制御するプロトコルであればどのようなプロトコルを用いることもできる。そのようなプロトコルとしては、既存のものであれば、ＳＣＴＰを挙げることができる。
【００５８】
また、ＵＤＰの代わりにデータ転送速度の制御を行わないプロトコルであればどのようなプロトコルを用いることもできる。既存のプロトコルとしてはＵＤＰが最も適したものではあるが、その他のプロトコルの使用を妨げるものではない。
【図面の簡単な説明】
【００５９】
【図１】本実施形態に係る無線通信装置の機能ブロックを示す図である。
【図２】受信端末の初期化処理の流れを示すフローチャートである。
【図３】送信端末におけるＴＣＰ通信の監視処理の流れを示すフローチャートである。
【図４】ＵＤＰ送信部が送信するパケットの構造を示す図である。
【図５】送信端末におけるＵＤＰパケットに対する到達確認処理の流れを示すフローチャートである。
【図６】受信端末におけるＵＤＰパケット受信時の処理の流れを示すフローチャートである。
【図７】送信端末におけるＴＣＰ通信の監視処理の流れを示すフローチャートである。
【図８】変形例に係る無線通信装置の機能ブロックを示す図である。
【図９】ウィンドウ制御を説明する図である。
【図１０】（ａ）は通信エラーが輻輳のみによる場合のウィンドウサイズの変化を示す図であり、（ｂ）は通信エラーがリンクエラーによっても生じる場合のウィンドウサイズの変化を示す図である。
【符号の説明】
【００６０】
１０ 送信端末
１１ ＴＣＰ送信部
１２ コントローラ
１３ ＵＤＰ送信部
２０ 受信端末
２１ ＴＣＰ受信部
２２ コントローラ
２３ ＵＤＰ受信部
【特許請求の範囲】
【請求項１】
無線パケット通信を行う無線通信装置であって、
通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、
データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、
前記第１の送信手段がパケットを送信している際に通信エラーが発生した場合は、前記第１の送信手段が送信するパケットを前記第２の送信手段によっても送信する通信制御手段と、
を有することを特徴とする無線通信装置。
【請求項２】
前記通信制御手段は、前記第２の送信手段によってパケットの送信を開始した後に、前記第１の送信手段によるデータ転送速度が前記通信エラー発生時のデータ転送速度まで回復した場合に、前記第２の送信手段によるパケットの送信を停止する
ことを特徴とする請求項１に記載の無線通信装置。
【請求項３】
前記通信制御手段は、前記第１の送信手段による送信における前記通信エラーが輻輳によるものと判断した場合は、前記第２の送信手段によるパケットの送信を停止する
ことを特徴とする請求項１または２に記載の無線通信装置。
【請求項４】
前記通信制御手段は、前記第１の送信手段のデータ転送速度が所定の増加率以上で増加した場合は、前記第１の送信手段における通信エラーが輻輳によるものではないと判断する
ことを特徴とする請求項３に記載の無線通信装置。
【請求項５】
前記第２の送信手段が送信したパケットが送信先まで到達したことを確認する送達確認手段をさらに備える
ことを特徴とする請求項１〜４のいずれかに記載の無線通信装置。
【請求項６】
前記送達確認手段によって前記第２の送信手段が送信したパケットが送信先まで到達したことが確認できなかった場合には、該パケットを前記第２の送信手段によって再送する
ことを特徴とする請求項５に記載の無線通信装置。
【請求項７】
前記第１の送信手段はＴＣＰプロトコルにしたがってパケットを送信し、
前記第２の送信手段はＵＤＰプロトコルにしたがってパケットを送信する
ことを特徴とする請求項１〜６のいずれかに記載の無線通信装置。
【請求項８】
通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、
データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置が行う無線通信方法であって、
前記第１の送信手段によって、パケットの送信を開始するステップと、
前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、
を含むことを特徴とする無線通信方法。
【請求項９】
通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場
合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、
データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置に対して無線通信を実行させるプログラムであって、
前記第１の送信手段によって、パケットの送信を開始するステップと、
前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、
を実行させることを特徴とするプログラム。
【請求項１】
無線パケット通信を行う無線通信装置であって、
通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、
データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、
前記第１の送信手段がパケットを送信している際に通信エラーが発生した場合は、前記第１の送信手段が送信するパケットを前記第２の送信手段によっても送信する通信制御手段と、
を有することを特徴とする無線通信装置。
【請求項２】
前記通信制御手段は、前記第２の送信手段によってパケットの送信を開始した後に、前記第１の送信手段によるデータ転送速度が前記通信エラー発生時のデータ転送速度まで回復した場合に、前記第２の送信手段によるパケットの送信を停止する
ことを特徴とする請求項１に記載の無線通信装置。
【請求項３】
前記通信制御手段は、前記第１の送信手段による送信における前記通信エラーが輻輳によるものと判断した場合は、前記第２の送信手段によるパケットの送信を停止する
ことを特徴とする請求項１または２に記載の無線通信装置。
【請求項４】
前記通信制御手段は、前記第１の送信手段のデータ転送速度が所定の増加率以上で増加した場合は、前記第１の送信手段における通信エラーが輻輳によるものではないと判断する
ことを特徴とする請求項３に記載の無線通信装置。
【請求項５】
前記第２の送信手段が送信したパケットが送信先まで到達したことを確認する送達確認手段をさらに備える
ことを特徴とする請求項１〜４のいずれかに記載の無線通信装置。
【請求項６】
前記送達確認手段によって前記第２の送信手段が送信したパケットが送信先まで到達したことが確認できなかった場合には、該パケットを前記第２の送信手段によって再送する
ことを特徴とする請求項５に記載の無線通信装置。
【請求項７】
前記第１の送信手段はＴＣＰプロトコルにしたがってパケットを送信し、
前記第２の送信手段はＵＤＰプロトコルにしたがってパケットを送信する
ことを特徴とする請求項１〜６のいずれかに記載の無線通信装置。
【請求項８】
通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、
データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置が行う無線通信方法であって、
前記第１の送信手段によって、パケットの送信を開始するステップと、
前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、
を含むことを特徴とする無線通信方法。
【請求項９】
通信エラーが発生していない場合はデータ転送速度を増加し、通信エラーが発生した場
合はデータ転送速度を減少するプロトコル、にしたがってパケットを送信する第１の送信手段と、
データ転送速度の制御を行わないプロトコルにしたがってパケットを送信する第２の送信手段と、を有する無線通信装置に対して無線通信を実行させるプログラムであって、
前記第１の送信手段によって、パケットの送信を開始するステップと、
前記第１の送信手段によるパケット送信において通信エラーが発生した際に、前記第１の送信手段が送信するパケットを、前記第２の送信手段によっても送信するステップと、
を実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００８−５３９０（Ｐ２００８−５３９０Ａ）
【公開日】平成２０年１月１０日（２００８．１．１０）
【国際特許分類】
【出願番号】特願２００６−１７５１０６（Ｐ２００６−１７５１０６）
【出願日】平成１８年６月２６日（２００６．６．２６）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２０年１月１０日（２００８．１．１０）
【国際特許分類】
【出願日】平成１８年６月２６日（２００６．６．２６）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]