仮想チャネル結合

著者らは特許

H04L1 - 受信情報中の誤りを検出または防止するための配置
H04W74/02 - ハイブリッドアクセス技術
H04W76/00 - 接続管理,例.接続の設定,解除または接続中制御
H04W88/06 - 複数のネットワークでの運用に適応したもの,例.マルチモード端末

の所有者の特許 JP2016517647:

オープン・ガーデン・インコーポレイテッド

 

多重チャネルを使用してインターネットとの接続を確立するための方法。デバイスは、利用可能ないくつかのチャネルを内部において、および/またはウェブページの様々なリソースを要求するための隣接するデバイスから利用し、異なるチャネルから来るリソースを使用してウェブページを組み立てる。デバイスは複数の内部チャネルを使用してインターネットに接続する能力があるとき、デバイスは、これらのチャネルを使用してウェブページリソースを要求するために内部ヒューリスティックを使用する。クラウド出口サーバは、セキュリティを強化し、多重チャネルを使用して扱われないかもしれない要求を扱うために使用され得る。

 

 

本出願は、2013年3月4日に出願した米国仮出願第61/772489号の優先権に関連し、主張する、参照により本明細書に組み込まれている2013年7月17日に出願した米国出願第13/944756号の優先権に関連し、主張するものである。
本開示は無線接続に関連し、特に多重チャネルを使用して接続を確立することに関連する。
様々な有線および無線技術が、インターネットなどのネットワークにアクセスするために利用可能である。例えば、最新式のスマートフォンは、3G、4G、Wi-Fi、および同様の無線技術を使用してインターネットにアクセスできる。さらに、無線技術は、2個以上のデバイスの間で相互接続を可能にする。そのような技術は、近距離無線通信(NFC)、Wi-Fi Direct、ブルートゥース、およびその他を含む。
テザリングは、一般に、主に科学技術に精通したユーザによって利用される「ギーク特徴」の分野に収まるように、重要なユーザの関与と知識を必要とする接続手順である。テザリングは、Wi-Fiあるいは他のインターネット接続が利用できないとき、セルラーネットワークを通じてインターネットへのアクセスを得るために、コンピュータを携帯電話に接続するのに大抵使用される。テザリングを確立させる際にユーザの関与が必要なことに加え、様々な通信業者や電話メーカーは、テザリングに対して阻止手段を設けており、このことが、Androidデバイスのルーティング、iOSデバイスのジェールブレーキング、およびテザリングアプリケーションのデバイスへのインストールなど、迂回のための「創意工夫」へと導いている。
一般に、アプリケーションがインターネットへのアクセスを必要とするとき、デバイスは、利用可能なチャネルのうちの1つ、例えばWi-Fiを選択し、選択されたチャネルのアプリケーションに必要とされる全ての通信を実行する。例えば、スマートフォンのブラウザがあるページを要求すると、そのページ用のリソースの全てが要求されて1つのチャネル、例えばWi-Fiにおいて受け取られるが、例えば4G等、他のチャネルも利用可能である。
また、単一の場所においていくつかのデバイスが存在し、各々が異なる通信業者を利用して、その結果、異なるレベルのサービスを受けるように、異なるデバイスが異なる通信業者を利用し得る。
以下の発明の概要は、発明のいくつかの態様および特徴の基礎的理解を提供するために含まれる。この概要は発明の広範な全体図ではなく、特に発明の主要あるいは重要な要素を特定すること、または発明の範囲を叙述することを意図しない。唯一の目的は、発明のいくつかの概念を以下に提示される詳細な説明への前置きとして簡易な形で提示することである。
様々な開示された実施形態は、多重チャネルを用いてインターネットとの接続の確立するための方法を提供する。デバイスは、利用可能ないくつかのチャネルを内部において、および/またはウェブページの様々なリソースを要求するための隣接するデバイスから利用し、異なるチャネルから来るリソースを使用してウェブページを組み立てる。実施形態は、例えばスマートフォンやタブレット等のモバイルデバイス上で動作するアプリなど、デバイス上で動作するクライアントとして実装され得る。簡略表記として、本明細書において、このクライアントは時々オープンガーデンアプリと表記され得る。オープンガーデンアプリは、他のアプリに沿ってモバイルデバイス上で動作し、モバイルデバイス上で実行する他のアプリを監視する。アプリが外部デバイス、例えばインターネット上のサーバと通信を試みるとき、オープンガーデンアプリは通信要求を遮り、その要求を外部デバイスに送る最も良い方法を決定する。また、オープンガーデンアプリは外部デバイスから来る通信を遮り、その通信を内部に送るか否かを決定し得る、すなわち、どのアプリにその通信を転送するか、あるいは別の外部デバイスに送る必要があるか否かを決定し得る。
デバイスは複数の内部チャネルを使用してインターネットに接続する能力があるとき、デバイスは、これらのチャネルを使用してウェブページリソースを要求するために内部ヒューリスティックを使用する。例えば、スマートフォンデバイスは、セルラーネットワーク無線とWi-Fi無線を有する。しかし、慣習的に、スマートフォンは、インターネットに接続してウェブページリソースを要求するために、これらのチャネルのうちの1つだけを使用する。開示された実施形態によると、スマートフォンは、ウェブページリソースを要求して、次いで、両方のチャネルを通じて受け取られたリソースを用いてウェブページを組み立てて表示するために、これらのチャネルの両方を使用する。
また、他の実施形態によると、デバイスは、他のデバイスを使用してウェブページリソースを要求し、その結果、多重チャネルを利用し得る。例えば、1つのスマートフォンデバイスは、別のスマートフォンデバイスとブルートゥース接続し得る。第1のスマートフォンは、ウェブページリソースを要求するために、自身の内部チャネル(例えば、セルラーやWi-Fi)を利用し得るが、第2のスマートフォンチャネルを使用して他のウェブページリソースを要求するために、第2のスマートフォンとのブルートゥース接続も使用し得る。
いくつかの実施形態によると、モバイルデバイスは、自身に固有のIPアドレスを使用する各チャネルを有することによってウェブページリソースを要求するために様々なチャネルを利用する。要求されたウェブページリソースは、全てが要求側デバイスに通じる各要求側IPアドレスに返される。次いで、要求側デバイスは、返されたリソースを使用してウェブページを組み立てる。一方、例えば安全なページ(https:)のための他の実施形態によると、対象デバイスは、要求が単一のIPアドレスから発せられたとみなす必要がある。それを達成するために、クラウド出口サーバはインターネットと接続される。全てのモバイルデバイスチャネルからの全ての要求は、クラウド出口サーバに送られる。クラウド出口サーバは、単一のIPアドレス、すなわち、クラウド出口サーバ自身のアドレスを使用して、適切なホストに要求を転送する。このように、対象ホストの視点からは、要求の全てが単一のIPアドレス、すなわち単一の装置から来る。このように、ホストは、クラウド出口サーバIPアドレスである要求側IPアドレスに、要求されたリソースを返す。次いで、クラウド出口サーバは、受け取ったリソースを適切な要求側IPアドレスに転送する。このように、モバイルデバイスの視点からは、多重チャネルを用いて要求は送られ、リソースは受け取られる。
様々な開示された実施形態は、より高い信頼度と帯域幅を供給するために、インターネットへのマルチパスアクセスを可能にする。さらに、様々な実施形態は、構成選択の削除を可能にし、ユーザは、デバイスが単純に複数の方法を同時に使用するので、もはやどのようにデバイスがインターネットに接続するかを選ぶ必要はない。さらに、デバイスは自動的に、インターネットへの利用可能なパスを見つける。例えば、パスが失敗すると、新しいものが選ばれ、新しい接続が確立される。その結果、ネットワークは、自己回復型および自己形成型となる。ノードはそれぞれ、局所的知識のみで動作するが、接続されたデバイスは、確率分散アルゴリズムを用いてネットワークを一緒に構成する。直接的なインターネット接続がないとき、メッシュネットワークを使用して、デバイスは他のデバイスの連鎖を通してインターネットにアクセスする。必要であれば、連鎖は、インターネットに達するように他のデバイスに接続することによって大きくなる。説明された実施形態は、デバイスを構成せずに、あるいはフープを通してジャンプせずに、ユーザが最も適切な接続を使用してインターネットにアクセスすることを可能にする。また、実施形態は、ユーザがインターネットにできるだけ安くアクセスすることを可能にする。ユーザは、利用可能なネットワーク毎に、確認することなく最も速い接続および最も強力な信号を見つけることができ、ネットワーク間をシームレスに移動できる。実施形態は、より多くの位置において、より速い速度で、より多くのデータにアクセスするための方法を提供する。ユーザはネットワークの一部となり、ベストで可能なアクセスを提供する時間と場所を備えた接続を共有する。これにより、より高品質のストリーミングビデオおよびオーディオ、より即時性のマルチプレイヤーゲーム、およびより速いダウンロードがもたらされる。
本明細書の一部に含まれ、および本明細書の一部を構成する添付図面は、本発明の実施形態を例示し、また、説明と共に本発明の原理を説明し、図示するのに役立つ。図面は、模範的な実施形態の主要な特徴を図表方式で示すことを意図する。図面は、実際の実施形態のあらゆる特徴や表現された要素の相対寸法を表現するように意図されるものではなく、また縮尺に合わせて描かれていない。
1つの実施形態に従って、複数の内部チャネルを使用してウェブリソースを要求するモバイルデバイスを示す概略図である。 1つの実施形態に従って、複数の外部のチャネルを使用してウェブリソースを要求するモバイルデバイスを示す概略図である。 1つの実施形態に従って、複数の外部チャネルおよびクラウド出口サーバを使用してウェブリソースを要求するモバイルデバイスを示す概略図である。 1つの実施形態に従って、複数の内部および外部チャネルを使用してウェブリソースを要求するモバイルデバイスを示す概略図である。 1つの実施形態で実行され得る処理フローの例を示す概略図である。 1つの実施形態従って、クラウド出口サーバによって実行され得る処理フローの例を示す概略図である。 本明細書に開示された様々な実施形態に従って、複数の接続を操作するための環境の例を示す。 本明細書に開示された様々な実施形態に従って、いくつかのデバイスが多重チャネルを利用する、メッシュネットワークの例を示す。 本明細書に開示された様々な実施形態に従って複数の接続を操作するための環境であって、クラウドルートオラクルサーバを含む環境の例を示す。
下記は、いくつかのチャネルを並列に利用してインターネット通信を確定するための方法およびシステムの例を提供する。
仮想チャネル結合は、1つ以上のインターネット接続が可能であるとき、コンピュータ、スマートフォン、タブレット、または別のデバイスのインターネット接続の信頼度、速度、および可用性の強化を可能にするコンピュータネットワーキング技術である。特定のデバイス自体は利用可能な複数のインターネット接続を持ち得る、あるいは、各デバイスは1つの接続を持ち得るのみであるが、インターネットにまとめてアクセスし、メッシュネットワークを経由して局所的にネットワークでつなぐことによって、デバイスは仮想チャネル結合を達成する。仮想チャネル結合は、必要としないが、性質あるいは仕様を変えるために何らかのネットワークデバイス(スイッチやルータなど)から利益を得ることがあり、それゆえ配備するのは容易である。しかしそれは、コンピュータ、スマートフォン、タブレット、スマートテレビ、または他のデバイス等のエンドシステムとともにネットワークデバイスで採用できるので、より大きいスケールでインターネットの接続性を大きく改良するために使用され得る。また、仮想チャネル結合は、ローカルネットワーク上のデバイス間通信の既存手段を向上させることができ、またはそのための単独手段を提供できる。
先行技術では、各対応デバイスが自身のリソースを使用してインターネットにアクセスする。インターネット接続が失敗のとき、デバイスは、接続を再確立するか、あるいは別の接続を発見し、確立するまでインターネットにアクセスできない。そのようなデバイスは、インターネットと接続して通信するための単一チャネルを利用する。例えば、4G対応スマートフォンは、4G接続を用いてインターネットと接続して通信する。しかし、スマートフォンがWi-Fi接続に発見して接続する場合、スマートフォンは、4G接続ではなく、Wi-Fi接続を用いてインターネットと接続して通信する。すなわち、Wi-Fi接続が利用可能であれば、デバイスは全てのインターネット通信にそのチャネルを使用する。しかし、その特定のチャネルが遅いことがある、または内部的あるいは外部的に利用可能な他のチャネルがより良い信頼度を提供し得る。さらに、多重チャネルでの並列通信は、インターネット通信の速度と信頼度を高めることができる。
このような状況において、メッシュネットワークは、デバイス間で直接アドホックリンクを通して確立されたネットワークであり、メッシュネットワークを含むデバイス間で局所的に通信するために使用できる。ある例において、メッシュネットワークはインターネット上のサーバによって調整できる。開示された実施形態によると、仮想チャネル結合は、デバイス間の追加接続を確立する手段の1つとしてメッシュネットワーキングを利用して、追加チャネルをインターネット接続および通信に提供できる。このため、メッシュネットワークは、イーサネット(登録商標)等の有線接続から、アクセスポイントあるいはアドホックモードにおけるWi-Fi、Wi-Fi Direct、ブルートゥース、ZigBee、NFC、3G技術、またはLTEやWiMAX等の様々な4G技術の無線までの、ピアツーピアあるいはローカル接続を確立するために、いかなる物理的な媒体も使用できる。基本的な技術の正確な性質は仮想チャネル結合によって考慮され得るが、いかなる基本的なネットワーキング技術も使用できる。また、切断されることがあっても、定義上、メッシュネットワークのいかなる組合せもメッシュネットワークであることに留意する。
図1は、スマートフォンやタブレット等の通信装置100が、無線接続112を使用するWi-Fi110を用いて、あるいは3G、4G、LTE、または同様のもの等のプロトコルを使用するセルラーネットワーク105を用いて、インターネット115とつながるサーバ120と通信する能力を有する実施形態を示す。例えば、セルラーネットワーク105は無線通信の標準無線電話システムであり得るが、Wi-Fiアクセスポイント110は、例えばケーブルあるいは地上電話回線を経由してインターネットに接続された無線ルータであり得る。一般に、そのような通信は、利用可能な接続107か112のどちらかを使用して実行される。ほとんどのモバイルデバイスに関して、Wi-Fiアクセス112が利用可能である場合、サーバ120との全ての通信はWi-Fi接続上にある。例えば、スマートフォンがWi-Fiルータの存在を検出すると、スマートフォンがWi-Fiルータを認識する場合、スマートフォンはWi-Fiルータに自動的に接続することがあり、また、スマートフォンがWi-Fiルータを認識しない場合、接続するか否かをユーザに尋ねることがある。一方、Wi-Fi接続112が利用可能でない場合、セルラー接続107は次いで、全ての通信、例えば音声やデータに使用される。この配置の理由の1つは、サーバ120がだれと通信しているかを「知る」ように、インターネットへの接続がIPアドレスを必要とするからである。このように、標準TCP-IPは、デバイス100が単一接続のみ、すなわちセルラー接続107あるいはWi-Fi接続112を介してインターネットと通信することを制限する。この制限は、以下で説明されるように、軽減される。
図1の実施形態において、デバイス100のプロセッサは、セルラーチャネル107とWi-Fiチャネル112の両方を用いてインターネットおよびサーバ120と通信することを可能にする特殊命令(例えば、クライアントアプリ)を実行する。例えば、デバイス100上のブラウザがサーバ120からウェブページのダウンロードを試みるとき、プロセスは、例えばテキスト、画像、Java(登録商標)スクリプト、および他のリソースなど、ウェブページを含む様々なリソースに対する要求を繰り返し送ることを伴う。しかし、先行技術で行われているように、単一チャネルを使用して要求の全てを送るより、プロセッサは、チャネル107と112の両方を使用して様々な要求を送るための割り当て機構を利用する。要求がサーバ120に到着するとき、サーバは2つの異なるIPアドレスから要求を得るが、サーバ120が接続されている限り、これは無関係である、つまり、サーバは単に、各要求されたリソースを特定の要求側アドレスに送る。リソースがデバイス100に到着すると、それらは一緒にキャッシュされて、組み立てられ、要求されたウェブページを形成する。すなわち、デバイス100のプロセッサは、両チャネルに到着したリソースの全てが送られた要求と関連し、ともに要求されたウェブページを含むことを理解している。
どのチャネルでどの要求を送るかを選択する限り、発呼101によって例示されるように、様々なアルゴリズムあるいはヒューリスティックを採用できる。例えば、各要求が前の要求と異なるチャネルで送られるように、簡単なものはチャネル間で交互に切り替えることである。別の例は、各チャネルの動作速度を考慮して、動作速度に応じて要求を送ることである。一例において、画像やビデオ等の重いリソースに対する要求は、高速チャネルを通じて送られる一方、テキストなどの軽いリソースは、より遅いチャネルを通じて送られる。別の例によると、各チャネルのサービスコストは考慮される。例えば、重いリソースは、より安いチャネルを通じて要求される一方、軽いリソースは、より高価なチャネルを通じて送られる。
図1の実施形態において、リソースを要求して他のデバイスから受け取るが、リソースをいかなる他のデバイスにも送らない点で、デバイス100はエンドシステムである、すなわち、いかなる他のデバイスのための媒介あるいはインターネットアクセスポイントとして機能しない。これは実施形態の要件ではないが、説明が容易になる。以下の説明の大部分では、そのような例は、説明を簡単で明確にするために利用される。しかし、要求側デバイスは、常にエンドシステムである必要はない。むしろ、デバイスは自身のためにウェブリソースを要求することがあるが、メッシュネットワークにおいて他のデバイスに中継するためにウェブリソースを要求することもある。
図1のシステムでは、モバイルデバイス100が内部チャネルを使用しインターネットと直接通信する。しかし、時々、モバイルデバイスの内部チャネルを使用しての通信が可能でない、あるいは望ましくないことがある。例えば、海外旅行の間、インターネットと直接通信するためにモバイルデバイス100を使用することは非常に高価であり得るか、あるいはサービスプロバイダの契約の範囲を超え得る。この問題は、図2Aに示す実施形態を採用することによって軽減される。
図2Aにおいて、モバイルデバイス200は、インターネットとの直接接続なしで、ウェブリソースを要求してサーバ220から受け取る。例えば、デバイス200は、ローカル無線プロバイダネットワークとの接続が不可能あるいは望んでいない、外国を旅行しているユーザのスマートフォンであり得る。それゆえ、本実施形態において、モバイルデバイス200は、例えばブルートゥース、NFC、および同様のプロトコルを用いてデバイス201および202とのメッシュネットワークを確立するために、ピアツーピア接続を利用する。説明の目的のために、2つのブルートゥース接続が示され、1つはデバイス200をデバイス201に接続させ、もう1つはデバイス200をデバイス202に接続させる。デバイス200はピアツーピア接続を用いて、それぞれが自身のIPアドレスを使用してウェブリソースを要求し、受け取ったリソースをピアツーピアネットワーク上で発信デバイス200に転送するようにデバイス201および202のプロセッサに命令する。
図2Aの概要において、実線は物理層接続を示し、破線はデータ通信を示す。このように、デバイス200は、物理層と、両デバイス201および202とのデータ通信の両方を有する。図2Aの特定の例において、両方の接続はブルートゥース接続として識別されるが、他のピアツーピアプロトコルが使用され得る。逆に、図2Aの特定の例において、デバイス201は4Gセルラーネットワークを使用してインターネットと通信する一方、デバイス202はWi-Fi接続でインターネットと通信する。
図1の例のように、デバイス200は、どのデバイスを経由してどの要求を送るかを決定するために、様々な規約あるいはヒューリスティックを使用し得る。例えば、デバイス200は、メッシュネットワークにおける各デバイスの応答時間、およびそれに関する帯域幅を測定することができ、要求を割り当てる際にこの情報を利用できる。また、メッシュネットワークにおける各デバイスは、帯域幅コストを伝達することがあり、要求側デバイスは、ウェブリソース要求の割り当てを決定する際にその情報を使用することがある。例えば、デバイス200は、通信する各ピアのコストおよび接続速度を列挙するテーブルを維持し、どのピアを各発信要求に使用するかを決定するために、そのテーブルを使用し得る。
図1および2Aの実施形態は、サーバ120あるいは220が異なるウェブアドレスから異なるウェブリソース要求をサービスできると仮定する。しかし、ある状況において、これは可能ではない。例えば、https等の暗号化された要求、あるいはSkype(登録商標)等の瞬時の通信の要求は、単一のIPアドレスを使用して扱われなければならない。図2Bの例は、サーバ220が単一のIPアドレスを使用して要求を出さなければならない状況において、デバイスが多重チャネル上でどうウェブリソース要求を送ることができるかを示す。
図2Bの例において、デバイス200は、デバイス201および202でメッシュネットワークを形成し、インターネット、例えば、サーバ220からリソースを得るためにそれらのデバイスを使用する。しかし、この特定の例では、2つの異なるIPアドレスを使用して要求をサービスすることは可能ではない。従って、この例において、クラウド出口サーバ222は、要求を受け取り、単一のIPアドレスを用いて、その要求を対象デバイス、例えば、サーバ220に中継するために使用される。対象デバイスが、クラウド出口サーバ222の単一のIPアドレスを使用して、要求されたリソースをクラウド出口サーバ222に返すと、クラウド出口サーバ222は、要求が到着したIPアドレスか他のチャネルのどちらかを経由して発信デバイス200に応答を送る。
一例では、デバイス200のプロセッサは、ウェブ要求を操作するための命令を実行する。この例では、これは、本明細書においてオープンガーデンと呼ばれるアプリケーションを実行するデバイス200によって達成される。オープンガーデンがリソースを要求するためのプロトコルを把握して、複数のパスを経由して要求を送ることができる全ての場合において、図1および2Aの例に示されるように、デバイス200は利用可能なチャネルを使用して要求を送る。一方、オープンガーデンがプロトコルを把握していない、あるいはプロトコルを理解しているが、要求を多重チャネルに分割できないとき、要求をカプセル化してクラウドの出口に送る。要求が単に中継デバイス、例えばデバイス201と202のどちらかからクラウド出口サーバ222のIPアドレスに送られることを必要とし、これらのデバイスは単に要求をそのIPアドレスに要求するということなので、デバイス200は選んだ任意のチャネルを経由して要求を送ることができる。
オープンガーデンアプリケーションで実行され得る処理フローの例を図2Dに示す。ステップ281において、プロセスは新しい要求を定期的に確認する。ステップ282では、要求が受信されると、プロセスが要求の解読を試み、成功の場合、プロセスは要求を送るためのチャネルを選択するためにステップ283に進む。適切なチャネルが選ばれると、ステップ284において要求が送られる。逆に、要求を解読できない場合、プロセスはステップ285に進み、そこで要求はカプセル化され、ステップ286において、クラウド出口サーバ222のアドレスが要求に適用される。次いで、プロセスはステップ283に進んでチャネルを選択し、ステップ284においてカプセル化された要求が送られる。
クラウド出口サーバ222が要求を受け取ると、それをデカプセル化し、発信および対象デバイスのアドレスが何であるかを決定する。受け取られたパケットが部分的な要求にすぎない場合、クラウドの出口は全てのチャネルから受け取られた全てのパーツから要求を組み立てる。クラウドの出口に完全な要求があると、それを対象宛先デバイス、例えば、サーバ220に送る。その宛先デバイスは、クラウド出口サーバアドレスを発信アドレスとして有する要求を受け取る。このように、対象デバイスはクラウド出口サーバ222に応答を送る。クラウド出口サーバ222が応答を受け取ると、デバイス201および202等の中間要求側デバイスを経由して、あるいは選んだ任意の他の適切なチャネルを経由して発信デバイス200にそれを中継する。すなわち、クラウド出口サーバ222は、要求がどこから発せられたかを認識しているので、任意の利用可能なチャネルを用いて応答を送ることができる。
クラウド出口サーバ222によって実行され得るプロセスの例を図2Eに示す。ステップ291において要求が受け取られた後、プロセスはステップ292に進み、受け取られた要求が部分的な要求であるか完全な要求であるかを確認する。完全な要求であれば、ステップ293において、対象サーバ220のアドレスが要求に適用され、次いでステップ294において送られる。一方、要求が部分的な要求にすぎなければ、ステップ295において、残りの要求は受け取られ、296において、完全な要求が組み立てられる。次いで、プロセスはステップ293に戻り、対象のアドレスを適用し、294において要求を送る。
このように、例えば、デバイス200が、クラウド出口222のIPアドレスを宛先として用いて、デバイス201を経由して要求1を送り、また、クラウド出口サーバ222のIPアドレスを宛先として用いて、デバイス202を経由して要求2を送る場合、デバイス201および202は、クラウド出口サーバ222のIPアドレスを用いて要求を中継する。クラウド出口サーバ222が要求1および2を受け取ると、それらをデカプセル化し、発信デバイスがデバイス200であり、対象デバイスがサーバ220であることを発見する。それゆえ、自身のIPアドレスを要求発信元として用いてサーバ220に要求を中継する。対象サーバ220が、クラウド出口222のIPアドレスを発信元と有する要求1および2を受け取ると、クラウド出口サーバ222のIPアドレスに応答1および応答2を送ることによって要求1および要求2を満たす。クラウド出口サーバ222が応答1および応答2を受け取ると、要求がデバイス200から発信されたことを認識するので、必ずしもデバイス201および202を経由せず、任意の利用可能なチャネルを用いて応答をデバイス200へ中継することができる。
上記で説明されたように、デバイス200は自身の多重チャネルを使用してインターネットにアクセスすることができる。また、デバイス200は、複数の接続されたデバイスのチャネルを使用してインターネットにアクセスすることができる。すなわち、デバイス200は、同時にこれらの方法の両方、すなわち内部チャネルの使用および接続されたデバイスの使用を利用し得る。図2Cは、デバイス200がセルラーネットワーク105およびWi-Fiデバイス110を経由してインターネットと接続するために内部チャネルを利用し、また、メッシュネットワークに接続された2つのデバイス201および202を用いてインターネットに接続する例を示す。さらにまた、デバイス201および202のそれぞれは、インターネットに接続するために多重チャネルを利用することがあり、デバイス200も同様にそれを利用することがある。例えば、図2Cは、セルラーネットワークを経由して、および同じWi-Fiアクセスポイント110(同じくらい容易に別のWi-Fiアクセスポイントを使用できたが)を経由してインターネットに接続するデバイス202を示す。
図3は、本明細書に開示された様々な実施形態に従って複数の接続を操作するために環境の例を示す。図3は、多くのメッシュネットワークにおいて相互接続された多くのデバイスを含み得る、全体環境の非常に小さな部分の説明図である。例えば、デバイス300、301、および302は、他のデバイスを有する1つのメッシュネットワークと接続される一方、デバイス303および309は別のメッシュネットワークにおいて相互接続される。デバイス300は、セルラータワー305と通信するためにセルラートランシーバを使用し、同時にモバイルデバイス308と通信するために第2のトランシーバ、例えばブルートゥーストランシーバを使用する。モバイルデバイス308はWi-Fiデバイス311を経由してインターネットに接続されるので、デバイス300は、インターネットサーバ、例えばサーバ320および321と通信するためにこの接続を使用し得る。さらに、クラウド出口サーバ322は、例えば、暗号化された、あるいはVOIPトラフィック等の複数の接続を用いて通常扱うことができないトラフィックをサービスできる。このように、デバイス300は、セルラーネットワークを経由して直接インターネットと通信するために1個のチャネルを利用し、モバイルデバイス308を通してWi-Fiデバイスと接続するために第2のチャネルを利用する。一方、デバイス302は、3個のチャネル、つまり、1個のセルラーチャネル、1個のWi-Fiチャネル、およびデバイス304との接続を通じた1個のチャネルを使用する。
ここまで説明されたように、仮想チャネル結合は、いくつかの技術を通じて、デバイス間のネットワーク結合およびデバイスのインターネット接続の速度、信頼度、および有用性を改良する。可能であれば、仮想チャネル結合は、互いにアクセスするか、あるいはインターネットに一緒にアクセスする全てのデバイスを接続するために、メッシュネットワーキングを使用し得る。特に、ここまで説明された仮想チャネル結合は、インターネット接続を持たない環境、あるいは持つことにかかわらず有益である。例えば、図4は相互接続した複数のデバイス400-409を表す環境を示し、少なくともいくつかのデバイス、例えば、デバイス401-409は多重チャネルを利用する。このように、このメッシュネットワークにおけるあらゆるデバイスは、1個以上のパスを使用して別のデバイスと通信できる。これは、例えば、ソーシャルネットワーク設定、デバイス間のダイレクトチャッティングおよびテキスティング、および他の可能なアプリケーションにおいて役立つ場合がある。もちろん、ネットワークにおける1つのデバイスがインターネットにアクセスするとすぐ、他の相互接続した全てのデバイスのための、インターネットへのゲートウェイとして機能し得る。
本明細書に記載されるように、仮想チャネル結合のための方法において、何らかの性質を把握するために通信トラフィックが分析され得る。すなわち、慣習的にプログラムが特定のOSI層上でトラフィックを対処して、より高い、あるいはより低いOSI層で起こるものに気づかない一方、本発明の実施形態ではトラフィックを分析して、どのOSI層を使用するかについての決定を行う。詳細には、その方法では通信の性質を見て、そのレベルで扱う。例えば、その方法では、ウェブ(HTTP)要求、DNS要求、ビットトレントトラフィック、およびHTTPS要求を検出し、特定の要求に最も効率的な方式で各要求を扱い得る。あるトラフィックが解読可能でなく、分類されないままであり得るが、通常、できるだけ多くのトラフィックを分類することは有利である。その理由は、より高いOSI層上で要求を出すことは、通常、より良い性能をもたらすからである。
以下は、トラフィックの分析および分類が仮想チャネル結合を利用することによってどう通信を促進できるかについてのいくつかの例である。第1の例は、要求が冪等であると決定される時である。例えば、GET要求などの通常冪等であるHTTP要求を検出すると、システムは再試行を試みるか、あるいは複数経路上で冗長な照会を送ることさえできる。このような場合、要求は、異なるチャネルあるいは異なるパス上で同時に複製して送られ得る。また、ある時間で応答が受け取られない場合、要求はまだ失敗していないかもしれないが、同じあるいは異なるチャネルで要求を再び送ることができる。要求が冪等であるので、サーバにとって複数の要求を受け取ったことは重要ではない。一方、2つの応答が受け取られる場合、後に受け取られたものを捨てることができるように、それらは同一であると保証される。また、この実装がデフォルトチャネルと呼ばれる単一チャネルだけを使用して動作するモバイルデバイスより信頼度が低いことを確かめるために、その方法では、他のチャネルに加えてデフォルトチャネルを使用して第1の要求を送ることを試みる。
別の例では、要求が、例えばウェブあるいはDNS要求であると決定される場合、適切な応答が、発信あるいはメッシュネットワークデバイスのキャッシュメモリに既に用意されてあり得る。キャッシングを使用すると、ネットワーク使用およびローディングの速度において中程度からかなりの程度までの低減が可能となる。DNS要求のために、システムはキャッシングの追加層を提供し、それらが1つのIPパケットで到着しなくても、同様にいくつかのユニットとしてうまく送ることができる。
1つの特定の例を提供するために、2人のユーザが互いの近くにいて、彼らのモバイルデバイスが本明細書に記載された実施形態の1つに従ってクライアントアプリケーションを実行する場合、各デバイスは、少なくとも自身のセルラーネットワーク接続、自身のWi-Fi接続、メッシュネットワーク、互いのセルラーおよびWi-Fi接続を使用して通信できる。そのような場合、両方のユーザが、例えばフェイスブックに進むと決める場合、フェイスブックスタイルシートはいつも同じであるので、両方のデバイスがそれをダウンロードする必要は全くなく、異なるユーザにとって、内容のみ異なる。このように、第1のデバイスがフェイスブックスタイルシートをダウンロードすることができるとき、それをキャッシュメモリに保存することができ、また、第2のデバイスがフェイスブックスタイルシートを要求するとき、実際にフェイスブックサーバに要求を送るよりもむしろ、もう一方のデバイスのキャッシュからそれが送られ得る。
上記のフェイスブックの例において、トラフィックの減少に小さな利得がある。しかし、メッシュネットワークにおける多くのユーザ間に何らかの話題の相関関係があるとき、はるかに大きな利得が結果として生じ得る。例えば、同じプレゼンテーションスライドを見ることを望む会議における多くのユーザ。あらゆるユーザがプレゼンテーションをダウンロードするよりも、1個あるいは2、3個のデバイスのみ、プレゼンテーションをダウンロードし、キャッシングを使用してメッシュネットワークにおける他のデバイスにプレゼンテーションを渡すことができ、従ってネットワークトラフィックの量を大幅に減少させる。
DNS要求がほとんどいつも冪等であることに留意する。それゆえ、応答がキャッシュの中に存在していない場合、システムは、上記で説明された解読要求を扱う方法を用いてDNS要求を扱うことができる。また、DNS要求が小さいので、冗長なDNS要求を送るオーバヘッドは幾分低いが、利益が幾分高くなるように、利益がよりロバストな操作においてあり得る。
通常、不明瞭で暗号化されたトラフィックは、システムによってIP層上で処理される、あるいは、HTTPSトラフィックに対してはTCP層上で処理される。トラフィックは通常IP層においてシステムに導入されるが、単にIP層上でそのようなトラフィックを送る先行技術と異なり、その方法は、異なる層を使用することが有益であるか否かを確認するためにトラフィックを分析する。メッシュネットワークはしばしば比較的高い非混雑性パケットロスを有する媒体で動作できるので、IPパケットのストリームよりむしろバイトストリームとしてTCP層でさえ処理することは、実際には大幅なパフォーマンスの改善につながり、このように、TCP接続のパフォーマンスは、IPパケットストリームとして扱われる場合、メッシュネットワーク上のパケットロスによって制限され得る。
一般に、システムは、いくつかの層上で、つまり、パケットが受け取られて転送されるIP層、バイトストリームが受け取られて転送されるTCP層、およびアプリケーション要求が受け取られて転送されるアプリケーション層上で、トラフィックを処理できる。この状況において、可能な限り最も高い層、例えば、アプリケーション層で要求を扱うことができるとき、開示された実施形態の利益が最大になることに留意する。例えば、物理層接続を倍にしても、ある要求に対する応答を受け取る速度は高くならない。一方、HTTPあるいはDNS要求を倍にすると、応答を得る速度と信頼度を上げることができる。このように、要求がIP層に導入されると、より高い層において扱うことができるかどうか、例えば、HTTPあるいはDNS要求であるかを確認するために分析される。
トラフィックの重要な一部、あるいはユーザがアプリケーションに費やす時間の重要な一部を含むアプリケーションが優先され得る。また、高値アプリケーションは、特別に認識されたアプリケーションの組に追加される。少なくない数の解読要求によるアプリケーションは、仮想チャネル結合を認識するのに特に魅力的であり、今日の最も重要な例は、HTTP、DNS、ビットトレント、およびHTTPSである。
システムは、送られている要求の種類を解読して検出するために様々なパラメータを使用し得る。例えば、システムはポート番号、パケットの種類(例えば、TCPやuDP)、および内容を考察することがある。特定の例は、要求がポート80を指定し、内容がGET_ABCから始まる場合、それはHTTP要求を表し、HTTP要求として扱うことができる、あるいは、ポート53でありuDPパケットである場合、DNSパケットのレイアウトを有し、DNSパケットとして扱うことができる。
異なるネットワークインタフェースを用いずに行うよりそれを使用してトラフィックを送るいくつかの場合、あるいは自身のインターネットアクセスを有する異なるデバイスへメッシュネットワーク上で要求を送るいくつかの場合、仮想チャネル結合を実装する方法は要求を満たし得る。仮想チャネル結合を使用するとき、システムが各デバイス上で、できるだけ多くのネットワークインタフェースを可能にすることが最良である。例えば、コンピュータは有線イーサネット(登録商標)接続、Wi-Fi、および4G LTEドングルを可能にでき、スマートフォンは4Gインタフェースを可能にでき、Wi-Fiネットワークに加わることができ、Wi-Fi Directおよびブルートゥースを使用してメッシュネットワークに加わることができる。
本明細書に開示された方法のいずれかを実装するとき、各デバイスが多重チャネルを使用して通信し得るので、チャネルあるいはルート選択を可能にするための、いくつかの方法あるいはヒューリスティックを提供することは都合がよい。様々な希望設計考察を最適化するために様々なルート選択エンジンを採用することができる。例えば、速度が主に重要であるとき、例えば、等バイト、等要求、過去性能比例バイト、および過去性能比例要求手法等、全ての利用可能なインターネット出口を最大限利用する方法が最も良く動作する。等要求手法は最も単純であり、全ての利用可能なインターネット出口におよそ等しい数の要求を送るように努める。それは様々な方法で行うことができ、例えば、ラウンドロビンスケジュールを使用して現在の要求のためのランダムな出口を選ぶ、あるいはランダムに選び、結果として起こる付加的な不均衡のトラックを維持し、修正する(倍数的不均衡は、大数の法則のため、結局可能ではない)。等バイト手法は、等要求方法を改良したものあり、バイト数で要求を重み付けする。これは、寄与するチャネルの中のバイト分布がより一定になることを可能にする。過去の性能に比例するバイトは、自然な用法に基づくか、あるいは総合的なテストトラフィックに基づいて、チャネルの過去の性能の推定を保持する方法であり、過去の性能推定によってこのチャネルを下げるバイト数を重み付けする。過去の性能に比例する要求は、同様の技術であるが、システムがバイトよりむしろ要求のトラックを保持するものである。
保存する信頼度が最高のであるとき、キュー流出ルートセレクターは、うまく動作する。キュー流出は、他のデバイスを通らないダイレクトインターネット接続を有する各デバイス内で仮想キューを維持する。キュー流出の規律の下、これらのデバイスはデフォルトでダイレクトインターネット接続を用いてトラフィックを送り、その方法では、それは仮想チャネル結合なしで送られる。要求の仮想キューが、予めあるいはこのデバイスの動きの測定に基づいて設定され得る特定の閾値に達するときのみ、デバイスは、メッシュにおける他のデバイスのインターネット接続も利用されるように、いくつかの要求をそれらに送り始める。キュー流出は、速度より信頼度と有用度を優先する、非常に保守的なシステムを提供する。キュー流出でうまく動作する再試行方法は、スロットが制限下の仮想キューにおいてアクセス可能になるときに他のデバイスを通る未解決の要求のために直接接続上で再試行を発行する。
典型的なウェブページがロードされるとき、多くのオブジェクト(ウェブリソース)が通常要求される。仮想チャネル結合の方法は、異なるパスで送られる要求を分離することによって、この手法を利用する。しかし、時々、ソフトウェアアップデートダウンロードの間やビデオを見るためにHTTPストリーミングが使用されるとき、単一の非常に大きいオブジェクトを要求され得る。この場合、複数の要求の使用を許可する、つまり、それぞれがオリジナルの要求の副要求を構成しファイルの一部のみを要求する、HTTP範囲要求を使用することによって複数の接続を使用する単一のアイテムが得られ得る。このように、ファイルは一度に全てではなく、パーツ毎に要求される。各副要求、すなわち各パーツは、利用可能なチャネルのいずれかを使用して要求され得る。ほとんどのビデオストリーミングサービスは、ユーザによるビデオにおけるスキップおよびシークを可能にする範囲要求をサポートする必要があり、範囲要求はこのように、YouTube(登録商標)、Netflix、Vimeo、およびAkamaiが提供する全てのサイト上で見てうまく動作するために、それらに対する完全に正常な形式の要求である。
図1〜4に示す実施形態において、仮想チャネル結合の方法は分散型システムとして実装され、そこでは、各デバイスはどの選択方式を使用するかを個別に決め、どのチャネルを利用するかに関して自身で決定し、自身の接続をセットアップする。しかし、1つの実施形態によると、クラウドルートオラクルサーバは、システムの任意の一部であり、クラウドにおいてよくつながり、よく規定されたサーバ、典型的にはインターネット上のどこかに、メッシュネットワークルーチングプロトコルの任意の一部をオフロードするために使用できる。図5の例は、クラウドルートオラクルサーバ524がシステムにおける様々なデバイスからの、ルートについて任意の照会を提供する環境を示す。これらの照会は、直接、あるいはローカルネットワーク上の他のデバイスを通してデバイスによって送られ得る。サンプル照会は、どうすれば一番よく任意のデバイスに辿り着くか、様々な接続のコストに関する照会、様々な利用可能なサービスの帯域幅、および同様のものについての情報のための要求を含み得る。クラウドルートオラクルサーバ524は、照会において供給された背景情報のいくつかを保持し、それをキャッシュあるいは保存する。次いで、オラクルサーバ524は、デバイスが他のデバイスを見つけ、ルートを選び、ルートおよびインターネット出口特性を重み付けすることを助ける。
クラウドルートオラクルサーバ524は、クラウド出口サーバ522の一部を形成し得るか、あるいは分離した独立サーバであり得る。クラウド出口サーバ522は、セキュリティ、プライバシー、および速度の改良、および、完全に不透明でさえあり、システムで分類されないままのトラフィックにチャネル結合利益を提供するために使用され得る。また、クラウド出口サーバ524は、分類されたトラフィックに適用可能であり、速度を改善するために、認識された性質が使用され得る。例えば、HTTPトラフィックは、削除されたコメントおよびジャバスクリプトで短くされた変数名、メタデータを下げ、より効率的な画像形式に変え、人間の目に見えにくい画像においてエンコードされたいくつかの情報を捨てることによって減らされた画像のサイズ、および、よりよく再エンコードされたビデオトラフィックを有する。
不明瞭なトラフィックを用いて使用されると、クラウド出口サーバ524を有するシステムは以下の通り動作する。要求がモバイルデバイスのユーザアプリケーションにおいて発信されるとき、モバイルデバイスに属するクライアントは、要求を解読あるいは分類することを試みる。要求が解読可能でクライアントがクラウド出口サーバ524のサポートなしに要求を扱うことができる場合、クライアントは要求を扱う。さもなければ、要求が解読可能でない場合、要求のパケットは発信モバイルデバイスのクライアントによってカプセル化され、1つあるいは複数の経路上で送られる。カプセル化したパケットはクラウド出口サーバ524のアドレスを対象先として有する一方、カプセル化されたパケットは対象サーバアドレスを対象先として有し、モバイルデバイスのアドレスを発信アドレスとして有する。
誤り訂正技術は、カプセル化されたパケットがクラウド出口サーバ524に到着するのを確実にするために使用され得る。一般に、リードソロモン符号などの多くの誤り訂正符号が適当であり得るが、以下の単純な技術も実際にはうまく動作する、つまり、2つ以上のパスが利用可能であるとき、パスの1つを使用して、他のパス上で送られたパケットの排他的論理和を送る。パケットの1つが到着しない場合、到着したパケットの排他的論理和を取ることによって、それを再構成できる。この方式の下、2つのパケットの損失はまだ再送を必要とするが、低いオーバヘッドと低確率の再送の組合せにより、この機構は魅力的になる。
カプセル化パケットがクラウド出口サーバ524に到着すると、それらはデカプセル化されて、対象アドレスおよび発信アドレスを公開する。現在デカプセル化されたパケットは、対象アドレスを宛先として使用し、クラウド出口サーバ524のアドレスを発信元として使用して対象サーバに向けられる。次いで、応答は対象サーバによってクラウド出口サーバ524に向けられる。応答がクラウド出口サーバ524に到着すると、任意の利用可能なチャネルを用いてそれらを発信デバイスに送る、すなわち、必ずしも要求がクラウド出口サーバ524によって受け取られた同じチャネルではない。
本明細書に記載されたプロセスと技術が、いかなる特定の装置に固定的に関連するものではなく、構成要素の任意の適当な組合せによって実装され得ることは理解されるべきである。さらに、本明細書に記載された教示によれば、様々な種類の汎用デバイスが使用され得る。本発明は、全ての点で限定的というよりむしろ説明的であることを意図する、特定の例と関連して説明された。当業者は、多くの異なる組合せが本発明を実施するのに適当であることを認識する。
さらに、本発明の他の実施は、本明細書に開示された発明の仕様および実施を考慮すると、当業者にとって自明である。説明された実施形態の様々な態様、および/または、構成要素は、単独あるいは任意の組合せで使用され得る。明細書と実施例は、典型的に、以下の請求の範囲に示される本発明の正確な範囲および精神のみで考慮されることを意図する。
100 通信装置
112 Wi-Fiアクセス
105 セルラーネットワーク
107 セルラー接続
120 サーバ
115 インターネット
110 Wi-Fiアクセスポイント
200 モバイルデバイス
201 デバイス
202 デバイス
220 サーバ
222 クラウド出口サーバ
220 対象サーバ
300 デバイス
301 デバイス
302 デバイス
303 デバイス
304 デバイス
305 セルラータワー
308 モバイルデバイス
309 デバイス
311 Wi-Fiデバイス
320 サーバ
321 サーバ
322 クラウド出口サーバ
400 デバイス
401 デバイス
402 デバイス
403 デバイス
404 デバイス
405 デバイス
406 デバイス
407 デバイス
408 デバイス
409 デバイス
522 クラウド出口サーバ
524 クラウドルートオラクルサーバ



  1. プロセッサが読み取り可能なコードにおいて具体化されたプロセスであって、実行時にモバイルデバイスに対し、
    a. 前記モバイルデバイスによって複数の他のデバイスとの複数の接続を確立して、同時に維持し、それによって複数の通信チャネルを確立するステップと、
    b. 複数のリソース要求を対象デバイスに送ることによって、複数のウェブリソースを得るステップであって、前記複数の要求のうちの少なくとも2つが、前記複数の通信チャネルのうちの2つの異なる通信チャネルで送られるステップと、
    を含むステップを実行させるプロセス。

  2. 複数の接続を維持するステップは、各通信チャネル用の固有のIPアドレスを維持するステップを含む、請求項1に記載のプロセス。

  3. 前記複数のリソース要求のうちの少なくとも1つが送信の前にカプセル化される、請求項1に記載のプロセス。

  4. 前記カプセル化された要求がクラウド出口サーバに送られ、前記クラウド出口サーバによってデカプセル化され、前記対象デバイスに転送される、請求項3に記載のプロセス。

  5. 前記複数のウェブリソース要求のうちの少なくとも1つが、前記コンピューティングデバイスに送られるファイルの一部を指定するHTTP範囲要求を含む、請求項1に記載に記載のプロセス。

  6. 前記コンピューティングデバイスが、前記複数の通信チャネルのそれぞれで等数の要求を送る、請求項1に記載のプロセス。

  7. 前記コンピューティングデバイスが要求を各要求におけるバイト数で重み付けし、前記通信チャネルのそれぞれで送られるバイト数を均衡化させる、請求項1に記載のプロセス。

  8. 前記コンピューティングデバイスは、前記複数の通信チャネルのそれぞれに関する過去の性能の推定を維持し、対応する過去の性能の推定に応じて前記複数の通信チャネルのそれぞれで送られるバイト数を重み付けする、請求項1に記載のプロセス。

  9. 前記コンピューティングデバイスは、前記複数の通信チャネルのそれぞれに関する過去の性能の推定を維持し、対応する過去の性能の推定に応じて前記複数の通信チャネルのそれぞれで送られる要求数を重み付けする、請求項1に記載のプロセス。

  10. 前記コンピューティングデバイスは、前記複数の通信チャネルのそれぞれの使用コストの推定を維持し、対応する使用コストの推定に応じて前記複数の通信チャネルのそれぞれで送られる要求数を重み付けする、請求項1に記載のプロセス。

  11. 前記コンピューティングデバイスは、前記複数の他のデバイスのうちの少なくとも1つに関する接続情報を得るために、サーバへ要求をさらに送る、請求項1に記載のプロセス。

  12. 前記複数の他のデバイスの1つはスマートフォンを含み、前記複数の他のデバイスの1つはWi-Fiルータを含む、請求項1に記載のプロセス。

  13. 前記複数のリソース要求のうちの少なくとも1つは、前記スマートフォンを経由してインターネットに送られる、請求項12に記載のプロセス。

  14. 前記複数の通信チャネルの1つはセルラーネットワークを通じて確立され、前記複数の通信チャネルの1つはWi-Fi送信を通じて確立される、請求項1に記載のプロセス。

  15. 前記複数の通信チャネルの1つはセルラーネットワークを通じて確立され、前記複数の通信チャネルの1つはブルートゥースを通じて確立される、請求項1に記載のプロセス。

  16. 前記複数のリソース要求のうちの少なくとも1つは、ブルートゥースを経由してインターネットに送られる、請求項12に記載のプロセス。

  17. モバイルデバイスとのマルチチャネル通信を可能にするシステムであって、前記モバイルデバイスは実行するユーザアプリケーションを有し、
    ネットワーク連結サーバ上にある主要アプリケーションであって、前記サーバに対し、
    前記モバイルデバイスから送られた、カプセル化された要求を受け取り、前記要求の発信アドレスを判定するステップと、
    デカプセル化された要求を得るために前記カプセル化された要求をデカプセル化し、前記デカプセル化された要求の対象を判定するために前記デカプセル化された要求から対象アドレスを判定するステップと、
    前記対象アドレスを使用して、前記デカプセル化された要求を前記対象に送るステップと、
    前記デカプセル化された要求への応答を前記対象から受け取るステップと、
    前記発信アドレスを使用して、前記応答を前記モバイルデバイスへ転送するステップと、
    を含むプロセスを実行させる前記主要アプリケーション
    を含むシステム。

  18. 前記要求の発信アドレスを判定するステップは、前記カプセル化された要求をデカプセル化した後に実行される、請求項17に記載のシステム。

  19. モバイルデバイスにあるクライアントアプリケーションであって、前記モバイルデバイスに対し、
    前記ユーザアプリケーションによって生成された要求を遮るステップと、
    前記要求が解読可能でクライアントアプリケーションによって扱われることが可能か否かを判定するために前記要求を分析するステップと、
    前記要求が解読可能でないとき、カプセル化パケット内に前記要求をカプセル化するステップであって、前記カプセル化された要求はソースアドレスおよび対象アドレスを含み、前記カプセル化パケットは前記ネットワーク連結サーバのアドレスを含む、カプセル化するステップと
    前記カプセル化された要求を前記ネットワーク連結サーバに送るステップと、
    を含む前記プロセスを実行させる前記クライアントアプリケーション
    をさらに含む、請求項18に記載のシステム

  20. 前記要求が解読可能であるとき、前記要求を前記対象アドレスに送る、請求項19に記載のシステム。

  21. 前記要求が解読要求であると解読可能なとき、複数のチャネルを使用して前記要求を前記対象アドレスに複数回送る、請求項19に記載のシステム。

  22. 前記要求が解読可能であるとき、前記要求を複数の副要求に分割し、複数のチャネルを使用して前記複数の副要求を前記対象アドレスに送る、請求項19に記載のシステム。

  23. 前記要求が解読可能であるとき、前記要求を前記対象アドレスに送り、前記要求に対する応答が受け取られるとき、前記応答の少なくとも一部をキャッシュメモリへ保存する、請求項19に記載のシステム。

  24. 第2のモバイルデバイスから転送要求を受け取り、前記転送要求に対する応答が前記モバイルデバイスの前記キャッシュメモリに保存されているか否か判定し、保存されている場合、前記転送要求を転送することなく前記応答を前記第2のモバイルデバイスに送るステップをさらに含む、請求項23に記載のシステム。

  25. 前記要求が解読可能であるとき、第2のモバイルデバイスを経由して前記要求を前記対象アドレスに送り、前記要求に対する応答が前記第2のモバイルデバイスで受け取られると、前記応答の少なくとも一部を前記第2のモバイルデバイスのキャッシュメモリに保存する、請求項19に記載のシステム。

  26. 前記要求が解読可能であるとき、第2のモバイルデバイスを経由して前記要求を前記対象アドレスに送り、前記要求が前記第2のモバイルデバイスによって受け取られると、前記要求に対する応答が前記第2のモバイルデバイスのキャッシュメモリに保存されているか否かを判定し、保存されている場合、前記第2のモバイルデバイスの前記キャッシュから前記応答を取得し、前記発信モバイルデバイスに前記応答を送る、請求項19に記載のシステム。

  27. 複数の副要求を含むように前記要求が解読可能であるとき、前記副要求の少なくともの1つに対する応答が前記キャッシュメモリに保存されているか否かを判定し、保存されている場合、前記応答を前記ユーザアプリケーションに提供し、残りの副要求を前記対象アドレスに送る、請求項19に記載のシステム。

  28. 前記複数の副要求は複数の通信チャネルを経由して送られ、前記通信チャネルの少なくとも1つは第2のモバイルデバイスへのアドホック接続を含む、請求項27に記載のシステム。

  29. プロセッサが読み取り可能なコードにおいて具体化されたプロセスであって、実行時にコンピューティングデバイスに対し、
    OSI IP層上で通信要求を受け取るステップと、
    前記要求を分類して、より高いOSI層で扱うことができるか否かを判定するために前記要求を分析するステップと、
    より高いレベルで前記要求を扱うことができないとき、前記IP層を通じて前記要求を送るステップと、
    より高いレベルで前記要求を扱うことができるとき、前記より高いOSI層を通じて前記要求を送るステップと、
    を含むステップを実行させるプロセス。

  30. 前記要求を分析するステップは、前記要求のポート番号、前記要求のパケットの種類、および前記要求の内容を判定するステップを含む、請求項29に記載のプロセス。

  31. OSIアプリケーション層を通じて前記要求を扱うことができると判定されるとき、複数の通信チャネルを通じて前記要求および前記要求の複製を送る、請求項29に記載のプロセス。

  32. 前記要求がHTTP要求として分類されるとき、前記アプリケーション層で複数の通信チャネルを通じて前記要求を送る、請求項29に記載のプロセス。

  33. より高いOSI層において前記要求を扱うことができないと判定されるとき、対象アドレスおよび発信アドレスを前記カプセル化された要求に含めることによって前記要求をカプセル化し、前記要求のカプセル化にクラウド出口サーバのウェブ出口アドレスを有し、前記クラウド出口サーバが前記要求をデカプセル化し、前記対象アドレスを使用して前記要求を転送することを可能にする、請求項29に記載のプロセス。

  34. 前記要求を暗号化するステップをさらに含む、請求項33に記載のプロセス。

  35. 前記要求をカプセル化するステップは、クラウド出口サーバアドレスを有するカプセル化パケット内にソースアドレスおよび対象アドレスを有する前記要求のパケットを置くステップを含む、請求項33に記載のプロセス。

  36. 前記要求をカプセル化するステップは、前記要求のパケットを複数のサブパケットに分け、クラウド出口サーバアドレスを有するカプセル化パケット内にソースアドレスおよび対象アドレスを有する各サブパケットを置き、複数のカプセル化された要求を生成するステップを含む、請求項33に記載のプロセス。

  37. 前記複数のカプセル化された要求は複数の通信チャネルを通じて送られる、請求項36に記載のプロセス。

 

 

Patent trol of patentswamp
類似の特許
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)にアクセスするためのWebRTCのアーキテクチャを提供する複数の実施形態が、概してここで説明される。いくつかの実施形態において、非IMSユーザ機器(UE)が、非IMSUEと共同配置されたアプリケーションシグナルインターワーキングファンクション(ASIF)とともに提供される。非IMSUEは、非IMSUEをIMSコアに登録するための登録メッセージをASIFに送信するように構成される。ASIFは、非IMSUEからの登録メッセージをIMSベースシグナルに変換し、IMSベースシグナルに変換した登録メッセージを用いて非IMSUEをIMSコアに登録するように構成される。
本発明の実施例は通信モード切替方法、装置及びシステムを提供し、前記方法は前記enbが所定ポリシーに基づいてモード切替方式を確定し;前記モード切替方式がpdcpパラメータ無し交換であれば、前記enbがd2dリンクのueに第一モード切替命令を送信し、また、全てのpdcp送信パラメータ及びpdcp受信パラメータを0にリセットし;前記モード切替方式が完全pdcpパラメータ交換又は部分pdcpパラメータ交換であれば、前記enbがd2dリンクのueにモード切替準備命令を送信し、これにより、前記ueがpdcp送信パラメータ、pdcp受信パラメータ、及びpdcp状態報告を報告し又は1番目の紛失したpdcp受信sn及びそれに対応するhfnを報告し、これにより、pdcpパラメータ構成及びモード切替を完成する。本発明の実施例の方法、装置及びシステムにより、異なる通信モード切替シナリオに異なる解決案を提供し、このようにして、モード切替時のサービス連続性問題を完全に解決できる。
通信システム // JP2016516334
移動デバイスが第1の無線技術を用いて基地局と通信し、第2の無線技術を用いて他のデバイスと通信するように動作可能である、移動通信システムが記述される。移動デバイスは、第1の基地局との制御プレーン接続を維持し、第2の基地局を介してユーザプレーン接続を維持する。第1の無線技術及び第2の無線技術を同時に使用することに起因して干渉が検出された場合、移動デバイスは、基地局に支援情報を与え、その情報に基づいて、基地局は検出された干渉の影響を軽減する。
WLAN送受信器の動作ステータスに基づいてAMP接続を管理するために、WLANおよびBluetooth(登録商標)システムの動作を調整するためのシステムおよび方法が開示される。
仮想ベアラを使用した無線ネットワークにおけるベアラ管理のためのシステム、方法、および手段が開示される。無線送信/受信ユニット(WTRU)をWLANへオフロードするためのeNB決定と、ANDSFポリシーとの間におけるコンフリクトを管理するためのシステム、方法、および手段も開示される。WLANのための、またはWLANへのオフロード中のドライブテストの最小化(MDT:minimization of drive tests)のためのシステム、方法、および手段も開示される。WTRUの能力をシグナリングするためのシステム、方法、および手段も開示される。
1つの革新は、第1のデータパケットと第2のデータパケットとを記憶するように構成されたメモリユニットを含む、第1のワイヤレスチャネルと第2のワイヤレスチャネルとを介して通信システムとワイヤレス通信するための、装置を含み、第1のデータパケットおよび第2のデータパケットは、連続するシーケンス番号を有する。本装置は、メモリユニットから第1のデータパケットと第2のデータパケットとを取り出すように構成されたプロセッサと、第1のチャネルを介して通信システムに第1のデータパケットを送信するように、通信システムから第1の確認応答を受信するように、プロセッサが、第1の確認応答が第1の受信情報の肯定応答を備えることを検出した後、第2のチャネルを介して通信システムに第2のデータパケットを送信するように構成されたトランシーバとをさらに含む。
フェイルオーバ、負荷分散、トラフィック分布、または他のピアツーピア接続性機能をサポートするために、デバイスのペア間に相互ワイヤレス接続が確立され得る。デバイスのペアの各デバイスは、デバイスのペアの他方のデバイスと通信するためにローカルワイヤレスアクセスポイントとローカルワイヤレス局の両方を実装し得る。第1のワイヤレス接続のプロトコル拡張を使用して、デバイスのペア間の第2のワイヤレス接続の確立が協調させられ得る。多重化(MUX)構成要素が相互ワイヤレス接続の間のトラフィックを協調させ得る。
モバイルデバイスにおいてネットワークを選択するための方法および装置であって、モバイルデバイスの位置推定を決定すること(410)と、ここで、モバイルデバイスは、複数のネットワーク(210、204、208、206)を介して通信するように構成された複数のトランシーバを備える;前記位置推定についての無線リソースマップにアクセスすること(420)と、ここで、前記無線リソースマップは、前記複数のネットワークにおける各ネットワークについての位置推定におけるコストおよびデータレートを含む;前記無線リソースマップにアクセスすることに基づいて、複数のネットワークからネットワークを選択し、前記複数のトランシーバから単一のトランシーバを選択すること(430)と;前記単一のトランシーバを介してトラフィックを通信すること(440)と、を備える。
デュアルSIMデュアルアクティブ(DSDA)モバイル端末などのデュアルSIMモバイル端末は、ネットワークに接続し、ネットワークを通じてユーザプレーン測位セッションまたは制御プレーン測位セッションを実行する。測位セッションがモバイル端末によって開始されるときには、いずれのSIMカードがそれに関連するネットワークに接続するのに使用されてもよい。測位セッションがネットワーク内の別のエンティティによって開始されるときには、いずれのSIMカードが測位セッションに使用されてもよい。モバイル端末がいずれかのSIMカードを使用して緊急呼のネットワークに接続し、ネットワークを通じて緊急測位セッションが実行されるとき、緊急測位セッションは、緊急呼および緊急コールバック期間の間のみ許容され、緊急呼が発信されるサブスクリプションに対してのみ許可され、いずれのSIMカードによる非緊急測位セッションも、緊急測位セッションまたは緊急呼の間は許可されない。
モバイルワイヤレスデバイス/プラットフォームは、消費電力節減、無線機共存の軽減、電磁干渉の削減など、当該モバイルワイヤレスデバイスに関連する状態を改善するために、所望のインターフェースを動的に選択またはインスタンス化する。1つの例では、モバイルワイヤレスデバイスは、モバイルワイヤレスデバイスホスト中の1つまたは複数のハードウェアインターフェースを識別する。モバイルワイヤレスデバイスは、次いで、周辺デバイスと前記モバイルワイヤレスデバイスホストとの間の通信を容易にするために、それらの1つまたは複数のハードウェアインターフェースを動的に選択する。
To top