(57)【要約】【課題】伝送遅延の差が大きい複数の経路を利用したマルチパス通信において、より効率的に帯域幅を活用することができるようにする。【解決手段】ＯＳ（オペレーティングシステム２０１）上で実行されるＴＣＰ／ＩＰ通信制御部２０２、および、ＭＰＴＣＰ制御部２０３が設けられている。ＴＣＰ／ＩＰ通信制御部２０２、および、ＭＰＴＣＰ制御部２０３の上位層としてアプリケーションプログラム２０４が実行される。ＭＰＴＣＰ制御部２０３の一部として分配制御部２１１が設けられ、各ネットワークインタフェースから送信されるデータに係る分配を制御するようになされている。分配制御部２１１は、サブフロー毎に伝送遅延を特定し、輻輳ウィンドウサイズを予測しながら、到達予想時間を算出／更新し、到達予想時間が最小となるサブフローにセグメントを送出する。【選択図】図６
2014127790.tif 000002
【特許請求の範囲】
【請求項１】
複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置であって、
前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択するキュー選択部と、
前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測するウィンドウサイズ予測部と、
前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出する送出予想時間算出部と、
前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新する更新部と、
前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配する輻輳時キュー制御部と
を備える情報処理装置。
【請求項２】
前記輻輳時キュー制御部は、
前記輻輳またはパケットロスの発生に伴って縮小された輻輳ウィンドウサイズを初期値として取得し、
前記輻輳またはパケットロスの発生したサブフローのキューに、前記キューに蓄積されていたセグメントを１つずつ仮想的に挿入し、前記キューに対応づけられた到達予想時間を、前記セグメント毎に再計算し、
前記再計算により、前記輻輳またはパケットロスの発生したサブフロー以外のサブフローに対応するキューのそれぞれに対応づけられた到達予想時間のうち、最大の到達予想時間を超える到達予想時間が得られた場合、そのセグメントより送信順が後のセグメントを、前記輻輳またはパケットロスの発生したサブフロー以外のサブフローに対応するキューに分配する
請求項１に記載の情報処理装置。
【請求項３】
前記複数のサブフローは、それぞれ伝送遅延が異なるネットワーク上でのデータの送受信により生成されたＴＣＰコネクションに対応する
請求項１に記載の情報処理装置。
【請求項４】
前記複数のＴＣＰコネクションのうちの少なくともいずれか１つは、広域無線通信によるネットワークを利用する
請求項１に記載の情報処理装置。
【請求項５】
複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置の情報処理方法であって、
キュー選択部が、前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択し、
ウィンドウサイズ予測部が、前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測し、
送出予想時間算出部が、前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出し、
更新部が、前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新し、
輻輳時キュー制御部が、前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配するステップ
を含む情報処理方法。
【請求項６】
コンピュータを、
複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置であって、
前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択するキュー選択部と、
前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測するウィンドウサイズ予測部と、
前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出する送出予想時間算出部と、
前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新する更新部と、
前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配する輻輳時キュー制御部とを備える情報処理装置として機能させる
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、情報処理装置および方法、並びにプログラムに関し、特に、伝送遅延の差が大きい複数の経路を利用したマルチパス通信において、より効率的に帯域幅を活用することができるようにする情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
近年、無線通信インフラの多様化により、スマートフォン等のモバイル機器には複数のネットワークインタフェースが搭載されることが多い。例えば、モバイル機器において、Bluetooth（登録商標）、Ｗｉ−Ｆｉなどの近距離無線通信を行いつつ、３Ｇ（IMT-2000）、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）などの広域無線通信を行うことが提案されている。
【０００３】
すなわち、物理層、データリンク層、または、ネットワーク層において、それぞれ異なる経路で同一の宛先と通信する、マルチパス通信が提案されている。
【０００４】
例えば、１つのアプリケーションプログラムが、複数のネットワークインタフェースを効率的に利用したマルチパス通信を行うことが可能であれば、アプリケーションプログラムの処理に係る時間を短縮することも可能になる。しかし、既存のトランスポート層プロトコルであるＴＣＰでは、複数のインタフェースを同時に利用する負荷分散はできず、利用可能な帯域を十分に活用できない。
【０００５】
また、ＴＣＰセッションは、ＩＰアドレスと１対１で対応していることから、ネットワーク層での接続が失われるとＴＣＰセッションが切断されることになる。
【０００６】
例えば、Ｗｉ−Ｆｉで通信中にエリア外に移動した場合、ネットワーク層での接続が一旦失われることになるが、この際に都度、ＴＣＰセッションが切断されると、アプリケーションの処理などに支障をきたしかねない。このような問題は、例えば、ユビキタスネットワークの発展を阻害する要因となり得る。
【０００７】
このような問題を解決するために提案されたプロトコルの１つに、マルチパスＴＣＰ（ＭＰＴＣＰ）がある。ＭＰＴＣＰは、複数のネットワークインタフェースを同時に利用することで、マルチホーミング（通信経路の冗長性確保や負荷分散）を実現するトランスポート層プロトコルのである。ＭＰＴＣＰは、既存のＴＣＰを拡張する（ヘッダ内のオプションを利用する）ものであるため、世界中に広く普及している既存のファイヤウォールやＮＡＴの変更なしに用いることが可能である。
【０００８】
ＭＰＴＣＰでは、リソース利用効率と冗長性を高めるために、同一宛先に対してＴＣＰコネクション（リンクとも称する）を複数経路に確立することができ、複数のＴＣＰコネクションを１つにまとめて上位層とのインタフェースを提供する。
【０００９】
一方、ネットワーク層でのマルチホーミングの方式として、ＳＨＡＫＥ(SHAring multipath procedure for a cluster networK Environment)が提案されている（例えば、非特許文献１参照）。
【００１０】
ＳＨＡＫＥでは、Ｍｏｂｉｌｅ  ＩＰをベースとしてホームエージェント(ＨＡ)にトラヒック分配機構を実装し、移動端末(ＭＮ)とＨＡとの間の帯域幅を集約する。
【００１１】
ＭＮがセグメントを送信する際には、パケットが順序通りに到達するよう、最も早くＨＡへ到着すると推測される経路を用いてセグメントを送信する。リンクには仮想的な送信キューを設け、キューから出力されるまでの待ち時間と伝送遅延からパケット到達時刻を予想し各経路へ振り分けるようになされている。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】K. Koyama, Y. Ito, H. Mineno and S. Ishihara, Performance Evaluation of TCP on Mobile IP SHAKE," IPSJ Journal, Vol. 45, No.10, pp. 2270{2278, Oct. 2004.
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ところで、ＭＰＴＣＰでは、リンク性能差（伝送遅延や帯域幅）が大きいネットワークを同時に用いた通信では、送信側の経路選択に応じて受信側においてパケット到着の順序が大きく入れ替わる。しかし、受信側のアプリケーションプログラムでは、所定の順番でパケットを処理する必要があるため、到着したパケットを並べ替えるために、受信側でパケットを一時的に保管するバッファが必要となる。
【００１４】
つまり、伝送遅延が大きいネットワークを介して送信されるパケットは、受信側に到着する時間に遅れが生じるため、伝送遅延が小さいネットワークを介して送信されるパケットより後に到着する。そうすると、送信側から送信した順番とは異なる順番で受信側にパケットが到着することがある。
【００１５】
また、ＭＰＴＣＰでは、送信側でのパケットの分配方式が受信側での並べ替え時間に影響を与えるため、分配方式の如何により受信側のアプリケーションのスループットが不安定になりやすい。すなわち、送信側でのパケットの分配が適切に行われないと、全リンクの帯域幅を有効に活用できない場合もある。
【００１６】
この点、非特許文献１の技術では、キューから出力されるまでの待ち時間と伝送遅延に基づいてパケット到達時刻を予測したパケットの分配が行われる。しかしながら、輻輳やパケットロスなどが発生した場合、到達時刻を精度高く予測することは極めて困難であり、リンク毎に伝送遅延が異なる場合、やはり全リンクの帯域幅を有効に活用することは難しかった。
【００１７】
本技術はこのような状況に鑑みて開示するものであり、伝送遅延の差が大きい複数の経路を利用したマルチパス通信において、より効率的に帯域幅を活用することができるようにするものである。
【課題を解決するための手段】
【００１８】
本技術の一側面は、複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置であって、前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択するキュー選択部と、前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測するウィンドウサイズ予測部と、前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出する送出予想時間算出部と、前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新する更新部と、前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配する輻輳時キュー制御部とを備える情報処理装置である。
【００１９】
前記輻輳時キュー制御部は、前記輻輳またはパケットロスの発生に伴って縮小された輻輳ウィンドウサイズを初期値として取得し、前記輻輳またはパケットロスの発生したサブフローのキューに、前記キューに蓄積されていたセグメントを１つずつ仮想的に挿入し、前記キューに対応づけられた到達予想時間を、前記セグメント毎に再計算し、前記再計算により、前記輻輳またはパケットロスの発生したサブフロー以外のサブフローに対応するキューのそれぞれに対応づけられた到達予想時間のうち、最大の到達予想時間を超える到達予想時間が得られた場合、そのセグメントより送信順が後のセグメントを、前記輻輳またはパケットロスの発生したサブフロー以外のサブフローに対応するキューに分配するようにすることができる。
【００２０】
前記複数のサブフローは、それぞれ伝送遅延が異なるネットワーク上でのデータの送受信により生成されたＴＣＰコネクションに対応するようにすることができる。
【００２１】
前記複数のＴＣＰコネクションのうちの少なくともいずれか１つは、広域無線通信によるネットワークを利用するようにすることができる。
【００２２】
本技術の一側面は、複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置の情報処理方法であって、キュー選択部が、前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択し、ウィンドウサイズ予測部が、前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測し、送出予想時間算出部が、前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出し、更新部が、前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新し、輻輳時キュー制御部が、前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配するステップを含む情報処理方法である。
【００２３】
本技術の一側面は、コンピュータを、複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置であって、前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択するキュー選択部と、前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測するウィンドウサイズ予測部と、前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出する送出予想時間算出部と、
前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新する更新部と、前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配する輻輳時キュー制御部とを備える情報処理装置として機能させるプログラムである。
【００２４】
本技術の一側面においては、前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューが選択され、前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズが予測され、前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間が算出され、前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間が更新され、前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部が、他のサブフローに対応するキューに分配される。
【発明の効果】
【００２５】
本技術によれば、伝送遅延の差が大きい複数の経路を利用したマルチパス通信において、より効率的に帯域幅を活用することができる。
【図面の簡単な説明】
【００２６】
【図１】従来のマルチパス通信を説明する図である。
【図２】図１のマルチパス通信におけるパケットの分配方式を説明する図である。
【図３】図１のマルチパス通信におけるパケットの分配方式を説明する図である。
【図４】本技術を適用したネットワークシステムの構成を示す図である。
【図５】図４のスマートフォンの構成例を示すブロック図である。
【図６】図５のＣＰＵで実行されるソフトウェアの機能的構成を説明する図である。
【図７】ＭＰＴＣＰ制御部によるマルチパス通信の方式を説明する図である。
【図８】分配制御部によるデータの分配の方式を説明する図である。
【図９】輻輳、または、パケットロスが発生した場合の分配制御部によるデータの分配の方式を説明する図である。
【図１０】セグメント分配処理の例を説明するフローチャートである。
【図１１】セグメント退避処理の例を説明するフローチャートである。
【図１２】遅延差の小さい複数のネットワークを用いた従来のマルチパス通信における受信側のリオーダ待ちデータの長さと、アプリケーションで処理可能なデータの送達レートの関係を示す図である。
【図１３】遅延差の大きい複数のネットワークを用いた従来のマルチパス通信における受信側のリオーダ待ちデータの長さと、アプリケーションで処理可能なデータの送達レートの関係を示す図である。
【図１４】図１２および図１３の測定結果を得るために用いたネットワークシステムの構成例を示す図である。
【図１５】パーソナルコンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【００２７】
以下、図面を参照して、ここで開示する技術の実施の形態について説明する。
【００２８】
最初に従来の技術の問題点を説明する。
【００２９】
図１は、従来のマルチパス通信を説明する図である。同図に示されるネットワークシステム１０においては、スマートフォン１１とサーバ１２がマルチパス通信を行うようになされている。
【００３０】
この例では、スマートフォン１１は、Bluetooth（登録商標）、Ｗｉ−Ｆｉなどの近距離無線通信を行うためのネットワークインタフェースと、３Ｇ、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）などの広域無線通信を行うネットワークインタフェースとを有している。
【００３１】
近距離無線通信では、スマートフォン１１から送信されたデータは、アクセスポイント２１を経由してインターネット３１に送出され、サーバ１２に受信される。一方、広域無線通信では、スマートフォン１１から送信されたデータは、基地局２３を経由してインターネット３１に送出され、サーバ１２に受信される。
【００３２】
ここで、近距離無線通信を行うネットワークインタフェースは、広帯域で遅延の小さい通信環境を提供するものとし、広域無線通信を行うネットワークインタフェースは、狭帯域で遅延の大きい通信環境を提供するものとする。
【００３３】
スマートフォン１１は、より効率的な通信を行うために、サーバ１２との通信において、近距離無線通信および広域無線通信のそれぞれのネットワークインタフェースを同時に利用したマルチパス通信を行う。このため、スマートフォン１１は、自分の送信バッファに蓄積されたパケットを、それぞれのネットワークインタフェースに分配する。
【００３４】
図１の例では、送信バッファには、「１」、「２」、および、「３」のパケットが蓄積されており、パケットを表す番号は、サーバ１２で実行されるアプリケーションプログラムにおける当該パケットの処理順序に対応している。
【００３５】
例えば、図２に示されるように、スマートフォン１１は、パケット「１」を、広域無線通信を行うネットワークインタフェースに送出し、パケット「２」およびパケット「３」を、近距離無線通信を行うネットワークインタフェースに送出する。なお、広帯域の近距離無線通信には、２つのパケットが割り振られたのに対し、狭帯域の広域無線通信には、１つのパケットが割り振られている。
【００３６】
例えば、マルチパスＴＣＰ（ＭＰＴＣＰ）を実装したスマートフォンおよびサーバ１２によれば、上述したようなパケットの分配が行われる。ＭＰＴＣＰでは、リソース利用効率と冗長性を高めるために、同一宛先に対してＴＣＰコネクション（リンクとも称する）を複数経路に確立することができ、複数のＴＣＰコネクションを１つにまとめて上位層とのインタフェースを提供する。
【００３７】
しかしながら、スマートフォン１１により、このようなパケットの分配が行われた場合、図３に示されるように、パケット「１」より先に、パケット「２」およびパケット「３」が先にサーバ１２に到着する可能性が高い。広域無線通信は、近距離無線通信と比較して遅延が大きいため、サーバ１２で受信されるまでに長い時間を要するからである。このような場合、サーバ１２では、パケット「１」が到着するまで、パケット「２」およびパケット「３」を処理することができない。このため、サーバ１２では、受信したパケット「２」、パケット「３」をバッファに蓄積し、パケット「１」を受信後に、これらのパケットを並べ替えに係る処理待ち（リオーダ待ち）が発生する。
【００３８】
このようなリオーダ待ちが発生すると、サーバ１２のアプリケーションプログラムが使用できる情報の伝送効率であるグッドプットが低下し、アプリケーションプログラムの処理速度の低下を招くことになる。
【００３９】
ＭＰＴＣＰとは異なる方式でパケットを分配する技術も提案されている。例えば、一方、ネットワーク層でのマルチホーミングの方式として、ＳＨＡＫＥ(SHAring multipath procedure for a cluster networK Environment)が提案されている。ＳＨＡＫＥでは、キューから出力されるまでの待ち時間と伝送遅延に基づいてパケット到達時刻を予測したパケットの分配が行われる。
【００４０】
しかしながら、輻輳やパケットロスなどが発生した場合、到達時刻を精度高く予測することは極めて困難であり、リンク毎に伝送遅延が異なる場合、やはり全リンクの帯域幅を有効に活用することは難しかった。
【００４１】
そこで、本技術では、輻輳やパケットロスなどが発生した場合であっても、極力リオーダ待ちを回避できるようにする。
【００４２】
図４は、本技術を適用したネットワークシステムの構成を示す図である。このネットワークシステム１００においては、スマートフォン１１１とサーバ１１２がマルチパス通信を行うようになされている。
【００４３】
この例では、スマートフォン１１１は、Bluetooth（登録商標）、Ｗｉ−Ｆｉなどの近距離無線通信を行うためのネットワークインタフェースと、３Ｇ、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）などの広域無線通信を行うネットワークインタフェースとを有している。さらに、スマートフォン１１１は、有線通信であるＬＡＮのネットワークインタフェースを有している。
【００４４】
近距離無線通信では、スマートフォン１１１から送信されたデータは、アクセスポイント１２１を経由してインターネット１３１に送出され、サーバ１１２に受信される。また、有線通信では、スマートフォン１１１から送信されたデータは、ルータ１２２を経由してインターネット１３１に送出され、サーバ１１２に受信される。広域無線通信では、スマートフォン１１１から送信されたデータは、基地局１２３を経由してインターネット１３１に送出され、サーバ１１２に受信される。
【００４５】
図５は、図４のスマートフォン１１１の構成例を示すブロック図である。
【００４６】
図５において、スマートフォン１１１のＣＰＵ（Central Processing Unit）１５１は、ＲＯＭ（Read Only Memory）１５２に記憶されているプログラム、または記憶部１６３からＲＡＭ（Random Access Memory）１５３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１５３にはまた、ＣＰＵ１５１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００４７】
ＣＰＵ１５１、ＲＯＭ１５２、およびＲＡＭ１５３は、バス１５４を介して相互に接続されている。このバス１５４にはまた、入出力インタフェース１６０も接続されている。
【００４８】
入出力インタフェース１６０には、キーボード、マウスなどよりなる入力部１６１、ＬＣＤ（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部１６２、および、ハードディスクやフラッシュメモリなどより構成される記憶部１６３が接続されている。
【００４９】
入出力インタフェース１６０にはまた、必要に応じてドライブ１６５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１６６が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１６３にインストールされる。
【００５０】
入出力インタフェース１６０にはさらに、広域無線通信部１７１、有線通信部１７２、および近距離無線通信部１７３が接続されている。
【００５１】
広域無線通信部１７１は、基地局１２３と無線通信を行い、広域通信網を介した通信を行う無線通信デバイスである。広域無線通信部１７１は、例えば２GHzの周波数帯を使い、通話アプリケーションだけでなく、最大２Mbpsのデータ通信を用いてインターネット接続など各種通信アプリケーションに利用される。広域無線通信部１７１は、例えば、いわゆる第３世代携帯電話の通信方式による通信が可能なデバイスなどとして構成される。
【００５２】
有線通信部１７２は、例えば、イーサネット（登録商標）などのＬＡＮに対応するインタフェースとされ、最大１００Mbpsのデータ通信を行う。
【００５３】
近距離無線通信部１７３は、例えば、Bluetooth（登録商標、ＢＴとも称する）やIEEE（Institute of Electrical and Electronic Engineers）802.11x等の近距離無線通信デバイスである。ここで、近距離無線通信とは、通信可能最大距離が数メートル乃至数十メートル程度のローカルな（狭域の）無線通信を意味する。通信規格は任意である。例えば、近距離無線通信部１７３がＢＴの通信を行うものである場合は、アンテナを経由して2.4GHz帯にて最大通信速度３Ｍビット／秒（バージョン2.0＋EDR以降）の通信を行う。
【００５４】
スマートフォン１１１の各部は、ＣＰＵ１５１により制御される。制御プログラムの実行バイナリコードはＲＯＭ１５２や記憶部１６３に保存されており、各種演算処理のためスタック、ヒープ領域はＲＡＭ１５３上に展開される。
【００５５】
図６は、図５のＣＰＵ１５１で実行されるソフトウェアの機能的構成を説明する図である。
【００５６】
図６の例では、ＯＳ（オペレーティングシステム２０１）上で実行されるＴＣＰ／ＩＰ通信制御部２０２、および、ＭＰＴＣＰ制御部２０３が設けられている。そして、ＴＣＰ／ＩＰ通信制御部２０２、および、ＭＰＴＣＰ制御部２０３の上位層としてアプリケーションプログラム２０４が実行されるようになされている。
【００５７】
また、図６に示されるように、ＭＰＴＣＰ制御部２０３の一部として分配制御部２１１が設けられている。分配制御部２１１は、後述するように、各ネットワークインタフェースから送信されるデータに係る分配を制御するようになされている。
【００５８】
図７は、ＭＰＴＣＰ制御部２０３によるマルチパス通信の方式を説明する図である。
【００５９】
図７に示されるように、ＭＰＴＣＰでは、広域無線通信部１７１による広域無線通信におけるＴＣＰコネクション、有線通信部１７２による有線通信におけるＴＣＰコネクション、および、近距離無線通信部１７３による近距離無線通信におけるＴＣＰコネクションのそれぞれがＴＣＰサブフローとしてＭＰＴＣＰコアにより管理される。そして、ＭＰＴＣＰコアが３つのＴＣＰサブフローをまとめて単一のＭＰＴＣＰコネクションを確立し、それをソケットＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する。なお、ここでは、ＴＣＰサブフローの数を３としているが、２以上のいくつであってもよい。
【００６０】
図８は、分配制御部２１１によるデータの分配の方式を説明する図である。
【００６１】
図８の例では、送信バッファ２３１に送信すべきデータが蓄積されており、分配制御部２１１が、送信バッファ２３１からデータを取り出して、サブフローＳＦ１乃至サブフローＳＦＮに割り当てられたキュー２４１−１乃至キュー２４１−Ｎに分配している。
【００６２】
なお、分配制御部２１１は、トランスポート層における処理を実行する機能ブロックであるから、キュー２４１−１乃至キュー２４１−Ｎに分配されるデータは、セグメントと称される。
【００６３】
また、図中において送信バッファ２３１内の「８」、「９」・・・「１２」の番号が付された矩形のそれぞれ、および、キュー２４１−１乃至キュー２４１−Ｎ内の「１」、「２」、・・・「７」の番号が付された矩形のそれぞれがセグメントを表している。これらの１２個のセグメントのそれぞれは、同じデータサイズであるものとし、例えば、ＴＣＰの最大セグメントサイズ（Maximum Segment Size）のデータとされる。さらに、各セグメントに付された番号は、それぞれのセグメントを送信すべき順番を表しているものとする。
【００６４】
なお、図８の例では、サブフローＳＦ１は、遅延が小さいサブフローであり、サブフローＳＦ２は、サブフローＳＦ１より遅延が大きいサブフローであり、・・・サブフローＳＦＮはサブフローＳＦＮ−１より遅延が大きいサブフローであるものとする。例えば、図４のスマートフォン１１１の場合、サブフローＳＦ１乃至サブフローＳＦ３が存在することになり、サブフローＳＦ１は有線通信に対応するサブフローとされ、サブフローＳＦ２は近距離無線通信に対応するサブフローとされ、サブフローＳＦ３は広域無線通信に対応するサブフローとされる。
【００６５】
分配制御部２１１は、キュー最後尾のセグメントが受信側に到達するまでの到達予想時間Ｄを算出し、到達予想時間Ｄが最も小さいキューを特定する。分配制御部２１１は、キューに格納されていたセグメントが出力され、ネットワーク層のプロトコルへ渡るときの輻輳ウィンドウを予測し、精度の高い到達予想時間Ｄを算出する。
【００６６】
ＴＣＰの輻輳制御アルゴリズムによれば、受信側から送出されたＡＣＫを送信側で受信した場合（輻輳が発生しなかった場合）、予め設定された割合で輻輳ウィンドウサイズが拡大される。すなわち、輻輳が発生しなかった場合、ネットワークの帯域に余裕があるとみなして伝送速度を上げるようになされている。
【００６７】
一方、ＴＣＰの輻輳制御アルゴリズムによれば、輻輳が発生した場合、または、パケットロスが発生した場合、輻輳ウィンドウサイズが縮小される。すなわち、輻輳またはパケットロスが発生した場合、輻輳またはパケットロスを回避するために伝送速度を下げるようになされている。
【００６８】
分配制御部２１１は、到達予想時間Ｄを次のようにして算出する。
【００６９】
まず、キューが空の場合、分配制御部２１１は、当該キューの到達予想時間Ｄを０に設定する。
【００７０】
分配制御部２１１は、サブフロー毎に、往復遅延時間(ＲＴＴ：round-trip time)を特定する。そして片道遅延時間ｄ＝ＲＴＴ／２を算出する。なお、セグメントが送信されてからＡＣＫが受信されるまでの時間の平均値が往復遅延時間とされ、サブフロー毎に逐次更新されるようになされている。
【００７１】
そして、分配制御部２１１は、Ｄ＋ｄが最小となるキューを選択し、そのキューにセグメントを挿入する。
【００７２】
また、分配制御部２１１は、これからキューに挿入されるセグメントがキューから出力される時の輻輳ウィンドウサイズexpect_cwndを予測する。なお、輻輳ウィンドウサイズは、最初は十分に小さい初期値が設定され、その後、拡大されていく。
【００７３】
上述したように、ＴＣＰの輻輳制御アルゴリズムによれば、輻輳が発生しなかった場合、予め設定された割合で輻輳ウィンドウサイズが拡大される。すなわち、サーバ１１２とのセグメントの送受信が行われる都度、輻輳ウィンドウサイズが徐々に拡大されていくようになされている。分配制御部２１１は、輻輳が発生しないことを前提として、現在の輻輳ウィンドウサイズと、キューに蓄積されている全てのセグメントを合計したデータサイズに基づいて、これからキューに挿入されるセグメントがキューから出力される時のウィンドウサイズを予測する。
【００７４】
さらに、分配制御部２１１は、式（１）により送出予想時間Ｗを算出する。すなわち、１つのセグメントがキューから送出されるまでに要すると推測される時間が、送出予想時間Ｗとして算出される。
【００７５】
【数１】
2014127790.tif 000003
【００７６】
なお、式（１）におけるＭＳＳは、ＴＣＰの最大セグメントサイズ（Maximum Segment Size）を意味している。また、送出予想時間Ｗは、サーバ１１２がセグメントを受信した際に送信するＡＣＫを受信したときの到達予想時間Ｄの更新に用いられるため、メモリなどに記憶される。
【００７７】
そして、分配制御部２１１は、式（２）により、セグメントが挿入されたキューの新たな到達予想時間Ｄnewを求める。
【００７８】
【数２】
2014127790.tif 000004
【００７９】
その後、分配制御部２１１は、式（２）により得られた到達予想時間Ｄnewを、当該キューの到達予想時間とし、到達予想時間Ｄを更新する。また、サーバ１１２からのＡＣＫを受信した場合、分配制御部２１１は、式（３）により得られた到達予想時間Ｄnewを、当該キューの到達予想時間とし、到達予想時間Ｄを更新する。
【００８０】
【数３】
2014127790.tif 000005
【００８１】
なお、式（３）におけるＷは、当該ＡＣＫに対応するセグメントをキューに挿入する際に算出した送出予想時間Ｗとされる。
【００８２】
そして、分配制御部２１１は、Ｄ＋ｄが最小となるキューを選択し、そのキューに次のセグメントを挿入する。
【００８３】
このようにして、キュー２４１−１乃至キュー２４１−Ｎのそれぞれに対応する到達予想時間Ｄが算出／更新されていくとともに、到達予想時間Ｄに基づいてセグメントが分配されていく。
【００８４】
本技術では、サブフロー毎に伝送遅延を特定し、輻輳ウィンドウサイズを予測しながら、到達予想時間を算出／更新するようにしたので、スマートフォン１１１から送信されたセグメントが、意図した順番にサーバ１１２に到着するように制御することが可能となる。例えば、図８に示される「１」乃至「１２」の各セグメントが、サブフローＳＦ１乃至サブフローＳＦＮを介して送信され、「１」乃至「１２」の番号順にサーバ１１２に受信されるようになる。
【００８５】
このように、本技術では、伝送遅延の異なるネットワークを利用したマルチパス通信において、受信側でのリオーダ待ちを回避して、アプリケーションプログラムの処理に要する時間を短縮させることができる。その結果、より効率的にネットワークの帯域幅を活用することができる。
【００８６】
しかしながら、サブフローＳＦ１乃至サブフローＳＦＮにおいて、輻輳、または、パケットロスが発生する場合がある。このような場合、スマートフォン１１１から送信された各セグメントが、「１」乃至「１２」の番号順にサーバ１１２に受信されなくなる可能性が高い。
【００８７】
そこで、分配制御部２１１は、サブフローＳＦ１乃至サブフローＳＦＮにおいて、輻輳、または、パケットロスが発生した場合、次のようにして、セグメントの再分配を行う。
【００８８】
最初に、分配制御部２１１は、輻輳、または、パケットロスが発生したサブフローを特定する。
【００８９】
次に、分配制御部２１１は、特定されたサブフローの輻輳ウィンドウサイズを取得する。上述したように、輻輳制御アルゴリズムによれば、輻輳が発生した場合、または、パケットロスが発生した場合、輻輳ウィンドウサイズが縮小される。分配制御部２１１は、輻輳、または、パケットロスが発生したサブフローの縮小後の輻輳ウィンドウサイズcwndを取得する。
【００９０】
そして、分配制御部２１１は、輻輳ウィンドウサイズexpect_cwnd＝輻輳ウィンドウサイズcwndとし、輻輳、または、パケットロスが発生したサブフローに対応するキューに蓄積されているセグメントついて、式（１）および式（２）の計算を再度行う。つまり、当該キューのセグメントのそれぞれに対応する到達予想時間Ｄを再計算する。
【００９１】
さらに、分配制御部２１１は、輻輳、または、パケットロスが発生したサブフロー以外の全てのサブフローに対応するキューの到達予想時間Ｄをそれぞれ取得し、それらの中の最大値を特定するとともに、上述のように再計算されたＤと比較する。そして、再計算されたＤが最大値を超えたセグメント以降のセグメントを、退避バッファに退避させる。
【００９２】
図９を参照して、さらに詳細に説明する。例えば、サブフローＳＦ１で、輻輳、または、パケットロスの発生が検出されたものとする。
【００９３】
分配制御部２１１は、サブフローＳＦ１以外のサブフローであるサブフローＳＦ２乃至サブフローＳＦＮのそれぞれに対応するキュー２４１−２乃至キュー２４１−Ｎのそれぞれの到達予想時間Ｄを取得する。この場合、キュー２４１−２乃至キュー２４１−Ｎのそれぞれ最後のセグメントについて計算された到達予想時間Ｄ２乃至到達予想時間ＤＮが取得される。
【００９４】
そして、分配制御部２１１は、到達予想時間Ｄ２乃至到達予想時間ＤＮの中の最大値を特定する。いまの場合、キュー２４１−Ｋの到達予想時間である到達予想時間ＤＫが最大値として特定されたものとする。
【００９５】
分配制御部２１１は、サブフローＳＦ１の縮小後の輻輳ウィンドウサイズcwndを取得する。輻輳ウィンドウサイズcwndが輻輳ウィンドウサイズexpect_cwndの初期値となる。分配制御部２１１は、キュー２４１−１内に蓄積されているセグメントに対応する到達予想時間Ｄ１を再計算する。
【００９６】
図９のキュー２４１−１内には、４つのセグメントが蓄積されている。分配制御部２１１は、最も先に送出されるセグメント（図中最も下の矩形に対応するセグメント）の到達予想時間を再計算する。すなわち、キュー２４１−１が空であるものと仮定して、１つのセグメントがキュー２４１−１に挿入された場合の到達予想時間Ｄ１が算出される。
【００９７】
そして、分配制御部２１１は、到達予想時間Ｄ１と、到達予想時間ＤＫを比較する。いまの場合、到達予想時間ＤＫの方が到達予想時間Ｄ１より大きかった（ＤＫ  ＞  Ｄ１）ものとする。
【００９８】
この場合、分配制御部２１１は、キュー２４１−１の中で２番目に送出されるセグメント（図中下から２番目の矩形に対応するセグメント）の到達予想時間を再計算する。すなわち、キュー２４１−１にセグメントが１つ蓄積されているものと仮定して、１つのセグメントがキュー２４１−１に挿入された場合の到達予想時間Ｄ１があらためて算出される。
【００９９】
このように、分配制御部２１１は、キュー２４１−１が1度空になったものと仮定し、輻輳ウィンドウサイズの初期値がcwndであるものとし、キュー２４１−１に蓄積されていたセグメントを、送信順に１つずつ仮想的にキュー２４１−１に挿入しながら、到達予想時間Ｄ１を算出して更新していく。
【０１００】
そして、分配制御部２１１は、到達予想時間Ｄ１と、到達予想時間ＤＫを比較する。いまの場合、到達予想時間Ｄ１の方が到達予想時間ＤＫより大きかった（Ｄ１  ＞  ＤＫ）ものとする。
【０１０１】
この場合、分配制御部２１１は、キュー２４１−１の中で２番目に送出されるセグメントより後のセグメント（図中下から３番目と４番目の矩形に対応するセグメント）を退避バッファ２３２に退避させる。これにより、キュー２４１−１には、２つのセグメントのみが蓄積された状態となる。
【０１０２】
分配制御部２１１は、退避バッファ２３２に蓄積されているセグメントを、キュー２４１−１乃至キュー２４１−Ｎに再度分配する。このとき、退避バッファ２３２内の最も下のセグメントから順に、Ｄ＋ｄが最小となるキューが選択されて挿入されていく。そして、セグメントが挿入されたキューの到達予想時間が更新されていく。
【０１０３】
このようにすることで、サブフローＳＦ１乃至サブフローＳＦＮにおいて、輻輳、または、パケットロスが発生した場合であっても、スマートフォン１１１から送信されたセグメントが、サーバ１１２にできるだけ順番に到着するようになる。
【０１０４】
従って、本技術によれば、伝送遅延の異なるネットワークを利用したマルチパス通信において、受信側でのリオーダ待ちを回避して、アプリケーションプログラムの処理に要する時間を短縮させることができる。さらに、輻輳、または、パケットロスが発生した場合であっても、受信側でのリオーダ待ちをできるだけ回避することが可能となる。その結果、常に効率的にネットワークの帯域幅を活用することができる。
【０１０５】
次に、図１０のフローチャートを参照して、分配制御部２１１によるセグメント分配処理の例について説明する。この処理は、例えば、スマートフォン１１１がマルチパス通信を行っているとき実行される。
【０１０６】
ステップＳ２１において、分配制御部２１１は、退避バッファ２３２が空であるか否かを判定する。
【０１０７】
ステップＳ２１において、退避バッファ２３２が空であると判定された場合、処理は、ステップＳ２３に進み、分配制御部２１１は、送信バッファ２３１からセグメントを取り出す。
【０１０８】
一方、ステップＳ２１において、退避バッファ２３２が空ではないと判定された場合、処理は、ステップＳ２２に進み、分配制御部２１１は、退避バッファ２３２からセグメントを取り出す。
【０１０９】
ステップＳ２４において、分配制御部２１１は、キュー毎の到達予想時間を取得する。このとき、例えば、キュー２４１−１乃至キュー２４１−Ｎのそれぞれの到達予想時間Ｄが取得される。
【０１１０】
ステップＳ２５において、分配制御部２１１は、ステップＳ２４の処理で取得した到達予想時間Ｄが最小のキューを選択する。
【０１１１】
ステップＳ２６において、分配制御部２１１は、ステップＳ２２またはステップＳ２３の処理で取り出したセグメントを、ステップＳ２５の処理で選択したキューに挿入する。
【０１１２】
ステップＳ２７において、分配制御部２１１は、ステップＳ２６の処理でキューに挿入されたセグメントがキューから出力される時の輻輳ウィンドウサイズexpect_cwndを予測する。
【０１１３】
ステップＳ２８において、分配制御部２１１は、ステップＳ２７の処理で予測した輻輳ウィンドウサイズexpect_cwndを用いて送出予想時間Ｗを計算する。このとき、上述した式（１）により送出予想時間Ｗが算出される。
【０１１４】
ステップＳ２９において、分配制御部２１１は、当該キューに対応する到達予想時間Ｄを更新する。すなわち、ステップＳ２８の処理で計算されたＷを用いて式（２）の演算が行われ、到達予想時間Ｄが更新される。
【０１１５】
ステップＳ３０において、分配制御部２１１は、いずれかのサブフローにおいて輻輳、または、パケットロスが発生したか否かを判定する。
【０１１６】
ステップＳ３０において、輻輳、または、パケットロスが発生していないと判定された場合、処理は、ステップＳ２１に戻り、それ以降の処理が繰り返し実行される。
【０１１７】
一方、ステップＳ３０において、輻輳、または、パケットロスが発生していないと判定された場合、処理は、ステップＳ３０に進み、図１１を参照して後述するセグメント退避処理が実行される。
【０１１８】
次に、図１１のフローチャートを参照して、図１０のステップＳ３０のセグメント退避処理の詳細な例について説明する。
【０１１９】
ステップＳ５１において、分配制御部２１１は、輻輳、または、パケットロスが発生したサブフロー以外のサブフローに対応するキューの到達予想時間Ｄを取得する。
【０１２０】
例えば、サブフローＳＦ１で輻輳、または、パケットロスが発生した場合、サブフローＳＦ１以外のサブフローであるサブフローＳＦ２乃至サブフローＳＦＮのそれぞれに対応するキュー２４１−２乃至キュー２４１−Ｎのそれぞれの到達予想時間Ｄ２乃至到達予想時間ＤＮが取得される。そして、分配制御部２１１は、到達予想時間Ｄ２乃至到達予想時間ＤＮの中の最大値を特定する。いまの場合、キュー２４１−Ｋの到達予想時間である到達予想時間ＤＫが最大値として特定されたものとする。
【０１２１】
ステップＳ５２において、分配制御部２１１は、サブフローＳＦ１の縮小後の輻輳ウィンドウサイズcwndを取得する。
【０１２２】
ステップＳ５３において、分配制御部２１１は、サブフローＳＦ１の最初のセグメントの到達予想時間を再計算する。すなわち、キュー２４１−１が空であるものと仮定して、１つのセグメントがキュー２４１−１に挿入された場合の到達予想時間Ｄ１が算出される。
【０１２３】
ステップＳ５４において、分配制御部２１１は、ステップＳ５３の処理により得られた到達予想時間Ｄ１と、ステップＳ５１の処理により得られた到達予想時間ＤＫを比較し、到達予想時間Ｄ１が、到達予想時間ＤＫを超えたか否かを判定する。
【０１２４】
ステップＳ５４において、到達予想時間Ｄ１が、到達予想時間ＤＫを超えていないと判定された場合、処理は、ステップＳ５５に進む。
【０１２５】
ステップＳ５５において、分配制御部２１１は、キュー２４１−１に挿入されたセグメントがキュー２４１−１から出力される時の輻輳ウィンドウサイズexpect_cwndを予測する。
【０１２６】
ステップＳ５６において、分配制御部２１１は、ステップＳ５５の処理で予測した輻輳ウィンドウサイズexpect_cwndを用いて送出予想時間Ｗを計算する。このとき、上述した式（１）により送出予想時間Ｗが算出される。
【０１２７】
ステップＳ５７において、分配制御部２１１は、ステップＳ５６の処理で計算されたＷを用いて式（２）の演算を行い、次のセグメントが挿入されたときの到達予想時間を再度算出する。すなわち、キュー２４１−１にセグメントが１つ蓄積されているものと仮定して、１つのセグメントがキュー２４１−１に挿入された場合の到達予想時間Ｄ１があらためて算出される。
【０１２８】
ステップＳ５４に戻り、分配制御部２１１は、ステップＳ５７の処理により得られた到達予想時間Ｄ１と、ステップＳ５１の処理により得られた到達予想時間ＤＫを比較し、到達予想時間Ｄ１が、到達予想時間ＤＫを超えたか否かを判定する。
【０１２９】
ここで、到達予想時間Ｄ１が、到達予想時間ＤＫを超えていないと判定された場合、処理は、ステップＳ５５に進み、その後、ステップＳ５４乃至ステップＳ５７の処理が繰り返し実行される。
【０１３０】
一方、ステップ５４において、到達予想時間Ｄ１が、到達予想時間ＤＫを超えていると判定された場合、ステップＳ５５乃至ステップＳ５７の処理はスキップされる。
【０１３１】
ステップＳ５８において、分配制御部２１１は、以降のセグメントを退避バッファ２３２に退避させる。
【０１３２】
このようにして、セグメント退避処理が実行される。
【０１３３】
図１２と図１３は、従来のマルチパス通信における受信側のリオーダ待ちデータの長さと、アプリケーションで処理可能なデータの送達レートの関係を示す図である。
【０１３４】
図１２と図１３は、横軸が時間、縦軸がリオーダ待ちデータの長さ（Queue Length）、および、アプリケーションで処理可能なデータの送達レート（Goodput）とされ、線３０１により、時間の経過に伴うQueue Lengthの変化が示されており、線３０２により、時間の経過に伴うGoodputの変化が示されている。
【０１３５】
図１２と図１３は、図１４に示されるようなネットワークシステムにおける測定結果を表すものである。図１４の例では、送信側（Sender）のパーソナルコンピュータ３２１から受信側（Receiver）のパーソナルコンピュータ３２２にデータが送信される。
【０１３６】
パーソナルコンピュータ３２１は、例えば、イーサネットＬＡＮのような有線通信のネットワークインタフェースを２つ有している。すなわち、パーソナルコンピュータ３２１は、経路３２５−１および経路３２５−２の２つの経路でルータ３２４と接続されている。経路３２５−１には、遅延発生装置３２３−１が接続されており、経路３２５−２は、遅延発生装置３２３−２が接続されている。
【０１３７】
なお、経路３２５−１の帯域幅は５Ｍｂｐｓとされ、経路３２５−２の帯域幅も５Ｍｂｐｓとされている。遅延発生装置３２３−１および遅延発生装置３２３−２は、それぞれ経路３２５−１および経路３２５−２上で任意の遅延時間を発生させることができる。
【０１３８】
パーソナルコンピュータ３２２は、高速ＬＡＮなどの有線通信のネットワークインタフェースを有しており、ルータ３２４と接続されている。
【０１３９】
図１２は、経路３２５−１上の遅延時間を１０ｍｓとし、経路３２５−２上の遅延時間も１０ｍｓとした場合のマルチパス通信における受信側のリオーダ待ちデータの長さと、アプリケーションで処理可能なデータの送達レートの関係を示している。なお、マルチパス通信における各径路へのデータの分配の方式は従来の方式を用いている。すなわち、ここでのマルチパス通信には、本技術のように、キューから出力されるまでの時間と伝送遅延を考慮して各経路にデータを分配するような方式が採用されていない。
【０１４０】
つまり、図１２は、従来のマルチパス通信であって、遅延差の小さい（無い）複数のネットワークを用いたマルチパス通信における受信側のリオーダ待ちデータの長さと、アプリケーションで処理可能なデータの送達レートの関係を示している。
【０１４１】
図１２に示されるように、約７ｍｓ経過後は、Queue Lengthがほぼ一定となり、Goodputは、１０Ｍｂｐｓよりやや低い値でほぼ一定となっている。なお、経路３２５−１と経路３２５−２の帯域幅の合計が１０Ｍｂｐｓなので、図１２に示されるGoodputは、高い値で安定していると考えられる。
【０１４２】
図１３は、経路３２５−１上の遅延時間を１００ｍｓとし、経路３２５−２上の遅延時間も１０ｍｓとした場合のマルチパス通信における受信側のリオーダ待ちデータの長さと、アプリケーションで処理可能なデータの送達レートの関係を示している。なお、マルチパス通信における各径路へのデータの分配の方式は従来の方式を用いている。すなわち、ここでのマルチパス通信には、本技術のように、キューから出力されるまでの時間と伝送遅延を考慮して各経路にデータを分配するような方式が採用されていない。
【０１４３】
つまり、図１３は、従来のマルチパス通信であって、遅延差の大きい複数のネットワークを用いたマルチパス通信における受信側のリオーダ待ちデータの長さと、アプリケーションで処理可能なデータの送達レートの関係を示している。
【０１４４】
図１３に示されるように、Queue Lengthは大きく変化しており、goodputは、通信開始直後が著しく低く、また、その後もQueue Lengthの増加に伴って、goodputの谷が形成されている。
【０１４５】
例えば、図１４のパーソナルコンピュータ３２１に本技術を適用すれば、経路３２５−１上の遅延時間を１００ｍｓとし、経路３２５−２上の遅延時間も１０ｍｓとした場合であっても、図１２とほぼ同様の結果を得ることができる。つまり、本技術によれば、遅延差の大きい複数のネットワークを用いたマルチパス通信において、Queue Lengthがほぼ一定となり、Goodputも高い値で安定させることが可能となる。
【０１４６】
なお、キューから出力されるまでの時間と伝送遅延を考慮して各経路にデータを分配するアルゴリズムも存在する。例えば、ＳＨＡＫＥ(SHAring multipath procedure for a cluster networK Environment)では、ＭＮがセグメントを送信する際には、パケットが順序通りに到達するよう、最も早くＨＡへ到着すると推測される経路を用いてセグメントを送信する。リンクには仮想的な送信キューを設け、キューから出力されるまでの待ち時間と伝送遅延からパケット到達時刻を予想し各経路へ振り分けるようになされている。
【０１４７】
しかしながら、ＳＨＡＫＥは、ネットワーク層でのマルチホーミングを行うためのプロトコルとされる。従って、ネットワーク層の制御情報などを用いてパケット到達時刻が予想される。しかしながら、ネットワーク層のプロトコル（例えば、ＩＰ）には、輻輳ウィンドウに関する制御情報が規定されておらず、本技術のように、これからキューに挿入されるセグメントがキューから出力される時の輻輳ウィンドウサイズexpect_cwndを予測することができない。
【０１４８】
また、ＴＣＰのアルゴリズムでは、輻輳が発生しない限り、輻輳ウィンドウサイズが徐々に拡大されるようになされている。従って、送信側からのデータの送出レートが経路３２５−１または経路３２５−２の帯域幅を超えるまで輻輳ウィンドウサイズが拡大され続けることもある。送信側からのデータの送出レートが経路３２５−１または経路３２５−２の帯域幅を超えた場合、その時点で必ず輻輳が発生することになり、輻輳ウィンドウサイズが縮小されることになる。パケットロスが発生した場合も、やはり輻輳ウィンドウサイズが縮小されることになる。
【０１４９】
このように、実際の通信では輻輳の発生に伴ってウィンドウサイズが適宜変更されるが、ネットワーク層での制御情報を用いたマルチホーミングの方式では、実際の輻輳ウィンドウサイズの変化を認識することができない。このため、輻輳やパケットロスが発生した場合、送信側で意図した順番で受信側にデータが到着しなくなる。すなわち、ネットワーク層での制御情報を用いたマルチホーミングの方式では、遅延差の大きい複数のネットワークを用いたマルチパス通信において、Goodputを高い値で安定させることができないと考えられる。
【０１５０】
これに対して、本技術によれば、遅延差の大きい複数のネットワークを用いたマルチパス通信において、輻輳やパケットロスが発生しても、Goodputを高い値で安定させることができる。
【０１５１】
なお、上述した実施の形態では、輻輳、または、パケットロスが発生したサブフローのみについて、セグメントの再分配を行っているが、輻輳、または、パケットロスが発生していない１以上のサブフローについて、未処理のセグメントの再分配を行うようにしてもよい。
【０１５２】
以上においては、本技術をスマートフォン、パーソナルコンピュータなどに適用する例について説明したが、その他の電子機器にも本技術を適用することが可能である。
【０１５３】
なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば図１５に示されるような汎用のパーソナルコンピュータ７００などに、ネットワークや記録媒体からインストールされる。
【０１５４】
図１５において、ＣＰＵ（Central Processing Unit）７０１は、ＲＯＭ（Read Only Memory）７０２に記憶されているプログラム、または記憶部７０８からＲＡＭ（Random Access Memory）７０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ７０３にはまた、ＣＰＵ７０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０１５５】
ＣＰＵ７０１、ＲＯＭ７０２、およびＲＡＭ７０３は、バス７０４を介して相互に接続されている。このバス７０４にはまた、入出力インタフェース７０５も接続されている。
【０１５６】
入出力インタフェース７０５には、キーボード、マウスなどよりなる入力部７０６、ＬＣＤ(Liquid Crystal display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部７０７、ハードディスクなどより構成される記憶部７０８、モデム、ＬＡＮカードなどのネットワークインタフェースカードなどより構成される通信部７０９が接続されている。通信部７０９は、インターネットを含むネットワークを介しての通信処理を行う。
【０１５７】
入出力インタフェース７０５にはまた、必要に応じてドライブ７１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア７１１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部７０８にインストールされる。
【０１５８】
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディア７１１などからなる記録媒体からインストールされる。
【０１５９】
なお、この記録媒体は、図１５に示される、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フロッピディスク（登録商標）を含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（MD（Mini-Disk）（登録商標）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア７１１により構成されるものだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているＲＯＭ７０２や、記憶部７０８に含まれるハードディスクなどで構成されるものも含む。
【０１６０】
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１６１】
また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０１６２】
１００  ネットワークシステム，  １１１  スマートフォン，  １１２  サーバ，  １２１  アクセスポイント，  １２２  ルータ，  １２３  基地局，  １３１  インターネット，  １５１  ＣＰＵ，  １７１  広域無線通信部，  １７２  有線通信部，  １７３  近距離無線通信部，  ２０１  ＯＳ，  ２０２  ＴＣＰ／ＩＰ通信制御部，  ２０３  ＭＰＴＣＰ制御部，  ２０４  アプリケーションプログラム，  ２１１  分配制御部，  ２３１  送信バッファ，  ２３２  退避バッファ，  ２４１−１乃至２４１−Ｎ  キュー
【図１】
2014127790.tif 000006
【図２】
2014127790.tif 000007
【図３】
2014127790.tif 000008
【図４】
2014127790.tif 000009
【図５】
2014127790.tif 000010
【図６】
2014127790.tif 000011
【図７】
2014127790.tif 000012
【図８】
2014127790.tif 000013
【図９】
2014127790.tif 000014
【図１０】
2014127790.tif 000015
【図１１】
2014127790.tif 000016
【図１２】
2014127790.tif 000017
【図１３】
2014127790.tif 000018
【図１４】
2014127790.tif 000019
【図１５】
2014127790.tif 000020