JP2014127790A - 情報処理装置および方法、並びにプログラム - Google Patents

情報処理装置および方法、並びにプログラム Download PDF

Info

Publication number
JP2014127790A
JP2014127790A JP2012282146A JP2012282146A JP2014127790A JP 2014127790 A JP2014127790 A JP 2014127790A JP 2012282146 A JP2012282146 A JP 2012282146A JP 2012282146 A JP2012282146 A JP 2012282146A JP 2014127790 A JP2014127790 A JP 2014127790A
Authority
JP
Japan
Prior art keywords
queue
congestion
segment
subflow
arrival time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2012282146A
Other languages
English (en)
Inventor
Nagatoshi Oikawa
永寿 及川
Taiichi Nakayama
泰一 中山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
University of Electro Communications NUC
Original Assignee
University of Electro Communications NUC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by University of Electro Communications NUC filed Critical University of Electro Communications NUC
Priority to JP2012282146A priority Critical patent/JP2014127790A/ja
Publication of JP2014127790A publication Critical patent/JP2014127790A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】伝送遅延の差が大きい複数の経路を利用したマルチパス通信において、より効率的に帯域幅を活用することができるようにする。
【解決手段】ＯＳ（オペレーティングシステム２０１）上で実行されるＴＣＰ／ＩＰ通信制御部２０２、および、ＭＰＴＣＰ制御部２０３が設けられている。ＴＣＰ／ＩＰ通信制御部２０２、および、ＭＰＴＣＰ制御部２０３の上位層としてアプリケーションプログラム２０４が実行される。ＭＰＴＣＰ制御部２０３の一部として分配制御部２１１が設けられ、各ネットワークインタフェースから送信されるデータに係る分配を制御するようになされている。分配制御部２１１は、サブフロー毎に伝送遅延を特定し、輻輳ウィンドウサイズを予測しながら、到達予想時間を算出／更新し、到達予想時間が最小となるサブフローにセグメントを送出する。
【選択図】図６

Description

本技術は、情報処理装置および方法、並びにプログラムに関し、特に、伝送遅延の差が大きい複数の経路を利用したマルチパス通信において、より効率的に帯域幅を活用することができるようにする情報処理装置および方法、並びにプログラムに関する。
近年、無線通信インフラの多様化により、スマートフォン等のモバイル機器には複数のネットワークインタフェースが搭載されることが多い。例えば、モバイル機器において、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を予測する。なお、輻輳ウィンドウサイズは、最初は十分に小さい初期値が設定され、その後、拡大されていく。
上述したように、ＴＣＰの輻輳制御アルゴリズムによれば、輻輳が発生しなかった場合、予め設定された割合で輻輳ウィンドウサイズが拡大される。すなわち、サーバ１１２とのセグメントの送受信が行われる都度、輻輳ウィンドウサイズが徐々に拡大されていくようになされている。分配制御部２１１は、輻輳が発生しないことを前提として、現在の輻輳ウィンドウサイズと、キューに蓄積されている全てのセグメントを合計したデータサイズに基づいて、これからキューに挿入されるセグメントがキューから出力される時のウィンドウサイズを予測する。
さらに、分配制御部２１１は、式（１）により送出予想時間Ｗを算出する。すなわち、１つのセグメントがキューから送出されるまでに要すると推測される時間が、送出予想時間Ｗとして算出される。
Figure 2014127790
なお、式（１）におけるＭＳＳは、ＴＣＰの最大セグメントサイズ（Maximum Segment Size）を意味している。また、送出予想時間Ｗは、サーバ１１２がセグメントを受信した際に送信するＡＣＫを受信したときの到達予想時間Ｄの更新に用いられるため、メモリなどに記憶される。
そして、分配制御部２１１は、式（２）により、セグメントが挿入されたキューの新たな到達予想時間Ｄnewを求める。
Figure 2014127790
その後、分配制御部２１１は、式（２）により得られた到達予想時間Ｄnewを、当該キューの到達予想時間とし、到達予想時間Ｄを更新する。また、サーバ１１２からのＡＣＫを受信した場合、分配制御部２１１は、式（３）により得られた到達予想時間Ｄnewを、当該キューの到達予想時間とし、到達予想時間Ｄを更新する。
Figure 2014127790
なお、式（３）におけるＷは、当該ＡＣＫに対応するセグメントをキューに挿入する際に算出した送出予想時間Ｗとされる。
そして、分配制御部２１１は、Ｄ＋ｄが最小となるキューを選択し、そのキューに次のセグメントを挿入する。
このようにして、キュー２４１−１乃至キュー２４１−Ｎのそれぞれに対応する到達予想時間Ｄが算出／更新されていくとともに、到達予想時間Ｄに基づいてセグメントが分配されていく。
本技術では、サブフロー毎に伝送遅延を特定し、輻輳ウィンドウサイズを予測しながら、到達予想時間を算出／更新するようにしたので、スマートフォン１１１から送信されたセグメントが、意図した順番にサーバ１１２に到着するように制御することが可能となる。例えば、図８に示される「１」乃至「１２」の各セグメントが、サブフローＳＦ１乃至サブフローＳＦＮを介して送信され、「１」乃至「１２」の番号順にサーバ１１２に受信されるようになる。
このように、本技術では、伝送遅延の異なるネットワークを利用したマルチパス通信において、受信側でのリオーダ待ちを回避して、アプリケーションプログラムの処理に要する時間を短縮させることができる。その結果、より効率的にネットワークの帯域幅を活用することができる。
しかしながら、サブフローＳＦ１乃至サブフローＳＦＮにおいて、輻輳、または、パケットロスが発生する場合がある。このような場合、スマートフォン１１１から送信された各セグメントが、「１」乃至「１２」の番号順にサーバ１１２に受信されなくなる可能性が高い。
そこで、分配制御部２１１は、サブフローＳＦ１乃至サブフローＳＦＮにおいて、輻輳、または、パケットロスが発生した場合、次のようにして、セグメントの再分配を行う。
最初に、分配制御部２１１は、輻輳、または、パケットロスが発生したサブフローを特定する。
次に、分配制御部２１１は、特定されたサブフローの輻輳ウィンドウサイズを取得する。上述したように、輻輳制御アルゴリズムによれば、輻輳が発生した場合、または、パケットロスが発生した場合、輻輳ウィンドウサイズが縮小される。分配制御部２１１は、輻輳、または、パケットロスが発生したサブフローの縮小後の輻輳ウィンドウサイズ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）（登録商標）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア７１１により構成されるものだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているＲＯＭ７０２や、記憶部７０８に含まれるハードディスクなどで構成されるものも含む。
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
１００ ネットワークシステム， １１１ スマートフォン， １１２ サーバ， １２１ アクセスポイント， １２２ ルータ， １２３ 基地局， １３１ インターネット， １５１ ＣＰＵ， １７１ 広域無線通信部， １７２ 有線通信部， １７３ 近距離無線通信部， ２０１ ＯＳ， ２０２ ＴＣＰ／ＩＰ通信制御部， ２０３ ＭＰＴＣＰ制御部， ２０４ アプリケーションプログラム， ２１１ 分配制御部， ２３１ 送信バッファ， ２３２ 退避バッファ， ２４１−１乃至２４１−Ｎ キュー

Claims (6)

  1. 複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置であって、
    前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択するキュー選択部と、
    前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測するウィンドウサイズ予測部と、
    前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出する送出予想時間算出部と、
    前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新する更新部と、
    前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配する輻輳時キュー制御部と
    を備える情報処理装置。
  2. 前記輻輳時キュー制御部は、
    前記輻輳またはパケットロスの発生に伴って縮小された輻輳ウィンドウサイズを初期値として取得し、
    前記輻輳またはパケットロスの発生したサブフローのキューに、前記キューに蓄積されていたセグメントを１つずつ仮想的に挿入し、前記キューに対応づけられた到達予想時間を、前記セグメント毎に再計算し、
    前記再計算により、前記輻輳またはパケットロスの発生したサブフロー以外のサブフローに対応するキューのそれぞれに対応づけられた到達予想時間のうち、最大の到達予想時間を超える到達予想時間が得られた場合、そのセグメントより送信順が後のセグメントを、前記輻輳またはパケットロスの発生したサブフロー以外のサブフローに対応するキューに分配する
    請求項１に記載の情報処理装置。
  3. 前記複数のサブフローは、それぞれ伝送遅延が異なるネットワーク上でのデータの送受信により生成されたＴＣＰコネクションに対応する
    請求項１に記載の情報処理装置。
  4. 前記複数のＴＣＰコネクションのうちの少なくともいずれか１つは、広域無線通信によるネットワークを利用する
    請求項１に記載の情報処理装置。
  5. 複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置の情報処理方法であって、
    キュー選択部が、前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択し、
    ウィンドウサイズ予測部が、前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測し、
    送出予想時間算出部が、前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出し、
    更新部が、前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新し、
    輻輳時キュー制御部が、前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配するステップ
    を含む情報処理方法。
  6. コンピュータを、
    複数のＴＣＰコネクションをまとめた単一のコネクションを確立し、ＡＰＩ（Application Program Interface）により、アプリケーションプログラムに提供する情報処理装置であって、
    前記複数のＴＣＰコネクションのそれぞれに対応するサブフローを介して送信されるセグメントを蓄積するキューに対応づけられた到達予想時間に基づいて、送信バッファから取り出したセグメントを挿入するキューを選択するキュー選択部と、
    前記キューから前記セグメントが送出されるときの輻輳ウィンドウサイズを予測するウィンドウサイズ予測部と、
    前記サブフローの遅延時間、および、前記輻輳ウィンドウサイズに基づいて、前記キューに挿入されたセグメントが前記キューから送出されるまでに要すると推測される送出予想時間を算出する送出予想時間算出部と、
    前記送出予想時間に基づいて、前記キューに対応づけられた到達予想時間を更新する更新部と、
    前記サブフローのいずれかにおいて輻輳またはパケットロスが発生した場合、少なくとも前記輻輳またはパケットロスの発生したサブフローに対応するキューに対応付けられた到達予想時間を再計算するとともに、前記輻輳またはパケットロスの発生したサブフローに対応するキューに蓄積されたセグメントの少なくとも一部を、他のサブフローに対応するキューに分配する輻輳時キュー制御部とを備える情報処理装置として機能させる
    プログラム。
JP2012282146A 2012-12-26 2012-12-26 情報処理装置および方法、並びにプログラム Pending JP2014127790A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012282146A JP2014127790A (ja) 2012-12-26 2012-12-26 情報処理装置および方法、並びにプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012282146A JP2014127790A (ja) 2012-12-26 2012-12-26 情報処理装置および方法、並びにプログラム

Publications (1)

Publication Number Publication Date
JP2014127790A true JP2014127790A (ja) 2014-07-07

Family

ID=51406997

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012282146A Pending JP2014127790A (ja) 2012-12-26 2012-12-26 情報処理装置および方法、並びにプログラム

Country Status (1)

Country Link
JP (1) JP2014127790A (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105873096A (zh) * 2016-03-24 2016-08-17 重庆邮电大学 一种多路径并行传输系统有效吞吐量的优化方法
CN107733811A (zh) * 2017-09-18 2018-02-23 中国电子科技集团公司第五十四研究所 一种动态调整编码强度的方法
JP2018506199A (ja) * 2014-12-10 2018-03-01 ノキア ソリューションズ アンド ネットワークス オサケユキチュア 通信における体感品質（ＱｏＥ）の強化
WO2018047645A1 (ja) * 2016-09-07 2018-03-15 パナソニックＩｐマネジメント株式会社 通信装置及び通信方法
US10555215B2 (en) 2016-08-03 2020-02-04 Fujitsu Limited Management apparatus, communication system, and allocation method
CN113271256A (zh) * 2021-04-06 2021-08-17 北京邮电大学 一种信息年龄多路径传输方法及系统
US11637764B2 (en) 2020-09-02 2023-04-25 Fujitsu Limited Abnormality detection method and a non-transitory computer-readable storage medium for storing abnormality detection program

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018506199A (ja) * 2014-12-10 2018-03-01 ノキア ソリューションズ アンド ネットワークス オサケユキチュア 通信における体感品質（ＱｏＥ）の強化
CN105873096A (zh) * 2016-03-24 2016-08-17 重庆邮电大学 一种多路径并行传输系统有效吞吐量的优化方法
CN105873096B (zh) * 2016-03-24 2019-05-10 重庆邮电大学 一种多路径并行传输系统有效吞吐量的优化方法
US10555215B2 (en) 2016-08-03 2020-02-04 Fujitsu Limited Management apparatus, communication system, and allocation method
WO2018047645A1 (ja) * 2016-09-07 2018-03-15 パナソニックＩｐマネジメント株式会社 通信装置及び通信方法
CN107733811A (zh) * 2017-09-18 2018-02-23 中国电子科技集团公司第五十四研究所 一种动态调整编码强度的方法
CN107733811B (zh) * 2017-09-18 2020-02-21 中国电子科技集团公司第五十四研究所 一种动态调整编码强度的方法
US11637764B2 (en) 2020-09-02 2023-04-25 Fujitsu Limited Abnormality detection method and a non-transitory computer-readable storage medium for storing abnormality detection program
CN113271256A (zh) * 2021-04-06 2021-08-17 北京邮电大学 一种信息年龄多路径传输方法及系统
CN113271256B (zh) * 2021-04-06 2022-08-30 北京邮电大学 一种信息年龄多路径传输方法及系统

Similar Documents

Publication Publication Date Title
JP2014127790A (ja) 情報処理装置および方法、並びにプログラム
US10958469B2 (en) Methods and systems for increasing wireless communication throughput of a bonded VPN tunnel
CN106576073B (zh) 用于通过聚合连接传输数据的方法及系统
CN107027152B (zh) 用于虚拟软交换的方法和装置
US20160218979A1 (en) Apparatus and method for transmitting packets through multi-homing based network
KR20150089853A (ko) 이종 무선망에서 트래픽 분산 제어방법 및 장치
WO2013000432A1 (en) Method and system for improved tcp performance over mobile data networks
US10601962B2 (en) Transmitting data over a plurality of different networks
US9019827B1 (en) Throughput optimization for bonded variable bandwidth connections
US9462530B2 (en) Wireless base station, wireless terminal, and packet transmission method
WO2012127275A1 (en) Buffer sizing for multi-hop network
KR101941362B1 (ko) Mptcp 성능 향상을 위한 전송 지연 측정 방법 및 시스템
Park et al. Impact of traffic splitting on the delay performance of MPTCP
Ahmad et al. Delay optimization using Knapsack algorithm for multimedia traffic over MANETs
US20140119182A1 (en) Wirespeed TCP Packet Window Field Modification For Networks Having Radio Segments
Lakkakorpi et al. Minimizing delays in mobile networks: With dynamic gateway placement and active queue management
Petrov et al. Design of novel 5G transport protocol
Latif et al. An investigation of scheduling and packet reordering algorithms for bandwidth aggregation in heterogeneous wireless networks
JP2008245011A (ja) 無線装置およびそれを備えた無線ネットワーク
JP5720007B2 (ja) 移動端末装置、それと通信を行う通信装置およびそれらを備えた通信ネットワーク
WANG et al. Research and Prospect of TCP Optimization in 5G Multi-Access Networks
Ha et al. A hybrid multipath congestion control algorithm for high speed and/or long delay networks
TWI757887B (zh) 用以促進一資料流從一發送端透過多路徑傳輸至一接收端的方法、網路控制器以及電腦程式產品
Ying et al. Research and Prospect of TCP Optimization in 5G Multi-Access Networks
US20240056885A1 (en) Multi-access traffic management

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151225