JP5194112B2 - 多重インターフェースの同時使用のためのインテリジェントコネクティビティフレームワーク - Google Patents

Description

本発明は一般的に無線装置、特に、多重インターフェース(multiple interfaces)を採用している無線装置に関し、好適実施形態は多重インターフェースの同時使用に対する新規なコネクティビティフレームワークを提供する。

異なる無線技術を十分に活用するために、モバイル装置がどの無線インターフェース（即ち、無線ネットワーク）を使用するか、及び好ましくはユーザアプリケーションに対してほとんど中断のないシームレス方法でインターフェース間（今後、無線ネットワーク間）をいつ切り替えるかを選択するように構成できる。

図４を参照して、幾つかの説明用実施例では、モバイル装置１は多重インターフェースを含むことが出来る。実施態様では、３つのインターフェース、即ち、インターフェース１、インターフェース２及びインターフェース３が示されている。しかしながら、種々実施例では、いくつのインターフェースでも使用し得る。具体例では、モバイル装置は、例えば、ポータブルコンピュータ、パーソナルディスクトップコンピュータ、ＰＤＡ、ポータブルボイスオーバＩＰテレホン及び／又は他の装置を含むことが出来る。代表的には、そのようなモバイル装置は（アクセスポイントと通信するためのアンテナを含む）トランシーバ、プロセッサ、（例えば、プログラムメモリ及びランダムアクセスメモリを含む）メモリを含む。また、図示のように、メモリは機能性を実行するためのプログラム又はモジュールを含むことができる。種々実施形態では、モバイル装置により実行されるべき処理は環境に基づいて適応に応じてソフトウェア、ハードウェア及び／又はファームウエアを介して行うことができる。

図４に示される説明用実施例では、複数のネットワーク、例えば、インターフェース１−３を介して通信できるモバイル装置１が示されている。例えば、モバイル装置はアクセスポイント２２又は図１（Ｂ）に示されるものと同様な基地局２を介して通信できる。更に、図４では、モバイル装置１は、例えば、他の無線ネットワーク又は有線ネットワークのような他のネットワークと通信もできる。図４を参照して、幾つかの説明的で限定されない実施例では、アクセスポイント２２が有線ネットワーク２０に接続される無線ローカルエリアネットワーク（ＷＬＡＮ）内に存在し得る。幾つかの実施例では、有線ネットワーク２０はインターネット（商標登録）又は企業データ処理ネットワークを含むことができる。幾つかの実施例では、アクセスポイント２２は無線ルータであり得る。幾つかの実施形態では、アクセスポイント２２は有線ネットワーク２１及びモバイル装置１と及び他のモバイル装置と通信する無線トランシーバにリンクされたネットワークインターフェース２５を持つことができる。一例として、無線トランシーバ２６はモバイル装置と無線又はマイクロ周波数通信のためのアンテナ２７を含む。アクセスポイント２２は好ましくはプロセッサ２８，プログラムメモリ２９及びランダムアクセスメモリ３１も有する。

異種ネットワーク技術が共存する環境を考慮すると、モバイル装置は複数のネットワークインターフェースを有する。そのような場合には、モバイルユーザは上述のように潜在的に複数の異種無線ネットワークを同時にアクセスできる。

そのようなシナリオでは、モバイルアプリケーションはアプリケーションに対して改良された品質及び信頼性をもたらす、使用ネットワーク及びそれらを使用する方法の豊富な選択を有する。しかしながら、今日の技術は多重無線インターフェースの存在を有効に使う我々の能力を制限する。この制限を導く要因にはアプリケーソンが多重ネットワークインターフェースを同時に介して通信することを不可能にするプロトコル、インテリジェントにする必要があるリアルタイム性能情報の不足、ダイナミックコネクティビティの決定及び多重インターフェースに特定される送信フレームワークの欠如がある。更に、無線ネットワーク環境及びユーザ要求は変化するので、現在の環境及びサービス品質要求に最適な異なるコネクティビティ戦略をダイナミックに選択及び実施することができるシステムが必要となる。

多重インターフェースを利用する問題は過去に研究されていた。研究者はより良いエンドツーエンド性能を達成するため多重インターフェースを利用する利点を認識していた。これらの利点を有効利用しようとするためにＯＳＩレイアの異なるレイアに導入される種々の方法がある。次のパラグラフでは、そのような働きの例が、各方法が加えられるＯＳＩレイアによって提供され、分類される。

以下の文献［１］はＣＤＰＤ無線ネットワークのための適応逆多重化に関する。パケットはリンクの観察処理能力に比例するサイズの断片に分割される。断片はマルチリンクＰＰＰを用いて複数のリンクを介してトンネル通過される。マルチリンクＰＰＰは複数の論理データチャネルを１つの論理リンクに集めるよう設計される。

以下の文献［２］はリナックス（登録商標）ベーストラフィックスケジュールｗＴＥＱＬに関し、複数の異種リンクを介してトラフィックを分割する重み付ラウンドロビンメカニズムを提供している。

以下の文献［３］はＩＰレベルで複数のＩＰインターフェースを介してデータフォローを分割することによって、複数のＩＰリンクの帯域幅を集合するメカニズムに関する。このメカニズムはＩＰレイヤのオリジナルパケットを他のヘッダと共にカプセル化し、受信端で、余分なヘッダをストリッピングすることによってトンネル化を使用することである。

以下の文献［４］は転送レイヤ解を提案する、負荷分散ＬＳ−ＳＣＴＰに関する。提案解はＳＣＴＰプロトコル（以下の文献［５］参照）に対する拡張を含み、１つの接続を伝えるため多重インターフェースを同時に使用する特徴を追加する。ＳＣＴＰアーチテクチャは経路選択モジュール及び経路監視モジュールを有する。

以下の文献［６］は他の単層レイヤ解、ｐ−ＴＣＰに関する。ｐ−ＴＣＰはＴＣＰ−仮想（ＴＣＰ−ｖ）と呼ばれる変形ＴＣＰと相互に作用するラッパ（wrapper）である。ＴＣＰ−ｖ接続はインタフェース毎に確立され、ｐＴＣＰはＴＣＰ−ｖパイプを介して送信バッファを管理する。分割はｐＴＣＰによって行われ、各ＴＣＰ−ｖの輻輳ウインドウサイズに基づいている。あるパイプに輻輳が生じると、ｐＴＣＰは大きな輻輳ウインドウで他のパイプにデータ再割当を行う。

多重エンドツーエンドルートがあるとき帯域幅集合を有効にする戦略に関する一連の知識も存在する。多重経路及びＱｏＳルーティングは以下の文献［７］及び［８］において考察される。多重ルートを介するビデオの層状優先分散化（Layered priority striping）が以下の文献［９］において検討されている。以下の文献［１０］には、著者はビデオ品質を改良するためにアドホックネットワークにおいて多重ルートを介する多重経路転送を考慮している。

更に、多重インターフェースの利用を研究している、他の種類の著作物があるが、1つだけのインターフェースがアクティブであり、送信できる場合である。他のインターフェースはフェイルオーバのために使用されている。これに関して、以下の文献［１１］、［１２］及び［１３］はこのクラスの方法に属する著作物である。以下の文献［１１］では、Ｄｅ他が輻輳を解放するためセルラ及びアドホックインタフェースを使用するｉＣＡＲを提案している。ｉＣＡＲシステムでは、ノードは最初に基地局と通信するためセルラインターフェースを使用する。セルが輻輳することになると、ノードはアドホックインターフェースを用いてパケットを中継することによって他のセルにおいて基地局と通信できる。以下の文献［１２］では、Ｌｕｏ他が３Ｇ及び８０２．１１無線通信を用いるＵＣＡＮを提案している。ＵＣＡＮでは、基地局とモバイルノードとの間のチャネル品質が悪いとき、基地局はプロキシクライアントにパケットを送付し、クライアントが８０２．１１インターフェースを用いてモバイルノードへのパケットを中継する。最後に、以下の文献［１３］では、Ｙｏｏｎ他が通信の第1の手段として高速、短距離無線を選択し、バックアップチャネルとして低速、長距離無線を使用する方法を提供する。

次の１３の文献［１］〜［１３］の各開示はここに全部記載されている如くそれらの全部についてここに援用される。

文献[1]: A.C. Snoeren, “Adaptive inverse multiplexing for wide area wireless networks”, Proceedings of the IEEE Globecomm, Rio de Janeiro, Brazil, Dec 1999;
文献[2]: J. Li, J. Brassil, “Performance Characterization of Traffic Equalizers on Heterogeneous Communication Links”, Submitted to Netwoking 2006;
文献[3]: D. Pathak, T. Goff, “A novel mechanism for data streaming across multiple IP links for improving throughput and reliability in mobile environments”, IEEE INFOCOM, New York, USA, 2002;
文献[4]: A. El Al, T. Sasadawi, M. Lee, “A Transport layer load sharing mechanism for mobile wireless hosts”, IEEE Conference on Pervasive Computing and Communications Workshops, 2004;
文献[5]: R. Stewart, Q. Xie et.al, “Stream Control Transmission Protocol”, IETF RFC 2960, 2000;
文献[6]: H. Hsieh, R. Sivakumar, “pTCP: Am end-to-end transport layer protocol for striped connections”, Proceedings of IEEE International Conference on Network Protocols, Paris, France, Nov 2002;
文献[7]: R. Ogier, V. Ruenburg, N. Shacham, “Distributed algorithms for computing shortest pairs of disjoint paths”, IEEE Transcations on Information Theory, March 1993;
文献[8]: I. Cidon, R. Rom, Y. Shavim, “Analysis of multi-path routing”, I.E.E.E./ACM Transactions on Networking, Dec 1999;
文献[9]: P. Sharma, S. Lee, J. Brassil, K Shin, “Handheld-routers: Intelligent bandwidth aggregation for mobile collaborative communities, HP Labs Technical Report, May 2003;
文献[10]: S. Mao, S. Lin, S. Panwar, Y. Wang, E. Celibi, “Video transport over ad-hoc networks: Multi-stream coding with multi-path transport”, IEEE JSAC, Vol 21, Dec 2003;
文献[11]: S. De, O. Tonguz, H. Wu and C. Qiao, “Integrated Cellular and Ad Hoc Relay (iCAR) Systems: Pushing the Performance Limits of Conventional Wireless Networks,” HICSS, pp. 3931-3938, 2002;
文献[12]: H. Luo, Ramachandran Ramjee, Prasun Sinha, Li Li, and Songwu Lu, “UCAN: A Unified Cellular and Ad-Hoc Network Architecture,” ACM MobiCom’03, 2003;
文献[13]: Wonyong Yoon, Jungmin; So, and Nitin H. Vaidya, "Routing Exploiting Multiple Heterogeneous Wireless Interfaces: A TCP Performance Study," IEEE MILCOM 2006, Washington DC, October 2006;
文献[14]: S. Kirkpatrick, C.D. Gelatt, M. P. Vecchi, “Optimization by Simulated Annealing,” Science Magazine, Vol. 220, number 4598, May 1983;
文献[15]: S. Mao, S. Lin, S. Panwar, Y. Wang, E. Celibi, “Video Transport over Ad-Hoc Networks: Multi-Stream Coding with Multi-Path Transport,” I.E.E.E. JSAC, Vol 21, December, 2003;
文献[16]: VLC Media Player, http://www.videolan.org/vlc;
文献[17]: Netfilter/IPtables http://www.netfilter.org/;及び
文献[18]: NISTnet, http://www-x.antd.nist.gov/nistnet/.
しかしながら、多重インターフェースの同時利用の課題に関する上述した指示的研究は、以下に述べるように、例えば、幾つかの弱点及び欠陥を含む、多数の重大な弱点及び欠陥を有する。

適応逆多重化（文献［１］）：この方法の有効な機能性は、ストリッピング（除去）がラウンドロビン（総当り）に基づいているので、類似特性を表す多重チャネル／リンクを介する流れを除去することに基づいている。しかしながら、この方法の有効性は関係するチャネル／リンクが異なる特性を持つ（例えば、ラウンドロビンがリンクの多様性を取り扱うことができない）とき、急速に低下する。更に、及び実際には、適応逆多重化方法は実質的に実行不可能である。なぜならば、所定装置に関するインターフェースは通常は、割当てられた異なるＩＰアドレスを持つことになり、完全に独立したインターネットサービスプロバイダ（ＩＳＰｓ）によって制御されることになるからである。故に、多重ＩＳＰリンクを１つの論理リンクにまとめる解決法は実現できないかもしれない。

ストリームコントロールトランスポートプロトコル（ＳＣＴＰ）（文献［４］及び［５］）：この方法は我々がマルチホーミング及びマルチストリーミングキャパビリティの利点を取り込みたいのであれば既存のＴＣＰ／ＵＤＰトランスポートレイヤを代用しなければならなくなる新たなトランスポートレイヤＳＣＴＰの設計に基づいている。これは非常に透明な方法ではなく、限定された範囲の利用となる。なぜならば、アプリケーションは新たなトランスポートプロトコルを中心に構築されなければならないからである。この方法によって提示されるプロービング及び適応特性に関しては、それらは本発明の好適実施形態が提供し、提示できるものに比較して限定がある。例えば、経路モニタモジュールのキャパビリティはリンクが使用可能であるかどうかを見分けることに制限がある。同様に、経路選択モジュールは観察されたラウンドトリップタイムだけに基づいて決定をする。

他方、本発明の好適実施形態に従った解決はより一般的となり、さまざまな情報を収集し、よりインテリジェントな決定をするために柔軟性を持つことができる。

並列ＴＣＴ（ｐＴＣＰ）（文献［６］）：このｐＴＣＰ方法の１つの主要な弱点は新経路が利用可能となるとき又は旧経路が使用できなくなるとき適応の欠如となる。特に、ｐＴＣＰはトランスポートコネクションの寿命中に経路のダイナミック付加／削除をサポートしない。

異種無線インターフェースを利用するｉＣＡＲ，ＵＣＡＮ及びルーティング（文献［１１］，［１２］及び［１３］）:これら文献によって説明される方法は破損リンクの問題を緩和するために多重インターフェース間の流れを取りさることができるので、それらは利用可能なインターフェースを同時に使用しようとしない。他方、それらは主にデータを送信するための主要なものとして１つのインターフェースを選択し、このインターフェースの調子が著しく悪いとき、それらは送信を完了するためのバックアップインターフェースに切り替わる。

他方、本発明の好適実施形態はエンドユーザに利用できる最良のサービスを提供する最も適切な方法で利用可能インターフェースの複数又は全てを、例えば、同時に利用できる（即ち、それは破損リンクによって生じる中断を回避して送信を完了する事態だけでない）。

一般的に言えば、関連する著作物は特定の問題を解決し、区分的解決法を提供し又は特定の実施／プロトコルに依存することを試みている。関連する著作物のどれも無線装置に複数インターフェースオプションを同時に使用させることを意図していなく、その結果、それらの要求に合うアーチテクチャを必要としない。

しかしながら、任意のアプリケーションがそのネットワークオプションをインテリジェントに使用することを可能にする完全な解決のために、アーチテクチャの全ての要素が一体になる必要がある。更に、フレームワーク新規／既存のプロトコルを組み入れるため柔軟である必要があり、特定のプロトコル／インプリメンテーションを使用することに束縛されない必要がある。（幾つかの例で、商標名：ＩＮＴＥＬｉＣＯＮ（登録商標）として参照できる）ここに記載された好適実施形態はマルチインターフェース装置のためのインテリジェントコネクティビティ決定のため完全及び柔軟性フレームワークの両方を提供するための新規及び有利なシステム及び方法を含む。

好適実施形態は背景技術の上記及び／又は他の問題を解決する。

我々はホームメディア及び他のアプリケーションのためのネットワークデータ配信の性能、信頼性及び弾力性を著しく改良する新規なネットワーク方法を紹介する。インテリジェントコネクティビティ（ＩＮＴＥＬｉＣＯＮ）フレームワークは極端な干渉及びパケットエラーの存在の下でさえ、完全なビデオ及びオーディオ配信を確実にするためインテリジェント、ダイナミック及び協調方法で同時に複数のネットワークリンクを活用する。ＩＮＴＥＬｉＣＯＮによって採用される技術はＷｉ−Ｆｉ，ＵＷＢ，イーサーネット（登録商標）などを含む、多数の無線及び優先ネットワーク技術にわたって使用し得る。ＩＮＴＥＬｉＣＯＮは幾つかのネットワークインターフェースを同時に介してメディア送信を管理し、円滑なリアルタイムビデオ及びオーディオ再生を確実にするため条件を変更することに動的に適応するインテリジェントフィードバックアルゴリズムを採用する。更に、ＩＮＴＥＬｉＣＯＮは従来の解決法に比較して非リアルタイムファイル配信のためにアプリケーション帯域を３倍以上にできる大幅な処理量増加を提供する。

セルラネットワークに対する３Ｇアップグレードと共にWi-Fiの広範囲の展開は、複数の無線IP技術が利用しやすいエリアを素早く作り出す。WiMAXはこの現象に更に貢献することになる。さまざまなアクセス技術を同時に使用する能力はアプリケーションサービス品質及び信頼性を改良する機会を作り出す。このアプリケーションでは、我々はデバイスが新規な方法でアクセスダイバーシティを利用することを可能にするインテリジェントコネクティビティフレームワーク(intelligent connectivity framework)(INTELiCON)を提供する。INTELiCONは最適なコネクティビティ戦略を発見し、選択し、実行し、評価するためのモジュラー、フレキシブルプラットフォームを提供する。フレームワークはコネクティビティ戦略を実行し、アプリケーションレイヤに対する透明性を維持しながらそれらの有効性を評価する。更に、INTELiCONはネットワーク条件又はアプリケーション要求における変化に合う新たな戦略をダイナミックに実行もできる。我々はプロトコルタイプのインプリメンテーションの詳細と共にINTELiCONフレームワークのアーチテクチャ特性を提供し、限定された資源及び信頼できないリンクにもかかわらず高品質のストリーミングビデオをサポートするためにフレームワークがどうのようにアクセスダイバーシティを利用するかを示している。

４Gバージョンの主要特徴は異種ネットワーク技術が共存し、モバイル装置が多重ネットワークインターフェースを有する環境のそれである。そのようなシナリオでは、モバイルアプリケーションは使用するネットワーク及びそれらを使用する方法の豊富な選択を有する。我々は装置がその‘コネクティビティ戦略’としてその利用可能無線インターフェースをどのように利用するかについて言及する。今日の技術は全ての利用可能なコネクティビティ戦略を実施する我々の能力を制限している。この制限の原因となる要因には、アプリケーションが多重ネットワークインターフェースを同時に介して通信することを可能にしないプロトコル、インテリジェントで、ダイナミックなコネクティビティ決定をするために必要性とするリアルタイム性能情報の利用不可、及び多重インターフェース装置に特定される送信フレームワークの欠如がある。

更に、無線ネットワーク環境及びエンドユーザの要求が変わるので、現在の環境及びサービス品質要求に最適である異なるコネクティビティ戦略をダイナミックに選択及び実施できるシステムが必要となる。我々は実現可能なコネクティビティ戦略の集合を両方共に拡張し、現在の条件に最も適応する戦略をインテリジェントに適応できる多重インターフェース装置フレームワーク(INTELiCON)を提案する。

我々は簡単なシナリオを介して存在できる可能性だけでなく今日のシステムの欠陥を検討できる。２つのインターフェース、即ち、３G及びWLANインターフェースを持つモバイルユーザを考える。更に、２つの異なるアプリケーションがあると仮定すると、ビデオセッション及びデータ転送セッションの両方はインターネットを介して同じエンドホストと通信する。商用インプリメンテーションは現在では1つだけのインターフェースを使用することを両方のアプリケーションを強制し、故に、コネクティビティ選択は利用可能なインターフェースの１つ及び1つだけを選択することに帰着する。使用されているネットワークが輻輳しており、しかも第２インターフェースが使用のままになっている状況を可視化することは容易である。

次に、我々は可能である幾つかの例のコネクティビティ戦略について述べるが技術はまだそれらサポートする環境が整っていない。リアルタイムであり、タイムリーに配信を要求するビデオセッションは高帯域WLAN接続を排他的に使用でき、データ転送は低帯域幅３Gネットワークを使用できる。他の戦略はビデオセッションのためにWLANネットワークを使用し、それから３G及びWLANリンクを介してデータパケットを交互に入れ替えることである。そのようなシナリオは利用可能ネットワークを介する負荷を平衡させることに役立つ。パケットを入れ替えることは複数の低帯域幅リンクを集合することによって広帯域幅セッションを実現させるために使用し得る集合戦略の一形態である。第３戦略はビデオ及びデータパケットを二重化する簡単な二重符号化方式を使用し、各インターフェースを介してコピーを送ることである。更に、そのような戦略は有効な帯域幅の利用が目的であるとき又は使用変更が適用できるときには望ましくない。しかしながら、この冗長性はフェイルオーバ信頼性の観点で有益である。即ち、１つのインターフェースが突然低下（例えば、セルラーでの呼出中断）すれば、セッションは連続し続ける。全てのシナリオにおいて又は全ての目的の中で望ましい単一の戦略はない。故に、必要に応じてコネクティビティ戦略をダイナミックに評価でき、適応できるフレームワークを持つことが重要である。

全ての上述したシナリオは何の情報がどのネットワークを介して送信されるかを決定するコネクティビティ戦略の実施例である。多重ネットワーク（又はインターフェース）を利用するため適当なコネクティビティ戦略を選択することは各アプリケーションの要求、ネットワーク条件及び提示されたサービスの品質を知ることに依存する。多重インターフェースの存在によって提示されるダイバーシティを十分に利用するためには、モバイル装置はそれらがインテリジェントコネクティビティ戦略を発見、決定、実行及び評価できる全体的フレームワークを必要とする。

発見はネットワーク環境（即ち、予想遅延、ジッタなど）及びアプリケーション要求（即ち、最大許容遅延及び最初要求処理能力）に関する情報を参照する。また、その現在のネットワーク環境、それがマルチインターフェース通信をサポートするかどうか、そうであれば、その代替インターフェースの構成の詳細を含めて、ピア装置に関する情報も発見することは重要である。

INTELiCONアーチテクチャの注目部分はインテリジェントコネクティビティ戦略(intelligent connectivity strategy)を決定するために発見を介して利用可能にする情報を用いることである。多目的最適化アルゴリズム又は単純経験則(simple heuristics)がこれらの決定をするために使用されてもよい。選択された戦略要求を実行することによって多重インターフェースを介してアプリケーショントラフィックを配信するために必要なプロトコル／システムを適応させる方法が分る。多重インターフェースを同時に介してアプリケーションセッションをストリーミングすることは今日の標準インターネットプロトコルのいずれかによってサポートされない。

決定されたコネクティビティ戦略を実行することによってインプリメンテーションの設計において考慮する必要があるいくつかの挑戦が行われる。我々のマルチインターフェースフレームワークはアプリケーションレイヤ変形を要求しないで全てのアプリケーションをサポートできるはずである。故に、エンドアプリケーションに対する透明性は重要な設計目標である。決定処理は受信機で適正でないパケットの余分な処理を含む異種インターフェースか介してセッションをストリーミングする副作用も明らかにすべきである。

無線ネットワーク環境は非常にダイナミックである可能性があり、ユーザ／アプリケーション要求を変更するとともに、コネクティビティ戦略が適応できるべきことを要求する。我々のマルチインターフェースフレームワークは現状に対して選択されたコネクティビティ戦略の適切性を評価できる必要がある。この評価プロセスは現在のネットワーク及びアプリケーション状態により良く合うように戦略を適応させる基礎を形成する。INTELiCONアーチテクチャは上述した特徴を達成する一般的フレームワークを提供する。フレームワークは任意の特定のインプリメンテーション、アルゴリズム又は標準に依存する必要がない。それは特定のタスクを行うために、現在の標準及びアルゴリズム、更に将来のものを組み入れるために十分柔軟性がある。例えば、メディア独立ハンドオフのための新たなIEEE 802.21標準はネットワークキャパビリティを発見するために使用でき、セッション初期プロトコル（ＳＩＰ）はピア装置のキャパビリティを発見するために使用し得る。

好適実施形態の幾つかによると、装置が有する複数の無線インターフェースをそれらがインテリジェントに及び同時に使用することを可能にするフレームワークが提供される。好適実施形態において、フレームワークはインターフェースの最適な使用を発見し、選択し、実行し、評価するモジュラー及び柔軟性プラットフォームを提供する。

幾つかの実施形態によると、無線装置の多重インターフェースの同時使用のためのインテリジェントコネクティビティフレームワークが提供される。このフレームワークは複数の異種無線ネットワークインターフェースを有する無線装置を含み、無線装置はネットワークの状態及び送信の品質に関するメトリクスを発見するように構成され、無線装置は発見されたメトリクスに基づいて複数のネットワークインターフェースの使用を含んでインテリジェントコネクティビティ戦略を決定するように構成され、無線装置はアプリケーションレイヤの変更をしないで複数の多重インターフェースを同時に介してアプリケーションセッションをストリームするように構成される。

幾つかの実施例では、インテリジェントコネクティビティフレームワークは複数のモバイルピア装置に同様なインテリジェントコネクティビティフレームワークを更に含む。幾つかの実施例では、無線装置は更にメトリクスに関する情報を収集するための測定モジュールを含む。幾つかの実施例では、測定モジュールはリモートピアモバイル装置を含めて、リモート情報源からメトリクスを収集するように構成される。幾つかの実施例では、モバイル装置は制御チャネルを介してリモート情報源からメトリクス情報を受信するように構成される。幾つかに実施例では、測定モジュールは局所情報源からメトリクスを収集するように構成される。幾つかの他の実施例では、測定モジュールはリンク品質及び／又は利用可能帯域幅に関するネットワーク性能マトリックスを監視及び／又は調査するように構成される。幾つかの他の実施例では、無線装置は更に測定モジュール内のメトリクスに関する情報に基づいて多重インターフェースを採用する戦略を決定する決定モジュールを含む。

幾つかの他の実施例では、決定モジュールは情報に基づいて品質及び／又はネットワーク状態を連続的に評価し、リアルタイムで戦略をダイナミックに適応させる。幾つかの他の実施例では、決定モジュールはネットワーク環境情報、サービス品質情報及び送信戦略のコストに基づいて多重インターフェースを採用する戦略を決定するように構成される。幾つかの他の実施例では、決定モジュールは最適化アルゴリズムに基づいて決定する。

幾つかの他の実施例では、無線装置は更に決定モジュールによって決定された戦略を実施するパケット処理モジュールを含む。幾つかの実施例では、パケット処理モジュールは受信パケットをバッファするように構成される。幾つかの実施例では、パケット処理モジュールは状態情報を送信済パケットにピギーバックすることによって性能情報を交換するように構成される。

幾つかの実施例では、無線装置は更に送信戦略に関する情報を交換するため制御チャネルを管理する制御モジュールを含む。幾つかの実施例では、無線装置は帯域内及び帯域外の両方のメトリクスに関する性能情報を通信するように構成される。幾つかの実施例では、帯域内情報は送信ピアとしての無線装置によって送信済ペイロードパケットにピギーバックし、パケットをアプリケーションに配信する前に受信ピアでそのような情報を回復することによって通信される。幾つかの実施例では、帯域外情報は無線装置と他のピアとの間の専用制御チャネルを介して通信される。幾つかの実施例では、無線装置と他のピアとの間の通信中に、送信機側で、測定、同期データ及び性能メトリクスが測定及び決定モジュールに移動され、受信機側では、制御データがパケット処理及び測定モジュールに配信される。

幾つかの他の実施形態では、無線装置の多重インターフェースのインテリジェント管理及び同時使用の方法が行われる。これは複数の異種無線ネットワークインターフェースを有する無線装置を提供することを含む。無線装置はネットワークの状態及び送信の品質に関するメトリクスを発見する。無線装置は発見されたメトリクスに基づいて複数の多重インターフェースの使用を含むインテリジェントコネクティビティ戦略を決定する。無線装置はアプリケーションレイヤの変更をしないで複数の多重インターフェースを同時に介してアプリケーションセッションを実施する。

上記及び／又は他の態様、種々実施形態の特徴及び／又は利点は添付図と関連して以下の説明を鑑みて更に理解されるであろう。種々の実施形態は適用できる場合異なる態様、特徴及び／又は利点を含める及び／又は除外できる。更に、種々実施形態は適用可能な場合他の実施形態の１以上の態様又は特徴を組み合わせることができる。特定の実施形態の態様、特徴及び／又は利点の説明は他の実施形態又は請求項を限定するとして解釈されるべきでない。

幾つかの具体的及び限定されない実施形態に従った構成要素を記載したアーチテクチャ図である。 構築された具体的実験プロトタイプシステムを示すアーチテクチャ図である。 戦略のダイナミック選択に関する幾つかのグラフを示す。 複数のインターフェースを有するモバイル装置が複数のネットワークと通信する具体的環境を示すアーチテクチャ図である。

本発明が多くの異なる形態で実施し得るが、具体的実施形態は本明細書が発明の原理の実施例を提供すると考えられべきであり、そのような実施例はここに記載され及び／又はここに示された好適実施形態に本発明を限定することを意図していないと言う了解の下でここに説明されている。

幾つかの好適実施形態によると、装置（例えば、モバイル装置）が持っている多重無線インターフェースをそれらがインテリジェントに及び同時に使用することを可能にするフレームワークが提供される。

幾つかの好適実施形態によると、インターフェースの最適な使用を発見し、選択し、実行し、評価するモジュラ及び柔軟性プラットフォームが提供される。

幾つかの実施形態によると、ＩＮＴＥＬｉＣＯＮアーチテクチャの重要な部分がインテリジェントコネクティビティ戦略を決定するために発見を介して利用可能にする情報を使用することを含む。多目的最適化アルゴリズム又は単純経験則がこれらの決定をするために使用されてもよい。選択戦略要求を実行することによって多重インターフェースを介してアプリケーショントラフィックを配信するため必要なプロトコル／システムを適応する方法が分る。多重インターフェースを同時に介してアプリケーションセッションをストリーミングすることは今日の標準インターネットプロトコルのどれによってもサポートされない。決定されたコネクティビティ戦略を実行することはインプリメンテーションの設計において考慮する必要がある幾つかの挑戦をもたらす。我々の複数インターフェースフレームワークはアプリケーションレイヤの変更を必要としないで全てのアプリケーションをサポートできるはずである。故に、エンドアプリケーションのための透明性は重要な設計目的である。決定処理は受信機で適切でないパケットを含む異種インターフェースを介してセッションをストリーミングする副作用も明らかにすべきである。

無線ネットワーク環境は非常にダイナミックである可能性があり、ユーザ／アプリケーション要求を変更すると共にコネクティビティ戦略が適用できることを要求する。我々の多重インターフェースフレームワークは本発明に対して選択されたコネクティビティ戦略の適切性を評価できるはずである。この評価処理は戦略を現在の状態により良く適応するための基礎を形成する。

ＩＮＴＥＬｉＣＯＮアーチテクチャは好ましくは上述した特徴を達成する一般的フレームワークを提供する。フレームワークはどの特定のインプリメーション、アルゴリズム又は規格にも依存しない。それは特定のタスクを実行するために、現在の規格及びアルゴリズム、更には未来のもの、を組み込むのに十分柔軟性がある。

実行された代表的ワーク及び多重ネットワークインターフェースの同時利用のために設計されたメカニズムはネットワーク環境が敏速に及び著しく変化するかもしれない場合に対処しないでそれを実行するメカニズムに主に焦点を合わせている。更に、既存のワークは存在するアプリケーションの配信及びそれらをサポートする基本となる各種プロトコルの変化を考慮していない。それらは特定のアプリケーション又はそれらの大規模な利用を制限するトランスポートレイヤプロトコル（即ち、ＴＣＰ）により多くの焦点が当てられる。研究の大部分から考慮されない問題は最も効率的な方法で多重インターフェースを介して送信がどのように外すかである。効率的には、我々がリンクの現在の状態に従って最善のサービス配信を得ることができるように我々は多重インターフェースを介してどのようにフローを外すことができるかを意味している。

ＩＮＴＥＬｉＣＯＮフレームワークはネットワークを介して送信するつもりであるアプリケーションに透過的に及びＯＳＩモデルの各種レイヤに利用されているプロトコルから独立して動作する。それは非常に多目的であり、最も効率的な方法で既存のワークをサポートするため全ての機能的モジュールを提供する。これはネットワークからネットワークの状態及び送信の品質に関する全ての適切なメトリクスを（例えば、測定モジュール及び制御モジュールを介して）収集することによって達成される。収集された情報は（例えば、パケット処理モジュールを介して）適用される送信方法を（例えば、決定モジュールを介して）及びこの方法がどのように活性インターフェースを沿ってフローを取り去るかを決定するために利用される。更に、（送信の相手側で）リモートを後続の送信戦略に関するＩＮＴＥＬｉＣＯＮモジュールに同期させ、そのようにエンドツーエンド送信を調整するために、好ましくは、制御モジュールによって提供される専用制御チャネル上で交換される同期信号伝達がある。

設計されたフレームワークは種々の及び異なる送信戦略に合せる、また基底ネットワーク（underlying network）の変化状態に利用可能戦略を適応させることの両方に対する全ての適切な機能モジュールを提供する。そのような方法は基底ネットワーク状態から独立して最良のエンドツーエンド性能を達成して、透明方法で多種多様のアプリケーションに適応することを可能にする。

１．パケット処理モジュール
活性インターフェースの同時使用はサービス品質及び信頼性において顕著な改良をもたらすことができるが、そのような使用を可能とするのはアプリケーションパケットの追加処理を必要とする。パケット処理モジュールはＩＮＴＥＬｉＣＯＮフレームワークの中心である。多重利用可能インターフェースを同時に及びインテリジェントに使用することは種々の送信戦略を実現する。これらの戦略はＩＰレイヤマングリング(IP layer packet mangling)、ストリーム制御送信プロトコル（Stream Control Transmission Protocol(SCTP)）のようなマルチホーミング（multihoming）（例えば、接続の１つ又は両方のエンドポイントが1以上のＩＰアドレスにより構成できる）をサポートするトランスポートプロトコル、又はＩＰｖ６マルチホーミングサポートに依存するかもしれないが、それに限定されない。

（例えば、我々の実験プロトタイプに採用されているような）幾つかの具体的実施形態では、パケット処理モジュールはＩＰマングリング技術を適用することによって実現される。とりわけ、そのような技術はそれらが提示する透明性及び柔軟性により望ましくなりえる。ＩＰマングリング技術はＩＰレイヤでネットワークパケットを獲得し、変更することに基づいている。パケットの獲得はネットワークスタックに提供されたカーネルホックを用いて実現される。これらのホックはｉｐｔａｂｌｅｓによって実施され、カーネル空間からユーザ空間への送信又は受信パケットを利用可能にする能力を有する。パケット処理モジュールは実現したコネクティビティ戦略に基づいてパケットの変更（マングリング）を行う。主にそれは送信元及び送信先ＩＰアドレスを変更し、ピギーバックデータを注入又は除去することに基づいている。

アーチテクチャのモジュール方式はパケット処理モジュールの一部として既存のメカニズムをサポートできる。更に、方法の新規性の１つはパケットモジュールが基底ネットワーク環境及び提供されるサービス品質を前提として送信戦略をダイナミックに及び透明的に適応できる。好ましくは、この適応は決定モジュールによって決定され、制御モジュールを介して通信される。

好適実施形態では、このワークは特定のものをターゲットとしないで、ネットワークサービスの改良に焦点を置いている。顕著なＩＮＴＥＬｉＣＯＮの対象は任意の既存及び未来データ交換サービスに対して有効である。故に、提供された透明性は提案フレームワークの耐久性に対して望ましい。好ましくは、サービスは変更される必要が無く又は主に下位ＯＳＩレイヤで動作する、フレームワークの存在性及び機能性を知っている必要がない。最終的に、提供されたサービスはネットワークがＩＮＴＥＬｉＣＯＮの透明性アプリケーションによりアプリケーションレイヤに対してより健全そうであるので改良されることになる。

多種多様のリンクが送信戦略に含まれているときに透明性を維持するために、パケット処理モジュールはリンク速度における電位差を明らかにしなければならない。これらの環境の下では、パケットは異常となるかもしれなく、又は要求及びタイムアウトをバッファリングするアプリケーションにより破棄されるかもしれない。同時利用の利点を実現し、そのような不所望なシナリオを避けるために、パケット処理サブモジュールは好ましくはバッファリング及びパケット再配列機能をサポートする。この機能はそれらをアプリケーションに解放する前に受信パケットをバッファする。受信パケットをバッファすることによってパケットの時間が低速インタフェースから受信され、再配列され、アプリケーションに配信されるのを可能にする。これは破棄パケットを少なくすることになり、提供されるサービスの品質を改良する。好ましくは、バッファリングパラメータ及び加算遅延はＩＮＴＥＬｉＣＯＮフレームワーク内で構成でき、それらはサービスの要求に依存する。好ましくは、これらパラメータはブートストラップでき、ネットワークの健全性及び提供されたサービスの現在の品質に関してＩＮＴＥＬｉＣＯＮパラメータのダイナミック適応に関与する決定モジュールによって送信にわたってダイナミックに適応し得る。

好ましくは、パケット処理モジュールは性能情報の交換にも寄与する。この情報は、例えば、サービス品質を評価し、ネットワーク健全性を評価し、送信戦略を調整するために使用される。幾つかの実施形態では、パケット処理モジュールは状態情報を送信パケットでピギーバックすることによって性能情報を交換する。これは既存のアプリケーショントラフィックパケットの利点を生かすことによってオーバヘッドを低減するのに役立つ。アプリケーショントラフィックがないとき、性能情報は以下のセクションで示される、制御モジュールを介して交換し得る。

２．制御モジュール
好適実施形態では、ＩＮＴＥＬｉＣＯＮ制御モジュールは送信戦略の有効性に関する情報を交換するために専用の制御チャネルを提供し、管理することに関与する。この情報はピア同期化、サービス品質及びネットワーク健全性のために必要である。アーチテクチャの新規性の１つはそれが帯域内及び帯域外の両方の性能情報を通信するためＩＮＴＥＬｉＣＯＮピアのための手段を提供することである。

帯域内情報は好ましくは送信ピアで送信済ペイロードにピギーバックすることによって通信される。他方、帯域外情報は好ましくは２つのＩＮＴＥＬｉＣＯＮピアの間にセットされる専用制御チャネルに生じる。情報のピギーバックがより資源効率的であっても、情報がピア間のアプリケーショントラフィックの存在が無くてピア間で通信でき、パケットの受信によりペイロードからの制御情報を分離するために必要性がないので、情報の帯域外交換はより健全であり、より多目的である。専用制御チャネルの存在は提供されたサービス品質、各種ネットワーク健全メトリクス及び同期化情報をリアルタイムで通信する柔軟性をピアに与える。

帯域内交換は主にリモート端間の性能メトリクスの便乗通信に関する。更に、制御モジュールによってサポートされている、リモートピア間の帯域外通信は性能メトリクス及び同期化信号伝達の両方を含む大量の多種の情報を転送することに関与している。特に、性能情報は観察された平均パケット遅延、ジッタ、破棄及び異常パケットを含むサービス特定品質メトリクスに関する、更に、ピアは送信の相手側にリンク状態を知らせることができる。この情報は決定モジュールに存在している戦略選択メカニズムのために使用できる。

制御モジュールによって受信される帯域内又は帯域外情報は更に処理するためのＩＮＴＥＬｉＣＯＮアーチテクチャの適正モジュールに伝達される。送信機側では、測定、同期化データ、及び性能メトリクスが測定及び決定モジュールに送られる。受信機側では、制御データがパケット処理及び測定モジュールに配信される、
３．測定モジュール
測定モジュールはネットワークの性能及び健全性に関する情報を（例えば、局所的に）収集し、分配し、対応するサービス品質を評価する。メトリクス収集に関しては、要求された情報を測定モジュールに提供する、２つの情報源がある。

− リモート情報源：制御及びパケット処理、及び
− 局所情報源：モニタリング及びプロービング（厳密調査）
上述したように、制御及びパケット処理モジュールはリモートピアからの情報を収集する能力を有している。特に、リモートピアは提供されたサービスに関するフィードバック情報のために制御チャネルを利用することができ、又はそれはフィードバック情報を送信済データパケットにピギーバックすることができる。検索及び収集情報は図1に示すように測定モジュールに送られる。リモートピアから直接配信されるサービスの品質に関するフィードバック情報を集中するアーチテクチャの能力はメカニズムの有効性及び適応特性に重要である。

フィードバック情報から離れて、測定モジュールは好ましくはリンク品質及び利用可能帯域幅に関するネットワーク性能メトリクスをモニタし、精査能力を有している。この情報はリモートピアから収集された性能メトリクスと共に記憶され、新たな戦略が決定されなければならないときにその要求毎に決定モジュールに送られる。更に、この情報は決定モジュールへの送付を強制できる。特に、測定モジュールは好ましくはサービス品質評価サブモジュールを有する。このサブモジュールは提供されたサービスの品質を評価するためのメトリクスモジュールによって収集された性能モジュールを利用し、この品質チェックが失敗すれば、そのときそれは他の適正な戦略を選択するため決定モジュールを始動する。始動処理は好ましくは戦略選択アルゴリズムの許可及び（例えば、測定モジュールから決定モジュールへ）関連収集メトリクスの送付の両方を含む。更に、局所的に収集された情報はそれがリモートピアに分配できるように制御及びパケット処理モジュールに提供できる。

４．決定モジュール
決定モジュールは好ましくはパケット処理モジュールが実現することになる戦略を決定することに関与する。このモジュールのコアはネットワーク環境、提供されたＱｏＳの現在のレベル及びユーザによって要求される又はサービスによって期待されるＱｏＳの目標レベルを表す種々パラメータを入力として受信する最適化アルゴリズムである。決定モジュールは異なる戦略間で決定し、所望のＱｏＳが（例えば、現在のネットワーク状態を前提にして）達成されるように選択された戦略のパラメータを構成する。

適用されるべき戦略を決定することから離れて、決定モジュールは既存のネットワーク状態の下で配信品質を連続的に評価もする。サービス品質は種々の性能メトリクスを収集し、品質評価機能を利用することによって定量化される。決定モジュールは好ましくは所望のサービス品質を適用された送信戦略によって配信されたサービス品質と比較でき、現在の戦略をダイナミックに再構成でき又は必要なら新たな送信戦略を実施できる。

リアルタイムでの戦略のダイナミック調整は非常に有力であり、基底ネットワーク環境に適応することによって顕著なサービス品質を配信する有望な方法を表す。ネットワーク環境及び所望のサービス品質が考慮されるだけでなく、送信戦略を切換えるコストが更に説明される。このコストは達成されたＱｏＳのレベルに影響し、適応処理中に考慮するのが望ましい。決定モジュールのコアメカニズムは最適化アルゴリズムに基づいているので、決定処理の注目すべき要素はサービス品質の定量化である。これは好ましくはネットワーク環境、サービスの目標及び現在品質及び既存戦略と新規戦略との間を切換えるコストを表すメトリクスを含む利用機能のアプリケーションによって実現される。

これは、例えば、以下のように表すことができる。

ｆ（Ｎ，ΔＱ，Ｃｓ_ｉ→ｓ_ｉ＋１）
但し，
Ｎ＝ネットワーク環境；
ΔＱ＝達成されたＱｏＳと所望のＱｏＳとの差；
ｓ_ｉ＝現在戦略；
ｓ_ｉ＋１＝未来戦略；
Ｃ＝現在戦略と未来戦略とを切換えるコスト。

最適化されるべき所定の利用関数に関して、最適化アルゴリズムの選択は注目に値する。このメカニズムは決定モジュールの根底である。具体的設計では、我々は制限で最適化アルゴリズムとなる一般的無作為近似アルゴリズムであるシミュレーションアニーリング（ＳＡ）アルゴリズム（例えば、 “Optimization by Simulated Annealing”と名称付けられ、参照により援用される文献１４を参照）を利用した。ＳＡはその幅広い適用性及び多用途性により非常に有力である。我々は幾つかの実施形態においてＳＡを採用したとしても、種々の実施形態は他のアルゴリズム又は一組のアルゴリズムの組み合わせアプリケーションを使用でき、考慮中であるシナリオに依存して、具体的実施例に限定されない。

５．ＩＮＴＥＬｉＣＯＮコントローラ
好適実施形態において、ＩＮＴＥＬｉＣＯＮコントローラは指定されたフレームワークのモジュール方式を保存することに関与するモジュールである。それは他のＩＮＴＥＬｉＣＯＮモジュール間の情報を中継することによってそれらの間に共通通信インターフェースを提供する。好ましくは、ＩＮＴＥＬｉＣＯＮコントローラは種々のモジュール間を流れる情報を傍受及び中継するプロセス間通信モジュールを実行する。そのようにモジュール（１−４）は共通メッセージ通過フレームワークを用いて互いに直接に接触する必要が無く互いに通信できる。ＩＮＴＥＬｉＣＯＮコントローラモジュールの１つの重要なことは、例えば、モジュラー方式の重要性及びフレームワークの拡張性にある。例えば、フレームワークがモジュールの１つ以上の連携を含むより多くの機能性によって拡張されなければならなくなる場合、ＩＮＴＥＬｉＣＯＮコントローラによって、提供されたプロセス間通信フレームワークが協同モジュールにできるだけ透明にこの拡張をサポートすることになる。

更に、ＩＮＴＥＬｉＣＯＮコントローラはモジュール間でより効率的な通信を果たす。特に、ＩＮＴＥＬｉＣＯＮモジュールが存在しないと仮定すると、モジュール（１−４）がそれらの間で通信するために、それらは可能な対のプロセス間通信チャネル毎のトラックを他のモジュールに対して開放し、維持しなければならない。この方法は重要な処理及び電力資源を無駄にしてしまうことになる。むしろ、ＩＮＴＥＬｉＣＯＮコントローラモジュールのアプリケーションはモジュール毎に１つのプロセス間通信チャネルの作成及び利用をもたらす。この単一チャネルはＩＮＴＥＬｉＣＯＮコントローラモジュールを介して各モジュールを他のモジュールと通信するのに充分である。

種々の新規なもの
我々の解決法の幾つかの基本的な新規なものは我々の設計がインテリジェントに、透明性に、モジュール方法で複数インターフェースの同時使用を可能にする統一的フレームワークを提供することである。他方、上記で検討した他の関連解決法は課題を完全に解決するためにフレームワークを提供しないで問題の１以上の部分を試みた。よりよい性能のために多重インタフェース利用の分野において他の方法に関して比較すると、ＩＮＴＥＬｉＣＯＮフレームワークは、例えば、以下を含む、多くの利点／差異を示す。

ａ）既存の方法は多重送信インタフェース利用の利点を生かすようにして、ＯＳＩモデルの種々のレイヤに作用している特定の送信戦略に焦点を合わせている。これに対して、ＩＮＴＥＬｉＣＯＮモデルはこれら異なる戦略の全てが送信の（サービスの）性能を改良するために実施でき、効率的に組み合わせることができるフレームワークを提供する。

ｂ）既存の方法はそれらが特定のトランスポートプロトコル（例えば、ＴＣＰ， ＳＣＴＰ）を前提とするので制限されたグループのアプリケーションに焦点を合わせている。これに対して、ＩＮＴＥＬｉＣＯＮモデルはそれが仮のトランスポートレイヤを用いるアプリケーションだけに限定されないようにどんなトランスポートレイヤの仮定を当てにしていないのでこの制限を受けることがない。

ｃ）送信戦略の大部分は特定のメカニズムに限定される。ネットワークの状態が変化すると又はリンクが追加又は除去されると、それらは適正に適応する能力を有さなくなる。これに対して、ＩＮＴＥＬｉＣＯＮフレームワークは広範囲の送信戦略をサポートできる。適正な利用機能を適用することによって、決定メカニズムは現在のネットワーク及び送信状態により良く適応する他の送信戦略を選択できる。決定モジュールによって追加された知性と組み合わせてＩＮＴＥＬｉＣＯＮフレームワークによって提供されるこの多用途性は多重インタフェースの利用のために提案された既存のメカニズムの中でフレームワークを新規及び画期的にする。

ｄ）ＩＮＴＥＬｉＣＯＮフレームワークはネットワーク状態及び現在の送信品質に関する多様なメトリクスの収集をサポートする。収集はネットワーク（例えば、測定モジュール）を調べることによって又は受信端（例えば、制御及びパケット処理モジュール）から送信品質及びネットワーク状態を受信することによってのいずれかで生じる。収集されているメトリクスに関してどんな制限もなく、このリストは性能要求及び対応アプリケーションにダイナミックに依存して変更し得る。後者はいずれも任意のリアルタイム探索をを行わない既存のメカニズムと比較して革新的であり、又はそれらは収集されているメトリクスに関して非常に限定された柔軟性を有する。収集されている多種多様のメトリクスは送信戦略を現在のネットワーク状態及び予想のエンドツーエンド送信品質に正確に適応するためＩＮＴＥＬｉＣＯＮフレームワークの能力を更に高めることができる。

ｅ）更に、メトリクスの収集に関して、既存の戦略は質的送信フィードバックを提供する固有の能力によりＴＣＰ又はＳＣＴＰトランスポートプロトコルに焦点を合わせている。しかしながら、これらのメカニズムに伴う問題はフィードバックが選択された送信プロトコルの制御信号伝達に限定され及び非常に特定していることである。これに対して、上記ｄ）においても述べたようにＩＮＴＥＬｉＣＯＮフレームワークはそれがメトリクスの収集のためのそれ自体の多目的で拡張可能なメカニズムを提供するので限定されない。これらメトリクスは、例えば、基底ネットワーク環境又はエンドツーエンド送信品質に関係され得る。更に、収集されるべきメトリクスの選択は性能要求又は現在の送信戦略の必要性に基づいてダイナミックに変えることができるので、収集されるべきメトリクスの選択は限定されなく、予め特定されない。

ｆ）送信戦略を決定するための利用機能及び最適化アルゴリズム（例えば、決定モジュール）のアプリケーションは既存のメカニズムによって利用される経験則及び政策と比較してより良い適応をもたらすことになる。

既存のワークは我々の設計においてパケット処理モジュールの一部である、多重インターフェースの利用のために適用されるべき送信戦略を単に指定することに焦点を合わせている。先の検討は現在のネットワーク状態及びエンドツーエンド送信品質に関して多様な戦略の中でダイナミック及びインテリジェント適応のより大きな問題を取り扱っていなかった。

既存のワークの大部分は特定のアプリケーション又はトランスポートレイヤ（例えば、ＴＣＰ又はＳＣＴＰ）に焦点を合わせていた。

我々は既存のワークの融合をサポートし、このワークの効率的な融合のために要求された機能的要素の全てを含むフレームワークを提供することによって、我々は、最善の可能な方法で、異なるネットワーク及び送信シナリオの全てを適応することができる。

更に、最適化メカニズム及び収集されたメトリクスに基づく戦略のダイナミック選択はインテリジェント方法でネットワークの現在の状態に適応し、要求されたエンドツーエンドサービスを提供するフレームワークに対する能力を提供する。先行技術は多様なシナリオにおいて適応されるのに充分に多目的にできる方法に拡張するよりも、アプリケーション又はトランスポートプロトコルの多くの制限空間に焦点が合わされていた。

具体的プロトタイプ
具体的及び限定されない実施例では、我々はＩＮＴＥＬｉＣＯＮアーチテクチャのリナックスプラットフォームに基づきプロトタイプインプリメンテーションを作成した。上述したように、ＩＮＴＥＬｉＣＯＮアーチテクチャは種々のモジュールを実行するための多くの可能なオプションに適用できる、一般的及び多目的フレームワークを提供する。このセクションはＩＮＴＥＬｉＣＯＮモジュールに関するインプリメンテーション詳細も提供する我々のラボプロトタイプを示す。その前に、利用サービス及び基底ネットワーク環境についての簡単な説明及び前提を提供する。

その人気及び需要サービス要求により、我々は我々のＩＮＴＥＬｉＣＯＮプロトタイプを評価するためマルチメディアサービスを選択した。我々はユニキャスト又はIPv4又はIPv6のマルチキャストでストリームするためにサーバとして使用し得る、ＶＬＣメディアプレーヤ（例えば、文献１６参照）を導入した。

我々が構築したネットワーク環境は図2に図解されている。我々は２台の活性イーサーネットインターフェースをそれぞれ有する送信機及び受信機装置を使用した。.各対のリモートインターフェースはリンクを介して接続される。遅延及びパケット損失のような各リンクの特性は図２に図解されているようにＮＩＳＴｎｅｔ（例えば、文献１８参照）を実行する２台の装置によって模倣される。

更に、パケット遅延に関するより正確な統計の収集のために、我々は送信機及び受信機装置のクロック同期のためそれらをＮＴＰサーバに接続した。

パケット処理モジュールは多重インターフェースを介してアプリケーションセッションを流さなければならない。これを成し遂げるために、我々はnetfilter/iptables library（例えば、文献１７参照）を用いて、リナックスに基づいてサポートされるＩＰマングル特徴を利用した。ユニキャストＶＬＣストリーミングを利用することによって、送信機からのＵＤＰパケットは受信機のＩＰアドレスの１つに誘導される。アプリケーション（ＶＬＣ）に透過的に、これらパケットはフィルタにかけられ、処理される（即ち、送信先ＩＰアドレスが適正なインターフェースを選択するために変更され、又はパケットが複製され送信される）。受信端では、事前指定ＩＰアドレスから受信されたパケットがＶＬＣアプリケーションに配信される前にフィルタにかけられ、処理される（即ち、ＩＰアドレスフィールドの調整及び再整列）。故に、アプリケーション及び対応するトランスポートレイヤがどのくらいのパケットかに気付かないように送信機と受信端との間のＩＮＴＥＬｉＣＯＭインターリーブが送信され及び配信される。

パケット処理ユニットの一部として、我々はピギーバックを介して性能情報の帯域内通信を実行した。我々はパケット遅延に関する各送信済パケットに事前に特定した余分なペイロードを追加する。このペイロードはパケットが受信され、測定モジュールに送られたときに取り去られる。測定モジュールは制御モジュールによって維持された制御チャネルを介して通信された帯域外メトリクスと共にこれら性能メトリクスを収集し、記憶する。送信機の決定モジュールは実現されるべきコネクティビティ戦略を決定するためにこれらメトリクスを利用できる。

更に、我々は２つのリンクに異なる遅延を導入すると、パケットは不適切なパケットとなるかもしれない。受信でのパケット処理モジュールはアプリケーションに透過的に、処理済パケットを配信する前に複製パケットを検出し、破棄するだけでなく、パケットをバッファし、再整理することに関与する。パケット処理モジュールは現在のところ２つのタイプのコネクティビティ戦略、即ち、代替送信及び重複送信をサポートする。代替送信はラウンドロビン基準（round-robin basis）でパケットを利用可能インターフェースに送信する。故に、２つのインターフェースがあれば奇数パケットは第1インターフェースを介して送出され、偶数パケットは第２インターフェースを介して送出される。

重複コネクティビティ戦略はパケットの複製コピーを作成し、それらを利用可能インターフェースを介して同時に送信する。これら２つのコネクティビティ戦略は２つの一般的なクラスの戦略、即ち、ａ）全アプリケーション帯域がどれか１つのインターフェースが提供できるものより大きい場合のシナリオに使用される、集合戦略、及びｂ）ある種の符号化が信頼できないリンクを介してエラー耐性を改善するために使用される場合の冗長戦略から出現していた。

達成された具体的結果
このセクションでは、我々は更に（図２に示された）我々のラボプロトタイプに行われた単純な実験を示す。この実験では、種々のＩＮＴＥＬｉＣＯＭモジュールが送信戦略をダイナミックに適応し、高ＱｏＳを提供するために相互に作用する。図３はＩＮＴＥＬｉＣＯＭアーチテクチャが変化するリンク信頼性としてコネクティビティ戦略をどのようにダイナミックに適応させたかを示している。この実験のために、我々はパケット処理モジュールの一部として２つの異なる送信戦略、即ち、ａ）代替戦略及びｂ）重複戦略を実行した。前者は単一のフローの送信済パケットを交替方法（例えば、ラウンドロビン）で複数リンクにストリップ化する。後者は同じパケットを複数インターフェースに送信する。実験的プロトタイプのために、我々は２つのリンクを使用し、我々は異なるリンク状態を、リンクエミュレータであるＮＩＳＴｎｅｔのアプリケーションで模倣した。

図３の上部のグラフは受信機で計算された損失メトリックであり、一方、下部グラフは送信機装置によって送られるパケットの数を示している。ビデオストリーミング速度はほぼ１５０パケット／秒である。最初は、両方のリンクは等しく、無損失である。決定モジュールは交互形式で各インターフェースに５０％のパケットを送信することによって分割戦略を実行した。この選択は２つの同等のリンク間のトラフィックを負荷平衡化するためである。戦略のダイナミック選択と名称付けた図３を参照。

最初にゼロ損失率から見て、受信パケットが２つの異なるインターフェースから到来するとしても、受信パケットの数は送信済パケットの数に整合する。ほぼ２７秒で、我々は両方のリンクに５％の損失を導入し、その結果、全体で５％のアプリケーション損失率となる。送信装置は性能フィードバックからより高い損失を知ることになり、制御モジュールを介して受信機装置にも知らせて、重複送信戦略に切換えることを決定する。新たな方式は送信パケットの総数が、アプリケーションが発生するものの現在２倍である場合の下部グラフから分るようにほぼ３０秒で効果がある。同じパケットが両方のリンクを介して送られているのであれば、パケット損失は両方のリンクがパケットを配信しないときだけ生じる。確率的に、結果のパケット損失率は０．２５％である。この著しく減少した損失率は重複方式の活性化後（＞３０秒）に、図３の結果によって証明される。概念インプリメンテーションの立証及びここに示された経験は高ＱｏＳを配信するための送信戦略をダイナミックに及びインテリジェントに適応するためにＩＮＴＥＬｉＣＯＭアーチテクチャのキャパビリティを示している。

具体的利点
ＩＮＴＥＬｉＣＯＭフレームワークは、より良い性能のための複数インターフェース利用の分野における他の方法と比較して、例えば以下を含む多くの利点を示す。

ａ） 特定の送信戦略に焦点を合わせる既存の方法と対比して、ＩＮＴＥＬｉＣＯＭフレームワークは任意の特定の送信戦略を提案するのではなく、これらの異なる戦略の全てが統一化し得るフレームワークを提供する。

ｂ） 既存の方法はそれらが特定のトランスポートプロトコル（例えば、ＴＣＰ，ＳＣＴＰ）を前提としているので限定されたグループのアプリケーションに焦点を合わせているが、ＩＮＴＥＬｉＣＯＭフレームワークはそれが仮定されたトランスポートレイヤを用いるアプリケーションだけに限定されないように、任意のトランスポートレイヤの仮定に依存していないので、この限定に苦慮することはない。

ｃ） ＩＮＴＥＬｉＣＯＭフレームワークは、−性能要求を表す−適正な利用機能を決定モジュールを介して適用することによって送信戦略及びそれらのパラメータを現在ネットワーク及び送信状態に適用する。

ｄ） 制御、測定及びパケット処理モジュールを用いる、ＩＮＴＥＬｉＣＯＭフレームワークは制限されたセットのプローブをサポートする既存のメカニズムに反して、ネットワーク状態及び現在の送信品質に関連する多様なメトリクスの収集をサポートする。

ｆ） 送信戦略を決定するための利用機能及び最適化アルゴリズム（例えば、決定モジュール）のアプリケーションは既存のメカニズムによって利用される経験則及び政策と比較してより良い適応となる。

ｇ） 文献［１１］に記載されたラボ経験では、１つの戦略だけが使用されていたら、送信は低品質のエンドツーエンド送信になってしまっていたであろうが、戦略の適応性は不完全リンクから素早く回復し、シームレスで及び連続する高エンドツーエンド品質となる。

具体的環境及びアプリケーション
幾つかの具体的実施例では、ここに記載された１以上の態様が以下の具体的製品及び／又はサービス内で採用し得る。この発明に基づくミドルウェアは、例えば、スマートフォン、ＰＤＡ及びラップトップを含むマルチモード装置に構築及び実装し得る。このミドルウェアはインターネットを介してマルチモード装置に帯域幅集中サービスを提供するウエブサービスにて実装もできる。１つの実施例として、例えば、YouTube, GoogleVideo, MSNのようなビデオ共有サイト又はその他のストリーミングビデオサイトはそれらのマルチモード顧客のためのサービス経験をより良く管理するためこのソフトウェアを実装できる。この発明はモームビデオ市場において大きな商業的インパクトを持つこともできる。例えば、本発明の実施形態はコンテンツを表示するＴＶに接続される無線メディア受信機にビデオコンテンツを流し込むホームビデオサーバに構築できる。本発明はメディアサーバと受信機との間で提供される無線ビデオ品質及び信頼性を改善できる。本発明はそれが重要情報の冗長配信を行うために使用できる場合にビデオセキュリティアプリケーションに有益でもある。これはフェイルオーバメカニズムを提供することによって信頼性を改善することになる。

幾つかの具体的事例では、本発明の態様は（例えば、一例として、Intel, Motorola, Atheros, Samsungなどのような）無線通信装置製造業者も（例えば、一例として、Cisco, Buffalo, EMC, NetGear, D-Linkなどのような）無線設備業者も、また（例えば、一例として、YouTube, GoogleVideo, MSN Videoなどのような）広帯域幅又はデータ重要サービスを配信するウエブサービスにも関心を向けることができる。

本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適応及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。

Claims (21)

1. 無線装置の多重インターフェースの同時使用のためのインテリジェントコネクティビティフレームワークであって、
   複数の異種無線ネットワークインターフェースを持つ無線装置を具備し、
   前記無線装置はネットワークの状態及び送信の品質に関するメトリクスを発見するように構成され、
   前記無線装置は前記発見メトリクスに基づいて複数の前記多重ネットワークインターフェースの使用を含むインテリジェントコネクティビティ戦略を決定するように構成され、
   前記無線装置はアプリケーションレイヤを変更しないで複数の前記多重インターフェースを同時に介してアプリケーションセッションを流すよう構成される、インテリジェントコネクティビティフレームワーク。
2. 複数のモバイルピア装置に類似のインテリジェントコネクティビティフレームワークを更に含む、請求項１のインテリジェントコネクティビティフレームワーク。
3. 前記無線装置は前記メトリクスに関する情報を収集するための測定モジュールを更に含む、請求項１のインテリジェントコネクティビティフレームワーク。
4. 前記測定モジュールはリモートピアモバイル装置を含むリモート情報源からのメトリクスを収集するように構成される、請求項３のインテリジェントコネクティビティフレームワーク。
5. 前記モバイル装置は制御チャネルを介してリモート情報源からメトリクスを受信するように構成される、請求項４のインテリジェントコネクティビティフレームワーク。
6. 前記測定モジュールは局所情報源からのメトリクスを収集するように構成される、請求項３のインテリジェントコネクティビティフレームワーク。
7. 前記測定モジュールはリンク品質及び／又は利用可能帯域幅に関するネットワーク性能メトリクスをモニタ及び／又は精査するように構成される、請求項６のインテリジェントコネクティビティフレームワーク。
8. 前記無線装置は前記測定モジュール内の前記メトリクスに関する情報に基づいて多重インターフェースを採用する戦略を決定する決定モジュールを更に含む、請求項３のインテリジェントコネクティビティフレームワーク。
9. 前記決定モジュールは前記情報に基づいて品質及び／又はネットワーク状態を連続的に評価し、リアルタイムで前記戦略をダイナミックに適応させる、請求項８のインテリジェントコネクティビティフレームワーク。
10. 前記決定モジュールはネットワーク環境情報、サービス品質情報、及び送信戦略のコストに基づいて多重インターフェースを採用する戦略を決定するように構成される、請求項８のインテリジェントコネクティビティフレームワーク。
11. 前記決定モジュールは最適化アルゴリズムに基づいて決定する、請求項１０のインテリジェントコネクティビティフレームワーク。
12. 前記無線装置は前記決定モジュールによって決定された戦略を実施するパケット処理モジュールを更に含む、請求項８のインテリジェントコネクティビティフレームワーク。
13. 前記パケット処理モジュールはリンク速度における差を決定づけるように構成される、請求項１２のインテリジェントコネクティビティフレームワーク。
14. 前記パケット処理モジュールは受信パケットをバッファするように構成される、請求項１３のインテリジェントコネクティビティフレームワーク。
15. 前記パケット処理モジュールは送信済パケットと状態情報をピギーバックすることによって性能情報を交換するよう構成される、請求項１３のインテリジェントコネクティビティフレームワーク。
16. 前記無線装置は前記送信戦略に関する情報を交換するため前記制御チャネルを管理する制御モジュールを更に含む、請求項５のインテリジェントコネクティビティフレームワーク。
17. 帯域内及び帯域外の両方の前記メトリクスに関する性能情報を通信するように構成される、請求項１のインテリジェントコネクティビティフレームワーク。
18. 帯域内情報は送信ピアとしての前記無線装置によって送信済ペイロードパケットにピギーバックし、前記パケットを前記アプリケーションに配信する前に受信ピアでそのような情報を回復することによって通信される、請求項１７のインテリジェントコネクティビティフレームワーク。
19. 帯域外情報は前記無線装置と他のピアとの間の専用制御チャネルを介して通信される、請求項１７のインテリジェントコネクティビティフレームワーク。
20. 前記送信機の側で前記無線装置と他のピアとの間での通信中に、測定、早期化データ及び性能メトリクスが測定及び決定モジュールに送られ、前記受信機の側で、制御データが前記パケット処理及び測定モジュールに配信される、請求項１９のインテリジェントコネクティビティフレームワーク。
21. 無線装置の多重インターフェースのインテリジェント管理及び同時使用のための方法であって、
    複数の異種無線ネットワークインターフェースを持つ無線装置を提供することを含み、
    前記無線装置はネットワークの状態及び送信の品質に関するメトリクスを発見し、
    前記無線装置は前記発見メトリクスに基づいて複数の前記多重ネットワークインターフェースの使用を含むインテリジェントコネクティビティ戦略を決定し、
    前記無線装置はアプリケーションレイヤを変更しないで複数の前記多重インターフェース同時に介してアプリケーションセッションを伝える、方法。

Images