JP2015170955A - 通信方法、通信制御プログラム、及び、通信装置 - Google Patents

Abstract

【課題】プロトコル切り替えのタイムラグを最小化できるようにする。
【解決手段】プロトコルの切り替えトリガが発生するよりも前に、第１及び第２のプロトコルの一方の送信データと同じ送信データを他方のプロトコルの送信バッファ７５１Ｕ／Ｔに重複して書き込み、前記切り替えトリガの発生に応じて、前記一方のプロトコルから前記他方のプロトコルへの切り替えを実施する。
【選択図】図６

Description

本発明は、通信方法、通信制御プログラム、及び、通信装置に関する。

下記の特許文献１〜４には、送信装置と受信装置との間の通信に用いるプロトコルを、通信品質に応じて、ＵＤＰ（user datagram protocol）及びＴＣＰ（transmission control protocol）のいずれかに切り替える手法が記載されている。

特開２００１−２９８４７９号公報 特開２００３−１２５０２０号公報 特開２００１−１４２４８８号公報 特開２０００−１５１６８０号公報

しかしながら、特許文献１〜４には、プロトコルを切り替える要因が発生してプロトコルを切り替える際に、送信装置での送信データのバッファ手法によっては切り替えタイミングにタイムラグ（遅延）が生じ得ることに関して何ら言及、検討されていない。

本発明の目的の１つは、プロトコル切り替えのタイムラグを最小化できるようにすることにある。

通信方法の一態様は、第１のプロトコル及び第２のプロトコルのいずれかを用いて通信する通信方法であって、プロトコルの切り替えトリガが発生するよりも前に、前記第１及び第２のプロトコルの一方の送信データと同じ送信データを他方のプロトコルの送信バッファに重複して書き込み、前記切り替えトリガの発生に応じて、前記一方のプロトコルから前記他方のプロトコルへの切り替えを実施する。

プロトコル切り替えのタイムラグを最小化できる。

ＷＡＮ最適化装置を適用した通信システムの一例を示すブロック図である。 図１に例示する通信システムにおいて現用系（ＴＣＰ）と予備系（ＵＤＰ）とを切り替える場合の動作例を模式的に例示する概念図である。 図２に例示する動作例の改善例を模式的に例示する概念図である。 第１実施形態に係る通信システムの構成例を示すブロック図である。 図４に例示する無線端末（ＷＯ＃１）の構成例を示すブロック図である。 図５に例示する仮想ソケット処理部、送信処理部、制御部及びプロトコル指定テーブルに着目した無線端末（ＷＯ＃１）の構成例を示すブロック図である。 図４に例示する無線基地局（ＷＯ＃２）の構成例を示すブロック図である。 図４に例示する通信システムにおいてアップストリームの送信側のＷＯ＃１と受信側のＷＯ＃２との間の品質計測に着目した動作概要を説明する図である。 図４に例示する無線端末（ＷＯ＃１）及び無線基地局（ＷＯ＃２）のハードウェア構成例を示すブロック図である。 図５に例示する無線端末（ＷＯ＃１）において用いられるプロトコル選択テーブルの一例を示す図である。 図５に例示する無線端末（ＷＯ＃１）において用いられるプロトコル指定テーブルの一例を示す図である。 図４に例示する通信システムにおいて用いられる、ＵＤＰベースプロトコルのデータパケットフォーマット例を示す図である。 図４に例示する通信システムにおいて用いられる、ＴＣＰベースプロトコルのデータパケットフォーマット例を示す図である。 図４に例示する通信システムにおいて用いられる、ＵＤＰベースプロトコルの計測パケットフォーマット例を示す図である。 図４に例示する通信システムにおいて用いられる、ＴＣＰベースプロトコルの計測パケットフォーマット例を示す図である。 図４に例示する通信システムにおいて用いられる、ネゴシエーション要求メッセージのフォーマット例を示す図である。 図１６に例示するネゴシエーション要求メッセージに対するネゴシエーション応答メッセージのフォーマット例を示す図である。 図４に例示する通信システムにおいて用いられる、計測結果通知メッセージのフォーマット例を示す図である。 図４に例示する通信システムの動作例を説明するシーケンス図である。 図４に例示する通信システムの動作例を説明するシーケンス図である。 図４に例示する通信システムの動作例を説明するシーケンス図である。 図４〜図６及び図８に例示する無線端末（ＷＯ＃１）における制御部の動作例を説明するフローチャートである。 第２実施形態に係る通信システムの構成例を示すブロック図である。 第３実施形態に係る通信システムにおいて用いられるプロトコル選択テーブルの一例を示す図である。 （Ａ）は第４実施形態に係る通信システムにおいて用いられるプロトコル選択テーブルの一例を示す図であり、（Ｂ）は（Ａ）に例示するプロトコル選択テーブルにおけるクリティカルリージョン（ＣＲ）を決めるパラメータの一例を説明する図である。 第５実施形態に係る通信システムの構成例を示すブロック図である。 図２６に例示する通信システムにおける無線端末（ＷＯ＃１）及び無線基地局（ＷＯ＃２）の構成例と動作例とを説明する図である。 図２６及び図２７に例示する通信システムにおいて用いられる、生存確認（キープアライブ）メッセージのフォーマット例を示す図である。 図２８に例示する生存確認メッセージに対する生存確認（キープアライブ）応答メッセージのフォーマット例を示す図である。 第６実施形態に係る通信システムにおいて用いられる、ランダムパリティストリーム（ＲＰＳ）プロトコル通信を説明する概念図である。 第６実施形態に係る通信システムにおける無線端末（ＷＯ＃１）及び無線基地局（ＷＯ＃２）の構成例と動作例とを説明する図である。 図３１に例示する通信システムにおいて用いられるプロトコル指定テーブルの一例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

クラウド利用の増加とワイヤレスブロードバンドの普及とが相まって、クラウドデータセンタのサーバに移動無線端末からアクセスする利用形態が増えている。クラウドデータセンタは、海外や地理的に遠方に存在することが多いため、通信の往復遅延時間（ＲＴＴ）が大きくなる傾向にある。一方、無線網では、無線回線の品質によって、データの廃棄や遅延が変動しやすい。ＲＴＴが大きい回線を用いてＴＣＰ通信を行なう場合、いったん廃棄が発生すると、性能（例えば、スループット）が低下し易い。

そこで、近年、ワイドエリアネットワーク（ＷＡＮ）高速化装置あるいはＷＡＮ最適化装置（ＷＡＮオプティマイザ：ＷＯ）と称される装置をＷＡＮの両端に配置することで、エンドデバイス間の平均スループットを改善することが試みられている。

図１にＷＡＮ最適化装置を適用した通信システムの一例を示す。図１に示す通信システム１は、例示的に、端末１０と、ＷＡＮ３０と、サーバ５０と、ＷＡＮ最適化装置７０及び９０（ＷＯ＃１及びＷＯ＃２）と、を備える。サーバ５０は、例えば、クラウドデータセンタ等に設置されてよい。ＷＡＮ３０は、無線アクセス網を含む概念として捉えてよい（以下、同様）。そのため、以下において、ＷＡＮ３０を無線アクセス網３０と表記することがある。

端末１０及びサーバ５０は、互いに、ＷＡＮ最適化装置７０、９０及びＷＡＮ３０を介して相互に通信することが可能である。例えば、端末１０は、アプリケーション（ＡＰＬ）＃１によって生成された、サーバ５０のＡＰＬ＃２宛のデータを、サーバ５０との間の通信に適した通信プロトコル（例えば、ＴＣＰ）で送信する。

端末１０から送信されたデータは、ＷＡＮ最適化装置７０にて受信、終端され、ＷＡＮ３０への送信に適した（あるいは最適化された）通信プロトコルのデータに変換されてＷＡＮ３０へ送信される。当該通信プロトコルは、例示的に、ＴＣＰ通信の平均スループットよりも高速なプロトコルであり、「高速通信プロトコル」と称してもよい。高速通信プロトコルの一例については後述する。

ＷＡＮ最適化装置７０からＷＡＮ３０へ高速通信プロトコルにて送信されたデータは、対向のＷＡＮ高速化装置９０にて受信、終端され、サーバ５０との間の通信に適した通信プロトコル（例えば、ＴＣＰ）のデータに変換されてサーバ５０へ送信される。

サーバ５０のＡＰＬから端末１０のＡＰＬへの逆方向の通信ついても上記と同様である。例えば、サーバ５０は、ＡＰＬ＃２によって生成された端末１０のＡＰＬ＃１宛のデータを、端末１０との通信に適した通信プロトコル（例えば、ＴＣＰ）で送信する。

サーバ５０から送信されたデータは、ＷＡＮ最適化装置９０にて受信、終端され、ＷＡＮ３０への送信に適した（あるいは最適化された）通信プロトコルのデータに変換されてＷＡＮ３０へ送信される。

ＷＡＮ最適化装置９０からＷＡＮ３０へ高速通信プロトコルにて送信されたデータは、対向のＷＡＮ高速化装置７０にて受信、終端され、端末１０との通信に適した通信プロトコル（例えば、ＴＣＰ）のデータに変換されて端末１０へ送信される。

このように、ＷＡＮ最適化装置７０及び９０は、端末１０とサーバ５０との間のＴＣＰセッションを一旦終端し、高速通信プロトコルに変換して対向のＷＡＮ最適化装置９０及び７０と通信する。対向のＷＡＮ高速化装置９０及び７０では、高速通信プロトコルを元の通信プロトコルに戻してサーバ５０及び端末１０とそれぞれ通信する。

これにより、エンドデバイス（本例では、端末１０及びサーバ５０）間の通信の輻輳制御や再送制御を、ＷＡＮ最適化装置７０及び９０間の輻輳制御や再送制御に置き換えることが可能となる。したがって、例えば、データの廃棄等が発生しても、ＷＡＮ最適化装置７０及び９０間の輻輳制御や再送制御によって、スループットの低下を抑制することが可能である。

ＷＡＮ最適化装置７０及び９０間に適用可能な高速通信プロトコルの非限定的な一例としては、ＴＣＰベースの通信プロトコルと、ＵＤＰベースの通信プロトコルと、が挙げられる。ＴＣＰベースの高速通信プロトコルの一例としては、ハイスピードＴＣＰが挙げられる。ＵＤＰベースの高速通信プロトコルの一例としては、ＵＤＴプロトコルが挙げられる。ＵＤＴは、「UDP-based data transfer」の略称であり、ＵＤＰに輻輳制御及び再送制御を付加した通信プロトコルに相当する。

無線回線のような遅延が大きくデータの廃棄が生じ易い回線では、ＴＣＰベースの通信プロトコルによると、いったん廃棄が発生した場合、スループットが大きく低下し易い。これに対し、ＵＤＰベースの通信プロトコルによれば、ＴＣＰベースの通信プロトコルよりも平均的に高いスループットを得ることができる。

しかし、ＵＤＰベースの通信プロトコルは、オーバヘッドがＴＣＰベースの通信プロトコルよりも大きいため、データの廃棄が少ない場合には、ＴＣＰベースの通信プロトコルの方が高いスループットを得ることができる。

このように、ＴＣＰベースの通信プロトコルとＵＤＰベースの通信プロトコルとでは、通信品質に応じて良好な性能（例えば、スループット）を得られる領域に違いがある。無線回線では、端末１０の移動や、他の電波の干渉等の影響によって通信品質が変化しやすい。

そこで、例えば、２つのＷＡＮ最適化装置７０及び９０の間に、ＵＤＰベースの通信プロトコルのパスと、ＴＣＰベースの通信プロトコルのパスと、を予め設定しておく。そして、通信回線の品質に応じて適切なパスを選んでデータを転送すれば、効率的なデータ伝送が可能になる。

ＵＤＰとＴＣＰとをネットワークの通信品質に応じて動的に切り替える技術については、下記の参考文献にも記載がある。
参考文献：真鍋準次ほか、「ネットワークの状況に応じてＴＣＰとＵＤＰを動的に切替えるファイル転送方式」（信学技報ＩＮ２０１１−１２）

ここで、データを伝送する通信路（例えば、パス）を切り替える技術として、「１：１プロテクション」あるいは「１＋１プロテクション」等のプロテクション技術が知られている。

「１＋１プロテクション」では、現用系及び予備系の双方のパスに同じデータを伝送しておく。そして、パス障害や通信品質低下等の切り替え要因が検出されると、各パスの受信端において、切り替え要因の発生していない方のパスのデータを選択受信する。これに対し、「１：１プロテクション」では、切り替え要因を検出してから、代替的なパスの設定及び有効化を行なう。

しかしながら、「１＋１プロテクション」では、現用系及び予備系の双方のパスに同じデータを送信するため、通信の帯域を無駄に使ってしまう。一方、「１：１プロテクション」では、切り替え要因の検出から代替的なパスへの切り替えまでの間に送信されたデータが破棄されてしまうことがある。

例えば、ＵＤＰとＴＣＰとを通信品質に応じて動的に切り替えることが可能な送信装置について、ＴＣＰのパスを現用系パス、ＵＤＰのパスを予備系パスとして、「１：１プロテクション」を適用する場合について検討する。

当該送信装置は、例示的に、ＴＣＰ（現用系）及びＵＤＰ（予備系）のそれぞれに対応した送信バッファを備える。そして、例えば図２に模式的に示すように、通常時には、送信装置は、現用系（ＴＣＰ）の送信バッファに、送信データ（＃４〜＃１２）を、順次、書き込んでゆく。なお、図２において、送信データ＃４〜＃６は、ＴＣＰの送信バッファから読み出された送信済みのデータを表している。

その後に、ＴＣＰでの通信品質の低下等の切り替え要因を検出すると、送信装置は、その後に送信すべき送信データの書き込み先を予備系（ＵＤＰ）の送信バッファに切り替える。したがって、図２において、送信データ＃１３〜＃１５は、ＵＤＰの送信バッファに書き込まれることになる。

しかし、切り替え要因発生までにＴＣＰの送信バッファに既に書き込まれた未送信の送信データ＃７〜＃１２については、ＵＤＰへの切り替えが実施されたにも関わらず、そのままＴＣＰの送信データとして送信されてしまう。その結果、当該送信データは、受信装置において不適切な通信プロトコルのデータとして破棄されることになる。

ＴＣＰからＵＤＰへの切り替えタイミングを切り替え要因の検出タイミングよりも遅らせれば、未送信の送信データ＃７〜＃１２についても切り替え後のＵＤＰでの送信が可能になるかもしれない。

しかし、この場合、プロトコル切り替えにタイムラグが発生するため、プロトコル切り替えによって得られる効果が薄くなる。例えば、送受信装置間の伝送距離が長く遅延が大きいほど、スループット改善のためにより大きな送信バッファを用いることとすると、プロトコル切り替えタイミングの遅延が更に大きくなると考えられる。

そこで、本実施形態では、例えば図３に模式的に示すように、通信品質の低下等の切り替え要因を検出したタイミングで、現用系において未送信の送信データ＃７〜＃１２を予備系で送信できるようにする。

（第１実施形態）
図４は、第１実施形態に係る通信システム１の構成例を示すブロック図である。図４に示す通信システム１は、例示的に、図１に例示した端末１０の一例としての無線端末１０と、図１に例示したサーバ５０及びＷＡＮ最適化装置９０（ＷＯ＃２）と、無線基地局１００と、を備える。

図４において、図１に例示したＷＡＮ最適化装置７０（ＷＯ＃１）は、無線端末１０に組み込まれている。例示的に、ＷＯ＃１は、プログラム（あるいは「ソフトウェア」と称してもよい。）で提供される仮想的（論理的）なアプライアンスとして無線端末１０のオペレーティングシステム（ＯＳ）やプロットフォーム上にインストールされてよい。

ただし、ＷＯ＃１は、無線端末１０に付属（外付け）の物理的なアプライアンスとして提供されてもよい。ＷＯ＃２についても同様である。例えば、ＷＯ＃２は、無線基地局１００に付属あるいは内蔵の物理的なアプライアンスとして提供されてもよいし、ソフトウェアで提供される仮想的なアプライアンスとして無線基地局１００のＯＳやプラットフォーム上にインストールされてもよい。

サーバ５０、ＷＡＮ最適化装置９０及び無線基地局１００は、例示的に、有線によって接続（通信）可能であり、無線端末１０は、無線基地局１００と無線によって接続（通信）可能である。無線基地局１００の非限定的な一例は、ＷｉＦｉ通信が可能な基地局である。当該基地局１００は、アクセスポイント（ＡＰ）と称してもよい。以下において、無線基地局１００を「ＷｉＦｉ基地局１００」と称することがある。

ＷＯ＃１及びＷＯ＃２の間には、ＵＤＰベースの高速通信プロトコルのパスと、ＴＣＰベースの高速通信プロトコルのパスと、が設定可能である。無線端末１０のＡＰＬ＃１とＷＯ＃１との間、及び、サーバ５０のＡＰＬ＃２とＷＯ＃２との間は、それぞれ、ＴＣＰ通信が可能である。なお、以下において、ＵＤＰベースの高速通信プロトコルを「ＵＤＰベースプロトコル」と称し、ＴＣＰベースの高速通信プロトコルを「ＴＣＰベースプロトコル」と称することがある。

（無線端末構成例）
図５は、図４に例示した無線端末１０のＷＡＮ最適化装置７０（ＷＯ＃１）に着目した構成例を示すブロック図である。図５に示す無線端末１０（ＷＯ＃１）は、例示的に、入出力インタフェース（ＩＦ）７１、ＴＣＰ処理部７２、プロキシ処理部７３、仮想ソケット処理部７４、送信処理部７５、受信処理部７６、及び、無線ＩＦ７７を備える。更に、ＷＯ＃１は、制御部７８、プロトコル選択テーブル７９Ａ、及び、プロトコル指定テーブル７９Ｂを備える。

入出力ＩＦ７１は、例示的に、ＡＰＬとの間のインタフェースを提供し、ＡＰＬが生成した送信データをＴＣＰ処理部７２へ送信する。また、入出力力ＩＦ７１は、ＴＣＰ処理部７２から受信した、ＡＰＬ＃１宛のデータをＡＰＬ＃１へ送信する。

ＴＣＰ処理部７２は、入出力ＩＦ７１から受信したデータをＴＣＰのパケットデータ（以下「ＴＣＰパケット」又は「送信パケット」又は単に「パケット」と称することがある。）に変換してプロキシ処理部７３へ送信する。また、ＴＣＰ処理部７２は、プロキシ処理部７３から受信したＴＣＰパケットを受信データに変換して入出力ＩＦ７１へ送信する。

プロキシ処理部７３は、ＴＣＰ処理部７２から受信したＴＣＰパケットに対してプロキシ設定を必要に応じて行ない、ＴＣＰパケットを仮想ソケット処理部７４へ送信する。また、プロキシ処理部７３は、ＴＣＰパケットとして同期（ＳＹＮ）パケットを受信すると、仮想ソケット処理部７４に対してソケットの生成を要求する。更に、プロキシ処理部７３は、仮想ソケット処理部７４から受信したＴＣＰパケットをＴＣＰ処理部７２へ送信する。

仮想ソケット処理部７４は、プロキシ処理部７３やＡＰＬ＃１に対してソケットアプリケーションプログラミングインタフェース（ソケットＡＰＩ）を提供する。また、仮想ソケット処理部７４は、制御部７８の指示に応じて、プロキシ処理部７３から受信したパケットに対して共通シーケンス番号を付与する。共通シーケンス番号を付与されたパケットは、送信処理部７５に備えられた、図６に例示する各ソケットバッファ７５１Ｕ及び７５１Ｔのいずれかに書き込まれる。

共通シーケンス番号は、例示的に、ＵＤＰベースプロトコル及びＴＣＰベースプロトコル等のプロトコルの相違に依存しないシーケンス番号であり、図６に例示する共通シーケンス番号付与部７４１によってパケットに付与される。各送信ソケットバッファ７５１Ｕ及び７５１Ｔへのデータの書き込みは、共通シーケンス番号で区切られたセグメントを単位に行なってよい。

また、仮想ソケット処理部７４は、受信処理部７６から受信したパケットをプロキシ処理部７３へ送信する。受信処理部７６の構成例は、図７により後述するＷＯ＃２における受信処理部９２と同様でよい。

送信処理部７５は、仮想ソケット処理部７４から受信した送信データを、ＵＤＰベースプロトコル及びＴＣＰベースプロトコルのいずれかのパケットに変換して、無線ＩＦ７７を通じてＷＡＮ３０へ送信する。

送信処理部７５は、図６に例示するように、ＵＤＰ送信ソケットバッファ７５１Ｕ、ＴＣＰ送信ソケットバッファ７５１Ｔ、ＵＤＰベースプロトコル送信処理部７５２Ｕ、ＴＣＰベースプロトコル送信処理部７５２Ｔ、及び、パケットフィルタ部７５３を備える。

ＵＤＰ送信ソケットバッファ７５１Ｕは、ＵＤＰベースプロトコルで送信すべきパケットを一時的に保持する。当該保持により、ＵＤＰベースプロトコル送信処理部７５２Ｕのデータ送信レートと、仮想ソケット処理部７４によるＵＤＰ送信ソケットバッファ７５１Ｕへのデータの書き込みレートと、の差を吸収することが可能である。

ＴＣＰ送信ソケットバッファ７５１Ｔは、ＴＣＰベースプロトコルで送信すべきＴＣＰパケットを一時的に保持する。当該保持により、ＴＣＰベースプロトコル送信処理部７５２Ｔのデータ送信レートと、仮想ソケット処理部７４によるＴＣＰ送信ソケットバッファ７５１Ｔへのデータの書き込みレートと、の差を吸収することが可能である。

ＵＤＰベースプロトコル送信処理部７５２Ｕは、ＵＤＰ送信ソケットバッファ７５１Ｕに書き込まれたパケットをＵＤＰベースプロトコルに応じた所定のレートで送信する処理部の一例である。また、ＵＤＰベースプロトコル送信処理部７５２Ｕは、例示的に、再送バッファ７５５Ｕを備え、送信したパケットに対する確認応答（ＡＣＫ／ＮＡＣＫ）が受信されるまで、一時的に、当該パケットを再送バッファ７５５Ｕに蓄積する。例えば、ＡＣＫが受信されると、再送バッファ７５５Ｕに蓄積されたパケットは破棄される。ＮＡＣＫが受信されると、再送バッファ７５５Ｕに蓄積されたパケットが再送される。

更に、ＵＤＰベースプロトコル送信処理部７５２Ｕは、例示的に、品質計測部７５６Ｕを備える。品質計測部７５６Ｕは、ＵＤＰベースプロトコルを用いて後述の計測パケットを送信したり、データパケットの送信間隔を調整（変化）したりすることで、ＷＡＮ３０の通信品質を測定する。

なお、「通信品質」の非限定的な一例としては、対向のＷＯ＃２との間（ＷＡＮ３０）におけるデータの廃棄率や往復遅延時間（ＲＴＴ）、帯域幅等が挙げられる。また、品質計測部７５６Ｕは、図７にて後述する受信側の品質計測部９２５Ｕでの測定結果を、例えば制御部７８を通じて受信可能である。

ＴＣＰベースプロトコル送信処理部７５２Ｔは、ＴＣＰ送信ソケットバッファ７５１Ｔに書き込まれたパケットをＴＣＰベースプロトコルに応じた所定のレートで送信する処理部の一例である。また、ＴＣＰベースプロトコル送信処理部７５２Ｔは、例示的に、再送バッファ７５５Ｔを備え、送信したパケットに対する確認応答（ＡＣＫ／ＮＡＣＫ）が受信されるまで、一時的に、当該パケットを再送バッファ７５５Ｔに蓄積する。例えば、ＡＣＫが受信されると、再送バッファ７５５Ｔに蓄積されたパケットは破棄される。ＮＡＣＫが受信されると、再送バッファ７５５Ｔに蓄積されたパケットが再送される。

更に、ＴＣＰベースプロトコル送信処理部７５２Ｔは、例示的に、品質計測部７５６Ｔを備える。品質計測部７５６Ｔは、ＴＣＰベースプロトコルを用いて後述の計測パケットを送信したり、データパケットの送信間隔を調整（変化）したりすることで、ＷＡＮ３０の通信品質を測定する。また、品質計測部７５６Ｔは、図７にて後述する受信側の品質計測部９２５Ｔでの測定結果を、例えば制御部７８を通じて受信可能である。

パケットフィルタ部７５３は、各プロトコル送信処理部７５２Ｕ及び７５２Ｔから受信したパケットに付与された共通シーケンス番号を基に、プロトコル指定テーブル７９Ｂを参照してパケットフィルタリングを行なう。例示的に、パケットフィルタ部７５３は、共通シーケンス番号に対応付けられたプロトコルの送信パケットは通過させるが、そうでないプロトコルの送信パケットは破棄する。

別言すると、パケットフィルタ部７５３は、プロトコル指定テーブル７９Ｂで指定（あるいは選択）されないパケットをフィルタする。フィルタ（破棄）されたパケットについて、パケットフィルタ部７５３は、当該パケットを送信したプロトコル送信処理部７５２Ｕ又は７５２Ｔに対し、再送バッファ７５５Ｕ又は７５５Ｔに蓄積されたパケットの再送をキャンセルする指示を与える。

図５に例示した無線ＩＦ７７は、例示的に、無線基地局１００との間の無線通信を可能にするＩＦを提供し、パケットフィルタ部７５３を通過した送信パケットを無線により無線基地局１００へ送信する。

プロトコル選択テーブル７９Ａは、データの廃棄率やＲＴＴ等の通信品質の指標となる情報（パラメータ）を基に、より高い性能（例えば、平均スループット）が得られるプロトコルを決定する制御データの一例である。当該制御データには、例示的に、プロトコルを切り替えるポイントの近傍（以下「クリティカルリージョン（ＣＲ）」とも称する。）を判断可能なデータが含まれてよい。ＣＲは、プロトコルの切り替えトリガの発生要因となる通信品質を示すポイントを含む所定の通信品質領域の一例である。プロトコル選択テーブル７９Ａの詳細については、図１０により後述する。

プロトコル指定テーブル７９Ｂは、図１１に例示するように、共通シーケンス番号付与部７４１が付与した共通シーケンス番号をもつパケットを、ＵＤＰベース及びＴＣＰベースの各プロトコルのいずれで送信するかを対応付けた制御データの一例である。プロトコル指定テーブル７９Ｂは、例示的に、制御部７８によって設定され、既述のように、パケットフィルタ部７５３によって参照される。

制御部７８は、品質計測部７５２Ｕ及び７５２Ｔから計測結果を受信し、当該計測結果を基にプロトコル選択テーブル７９Ａを参照し、各タイミングでの通信品質に適したプロトコルを決定する。また、制御部７８は、共通シーケンス番号付与部７４１が付与した共通シーケンス番号をもつパケットを、ＵＤＰベース及びＴＣＰベースの各プロトコルのいずれで送信するかを示した対応関係をプロトコル指定テーブル７９Ｂに設定（登録）する。

非限定的な一例として、図１１に例示するプロトコル指定テーブル７９Ｂには、共通シーケンス番号１０〜１４が付与されたパケット＃１０〜＃１４はＴＣＰベースプロトコルで送信し、パケット＃１５〜＃２０はＵＤＰベースプロトコルで送信することが指定されている。

なお、パケット＃ｉ（ｉは自然数）は、それぞれ、共通シーケンス番号「ｉ」が付与されたパケットを表す。別言すると、図１１のプロトコル指定テーブル７９Ｂにおいて、シーケンス番号１４及び１５の間が、制御部７８においてプロトコルの切り替え要因が検出されたタイミングに相当すると捉えてよい。本実施形態では、当該タイミングで、ＵＤＰベース及びＴＣＰベースの各プロトコル間の切り替えを実施可能である。なお、当該タイミングを「プロトコル切り替えタイミング」と称することがある。

更に、制御部７８は、通信品質が図１０に例示するプロトコル選択テーブル７９Ａに設定したクリティカルリージョン（ＣＲ）に入ったと判断すると、仮想ソケット処理部７４に対し冗長書き込みを指示する。例えば、制御部７８は、仮想ソケット処理部７４に対し、切り替え候補のプロトコルに対応する各送信ソケットバッファ７５１Ｕ及び７５１Ｔのそれぞれにパケットを書き込むように指示する。

例示的に、図６には、制御部７８において通信品質がＣＲに入ったと判断されて、仮想ソケット処理部７４が、制御部７８の指示に応じて、パケット＃１３〜＃１８を各ソケットバッファ７５１Ｕ及び７５１Ｔの双方に冗長的に（重複して）書き込む様子を模式的に例示している。

したがって、パケットフィルタ部７５３には、双方の送信ソケットバッファ７５１Ｕ及び７５１Ｔに書き込まれたパケット＃１３〜＃１８が、それぞれ、ＵＤＰベースプロトコル送信処理部７５２Ｕ及びＴＣＰベースプロトコル送信処理部７５２Ｔで処理されて入力される。

そして、パケットフィルタ部７５３は、プロトコル指定テーブル７９Ｂに従って、各プロトコル送信処理部７５２Ｕ及び７５２Ｔから入力されたパケット＃１３〜＃１８のフィルタリングを行なう。例えば図１１のプロトコル指定テーブル７９Ｂに示すように、パケット＃１０〜＃１４はＴＣＰベースプロトコルで送信し、パケット＃１５〜＃２０はＵＤＰベースプロトコルで送信することが制御部７８によって指定されていると仮定する。

この場合、パケットフィルタ部７５３は、ＴＣＰベースプロトコル送信処理部７５２Ｔから入力されるパケット＃１３〜＃１８のうち、パケット＃１３及び＃１４を無線ＩＦ７７へ通過させ、パケット＃１５〜＃１８は破棄する。パケット＃１５〜＃１８の破棄に応じて、パケットフィルタ部７５３は、破棄したパケット＃１５〜＃１８の再送をキャンセルする指示をＴＣＰベースプロトコル送信処理部７５２Ｔに与える。

また、パケットフィルタ部７５３は、ＵＤＰベースプロトコル送信処理部７５２Ｕからのパケット＃１３〜＃１８のうち、パケット＃１３及び＃１４を破棄し、パケット＃１５〜＃１８を無線ＩＦ７７へ通過させる。パケット＃１３及び＃１４の破棄に応じて、パケットフィルタ部７５３は、破棄したパケット＃１３及び＃１４の再送をキャンセルする指示をＵＤＰベースプロトコル送信処理部７５２Ｕに与える。

これにより、無線端末１０（ＷＯ＃１）は、プロトコルの切り替え要因が検出されたタイミングで（別言すると、最小限のタイムラグで）プロトコル切り替えを実施して、切り替え後のプロトコルで適切にパケットを送信することが可能となる。

（無線基地局構成例）
次に、図７に、ＷＡＮ最適化装置９０（ＷＯ＃２）を組み込んだ無線基地局１００の構成例を示す。図７に示す無線基地局１００は、例示的に、無線端末１０との無線通信を可能にする無線ＩＦ９１と、ＷＡＮ最適化装置９０（ＷＯ＃２）と、を備える。

ＷＯ＃２は、例示的に、受信処理部９２、送信処理部９３、仮想ソケット処理部９４、プロキシ処理部９５、ＴＣＰ処理部９６、有線ＩＦ９７、制御部９８、プロトコル選択テーブル９９Ａ、及び、プロトコル指定テーブル９９Ｂを備える。

受信処理部９２は、例えば、無線ＩＦ９１を通じて無線端末１０（ＷＯ＃１）から受信されたパケットに対して受信処理を行なう。受信処理には、例示的に、ＵＤＰベースプロトコルに従った受信処理や、ＴＣＰベースプロトコルに従った受信処理等が含まれてよい。

そのため、図７に例示する受信処理部９２は、例えば、ＵＤＰベースプロトコル受信処理部９２１Ｕと、ＴＣＰベースプロトコル受信処理部９２１Ｔと、ＵＤＰ受信ソケットバッファ９２２Ｕと、及びＴＣＰ受信ソケットバッファ９２２Ｔと、を備える。

ＵＤＰベースプロトコル受信処理部９２１Ｕは、無線ＩＦ９１から受信した、ＵＤＰベースプロトコルのパケットを受信処理し、正常に受信できたパケットをＵＤＰ受信ソケットバッファ９２２Ｕへ書き込む。当該書き込みは、共通シーケンス番号で区切られたセグメントを単位に行なってよい。

なお、正常に受信できなかったパケットは、ＵＤＰベースプロトコル受信処理部９２１Ｕにおいて廃棄してよい。ＵＤＰベースプロトコル受信処理部９２１Ｕは、受信パケットの送信元である無線端末１０のＵＤＰベースプロトコル送信処理部７５２Ｕに対し、例えば、確認応答パケットを用いてパケット廃棄の有無を通知し、廃棄されたパケットの再送を要求する。

ＴＣＰベースプロトコル受信処理部９２１Ｔは、無線ＩＦ９１から受信した、ＴＣＰベースプロトコルのパケットを受信処理し、正常に受信できたパケットをＴＣＰ受信ソケットバッファ９２２Ｔへ書き込む。当該書き込みは、共通シーケンス番号で区切られたセグメントを単位に行なってよい。

なお、正常に受信できなかったパケットは、ＴＣＰベースプロトコル受信処理部９２１Ｔにおいて廃棄してよい。ＴＣＰベースプロトコル受信処理部９２１Ｔは、受信パケットの送信元である無線端末１０のＴＣＰベースプロトコル送信処理部７５２Ｔに対し、例えば、確認応答パケットを用いてパケット廃棄の有無を通知し、廃棄されたパケットの再送を要求する。

上述した各プロトコル受信処理部９２１Ｕ及び９２１Ｔは、それぞれ、例示的に、品質計測部９２５Ｕ及び９２５Ｔを備える。

品質計測部９２５Ｕ及び９２５Ｔは、それぞれ、無線端末１０（送信側）の品質計測部７５６Ｕ及び７５６Ｔ（図６参照）によって送信された計測パケットやパケットの送信間隔が調整されたデータパケットを監視して、ネットワークの通信品質を計測する。計測結果は、受信パケットの送信元である無線端末１０（送信側）の品質計測部１３２Ｕ及び１３２Ｔに対して通知される。計測結果の通知は、例示的に、制御部９８及び送信処理部９３を通じて行なってよい。当該通知には、例えば図１８にて後述する計測結果通知メッセージを用いることができる。

ＵＤＰ受信ソケットバッファ９２２Ｕは、ＵＤＰベースプロトコル受信処理部９２１Ｕに対応して備えられており、ＵＤＰベースプロトコル受信処理部９２１Ｕで受信されたパケットを一時的に保持する。当該保持により、ＵＤＰベースプロトコル受信処理部９２１Ｕでのデータ受信レートと、仮想ソケット処理部９４を介したプロキシ処理部９５によるデータ読み出しレートと、の差を吸収することが可能である。

ＴＣＰ受信ソケットバッファ９２２Ｔは、ＴＣＰベースプロトコル受信処理部９２１Ｔに対応して備えられており、ＴＣＰベースプロトコル受信処理部９２１Ｔで受信されたパケットを一時的に保持する。当該保持により、ＴＣＰベースプロトコル受信処理部９２１Ｔでのデータ受信レートと、仮想ソケット処理部９４を介したプロキシ処理部９５によるデータ読み出しレートと、の差を吸収することが可能である。

なお、上述したＷＯ＃２の受信処理部９２と同等の機能が、図５に例示した無線端末１０（ＷＯ＃１）の受信処理部７６の一例として備えられてよい。

別言すると、無線端末１０（ＷＯ＃１）は、無線端末１０からサーバ５０への方向であるアップストリームの通信についての受信処理部９２と同等の機能を、逆方向のダウンストリームの通信についての受信処理部７６として備えてよい。「ダウンストリーム」及び「アップストリーム」は、それぞれ、「ダウンリンク」及び「アップリンク」と称してもよい。

対称的に、図７に例示する無線基地局１００（ＷＯ＃２）において、ダウンストリームの通信についての送信処理部９３は、図６に例示した無線端末１０におけるアップストリームの通信についての送信処理部７５と同等の機能を有する。

例えば、図７に示す送信処理部９３は、仮想ソケット処理部９４から受信した、無線端末１０宛のデータを、ＵＤＰベースプロトコル及びＴＣＰベースプロトコルのいずれかのパケットにて、無線ＩＦ９１を通じて送信する。

そのため、送信処理部９３は、無線端末１０の送信処理部７５と同様に、例えば、ＵＤＰ送信ソケットバッファ９２２Ｕと、ＴＣＰ送信パケットバッファ９２２Ｔと、を備える。また、送信処理部９３は、例示的に、ＵＤＰベース及びＴＣＰベースの各プロトコル送信処理部９３２Ｕ及び９３２Ｔと、パケットフィルタ部９３３と、を備える。

ＵＤＰ送信ソケットバッファ９３１Ｕは、ＵＤＰベースプロトコルに対応して備えられており、ＵＤＰベースプロトコルで送信すべきパケットを一時的に保持する。当該保持により、ＵＤＰベースプロトコル送信処理部９３２Ｕのデータ送信レートと、仮想ソケット処理部９４によるＵＤＰ送信ソケットバッファ９３１Ｕへのデータの書き込みレートと、の差を吸収することが可能である。

ＴＣＰ送信ソケットバッファ９３１Ｔは、ＴＣＰベースプロトコルに対応して備えられており、ＴＣＰベースプロトコルで送信すべきＴＣＰパケットを一時的に保持する。当該保持により、ＴＣＰベースプロトコル送信処理部９３２Ｔのデータ送信レートと、仮想ソケット処理部９４によるＴＣＰ送信ソケットバッファ９３１Ｔへのデータの書き込みレートと、の差を吸収することが可能である。

ＵＤＰベースプロトコル送信処理部９３２Ｕは、無線端末１０におけるＵＤＰベースプロトコル送信処理部７５２Ｕ（図６参照）と同等の機能を提供する。例えば、ＵＤＰベースプロトコル送信処理部９３２Ｕは、ＵＤＰ送信ソケットバッファ９３１Ｕに書き込まれたパケットをＵＤＰベースプロトコルに応じた所定のレートで送信する処理部の一例である。

なお、図７には図示を省略しているが、ＵＤＰベースプロトコル送信処理部９３２Ｕは、無線端末１０におけるＵＤＰベースプロトコル送信処理部７５２Ｕに備えられた再送バッファ７５５Ｕと同様の再送バッファを備えてよい。ＵＤＰベースプロトコル送信処理部９３２Ｕは、送信したパケットに対する確認応答（ＡＣＫ／ＮＡＣＫ）が受信されるまで、一時的に、当該パケットを再送バッファに保存（キャッシュ）する。例えば、ＡＣＫが受信されると、再送バッファに保存されたパケットは破棄（削除）される。ＮＡＣＫが受信されると、再送バッファに保存されたパケットが再送される。

更に、ＵＤＰベースプロトコル送信処理部９３２Ｕは、例示的に、品質計測部９３５Ｕを備えてよい。品質計測部９３５Ｕは、ＵＤＰベースプロトコルを用いて、図１４により後述する計測パケットを送信したり、データパケットの送信間隔を調整（変化）したりすることで、ＷＡＮ３０の通信品質を測定する。

ここでの「通信品質」の非限定的な一例としては、例示的に、無線端末１０（対向のＷＯ＃１）との間（ＷＡＮ３０）におけるデータの廃棄率やＲＴＴ、帯域幅等が挙げられる。品質計測部９３５Ｕは、無線端末１０の受信処理部７６にダウンストリームのＵＤＰベースプロトコルに対して備えられた、受信側の品質計測部（図５において図示省略）での計測結果を、例えば制御部９８を通じて受信可能である。

ＴＣＰベースプロトコル送信処理部９３２Ｔは、ＴＣＰ送信ソケットバッファ９３１Ｔに書き込まれたパケットをＴＣＰベースプロトコルに応じた所定のレートで送信する処理部の一例である。また、ＴＣＰベースプロトコル送信処理部９３２Ｔは、無線端末１０のＴＣＰベースプロトコル送信処理部７５２Ｔに備えられた再送バッファ７５５Ｔと同様の再送バッファを備えてよい。

ＴＣＰベースプロトコル送信処理部９３２Ｔは、送信したパケットに対する確認応答（ＡＣＫ／ＮＡＣＫ）が受信されるまで、一時的に、当該パケットを再送バッファに蓄積する。例えば、ＡＣＫが受信されると、再送バッファに蓄積されたパケットは破棄される。ＮＡＣＫが受信されると、再送バッファに蓄積されたパケットが再送される。

更に、ＴＣＰベースプロトコル送信処理部９３２Ｔは、例示的に、品質計測部９３５Ｔを備えてよい。品質計測部９３５Ｔは、ＴＣＰベースプロトコルを用いて、図１５により後述する計測パケットを送信したり、データパケットの送信間隔を調整（変化）したりすることで、ＷＡＮ３０の通信品質を測定する。また、品質計測部９３５Ｔは、無線端末１０の受信処理部７６にダウンストリームのＴＣＰベースプロトコルに対して備えられた、受信側の品質計測部（図５において図示省略）での計測結果を、例えば制御部９８を通じて受信可能である。

パケットフィルタ部９３３は、無線端末１０におけるパケットフィルタ部７５３と同様の機能を提供する。例えば、パケットフィルタ部９３３は、各プロトコル送信処理部９３２Ｕ及び９３２Ｔから受信した送信パケットに付与された共通シーケンス番号を基にプロトコル指定テーブル９９Ｂを参照して、パケットフィルタリングを行なう。

例示的に、パケットフィルタ部９３３は、共通シーケンス番号に対応付けられたプロトコルの送信パケットは通過させるが、そうでないプロトコルの送信パケットは破棄する。破棄が生じた場合、パケットフィルタ部９３３は、破棄したパケットを送信したプロトコル送信処理部９３２Ｕ又は９３２Ｔに対し、再送バッファに蓄積されたパケットの再送をキャンセルする指示を与える。

仮想ソケット処理部９４は、プロキシ処理部９５に対してソケットＡＰＩを提供する。また、仮想ソケット処理部９４は、制御部９８の指示に応じて、受信パケットの順序制御や、無線端末１０宛の送信パケットに対する共通シーケンス番号の付与等を行なう。

そのため、図６に例示する仮想ソケット処理部９４は、例えば、共通シーケンス番号付与部９４１、リオーダリング処理部９４２、及び、リオーダリングバッファ９４３を備える。

共通シーケンス番号付与部９４１は、無線端末１０における共通シーケンス番号付与部７４１と同様の機能を提供する。例えば、共通シーケンス番号付与部９４１は、制御部９８の指示に応じて、プロキシ処理部９５から受信したパケットに対して共通シーケンス番号を付与する。共通シーケンス番号を付与されたパケットは、送信処理部９３における各送信ソケットバッファ９３１Ｕ及び９３１Ｔのいずれかに書き込まれる。

リオーダリング処理部９４２は、ＵＤＰベース及びＴＣＰベースの各プロトコルのパスを通じて受信したパケットの順序が入れ替わった場合に、受信パケットに付与されている共通シーケンス番号を基に、正しい順序にパケットの順序を並べ替える。そのため、各受信ソケットバッファ９２２Ｕ及び９２２Ｔからリオーダリング処理部９４２へ読み出されたパケットは、例えば、リオーダリングバッファ９４３に一時的に保持される。

なお、図５には図示を省略しているが、上述のアップストリームについてのリオーダリング処理部９４２及びリオーダリングバッファ９４３と同様の機能が、無線端末１０（ＷＯ＃１）の仮想ソケット処理部７４に備えられてよい。すなわち、無線端末１０（ＷＯ＃１）は、ダウンストリームの受信パケットについて、共通シーケンス番号に基づく順序制御を行なってよい。

プロキシ処理部９５は、ＴＣＰ処理部９６から受信したＴＣＰパケットに対してプロキシ設定を必要に応じて行ない、ＴＣＰパケットを仮想ソケット処理部９４へ送信する。また、プロキシ処理部９５は、ＴＣＰパケットとして同期（ＳＹＮ）パケットを受信すると、仮想ソケット処理部９４に対してソケットの生成を要求する。更に、プロキシ処理部９５は、仮想ソケット処理部９４から受信したＴＣＰパケットをＴＣＰ処理部９６へ送信する。

ＴＣＰ処理部９６は、有線ＩＦ９７から受信したデータをパケットに変換してプロキシ処理部９５へ送信する。また、ＴＣＰ処理部９６は、プロキシ処理部９５から受信したＴＣＰパケットを受信データに変換して有線ＩＦ９７へ送信する。

有線ＩＦ９７は、例示的に、サーバ５０との間の有線通信を可能にする通信インタフェースを提供し、ＴＣＰ処理部９６から受信した、サーバ５０宛の送信データをサーバ５０へ送信する。また、有線ＩＦ９７は、サーバ５０から受信した、無線端末１０宛のデータをＴＣＰ処理部９６へ送信する。

制御部９８は、無線端末１０（ＷＯ＃１）における制御部７８（図５及び図６参照）と同様の機能を提供する。例えば、制御部７８は、品質計測部９３５Ｕ及び９３５Ｔから計測結果を受信し、当該計測結果を基に、プロトコル選択テーブル９９Ａを参照し、各タイミングでの通信品質に適したプロトコルを決定する。

また、制御部９８は、共通シーケンス番号付与部９４１が付与した共通シーケンス番号をもつパケットを、ＵＤＰベース及びＴＣＰベースの各プロトコルのいずれで送信するかを示した対応関係をプロトコル指定テーブル９９Ｂに設定（登録）する。当該プロトコル指定テーブル９９Ｂは、例示的に、ダウンストリームのパケット送信において、パケットフィルタ部９３３によって参照される。

非限定的な一例として、プロトコル指定テーブル９９Ｂは、ＷＯ＃１におけるプロトコル指定テーブル７９Ｂ（図６及び図１１参照）と同様のデータ形式を有してよい。例えば、共通シーケンス番号１２〜１４が付与されたパケット＃１２〜＃１４はＴＣＰベースプロトコルで送信し、パケット＃１５〜＃１７はＵＤＰベースプロトコルで送信することが指定されてよい。

更に、制御部９８は、既述のように計測された通信品質がプロトコル選択テーブル９９Ａに設定したクリティカルリージョン（ＣＲ）に入ったと判断すると、仮想ソケット処理部９４に対し冗長書き込みを指示する。例えば、制御部９８は、切り替え候補のプロトコルに対応する各送信ソケットバッファ９３１Ｕ及び９３１Ｔの双方にパケットを書き込むように指示する。

そして、送信処理部９３のパケットフィルタ部９３３は、プロトコル指定テーブル９９Ｂに従って、各プロトコル送信処理部９３２Ｕ及び９３２Ｔから入力されたパケットのフィルタリングを行なう。

これにより、無線基地局１００（ＷＯ＃２）は、アップストリームと同様に、ダウンストリームのプロトコルの切り替え要因が検出されたタイミングで（別言すると、最小限のタイムラグで）プロトコル切り替えを実施できる。したがって、ＷＯ＃２は、切り替え後のプロトコルで適切にパケットを無線端末１０へ送信することが可能となる。

次に、図８を参照して、アップストリームの送信側のＷＯ＃１と受信側のＷＯ＃２との間の品質計測に着目した動作概要について説明する。ただし、図７は、アップストリームに着目した場合の、送信装置としてのＷＯ＃１及び受信装置としてのＷＯ＃２の構成例を示しており、ダウンストリームの構成については図示を省略している。

送信装置としてのＷＯ＃１における制御部７８は、周期的に、各プロトコル送信処理部７５２Ｕ及び７５２Ｔにおける品質計測部７５６Ｕ及び７５６Ｔへそれぞれ通信品質の測定指示を与える。

各品質計測部７５６Ｕ及び７５６Ｔは、それぞれ、ＵＤＰベース及びＴＣＰベースの各プロトコルのそれぞれについて複数の計測パケットをアップストリーム（ＷＯ＃２）へ送信する。

受信装置としてのＷＯ＃２では、受信処理部９２において、各プロトコルの計測パケットを、対応するプロトコル受信処理部９２１Ｕ及び９２１Ｔの品質計測部９２５Ｕ及び９２５Ｔにて受信する。品質計測部９２５Ｕ及び９２５Ｔは、それぞれ、計測パケットの破棄数を計測し、廃棄率（以下「パケット廃棄率」とも称する。）を計算する。

なお、各プロトコルで送信される計測パケット数は、既知としてよい。例えば、ＷＯ＃１の制御部７８とＷＯ＃２の制御部９８との間で、ネゴシエーションメッセージを送受信することで、各プロトコルで送信する計測パケット数を互いに通知するようにしてよい。代替的に、計測パケット数は、ＷＯ＃１及びＷＯ＃２において既知の数としてメモリ等に記憶しておいてもよい。

また、品質計測部９２５Ｕ及び９２５Ｔは、例えば、受信した計測パケットのパケット間隔を計測することで、空き帯域を計測し、計測結果を制御部９８へ通知する。制御部９８は、通知された計測結果を、例えば図１８に示すような計測結果通知メッセージを用いてＷＯ＃１の制御部７８へ通知する。

ＷＯ＃１では、各プロトコルの品質計測部７５６Ｕ及び７５６Ｔにおいて、送信したデータパケットに対してＷＯ＃２が送信してくる確認応答を受信するまでの時間（ＲＴＴ）を計測し、計測結果を制御部７８へ通知する。

（ハードウェア構成例）
次に、図９に、上述した無線端末１０及び無線基地局１００のハードウェア構成例を示す。なお、無線端末１０及び無線基地局１００を、便宜的に「無線装置３００」と総称することがある。図９に例示するように、無線装置３００は、ＣＰＵ３０１と、メモリ３０２と、ストレージ３０３と、ネットワークインタフェースカード（ＮＩＣ）３０４及び３０５と、バス３０９と、を備える。また、無線装置３００は、オプションとして、入力装置３０６、出力装置３０７、及び、記録媒体ドライブ３０８を備えてよい。

ＣＰＵ３０１、メモリ３０２、ストレージ３０３、ＮＩＣ３０４及び３０５は、バス３０９によって相互通信可能に接続されている。無線装置３００に、入力装置３０６、出力装置３０７、及び、記録媒体ドライブ３０８のいずれかが備えられる場合には、当該機器もバス３０９に接続されてよい。

ＣＰＵ３０１は、演算能力を備えたプロセッサの一例であり、無線装置３００の全体的な動作を制御する。演算能力を備えたプロセッサは、コンピュータの一例であると捉えてもよい。

例示的に、ＣＰＵ３０１が、メモリ３０２やストレージ３０３に記憶されたプログラム（あるいはソフトウェア）やデータを適宜に読み取って実行することにより、図５及び図６に例示した無線端末１０、あるいは、図７に例示した無線基地局１００としての機能が具現される。

例えば、図５及び図６に例示した無線端末１０における、ＴＣＰ処理部７２、プロキシ処理部７３、仮想ソケット処理部７４、送信処理部７５、受信処理部７６、及び、制御部７８は、ＣＰＵ３０１の処理として具現される。

また、図７に例示した無線基地局１００における、受信処理部９２、送信処理部９３、仮想ソケット処理部９４、プロキシ処理部９５、ＴＣＰ処理部９６、及び、制御部９８も、ＣＰＵ３０１の処理として具現される。

なお、上述のごとくＣＰＵ３０１の処理として具現される、無線端末１０（ＷＯ＃１）及び無線基地局１００（ＷＯ＃２）としての動作（機能）を実現するプログラムは、通信制御プログラム（あるいはソフトウェア）と称してよい。

メモリ３０２は、例示的に、ＲＡＭやＲＯＭであり、上述したプログラムやデータを記憶する。データには、ＣＰＵ３０１が処理に用いるデータやＣＰＵ３０１による処理の結果であるデータが含まれてよい。既述のプロトコル選択テーブル７９Ａ（９９Ａ）やプロトコル指定テーブル７９Ｂ（９９Ｂ）は、メモリ３０２において記憶、実現されてよい。

また、既述の各ソケットバッファ７５１Ｕ，７５１Ｔ，９２２Ｕ，９２２Ｔ，９３１Ｕ及び９３１Ｔは、仮想的（あるいは論理的）なバッファとして、メモリ３０２において実現されてよい。更に、既述の再送バッファ７５５Ｕ及び７５５Ｔやリオーダリングバッファ９４３についても、仮想的（あるいは論理的）なバッファとして、メモリ３０２において実現されてよい。

ストレージ３０３は、例示的に、ハードディスクドライブ（ＨＤＤ）等の外部記憶装置であってよく、上述したプログラムやデータを記憶する。ストレージ３０３に記憶されたプログラムやデータは、例えば、ＣＰＵ３０１の指示に応じて、適宜に、メモリ３２に展開されて、ＣＰＵ３０１による処理に用いられる。

ＮＩＣ３０４は、例えば、無線基地局１００あるいは無線端末１０との間の無線接続を提供し、無線基地局１００あるいは無線端末１０との間でアンテナ３１０を通じた無線通信を可能にする。別言すると、ＮＩＣ３０４によって、図５に例示した無線端末１０の無線ＩＦ７７、あるいは、図７に例示した無線基地局１００の無線ＩＦ９１が実現される。

ＮＩＣ３０５は、例えば、外部機器との有線接続を提供する。例えば、無線基地局１００のＮＩＣ３０５は、サーバ５０との有線接続を提供する。別言すると、ＮＩＣ３０５によって、図７に例示した無線基地局１００の有線ＩＦ９７が実現される。

入力装置３０６は、例示的に、キーボードやマウス、タッチパネル等であり、出力装置３０７は、表示装置（ディスプレイやタッチパネル等）や印刷装置等である。

記録媒体ドライブ３０８は、メモリ３０２やストレージ３０３のデータを記録媒体３１１に出力することができ、また、記録媒体３１１からプログラムやデータ等を読み出してストレージ３０３やメモリ３０２に出力することができる。したがって、無線装置３００としての機能を実現するプログラムやデータは、記録媒体３１１からインストールすることができる。

記録媒体３１１は、例示的に、フレキシブルディスクや、Magneto-Optical（ＭＯ）ディスク、Compact Disc Recordable（ＣＤ−Ｒ）やDigital Versatile Disk Recordable（ＤＶＤ−Ｒ）等の任意の記録媒体であってよい。なお、無線装置３００としての機能を実現するプログラムやデータは、ＮＩＣ３０４やＮＩＣ３０５を通じてサーバ５０等の外部機器から通信により無線装置３００にダウンロード、インストールされてもよい。

（プロトコル選択テーブルの一例）
図５及び図６に例示したＷＯ＃１は、プロトコル選択テーブル９９Ａの一例として、図１０に示すような特性データを有する。図１０に例示する特性データは、ＵＤＰベースプロトコルでの通信及びＴＣＰベースプロトコルでの通信における廃棄率（％）に対する平均スループットの変化を示すデータである。

図１０から分かるように、ＴＣＰベースプロトコルの方がＵＤＰベースプロトコルよりも高い平均スループットが得られる領域と、これらの関係が逆転する領域と、が存在する。これら２つの領域の境界は、各特性の交点に相当する廃棄率で示される。

したがって、制御部７８（又は、９８）は、既述の通信品質の計測結果が当該廃棄率を示すポイント（タイミング）でプロトコル切り替えを実施できるように、当該ポイントを含む或る範囲の廃棄率をクリティカルリージョン（ＣＲ）として決定する。例示的に、クリティカルリージョンは、プロトコル切り替えポイントの廃棄率ｐ（％）に対して、以下の式（１）で表される範囲に設定してよい。

廃棄率ｐがＣＲの範囲外から範囲内に変化したことを検出すると、制御部７８（又は、９８）は、送信パケットのソケットバッファへの冗長的な書き込み制御を実施する。すなわち、制御部７８（又は、９８）は、既述のように、仮想ソケット処理部７４（又は、９４）に指示を与え、各プロトコルの送信ソケットバッファ７５１Ｕ及び７５１Ｔ（又は、９３１Ｕ及び９３１Ｔ）の双方に送信パケットを冗長的に書き込ませる。

（パケットフォーマット例）
次に、図１２〜図１８に、上述した通信システム１で用いられるパケットあるいはメッセージのフォーマット例を示す。

図１２は、ＵＤＰベースプロトコルのデータパケットフォーマットの一例を示し、図１３は、ＴＣＰベースプロトコルのデータパケットフォーマットの一例を示す。また、図１４は、ＵＤＰベースプロトコルの計測パケットフォーマットの一例を示し、図１５は、ＴＣＰベースプロトコルの計測パケットフォーマットの一例を示す。

更に、図１６及び図１７は、ネゴシエーションメッセージのフォーマットの一例を示し、図１６は、ネゴシエーション要求メッセージのフォーマットの一例を示し、図１７は、ネゴシエーション応答メッセージのフォーマットの一例を示す。また、図１８は、既述の品質計測結果の通知に用いられる計測結果通知メッセージのフォーマットの一例を示す。

図１２に例示するように、ＵＤＰベースプロトコルのデータパケットは、ＩＰヘッダ、ＤＵＰヘッダ、及び、ＵＤＰペイロードを有する。ＵＤＰペイロードは、例示的に、ＵＤＰベースプロトコルヘッダと、既述の共通シーケンス番号（例えば、４バイト）と、データ（例えば、可変長）と、を有する。ＵＤＰベースプロトコルヘッダは、例示的に、ＵＤＰベースプロトコルの種別を示す情報要素（例えば、２バイト）と、グループ識別子（ＩＤ）（２バイト）と、ＵＤＰベースプロトコルシーケンス番号（４バイト）とを、有する。

なお、前述した品質計測は、送信データパケットが存在する場合には、計測パケットの代わりにデータパケットを用いてもよい。品質計測の際、ＷＯ＃１とＷＯ＃２との間で予め品質計測で送信するパケット数をネゴシエーションした場合、グループ識別子は、例示的に、ネゴシエーションした数のデータパケットを区別するために用いる。ネゴシエーションした数に含まれるパケットには同じ識別子を設定してよい。ネゴシエーションした数のパケットが繰り返し送信される場合には、当該フィールドに異なる値を設定してよい。

一方、図１３に例示するように、ＴＣＰベースプロトコルのデータパケットは、ＩＰヘッダと、ＴＣＰヘッダと、ＴＣＰペイロードと、を有する。ＴＣＰペイロードは、既述の共通シーケンス番号（例えば、４バイト）と、データ（例えば、可変長）と、を有する。

図１２及び図１３に例示するパケットフォーマットの共通シーケンス番号が、共通シーケンス番号付与部７４１（又は、９４１）によって付与される。

また、図１４に例示するように、ＵＤＰベースプロトコルの計測パケットは、図１２に例示したＵＤＰベースプロトコルのデータパケットに比して、ＵＤＰベースプロトコルシーケンス番号に代えて計測用シーケンス番号（例えば、４バイト）を有する点が異なる。また、ＵＤＰベースプロトコルの計測パケットは、データとしてダミーデータ（例えば、可変長）を有する。

一方、図１５に例示するように、ＴＣＰベースプロトコルの計測パケットは、図１３に例示したＴＣＰベースプロトコルのデータパケットに比して、ＴＣＰオプションヘッダを追加的に有する点が異なる。

ＴＣＰオプションヘッダは、例示的に、オプションコード（例えば、１バイト）、ＴＣＰオプションヘッダのサイズを示す情報要素（例えば、１バイト）、グループＩＤ（例えば、２バイト）、及び、計測用シーケンス番号（例えば、４バイト）を有する。オプションコードには、当該パケットが計測パケットであることを示すコード（非限定的な一例として、１６進数で０ｘ８）が設定される。

図１４及び図１５に例示したフォーマットにおける計測用シーケンス番号を基に、既述のパケット廃棄率やＲＴＴ等を計測することが可能になる。

また、図１６及び図１７に例示するネゴシエーションメッセージは、既述のとおり、制御部７８と制御部９８との間の通信（通知）に用いられる。図１６に例示するネゴシエーション要求メッセージは、例えば、リクエスト識別番号（例えば、４バイト）、既述の共通シーケンス番号（例えば、４バイト）、連続フラグ（例えば、２バイト）、及び、プロトコル種別を示す情報要素（例えば、２バイト）を有する。

リクエスト識別番号は、当該メッセージによって要求する処理を識別する情報要素の一例である。例えば、制御部７８（又は、９８）は、計測パケットの送信処理の要求を当該ネゴシエーション要求メッセージによって行なうことが可能である。

連続フラグは、例えば、計測パケットを連続的に送信する数を示す情報要素の一例である。

プロトコル種別を示す情報要素は、例示的に、ＵＤＰベースプロトコル及びＴＣＰベースプロトコルのいずれかを示す情報要素の一例である。

制御部７８（又は、９８）は、「プロトコル種別」で指定されたプロトコルの計測パケットを「連続フラグ」で指定された数だけ送信することが可能である。

図１７に例示するネゴシエーション応答メッセージは、図１６に例示したネゴシエーション要求メッセージを受信した制御部７８（又は、９８）が、当該要求メッセージによって要求された処理に応じた応答を返信するのに用いられる。ネゴシエーション応答メッセージは、例示的に、どの要求に対する応答であるかを識別する情報要素の一例としてリクエスト識別番号（例えば、４バイト）を有する。

また、図１８に例示するように、計測結果通知メッセージは、プロトコル種別を示す情報要素（例えば、２バイト）、グループＩＤ（例えば、２バイト）、計測結果（廃棄率）（例えば、４バイト）、及び、計測結果（空き帯域）（４バイト）を有する。プロトコル種別を示す情報要素には、例示的に、ＵＤＰベース及びＴＣＰベースの各プロトコルのいずれかを示す情報が設定される。

（動作例）
次に、図１９〜図２２を参照して、上述した通信システム１の動作例について説明する。図１９〜図２１は、それぞれ、無線端末１０からサーバ５０への方向であるアップストリームのパケットの流れに着目した動作シーケンス例を示す。なお、図１９〜図２１において、ＴＣＰ通信に関する確認応答等は図示を省略している。図２２は、アップストリームの送信元である無線端末１０（ＷＯ＃１）における制御部７８の動作例を示すフローチャートである。

まず、無線アクセス網３０でのパケット廃棄率が図９に例示したプロトコル切り替えポイントよりも低いため、無線端末１０は、ＴＣＰベースプロトコルでサーバ５０と通信を行なっていたと仮定する。その後、例えば無線端末１０の移動に伴ってパケット廃棄率がプロトコル切り替えポイントよりも高くなると、無線端末１０は、ＵＤＰベースプロトコルに切り替えて通信を行なう。以下では、この場合の動作例について説明する。

（動作シーケンス例）
図１９に例示するように、無線端末１０は、例えばＡＰＬ＃１によってサーバ５０宛のデータが生成されると、サーバ５０に接続するためにＴＣＰソケットを生成し（処理Ｐ１０）、コネクション設定を開始する。コネクション設定の開始に応じて、無線端末１０は、ＴＣＰの同期（ＳＹＮ）パケットを生成する。ＳＹＮパケットは、ＳＹＮフラグがセットされたパケットである。

ＳＹＮパケットは、ＷＯ＃１によって無線アクセス網３０へ中継される。ＷＯ＃１において、ＳＹＮパケットは、入出力７１及びＴＣＰ処理部７２を経由してプロキシ処理部７３に転送される（処理Ｐ１０ａ）。

プロキシ処理部７３は、サーバ５０に成り代わってＳＹＮパケットに対する応答である同期確認（ＳＹＮ／ＡＣＫ）パケットを無線端末１０のＡＰＬ＃１に返信し、ＴＣＰの終端処理を行なう。なお、ＳＹＮ／ＡＣＫパケットは、ＳＹＮフラグとＡＣＫフラグとをセットしたパケットである。

無線端末１０のＡＰＬ＃１は、ＳＹＮ／ＡＣＫパケットを受信すると、ＡＣＫフラグをセットした確認（ＡＣＫ）パケットを生成する。ＡＣＫパケットは、ＳＹＮパケットと同様に、ＷＯ＃１のプロキシ処理部７３にて受信される。

したがって、無線端末１０は、サーバ５０と通信しているつもりになっているが、実際には、ＷＯ＃１のプロキシ処理部７３と通信することになる。なお、以上のような、ＳＹＮパケットの送信、ＳＹＮ／ＡＣＫパケットの返信、及び、ＡＣＫパケットの送信を含む通信手順は、「３ウェイハンドシェーク」と呼ばれる。

ＷＯ＃１のプロキシ処理部７３は、無線端末１０からＴＣＰセッションが設定されると、ＷＯ＃１の仮想ソケット処理部７４にソケットを生成する（処理Ｐ１００）。仮想ソケット処理部７４は、ＴＣＰベースプロトコル送信処理部７５２Ｔに対し、ＷＯ＃２との間にＴＣＰベースプロトコルのセッションを設定するよう指示する（処理Ｐ１１０）。

指示を受けたＴＣＰベースプロトコル送信処理部７５２Ｔは、ＷＯ＃２のＴＣＰベースプロトコル受信処理部９２１Ｔとの間で、３ウェイハンドシェークを実施し、ＴＣＰベースプロトコルのコネクションを設定する。

ＷＯ＃２のＴＣＰベースプロトコル受信処理部９２１Ｔは、ＷＯ＃２の仮想ソケット処理部９４に対してＴＣＰソケットの生成を指示する。指示を受けた仮想ソケット処理部９４は、ＷＯ＃１で生成されたＴＣＰソケットに対応するＴＣＰソケットを生成する（処理Ｐ２００）。

ＷＯ＃１及び＃２の仮想ソケット処理部７４及び９４においてＴＣＰソケットがそれぞれ生成されると、仮想ソケット処理部７４及び９４は、それぞれ、ＵＤＰソケットを生成する（処理Ｐ１１１及びＰ２０１）。

なお、ＵＤＰは、コネクションレスなプロトコルであるため、３ウェイハンドシェークは必要ない。したがって、ＷＯ＃１の仮想ソケット処理部７４は、ＵＤＰベースプロトコル送信処理部７５２Ｕに対してＵＤＰソケットのアドレスを登録して処理を終了する。同様に、ＷＯ＃２の仮想ソケット処理部９４は、ＵＤＰベースプロトコル受信処理部９２１Ｕに対してＤＵＰソケットのアドレスを登録して処理を終了する。

ＷＯ＃２の仮想ソケット処理部９４は、ＷＯ＃２のプロキシ処理部９５が設定した待受けソケットに対し、外部から接続があったことを当該プロキシ処理部９５に通知する（処理Ｐ２０２）。

ＷＯ＃２のプロキシ処理部９５は、待受けソケットをアクセプト（接続）すると共に（処理Ｐ２１１）、サーバ５０との間にＴＣＰのコネクションを設定しサーバ５０との接続を確立する（処理Ｐ２１２）。この際、ＷＯ＃２のプロキシ処理部９５とサーバ５０との間で３ウェイハンドシェークが実施されるが、図１９には図示を省略している。

ＷＯ＃１及び＃２の仮想ソケット処理部７４及び９４においてＵＤＰソケットがそれぞれ生成されると、ＷＯ＃１における品質計測部７５６Ｕ及び７５６Ｔは、それぞれ、計測パケットを生成してアップストリームへ送信する（処理Ｐ１１２）。例えば、品質計測部７５６Ｕは、図１４に例示したＵＤＰベースプロトコルの計測パケットを生成し、品質計測部７５６Ｔは、図１５に例示したＴＣＰベースプロトコルの計測パケットを生成する。

ＵＤＰベースプロトコルの計測パケットは、ＷＯ＃２のＵＤＰベースプロトコル受信処理部９２１Ｕにおける品質計測部９２５Ｕで受信される。ＴＣＰベースプロトコルの計測パケットは、ＷＯ＃２のＴＣＰベースプロトコル受信処理部９２１Ｔにおける品質計測部９２５Ｔで受信される。

ＷＯ＃２の各品質計測部９２５Ｕ及び９２５Ｔは、それぞれ、受信した計測パケットを基に、対応するプロトコルでの廃棄数やＲＴＴ、空き帯域等幅を計測する。計測結果は、例えば図１８に例示した計測結果通知メッセージによってＷＯ＃１における品質計測部７５６Ｕ及び７５６Ｔへ通知される。以降、計測パケットの送信及び計測結果の通知は、周期的に実施されてよい。

無線端末１０は、サーバ５０との接続が完了すると、ＴＣＰのデータパケットの送信を開始する（処理Ｐ１１）。データパケットは、ＷＯ＃１のＴＣＰ処理部７２を経由してプロキシ処理部７３に転送される（処理Ｐ１２）。ＷＯ＃１のプロキシ処理部７３は、ＴＣＰセッションからの受信データパケットを、再度、仮想ソケット処理部７４に書き込む（処理Ｐ１３）。

ここで、測定結果が廃棄率＝０．０００１％、ＲＴＴ＝１５０ｍｓであったと仮定する。当該測定結果は、例示的に、品質計測部７５６Ｕ及び７５６Ｔから制御部７８に通知されている。ＷＯ＃１の制御部７８は、当該測定結果を基に、図１０に例示したプロトコル選択テーブル７９Ａを参照する。

この場合、ＵＤＰベースプロトコルよりもＴＣＰベースプロトコルの方が高い平均スループットを得られるので、制御部７８は、ＴＣＰベースプロトコルでデータパケットを送信することに決定し、その旨を仮想ソケット処理部７４に通知する。

仮想ソケット処理部７４は、プロキシ処理部７３から受信した（書き込まれた）データパケットに対して共通シーケンス番号を共通シーケンス番号付与部７４１によって付与する（処理Ｐ１１３）。共通シーケンス番号を付与されたデータパケットは、ＴＣＰ送信ソケットバッファ７５１Ｔに書き込まれる（処理Ｐ１１４）。

例えば図２０には、共通シーケンス番号＃１０〜＃１２をもつデータパケット＃１０〜＃１２が、ＴＣＰ送信ソケットバッファ７５１Ｔに書き込まれることを表している。なお、仮想ソケット処理部７４は、データパケットに付与した共通シーケンス番号を制御部７８へ通知する。制御部７８は、通知された共通シーケンス番号毎に図１０に例示したプロトコル指定テーブル７９Ａを更新する。

ＴＣＰ送信ソケットバッファ７５１Ｔに書き込まれたデータパケット＃１０〜＃１２は、ＴＣＰベースプロトコル送信処理部７５２Ｔによって読み出され、ＴＣＰベースプロトコルのデータパケット（図１３参照）に変換されて、パケットフィルタ部７５３へ転送される。

パケットフィルタ部７５３は、ＴＣＰベースプロトコル送信処理部７５２Ｔからデータパケットを受信すると、図１１に例示したプロトコル指定テーブル７９Ｂを参照する。ここで、プロトコル指定テーブル７９Ｂにおいて、共通シーケンス番号＃１０〜＃１２をもつデータパケット＃１０〜＃１２は、ＴＣＰベースプロトコルで送信することが指定されているものと仮定する。したがって、パケットフィルタ部７５３は、データパケット＃１０〜＃１２を無線ＩＦ７７へ通過させて無線アクセス網３０へ送信する（処理Ｐ１２０〜Ｐ１２２）。

無線アクセス網３０へ送信されたＴＣＰベースプロトコルのデータパケット＃１０〜＃１２は、ＷＯ＃２のＴＣＰベースプロトコル受信処理部９２１Ｔで受信される。ＴＣＰベースプロトコル受信処理部９２１Ｔは、受信したデータパケット＃１０〜＃１２を、ＴＣＰベースプロトコル変換前のフォーマットに戻して、ＴＣＰ受信ソケットバッファ９２２Ｔに受信した順序で書き込む。

ＴＣＰ受信ソケットバッファ９２２Ｔに書き込まれたデータパケット＃１０〜＃１２は、仮想ソケット処理部９４によって、書き込み順序どおりに読み出される。仮想ソケット処理部９４は、順番に読み出したデータパケット＃１０〜＃１２のそれぞれに含まれるデータ（ペイロード）を抽出してプロキシ処理部９５に転送する。

プロキシ処理部９５は、仮想ソケット処理部９４から受信したデータをＴＣＰ処理部９６に転送し、ＴＣＰ処理部９６は、受信したデータをサーバ５０との間に有線ＩＦ９７を介して確立されたＴＣＰセッションで送信する。

ここで、無線アクセス網３０の通信品質が低下し、既述のように周期的に実施されている品質計測の結果、ＷＯ＃１の制御部７８が、廃棄率＝０．００１％、ＲＴＴ＝１５０ｍｓという測定結果を取得したとする。この場合、図２０に例示するように、制御部７８は、図１０に例示したプロトコル選択テーブル７９Ａを参照することにより、廃棄率がＣＲに入ったと判断（検出）する（処理Ｐ１１５）。当該判断に応じて、制御部７８は、仮想ソケット処理部７４に対して、ＵＤＰ送信ソケットバッファ７５１Ｕ及びＴＣＰソケットバッファ７５１Ｔの双方にデータパケットを書き込むよう指示する。

併せて、制御部７８は、以降にデータパケットに付与される共通シーケンス番号毎に、図１１に例示したプロトコル指定テーブル７９Ｂを更新する。例えば図１１に示すように、制御部７８は、共通シーケンス番号＃１５〜＃１９が付与されるデータパケット＃１５〜＃１９がＵＤＰベースプロトコルで送信されるようプロトコル指定テーブル７９Ｂを更新する。

仮想ソケット処理部７４は、プロキシ処理部７３から受信したデータパケットに共通シーケンス番号を共通シーケンス番号付与部７４１によって付与し、当該データパケットを各送信ソケットバッファ７５１Ｕ及び７５１Ｔの双方に書き込む（処理Ｐ１１６）。例えば、仮想ソケット処理部７４は、共通シーケンス番号＃１３〜＃１５を付与したデータパケット＃１３〜＃１５を各送信ソケットバッファ７５１Ｕ及び７５１Ｔの双方に書き込む。

したがって、各プロトコル送信処理部７５２Ｕ及び７５２Ｔは、それぞれ、同じデータパケット＃１３〜＃１５を、対応する送信ソケットバッファ７５１Ｕ及び７５１Ｔから読み出すことになる。各プロトコル送信処理部７５２Ｕ及び７５２Ｔは、それぞれ、読み出したデータパケット＃１３〜＃１５を、対応するプロトコルのデータパケット（図１２及び図１３参照）に変換して、パケットフィルタ部７５３へ転送する。

パケットフィルタ部７５３は、各プロトコル送信処理部７５２Ｕ及び７５２Ｔから無線ＩＦ７７へ出力されようとしているデータパケットを、図１１に例示したプロトコル指定テーブル７９Ｂを参照してフィルタリングする。

ここで、プロトコル指定テーブル７９Ｂは、データパケット＃１０〜＃１４はＴＣＰベースプロトコルで送信し、以降のデータパケット＃１５〜＃１９・・・はＵＤＰベースプロトコルで送信するよう更新されている。

したがって、パケットフィルタ部７５３は、図２０及び図２１に例示するように、ＴＣＰベースプロトコル送信処理部７５２Ｔから受信されるデータパケット＃１３及び＃１４の通過を許可する（処理Ｐ１２３及びＰ１２４）。また、パケットフィルタ部７５３は、その後にＴＣＰベースプロトコル送信処理部７５２Ｔから受信されるデータパケット＃１５以降のデータパケットを破棄する。

これに対し、ＵＤＰベースプロトコル送信処理部７５２Ｕから受信されるデータパケット＃１３及び＃１４については、パケットフィルタ部７５３おいて破棄される。また、パケットフィルタ部７５３は、その後にＵＤＰベースプロトコル送信処理部７５２Ｕから受信されるデータパケット＃１５以降の通過を許可する（処理Ｐ１２５）。

なお、データパケットをパケットフィルタ部７５３へ送信した各プロトコル送信処理部７５２Ｕ及び７５２Ｔは、それぞれ、無線アクセス網３０でのパケットロスに備えて再送バッファ７５５Ｕ及び７５５Ｔにそれぞれ送信済みのデータパケットを保持している。

当該データパケットについての確認応答がＷＯ＃２から一定時間以上経過しても通知されない場合、対応するプロトコル送信処理部７５２Ｕ又は７５２Ｔは、送信済みのデータパケットの再送を実施することになる。

しかし、上述したパケットフィルタ部７５３でのパケットフィルタリングによって破棄されたデータパケットについては、確認応答が通知されないことになるので、無用なデータパケットの再送が実施されてしまうことになる。

このような無用な再送を防ぐために、パケットフィルタ部７５３は、プロトコル指定テーブル７９Ｂに従って意図的に破棄したデータパケットの送信元（プロトコル送信処理部７５２Ｕ又は７５２Ｔ）に対し、再送をキャンセルする通知を与える。当該通知を受けたプロトコル送信処理部７５２Ｕ又は７５２Ｔは、再送バッファ７５５Ｕ又は７５５Ｔに保持した該当データパケットを削除する。

さて、上述のごとくＷＯ＃１からＴＣＰベースプロトコルで送信されたデータパケット＃１３及び＃１４、並びに、ＵＤＰベースプロトコルで送信されたデータパケット＃１５以降のデータパケットは、送信された順序でＷＯ＃２にて受信されるはずである。しかし、例えば無線アクセス網３０のトラフィック状況によっては受信順序が送信順序と整合しないこともある。

例えば、ＷＯ＃２の受信処理部９２において、データパケット＃１３が受信された後、データパケット＃１４よりも先にデータパケット＃１５が受信されたとする。この場合、仮想ソケット処理部９４は、ＵＤＰベースプロトコルのデータパケット＃１５をＵＤＰ受信ソケットバッファ９２２Ｕから読み出した後、ＴＣＰベースプロトコルのデータパケット＃１４をＴＣＰ受信ソケットバッファ９２２Ｔから読み出すことになる。

そのため、仮想ソケット処理部９４は、リオーダリング処理部９４２によって、共通シーケンス番号を基に、受信データパケットのプロキシ処理部９５への転送順序を制御（修正）する。例えば、リオーダリング処理部９４２は、データパケット＃１３を読み出した後に共通シーケンス番号が不連続となるデータパケット＃１５を読み出すと、当該データパケット＃１５をリオーダリングバッファ９４３へいったん格納する（処理Ｐ２０３）。

その後に、データパケット＃１４がＴＣＰ受信ソケットバッファ９２２Ｔから読み出されると、リオーダリング処理部９４２は、当該データパケット＃１４に含まれるデータ（ペイロード）をプロキシ処理部９５へ転送する。続いて、リオーダリング処理部９４２は、リオーダリングバッファ９４３に格納したデータパケット＃１５に含まれるペイロードをプロキシ処理部９５へ転送する。このようにして、リオーダリング処理部９４２は、データパケットのＷＯ＃１からの送信順序を保証するようにデータパケットの受信順序を修正する（処理Ｐ２０４）。

プロキシ処理部９５は、仮想ソケット処理部９４から受信したデータ（ペイロード）をＴＣＰ処理部９６へ転送し、ＴＣＰ処理部９６は、受信したデータをサーバ５０との間に有線ＩＦ９７を介して確立されたＴＣＰセッションで送信する。

次に、無線アクセス網３０の通信品質が更に低下し、既述のように周期的に実施されている品質計測の結果、ＷＯ＃１の制御部７８が、廃棄率＝０．０１％、ＲＴＴ＝１５０ｍｓという測定結果を取得したとする。

制御部７８は、当該計測結果を基に、図１０に例示したプロトコル選択テーブル７９Ａを参照すると、パケット廃棄率が、増加する方向にＣＲから外れたことを検出する（処理Ｐ１１７）。

この場合、制御部７８は、プロトコル選択テーブル７９Ａから、ＴＣＰベースプロトコルよりもＵＤＰベースプロトコルでデータパケットを送信した方が高い平均スループットを得られると判断する。

当該判断に応じて、制御部７８は、仮想ソケット処理部７４に対し、ＵＤＰベースプロトコルに対応するＵＤＰ送信ソケットバッファ７５１Ｕにデータパケットを書き込むよう指示する。別言すると、データパケットを各プロトコルに対応した送信ソケットバッファ７５１Ｕ及び７５１Ｔの双方に書き込むことは停止される。

当該指示に応じて、仮想ソケット処理部７４は、プロキシ処理部７３から受信したデータパケットに共通シーケンス番号を付与し、ＵＤＰ送信ソケットバッファ７５１Ｕに当該データパケットを書き込む（処理Ｐ１１８）。例えば図２１には、共通シーケンス番号＃１９以降のデータパケットがＵＤＰ送信ソケットバッファ７５１Ｕに書き込まれることを表している。

ＵＤＰ送信ソケットバッファ７５１Ｕに書き込まれたデータパケットは、ＵＤＰベースプロトコル送信処理部７５２Ｕによって読み出される。ＵＤＰベースプロトコル送信処理部７５２Ｕは、読み出したデータパケットをＵＤＰベースプロトコルのデータパケット（図１２参照）に変換して、パケットフィルタ部７５３に転送する。

パケットフィルタ部７５３は、図１１に例示したプロトコル指定テーブル７９Ｂを参照して、プロトコル指定テーブル７９Ｂに従って、ＵＤＰベースプロトコル送信処理部７５２Ｕから受信したデータパケットのフィルタリングを行なう。

例えば、図１１に例示するプロトコル指定テーブル７９Ｂでは、共通シーケンス番号＃１９以降の共通シーケンス番号をもつデータパケットをＵＤＰベースプロトコルで送信することが指定されている。そのため、パケットフィルタ部７５３は、データパケット＃１９以降のデータパケットの送信を許可し、無線ＩＦ７７へ通過する（処理Ｐ１２７及びＰ１２８）。

なお、上述した例では、パケット廃棄率が変化した場合について説明したが、ＲＴＴが変化することで平均スループットが変化する場合や、パケット廃棄率及びＲＴＴの双方が変化することで平均スループットが変化する場合にも対応可能である。例えば、パケット廃棄率やＲＴＴ等の通信品質の指標となるパラメータに応じたプロトコル選択テーブル１２０（又は２１８）を用意すればよい。

また、上述した例は、アップストリームに着目した動作例であるが、ダウンストリームの動作例についても上述した例と同様と考えてよい。例えば、ダウンストリームの動作例は、図１９〜図２１において、無線端末１０及びサーバ５０をそれぞれサーバ５０及び無線端末１０に読み替え、かつ、ＷＯ＃１及びＷＯ＃２をそれぞれＷＯ＃２及びＷＯ＃１に読み替えた動作に相当すると捉えてよい。

（制御部動作例）
次に、図２２を参照して、ＷＯ＃１における制御部７８の動作例について説明する。
ＷＯ＃１において、仮想ソケット処理部７４の共通シーケンス番号付与部７４１は、プロキシ処理部７３からデータパケットを受信する毎に、所定のデータサイズの単位で共通シーケンス番号を付与する。なお、所定のデータサイズは、ＭＴＵ（Maximum Transmission Unit）から共通シーケンス番号のサイズを除いたサイズとしてよい。

仮想ソケット処理部７４は、共通シーケンス番号付与部７４１が共通シーケンス番号をデータパケットに付与する度に、付与した共通シーケンス番号を制御部７８に通知する。制御部７８は、仮想ソケット処理部７４から当該通知を受けると（処理Ｐ５１）、品質計測部７５６Ｕ及び７５６Ｔが周期的に計測し更新している通信品質の測定結果を参照する（処理Ｐ５２）。

制御部７８は、測定結果を基にプロトコル選択テーブル７９Ａを参照して、ＵＤＰベース及びＴＣＰベースの各プロトコルの推定スループットを求める（処理Ｐ５３）。また、制御部７８は、測定結果（例えば、パケット廃棄率等）がＣＲに入っているかどうかをチェックする（処理Ｐ５４）。

測定結果がＣＲに入っていなければ（処理Ｐ５４でＮｏの場合）、制御部７８は、ＵＤＰベースプロトコルの推定スループットがＴＣＰベースプロトコルの推定スループットよりも大きいか否かを判定する（処理Ｐ５５）。

判定の結果、ＵＤＰベースプロトコルの推定スループットがＴＣＰベースプロトコルの推定スループット以下であったとする（処理Ｐ５５でＮｏ）。この場合、制御部７８は、プロトコル指定テーブル７９Ｂに、仮想ソケット処理部７４から通知された共通シーケンス番号のデータパケットをＴＣＰベースプロトコルで送信することを登録する（処理Ｐ６１）。また、制御部７８は、仮想ソケット処理部７４に対し、当該共通シーケンス番号のデータパケットを、各送信ソケットバッファ７５１Ｕ及び７５１Ｔのうち、ＴＣＰ送信ソケットバッファ７５１Ｔに対してのみ書き込むよう指示する（処理Ｐ６２）。

一方、処理Ｐ５５での判定の結果、ＵＤＰベースプロトコルの推定スループットがＴＣＰベースプロトコルの推定スループットよりも大きい場合（処理Ｐ５５でＹｅｓの場合）、制御部７８は、以下の処理Ｐ７１及びＰ７２を実施する。

例えば、制御部７８は、プロトコル指定テーブル７９Ｂに、仮想ソケット処理部７４から通知された共通シーケンス番号のデータパケットをＵＤＰベースプロトコルで送信することを登録する（処理Ｐ７１）。また、制御部７８は、仮想ソケット処理部７４に対し、当該共通シーケンス番号のデータパケットを、各送信ソケットバッファ７５１Ｕ及び７５１Ｔのうち、ＵＤＰ送信ソケットバッファ７５１Ｕに対してのみ書き込むよう指示する（処理Ｐ７２）。

これに対し、処理Ｐ５４において測定結果がＣＲに入っている場合（処理Ｐ５４でＹｅｓの場合）、制御部７８は、ＵＤＰベースプロトコルの推定スループットがＴＣＰベースプロトコルの推定スループットよりも大きいか否かを判定する（処理Ｐ５６）。

判定の結果、ＵＤＰベースプロトコルの推定スループットがＴＣＰベースプロトコルの推定スループット以下であった場合（処理Ｐ５６でＮｏの場合）、制御部７８は、以下の処理Ｐ８１及びＰ８３を実施する。

例えば、制御部７８は、プロトコル指定テーブル７９Ｂに、仮想ソケット処理部７４から通知された共通シーケンス番号のデータパケットをＴＣＰベースプロトコルで送信することを登録する（処理Ｐ８１）。また、制御部７８は、仮想ソケット処理部７４に対し、当該共通シーケンス番号のデータパケットをＵＤＰ送信ソケットバッファ７５１Ｕ及びＴＣＰ送信ソケットバッファ７５１Ｔの双方に書き込むよう指示する（処理Ｐ８３）。

これに対し、処理Ｐ５６での判定の結果、ＵＤＰベースプロトコルの推定スループットがＴＣＰベースプロトコルの推定スループットよりも大きい場合（処理Ｐ５６でＹｅｓの場合）、制御部７８は、以下の処理Ｐ８２及びＰ８３を実施する。

すなわち、制御部７８は、プロトコル指定テーブル７９Ｂに、仮想ソケット処理部７４から通知された共通シーケンス番号のデータパケットをＵＤＰベースプロトコルで送信することを登録する（処理Ｐ８２）。また、制御部７８は、仮想ソケット処理部７４に対し、当該共通シーケンス番号のデータパケットをＵＤＰ送信ソケットバッファ７５１Ｕ及びＴＣＰ送信ソケットバッファ７５１Ｔの双方に書き込むよう指示する（処理Ｐ８３）。

以上のようにして、制御部７８は、通信品質の測定結果に応じて、データパケットを書き込む送信ソケットバッファ７５１Ｕ及び７５１Ｔを適応的に選択制御する。これにより、無線端末１０（ＷＯ＃１）は、無線アクセス網３０の通信品質に応じた適切なプロトコルでデータパケットを送信することができる。したがって、ＷＯ＃１及びＷＯ＃２の間の通信性能（例えば、平均スループット）の向上を図ることができる。

また、ＣＲ内では、送信ソケットバッファ７５１Ｕ及び７５１Ｔの双方にデータパケットを書き込むので、ＵＤＰベース及びＴＣＰベースのプロトコル間の切り替えを最小限のタイムラグで、また、パケットロスを発生させずに実施することが可能である。

なお、上述した例は、アップストリームについてのＷＯ＃１における制御部７８に着目した動作例であるが、ダウンストリームについてのＷＯ＃２における制御部９８の動作例も、上述した例と同様でよい。

（第２実施形態）
図２３は、第２実施形態に係る通信システム１の構成例を示すブロック図である。図２３に例示する通信システム１の構成は、例えば図６及び図８において例示したパケットフィルタ部７５３を、ＷＯ＃１に備えず、代替的に、ＷＯ＃２に備えた構成に相当する。別言すると、第２実施形態では、第１実施形態においてアップストリームの送信側であるＷＯ＃１で実施していたパケットフィルタリングを、受信側であるＷＯ＃２において実施する。

そのため、第２実施形態のＷＯ＃１では、ＷＯ＃１の仮想ソケット処理部７４から各プロトコルに対応した送信ソケットバッファ７５１Ｕ及び７５１Ｔの双方に書き込まれたデータパケットが、フィルタリングされずに各プロトコルでＷＯ＃２へ送信される。

ただし、第２実施形態では、ＷＯ＃１の制御部７８が、ＷＯ＃２の制御部９８とネゴシエーションメッセージを交換することにより、ＷＯ＃１におけるプロトコル指定テーブル７９Ｂの内容をＷＯ＃２に通知する。

ＷＯ＃２の制御部９８は、通知されたプロトコル指定テーブル７９Ｂの内容に従って、どの共通シーケンス番号をもつデータパケットを通過させ破棄するかをＷＯ＃２のパケットフィルタ部７５３に指示する。

パケットフィルタ部７５３は、制御部９８からの指示に従い、採用しないプロトコルのデータパケットを破棄する。この際、パケットフィルタ部７５３は、破棄したパケットに対する再送をＷＯ＃１に求めないよう、ＷＯ＃２の各プロトコル受信処理部９２５Ｕ及び９２５Ｔに対し通知する。

ＷＯ＃２の各プロトコル受信処理部９２５Ｕ及び９２５Ｔは、パケットフィルタ部７５３から通知された破棄パケットに対しては、あたかも受信したかのように確認応答パケットをＷＯ＃１へ返信する。ＷＯ＃１の各プロトコル送信処理部７５２Ｕ及び７５２Ｔでは、確認応答パケットを受信すると、再送バッファ７５５Ｕ及び７５５Ｔに保持した該当データパケットを削除する。これにより、第１実施形態と同様に、ＷＯ＃２のパケットフィルタ部７５３で意図的に破棄されたデータパケットについての再送がキャンセルされる。

以上のように、パケットフィルタを受信側で実施することによっても、第１実施形態と同様の作用効果を得ることができる。

なお、他の動作（処理）については、第１実施形態と同様である。また、上述した例は、アップストリームの動作例であるが、ダウンストリームの動作についても上述した例と同様と考えてよい。例えば、ダウンストリームについては、送信側であるＷＯ＃２にはパケットフィルタ部を備えず、代替的に、受信側であるＷＯ＃１にパケットフィルタ部を備えればよい。

（第３実施形態）
次に、図２４を参照して、第３実施形態について説明する。図２４は、図１０に例示したプロトコル選択テーブル７９Ａ（９９Ａ）の変形例を示す図である。図１０にＣＲを例示したが、ＣＲの決め方によって、ＵＤＰベース及びＴＣＰベースの各プロトコルの送信ソケットバッファ７５１Ｕ及び７５１Ｔに書き込み可能なデータ量が決まる。

そのため、ＣＲは、例示的に、送信側のＷＯ＃１（又は、ＷＯ＃２）が搭載するメモリサイズに応じて可変としてよい。例えば、ＣＲは、以下の式（２）に例示するように設計してもよい。なお、式（２）において、ｐは廃棄率（％）、ＴはＷＯ＃１（又は、ＷＯ＃２）が搭載する総メモリサイズ（ギガバイト）、ＮはＷＯ＃１（又は、ＷＯ＃２）が扱う通信セッションの数（別言すると、仮想ソケットの数）、Ｍは、Ｔ／Ｎで表される、セッションあたりのメモリサイズ（ギガバイト）をそれぞれ表す。

上記の式（２）によると、図２４に例示するように、搭載メモリサイズが大きいほどＣＲが広くなる。なお、図２４には、例示的に、搭載メモリサイズが１ギガバイトの場合のＣＲ＃１と、搭載メモリサイズが１０ギガバイトの場合のＣＲ＃２と、を示している。

例えば、無線基地局１００と無線端末１０とでは、メモリサイズが異なり、また、扱う通信セッションは無線端末１０よりも無線基地局１００の方が多いと考えられる。したがって、無線基地局１００と無線端末１０とで、メモリサイズ及び扱う通信セッション数に応じてＣＲを最適化することが可能となり、それぞれに適したプロトコル切り替えを実現可能である。

（第４実施形態）
ＣＲは、下記の式（３）に例示するように、ＷＯ＃１（又は、ＷＯ＃２）のメモリ使用率ｍ（％）に応じて可変にしてもよい。

式（３）において、αは、式（４）で表される、廃棄率ｐの時間変化（時間微分）を表す。また、式（３）において、Ｍはセッションあたりのメモリサイズ（ギガバイト）を表す。更に、図２５（Ｂ）に模式的に例示するように、ｗは仮想ソケット処理部７４（又は、９４）による送信ソケットバッファ７５１Ｕ及び７５１Ｔ（又は、９３１Ｕ及び９３１Ｔ）へのデータ書き込みレートを表す。また、ｓはＷＡＮ３０へのデータ出力（送信）レートを表す。

ただし、データ書き込みレート（ｗ）は、仮想ソケット処理部７４（又は、９４）へのデータ入力レートと同じであると仮定している。また、ＷＡＮ３０へのデータ送信レート（ｓ）は、送信ソケットバッファ７５１Ｕ及び７５１Ｔ（又は、９３１Ｕ及び９３１Ｔ）からのデータ読み出しレートと同じであると仮定している。

メモリには、入力レート（ｗ）の入力データに対し、ＵＤＰ及びＴＣＰそれぞれの送信ソケットバッファ７５１Ｕ及び７５１Ｔ（又は、９３１Ｕ及び９３１Ｔ）に書き込むため２ｗのレートで書き込むのに対し、レートｓでデータが減る。従って、２ｗ−ｓの割合でメモリにデータが蓄積する。

メモリ使用率をｍで表すと、（１００−ｍ）Ｍのメモリが空き容量として利用可能である。２ｗ−ｓの割合でデータが蓄積するので、ｔ＝（１００−ｍ）Ｍ／（２ｗ−ｓ）秒の間はデータを蓄積できる。ここで、廃棄率ｐの時間変化がαであるため、α×（１００−ｍ）／（２ｗ−ｓ）だけ廃棄率ｐが変化してもデータをバッファに蓄積可能である。プロトコル切替えポイントｐの前後にα×（１００−ｍ）／（２ｗ−ｓ）を均等に分配するため、２で割ると、式（３）が得られる。

上記の式（３）によると、図２５（Ａ）に例示するように、メモリ使用率（ｍ）が低いほど（別言すると、空きメモリサイズが多いほど）ＣＲが広くなる。なお、図２５（Ａ）には、例示的に、空きメモリサイズが１ギガバイトの場合のＣＲ＃３と、空きメモリサイズが１０ギガバイトの場合のＣＲ＃４と、を示している。

したがって、第３実施形態と同様に、無線基地局１００と無線端末１０とで、それぞれの処理能力及び扱う通信セッション数に応じてＣＲを最適化することが可能となり、それぞれに適したプロトコル切り替えを実現可能である。

（第５実施形態）
図２６は、第５実施形態に係る通信システム１の一例を示すブロック図である。図２６に示す通信システム１は、図４に例示した構成に比して、第１の無線基地局の一例であるＷｉＦｉ基地局１００に加え、第２の無線基地局１０１を備える点が異なる。

第２の無線基地局１０１の一例は、ＬＴＥ（Long Term Evolution）やＬＴＥ−Ａｄｖａｎｃｅｄ等の規格に準拠した無線基地局１０１である。そのため、以下、無線基地局１０１を「ＬＴＥ基地局１０１」と称することがある。

ＬＴＥ基地局１０１は、ＷＡＮ最適化装置９０（ＷＯ＃２）と例えば有線により通信可能に接続されてよい。ＬＴＥ基地局１０１は、無線通信が可能な無線エリアを提供する。無線エリアは、カバレッジあるいはセル等とも称される。セルには、マクロセルやスモールセル（例えば、フェムトセル、ピコセル、マイクロセル）等が含まれてよい。

図２６に例示する通信システム１では、無線端末１０は、ＷｉＦｉ基地局１００が提供する無線エリアとＬＴＥ基地局１０１が提供する無線エリアとの双方に位置する場合、双方の無線基地局１００及び１０１を介してサーバ５０にアクセスすることが可能である。別言すると、無線端末１０は、ＷｉＦｉ回線とＬＴＥ回線との双方を介してサーバ５０と通信することが可能である。なお、「回線」は「パス」や「チャネル」と称してもよい。

この場合、ＷｉＦｉ回線とＬＴＥ回線とで異なる通信プロトコルを用いることが可能である。例えば、ＷＯ＃１とＷＯ＃２との間の通信に関して、ＷｉＦｉ回線ではＵＤＰベースプロトコルを用い、ＬＴＥ回線ではＴＣＰベースプロトコルを用いることができる。

ここで、例えば、ＬＴＥ回線にてＴＣＰベースプロトコルを用いて各ＷＯ＃１及び＃２が通信している時に、無線端末１０の移動やＬＴＥ回線の障害発生等に伴ってＬＴＥ回線が不通になったとする。この場合、無線端末１０は、ＷｉＦｉ回線でサーバ５０と通信を継続することが可能である。ただし、ＷＯ＃１及びＷＯ＃２は、ＬＴＥ回線で使用していたＴＣＰベースプロトコルをＷｉＦｉ回線で使用するＵＤＰベースプロトコルに切り替える。

このような回線切り替えに応じたプロトコル切り替えを実現するＷＯ＃１及びＷＯ＃２の構成例を図２７に示す。ただし、図２５には、アップストリームに着目した場合の、送信装置としてのＷＯ＃１及び受信装置としてのＷＯ＃２の構成例を示しており、ダウンストリームの構成については図示を省略している。

図２７に示すＷＯ＃１は、既述の各実施形態に比して、ＵＤＰベース及びＴＣＰベースの各プロトコル送信処理部７５２Ｕ及び７５２Ｔのそれぞれに生存確認（キープアライブ確認）部７５７Ｕ及び７５７Ｔを備える点が異なる。

また、図２７に示すＷＯ＃２は、既述の各実施形態に比して、ＵＤＰベース及びＴＣＰベースの各プロトコル受信処理部９２１Ｕ及び９２１Ｔのそれぞれに生存確認（キープアライブ確認）部９２７Ｕ及び９２７Ｔを備える点が異なる。

更に、図２７に示すＷＯ＃１及びＷＯ＃２は、既述の各実施形態に比して、既述のパケットフィルタ部７５３及びプロトコル選択テーブル７９Ａ（９９Ａ）を備えなくてよい点が異なる。

送信装置としてのＷＯ＃１の各キープアライブ確認部７５７Ｕ及び７５７Ｔは、それぞれ、図２８に例示するようなキープアライブメッセージを周期的に受信装置としてのＷＯ＃２へ送信する。キープアライブメッセージには、図２８に例示するように、メッセージ（リクエスト）を識別する識別番号（例えば、４バイト）と、当該メッセージの送信時刻を示すタイムスタンプ（例えば、４バイト）と、が含まれてよい。

ＷＯ＃２では、各プロトコル受信処理部９２１Ｕ及び９２１Ｔにおいてそれぞれキープアライブメッセージが受信されると、キープアライブ確認部９２７Ｕ及び９２７Ｔが、図２９に例示するようなキープアライブ応答メッセージをＷＯ＃１へ送信する。図２８と図２９と比較してみれば分かるとおり、キープアライブ確認部９２７Ｕ及び９２７Ｔは、それぞれ、受信したキープアライブメッセージの内容をキープアライブ応答メッセージの内容としてコピーして送信してよい。

ＷＯ＃１におけるキープアライブ確認部７５７Ｕ及び７５７Ｔは、それぞれ、キープアライブ応答メッセージがキープアライブメッセージを送信してから所定時間内に受信されないと、その旨を制御部７８に通知する。

制御部７８は、ＴＣＰベース及びＵＤＰベースの各プロトコルのそれぞれについて、キープアライブ応答メッセージの不達通知を監視し、所定回数連続して不達通知を検出すると、対応するプロトコルでの通信が不能であると判断する。

例えば、上述したようにＬＴＥ回線が不通になると、ＴＣＰベースプロトコルでのキープアライブ応答メッセージが受信されなくなるので、制御部７８は、ＴＣＰベースプロトコルでの通信が不能であると判断する。なお、通信が不能であると判断される、キープアライブ応答メッセージの連続不達回数は、特に限定されないが、例示的に、５回に設定してよい。

ただし、制御部７８は、キープアライブ応答メッセージの不達通知を一度でも受信すると、仮想ソケット処理部７４に対し、以降にプロキシ処理部７３から受信したデータパケットをＵＤＰ送信ソケットバッファ７５１Ｕ及びＴＣＰ送信ソケットバッファ７５１Ｔの双方に書き込むよう指示を与える。併せて、制御部７８は、両送信ソケットバッファ７５１Ｕ及び７５１Ｔに書き込み指示を与えたデータパケットはＵＤＰベース及びＴＣＰベースの双方のプロトコルで送信することをプロトコル指定テーブル７９Ｂに登録する。

例えば、ＴＣＰベースプロトコル送信処理部７５２Ｔにおけるキープアライブ確認部７５７Ｔが、共通シーケンス番号＃１２の付与されたデータパケット＃１２を送信したところで、キープアライブ応答メッセージの不達が制御部７８において検出されたとする。この場合、制御部７８は、仮想ソケット処理部７４に対し、データパケット＃１３以降のデータパケットを両送信ソケットバッファ７５１Ｕ及び７５１Ｔに書き込むよう指示し、当該指示に応じてプロトコル指定テーブル７９Ｂを更新する。

本実施形態では、ＷＯ＃１にパケットフィルタ部７５３が備えられていないので、各送信ソケットバッファ７５１Ｕ及び７５１Ｔに書き込まれたデータパケットは、それぞれ、ＵＤＰベース及びＴＣＰベースの各プロトコルでＷＯ＃２へ送信される。

しかし、上述したようにＬＴＥ回線が不通になっている場合、共通シーケンス番号＃１３以降が付与された、ＴＣＰベースプロトコルの各データパケットは全てパケットロスすることになる。

そして、ＷＯ＃１の制御部７８は、キープアライブ応答メッセージの連続不達通知回数が所定回数に達したことを検出すると、ＴＣＰベースプロトコルでの通信が不能と判断する。当該判断に応じて、制御部７８は、仮想ソケット処理部７４に対し、以降にプロキシ処理部７３から受信されるデータパケットの書き込み対象をＵＤＰ送信ソケットバッファ７５１Ｕに切り替える指示を与える。

例えば、キープアライブ応答メッセージの連続不達通知回数が所定回数に達したタイミングが、仮想ソケット処理部７４がデータパケット＃１８を両送信ソケットバッファ７５１Ｕ及び７５１Ｔに書き込んだ後であったとする。この場合、仮想ソケット処理部７４は、制御部７８からの指示に応じて、データパケット＃１９以降のデータパケットを、両送信ソケットバッファ７５１Ｕ及び７５１Ｔのうち、ＵＤＰ送信ソケットバッファ７５１Ｕのみに書き込む。また、制御部７８は、データパケット＃１９以降のデータパケットはＵＤＰベースプロトコルで送信することをプロトコル指定テーブル７９Ｂに登録する。

その一方で、ＷＯ＃１の制御部７８は、ＷＯ＃２の制御部９８に対し、ネゴシエーションメッセージを用いてプロトコル指定テーブル７９Ｂの内容を通知する。別言すると、制御部７８は、データパケット＃１３〜＃１８についてはＵＤＰベース及びＴＣＰベースの双方のプロトコルで送信し、かつ、データパケット＃１９以降のパケットについてはＵＤＰベースのプロトコルに切り替えて送信することを通知する。ＷＯ＃２は、通知されたプロトコル指定テーブル７９Ｂの内容を自装置のプロトコル指定テーブル９９Ｂとして例えばメモリ３０２（図９参照）に登録する。

ＷＯ＃２では、ＴＣＰベースプロトコルのデータパケット＃１３以降のパケットロスがＴＣＰベースプロトコル受信処理部９２１Ｔにて検出される。しかし、ＵＤＰベースプロトコル受信処理部９２１ＵにてＵＤＰベースプロトコルでデータパケット＃１３以降のパケットを受信していれば、ＷＯ＃１に対して該当パケットの再送要求は実施せずに受信成功と判断する。なお、ＵＤＰベースプロトコル受信処理部９２１ＵにてＵＤＰベースプロトコルでデータパケット＃１３以降のパケットを受信しているか否かは、制御部９８を通じてＴＣＰベースプロトコル受信処理部９２１Ｔに通知してよい。

そして、ＷＯ＃２の制御部９８は、プロトコル指定テーブル９９Ｂを参照することで、共通シーケンス番号＃１９以降のデータパケットはＵＤＰベースプロトコルで受信されることを認識する。これにより、制御部９８は、ＵＤＰベースプロトコル受信処理部９２１Ｕに対し、データパケット＃１９以降のパケットから抽出したデータ（ペイロード）をＵＤＰ受信ソケットバッファ９２２Ｕに書き込むよう指示する。

以上のようにして、無線端末１０とサーバ５０との間を経由する回線の切り替えに応じたプロトコル切り替えを、既述の各実施形態と同様に、遅滞無く適切に実施することが可能である。

なお、上述した例は、アップリンクに着目したプロトコル切り替え動作であるが、既述の各実施形態でも付言したとおり、ダウンリンクのプロトコル切り替え動作についても、上述した例と同様にして実施可能である。

（第６実施形態）
上述した各実施形態では、プロトコル切り替えを実施するタイミングが、各送信ソケットバッファ７５１Ｕ及び７５１Ｔ（又は、９３１Ｕ及び９３１Ｔ）に書き込まれるデータパケット間の境界（バウンダリ）に一致している場合について説明した。しかし、通信プロトコルによっては、プロトコル切り替えタイミングとデータパケット間の境界とが一致しない場合もある。そのような場合には、制御部７８（又は、９８）は、プロトコル切り替えタイミングを遅らせる等して補正するようにしてもよい。

プロトコル切り替えタイミングとデータパケット間の境界との不一致が生じ得る通信プロトコルの一例として、送信データに冗長符号を付加し、冗長化したデータを送信するプロトコルが挙げられる。そのような通信プロトコルの非限定的な一例としては、ランダムパリティストリーム（ＲＰＳ）と呼ばれるプロトコルが挙げられる。

図３０に、ＲＰＳを用いた通信の概要を模式的に例示する。図３０に例示するように、送信装置４００は、送信データ（例えば、＃１〜＃４，…）に対し符号化行列を排他論理和演算（ＸＯＲ）することで、冗長化データ（例えば、＃Ａ〜＃Ｅ，…）を生成する。この冗長化データは、送信データに対して冗長符号が付加されているため、データサイズが元の送信データのサイズよりも大きくなる。送信装置４００は、生成した冗長化データを受信装置５００へ送信する。

受信装置５００は、受信した冗長化データに対して再度ＸＯＲ演算を行なうことで、元の送信データを得る。ＲＰＳでは、冗長化データの一部がネットワーク（例えば、ＷＡＮ３０）で失われても、他の受信パケットに含まれる冗長化データから送信データを復元できる。

そのため、ＲＰＳでは、一定量のパケットロスに対しては再送要求が不要であるというメリットがある。なお、冗長化データを生成するために用いる符号化行列や演算方法は、上記に限定されず、他の行列や演算方法を用いてもよい。

ここで、ＲＰＳでは、上述のような冗長符号化を行なうため、送信データのサイズは一定とされる。そのため、例えば第１実施形態において、各送信ソケットバッファ（符号省略）にデータが書き込まれ始めた後、プロトコル切り替えタイミングが到来しても、当該タイミングが送信データの境界（バウンダリ）と一致しないことがある。

例えば図３１に示すように、仮想ソケット処理部７４が共通シーケンス番号＃１３のデータパケット＃１３を受信したタイミングで、制御部７８においてパケット廃棄率がＣＲに入ったことが検出されたとする。なお、図３１は、第１実施形態の図８と対応する図であり、図８と同様に、アップストリームに着目した場合の、送信装置としてのＷＯ＃１及び受信装置としてのＷＯ＃２の構成例を示し、ダウンストリームの構成については図示を省略している。

この場合、仮想ソケット処理部７４は、データパケット＃１３以降のデータパケットを各送信ソケットバッファ７５１Ｕ及び７５１Ｔの双方に書き込み始める。

そして、制御部７８は、例えばパケット廃棄率がプロトコル切り替えポイント（図１０参照）に到達したタイミング（例えば、データパケット＃１６の書き込みタイミング）でプロトコル切り替えを実施しようとする（図３２参照）。

しかし、例えば、データパケット＃１１〜＃１４が第１の送信データ＃１を成し、データパケット＃１５〜＃１８が第２の送信データ＃２を成す場合、データパケット＃１６の書き込みタイミングは、第２の送信データ＃２の書き込み途中のタイミングに相当する。

そこで、制御部７８は、図３２に例示するように、プロトコル切り替えタイミングを例えば第２の送信データ＃２を成す最終パケット＃１８の書き込みが完了するタイミングに補正し、補正したタイミングを例えばプロトコル指定テーブル７９Ｂに設定する。

なお、廃棄率がＣＲを超えない範囲にある間は、プロトコル切り替えタイミングを補正したタイミング（補正プロトコル切り替えタイミング）に設定してよい。また、送信データをソケットバッファに書き込んでいる途中で廃棄率がＣＲを外れた場合は、その一連のデータに限り廃棄率がＣＲを外れていても、一番近いバウンダリまで両ソケットバッファに書き続けるようにしてもよい。

その後、制御部７８において、プロトコル選択テーブル７９Ａに基づき、例えばパケット廃棄率がＣＲを抜けたことが検出されてプロトコルが選択されると、仮想ソケット処理部７４は、選択プロトコルの送信ソケットバッファに書き込み対象を切り替える。この場合も、当該切り替えの際に書き込み途中の送信データがあれば、仮想ソケット処理部７４は、書き込み途中の送信データのバウンダリが到来するまで書き込みを継続する。

なお、その他の動作（処理）は、既述の実施形態と同様でよい。また、図３１には、アップストリームに着目した動作例を示しているが、既述の各実施形態でも付言したとおり、ダウンストリームについても、上述した例と同様にして実施可能である。

以上のように、本実施形態によれば、例えば１つのデータとして処理されるべき送信データと他の送信データとのバウンダリに応じて、プロトコル切り替えタイミングを補正することができる。したがって、既述の各実施形態と同様の作用効果が得られるほか、１つの送信データの途中でプロトコルが切り替えられてしまって当該送信データが正しく送受信されなくなることを防止できる。

（その他）
上述した各実施形態では、ＴＣＰベースプロトコルからＵＤＰベースプロトコルへの切り替えについて説明したが、逆の切り替えについても上述した各実施形態と同様にして実施可能である。また、上述した各実施形態では、ＴＣＰベース及びＵＤＰベースというベースの異なるプロトコル間の切り替え動作について説明したが、ベースが同じプロトコル間の切り替え動作についても、上述した各実施形態と同様に実施可能である。

例えば、ＴＣＰベースプロトコルを別のＴＣＰベースプロトコルに切り替えることも可能であるし、ＵＤＰベースプロトコルを別のＵＤＰベースプロトコルに切り替えることも可能である。更に、上述した各実施形態では、ＵＤＰベースとＴＣＰベースの２つのプロトコル間の切り替えについて説明したが、３つ以上のプロトコル間の切り替えも、上述した各実施形態と同様にして実施可能である。

１０ 端末（無線端末）
３０ ＷＡＮ（無線アクセス網）
５０ サーバ
７０ ＷＡＮ最適化装置（ＷＯ＃１）
７１ 入出力インタフェース（ＩＦ）
７２ ＴＣＰ処理部
７３ プロキシ処理部
７４ 仮想ソケット処理部
７４１ 共通シーケンス番号付与部
７５ 送信処理部
７５１Ｕ ＵＤＰ送信ソケットバッファ
７５１Ｔ ＴＣＰ送信ソケットバッファ
７５２Ｕ ＵＤＰベースプロトコル送信処理部
７５２Ｔ ＴＣＰベースプロトコル送信処理部
７５３ パケットフィルタ部
７５５Ｕ，７５５Ｔ 再送バッファ
７５６Ｕ，７５６Ｔ 品質計測部（送信側）
７５７Ｕ，７５７Ｔ 生存確認部（送信側）
７６ 受信処理部
７７ 無線ＩＦ
７８ 制御部
７９Ａ プロトコル選択テーブル
７９Ｂ プロトコル指定テーブル
９０ ＷＡＮ最適化装置（ＷＯ＃２）
９１ 無線ＩＦ
９２ 受信処理部
９２１Ｕ ＵＤＰベースプロトコル受信処理部
９２１Ｔ ＴＣＰベースプロトコル受信処理部
９２２Ｕ ＵＤＰ受信ソケットバッファ
９２２Ｔ ＴＣＰ受信ソケットバッファ
９２５Ｕ，９２５Ｔ 品質計測部（受信側）
９２７Ｕ，９２７Ｔ 生存確認部（受信側）
９３１Ｕ ＵＤＰ送信ソケットバッファ
９３１Ｔ ＴＣＰ送信ソケットバッファ
９３２Ｕ ＵＤＰベースプロトコル送信処理部
９３２Ｔ ＴＣＰベースプロトコル送信処理部
９３３ パケットフィルタ部
９３５Ｕ，９３５Ｔ 品質計測部（送信側）
９４１ 共通シーケンス番号付与部
９４２ リオーダリング処理部
９４３ リオーダリングバッファ
９３ 送信処理部
９４ 仮想ソケット処理部
９５ プロキシ処理部
９６ ＴＣＰ処理部
９７ 有線ＩＦ
９８ 制御部
９９Ａ プロトコル選択テーブル
９９Ｂ プロトコル指定テーブル
１００ 無線（ＷｉＦｉ）基地局
３００ 無線装置
３０１ ＣＰＵ
３０２ メモリ
３０３ ストレージ
３０４，３０５ ＮＩＣ
３０６ 入力装置
３０７ 出力装置
３０８ 記録媒体ドライブ
３０９ バス
３１０ アンテナ
４００ 送信装置
５００ 受信装置

Claims (15)

1. 第１のプロトコル及び第２のプロトコルのいずれかを用いて通信する通信方法であって、
   プロトコルの切り替えトリガが発生するよりも前に、前記第１及び第２のプロトコルの一方の送信データと同じ送信データを他方のプロトコルの送信バッファに重複して書き込み、
   前記切り替えトリガの発生に応じて、前記一方のプロトコルから前記他方のプロトコルへの切り替えを実施する、通信方法。
2. 前記送信データを送信する送信装置は、
   前記送信データを受信する受信装置との間の通信品質を計測し、
   前記計測の結果が、前記切り替えトリガの発生要因となる通信品質を示すポイントを含む所定の通信品質領域に入ると、前記送信バッファに対する前記送信データの重複した書き込みを開始する、請求項１に記載の通信方法。
3. 前記送信装置は、前記計測の結果が、前記通信品質領域から外れると、前記送信バッファに対する前記送信データの重複した書き込みを停止する、請求項２に記載の通信方法。
4. 前記送信装置は、前記送信バッファに重複して書き込まれた送信データのうち、前記切り替えトリガの発生に応じて選択されないプロトコルについての送信データをフィルタする、請求項１〜３のいずれか１項に記載の通信方法。
5. 前記送信装置は、前記送信バッファに重複して書き込まれた送信データを前記第１及び第２のプロトコルで送信し、
   前記受信装置は、前記各プロトコルで受信した前記送信データのうち、前記切り替えトリガの発生に応じて選択されないプロトコルについての送信データをフィルタする、請求項１〜３のいずれか１項に記載の通信方法。
6. 前記送信装置は、
   前記送信データを再送に備えて再送バッファに記憶しておき、
   前記フィルタされた送信データを前記再送バッファから削除する、請求項４又は５に記載の通信方法。
7. 前記送信装置は、
   冗長符号化された前記送信データの境界に応じて前記プロトコルの切り替えタイミングを補正する、請求項１〜６のいずれか１項に記載の通信方法。
8. 前記送信装置は、
   前記送信データに対し前記第１及び第２のプロトコルに依存しないシーケンス番号を付与し、
   前記受信装置は、
   受信した前記送信データに付与されたシーケンス番号に基づいて前記送信データの受信処理を制御する、請求項１〜７のいずれか１項に記載の通信方法。
9. 前記受信処理は、受信した前記送信データを当該送信データが前記送信装置から送信された順序となるように並べ替える処理を含む、請求項８に記載の通信方法。
10. 前記切り替えトリガは、記第１のプロトコルを用いた第１の通信パスと前記第２のプロトコルを用いた第２の通信パスとのうち、前記第１のパスの不通によって発生する、請求項１〜９のいずれか１項に記載の通信方法。
11. 前記第１のプロトコルは、ＴＣＰ（transmission control protocol）に基づくプロトコルであり、前記第２のプロトコルは、ＵＤＰ（user datagram protocol）に基づくプロトコルである、請求項１〜１０のいずれか１項に記載の通信方法。
12. 前記通信品質領域は、前記送信バッファが含まれるメモリのサイズに応じて設定される、請求項２又は３に記載の通信方法。
13. 前記通信品質領域は、前記送信バッファが含まれるメモリの使用率に応じて設定される、請求項２又は３に記載の通信方法。
14. 第１のプロトコル及び第２のプロトコルのいずれかを用いて通信する通信装置の通信制御プログラムであって、
    前記通信制御プログラムは、コンピュータに、
    プロトコルの切り替えトリガが発生するよりも前に、前記第１及び第２のプロトコルの一方の送信データと同じ送信データを他方のプロトコルの送信バッファに重複して書き込ませ、
    前記切り替えトリガの発生に応じて、前記一方のプロトコルから前記他方のプロトコルへの切り替えを実施する、
    処理を実行させる、通信制御プログラム。
15. 第１のプロトコル及び第２のプロトコルのいずれかを用いて通信する通信装置であって、
    前記第１及び第２のプロトコルのそれぞれに対応した送信バッファと、
    プロトコルの切り替えトリガが発生するよりも前に、前記第１及び第２のプロトコルの一方の送信データと同じ送信データを他方のプロトコルの送信バッファに重複して書き込み、前記切り替えトリガの発生に応じて、前記一方のプロトコルから前記他方のプロトコルへの切り替えを実施する制御部と、
    を備えた、通信装置。

Images