JP5423653B2 - 無線デバイス間のマルチ無線通信 - Google Patents

Description

スマートフォン、ラップトップ、ネットブック等の様々な無線デバイスの登場に伴い、これらデバイスの通信で、複数種類の無線プロトコルをサポートすることが期待されている。例として、ＷｉＭＡＸ又はＬＴＥのような広域プロトコル、ＷｉＦＩのようなローカルエリアプロトコル、そしてＢｌｕｅｔｏｏｔｈ（登録商標）のようなパーソナルエリアプロトコルが挙げられる。第１のデバイスが、選択可能な複数のプロトコルの中から、最も利用に適したプロトコルを使用して第２のデバイスと通信を行えるような技術を実現するべく、様々な努力がなされてきた。また、あるデバイスは、２つの異なるデバイスとそれぞれ異なるプロトコルを使用して通信可能である。所与のネットワークでは、通常、全ての通信に１つのプロトコルを使用しているため、一般的には、他のデバイスがどのネットワークに属しているかに応じてプロトコルが選択される。しかしながら、２つのデバイスのそれぞれが複数のプロトコルを使用可能であっても、従来のネットワークにおいてこれら２つのデバイス間の特定の１つの通信を改善することはほとんどできていなかった。

本発明の実施形態は、以下の詳細な説明及び本発明の実施形態を例示するのに使用される添付の図面を参照することにより、より良く理解されるであろう。

本発明の実施形態に係る、互いに通信を行う２つの無線デバイスを示す。 本発明の実施形態に係る、複数のプロトコルを使用して２つのデバイス間で通信を行う方法を示したフローチャートである。 本発明の実施形態に係る、チャネル状態に応じたマルチプロトコル通信をベースとする方法を示すフローチャートである。 本発明の実施形態に係る、通信冗長に複数のプロトコルを使用する方法を示したフローチャートである。 本発明の実施形態に係る、通信のダイバーシチに複数プロトコルを使用する方法を示したフローチャートである。 本発明の実施形態に係る、負荷分散に複数のプロトコルを使用する方法を示したフローチャートである。

以下の詳細な説明では、本発明を理解するために多くの詳細事項が記される。しかしながら、これら詳細事項がなくとも本発明を実施可能であることは、当業者にとって明らかである。また、本発明の説明の理解を不明瞭にしない目的から、周知の回路、構造及び技術についての詳細な説明を省略している。

また、"一実施形態"、"ある実施形態"、"例示的実施形態"、"様々な実施形態"等の言葉は、少なくとも本発明の実施形態が、実施形態に関連した特定の特徴、構造又は特性を含むことを示唆するが、必ずしも全ての実施形態が、これら特定の特徴、構造及び特性を含むことを意味しない。また、ある実施形態は、他の実施形態で記載された特徴の全てを有していてもよいし、全く有していなくてもよい。

以下に記載の説明及び特許請求の範囲において、"連結（ｃｏｕｐｌｅｄ）"及び"接続（ｃｏｎｎｅｃｔｅｄ）"という言葉、並びにこれらの派生語が使用されることがある。この２つの言葉は、同義語として使用されているのではない。特定の実施形態において、"接続"は、２つ又は２つ以上の要素が物理的に又は電気的に直接互いに接触していることを指すのに使用されている。一方、"連結"は、２つ又は２つ以上の要素が、互いに協動又は相互作用していることを指すのに使用され、これら２つ又は２つ以上の要素の間に物理的又は電気的要素が介在している場合も介在していない場合も含む。

また、特許請求の範囲において、共通の要素に使用される序数詞"第１の"、"第２の"、"第３の"等は、特に記載がない限り、単に同類の要素の異なる例を示しているに過ぎず、当該要素の時間的な若しくは空間的な順序、又は序列等における順番を示しているわけではない。

本発明の様々な実施形態が、ハードウェア、ファームウェア、ソフトウェア、及びこれらの組み合わせにより実施可能である。また、本発明は、コンピュータ可読媒体に含まれる命令として、又はコンピュータ可読媒体に対する命令として実施可能であり、当該命令は、明細書に記載のオペレーションを実行可能にする一つ又は複数のプロセッサによって、読み出され、実行される。コンピュータ可読メディアとしては、１つ又は複数のコンピュータが可読な形式で情報を蓄積するあらゆる装置が含まれる。そのようなコンピュータ可読媒体としては、これらに限定されないが、例えば、リード・オンリー・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学式記憶媒体、フラッシュメモリ装置等の有形の記憶媒体が含まれる。

"無線（ｗｉｒｅｌｅｓｓ）"という言葉は、非固体媒体を通して変調電磁放射を利用することによりデータ通信を行う回路、デバイス、システム、方法、手法、通信チャネル等を表現するのに使用されている場合がある。この"無線"という言葉は、関連するデバイスが、電線を有していないという意味ではない。無線デバイスは、少なくとも１つのアンテナ、少なくとも１つの無線機、少なくとも１つのメモリ及び少なくとも１つのプロセッサを含んで構成されていてもよく、無線機は、データを表す信号をアンテナを通じて送信し、データを表す信号をアンテナを通じて受信する一方、プロセッサは、送信すべきデータ及び受信されたデータを処理してもよい。また、プロセッサは、送信又は受信されない他のデータを処理してもよい。

本明細書において使用される、"通信（する）（ｃｏｍｍｕｎｉｃａｔｉｎｇ）"という言葉は、１）他のデバイスと無線送信を行う、２）他のデバイスから無線受信を行う、又は、３）他のデバイスへの無線送信及び他のデバイスからの無線受信を行うことを意味する。送信すべきデータには、転送すべきコンテンツ、全通信からどのようにコンテンツを抽出するかを示す制御データ、受信されたデータが送信されたデータと一致するかを判断する認証データ、及び受信機と入力信号とを同期させるためのプリアンブルデータが含まれてもよい。

また、本明細書で使用される"プロトコル"という言葉は、無線通信の１つ又は複数の規格で規定された特定の一連のフォーマット、チャネル、変調技術、通信規則等を指す。例えば、ＷｉＦｉ、ＷｉＭＡＸ、ＬＴＥ及びＢｌｕｅｔｏｏｔｈ（登録商標）は、それぞれ異なるプロトコルと考えられ、またそれぞれ、ある目的のために異なる複数のプロトコルにさらに分類される場合もある。

本明細書では、"同時（ｓｉｍｕｌｔａｎｅｏｕｓ）"通信という言葉は、２つの通信（送信、受信又は送受信）が同時に発生することを意味し、"並行（ｃｏｎｃｕｒｒｅｎｔ）"通信という言葉は、２つの通信が同じ期間に発生する場合があるが必ずしも同時に発生するとは限らないことを指す。並行通信は、より広義な言葉であり、同時通信の事例も含む。２つの通信が完全ではないが部分的にオーバーラップする場合、この通信を全体として並行（ｃｏｎｃｕｒｒｅｎｔ）であると表現でき、オーバーラップする部分を、同時（ｓｉｍｕｌｔａｎｅｏｕｓ）であると表現できる。実際には、様々なプロトコルが、並行通信又は同時通信のために、同一デバイスに設けられた同一無線ハードウェアの幾つか又は全てを使用する場合もあるし、全く使用しない場合もある。

本明細書において、第１のプロトコル及び第２のプロトコルを使用して同時に通信を行うということは、両方のプロトコルが、同時に送信及び／又は受信において使用されるということを指し、第１のプロトコル及び第２のプロトコルを使用して並行に通信を行うということは、特定の期間に、特定のシーケンスの送信及び／又は受信について両方のプロトコルが使用されるが、一方が他方と全く同時に使用される場合もあるし、使用されない場合もあることを指す。

様々な実施形態において、２つのデバイスは、複数のプロトコルを使用して互いに通信を行ってもよく、通信データを幾つかの部分に分割し、それぞれの部分の通信を異なるプロトコルを使用して行ってもよい。このような技術は、様々な方法において応用され、様々な利点を提供する。２つのデバイスはそれぞれ、関連するネットワークにおいて実行可能な機能を果たしていてもよく、例えば、ネットワークコントローラ（アクセスポイント、基地局、中心点等）、携帯デバイス（移動ノード、加入者局、ＳＴＡ等）、中継局、サーバ等であってもよい。幾つかの実施形態において、複数のプロトコルにより通信されるデータは、１つのアプリケーションと関連付けられていてもよく、これらに限定されないが、例えば、ｈｔｔｐトラフィック、動画ストリーミング、ファイルダウンロード、ｅメール、ネットワーク情報等であってもよい。

図１は、本発明の実施形態に係る互いに通信を行う２つの無線デバイスを示している。図示されているデバイスは、ノートブックコンピュータ１１０及び無線制御装置１２０であるが、互いに無線通信を行うどのような２つのデバイスであってもよい。各デバイスに搭載されるアンテナの数は、各デバイスがサポート可能な特定のプロトコルに応じて決められていてもよい。これらのデバイスは、３つ以上の異なるプロトコルをサポート可能であるが、２つの異なるプロトコル、プロトコルＡ及びプロトコルＢを使用して互いに通信を行っている。以下の説明では、特に、デバイスが２つのプロトコルを使用して互いに通信を行っている場合を記載しており、プロトコルの例としては、ＷｉＦｉ及びＷｉＭＡＸが挙げられる。しかしながら、本発明の概念は、３つ又はそれ以上の数のプロトコルについても適用でき、実行可能な特定の複数のプロトコルを使用して通信を行うことができる。ＷｉＦｉ及びＷｉＭＡＸ以外の例としては、ＬＴＥ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＧＳＭ、３Ｇ、４Ｇ、Ｚｉｇｂｅｅ、６０ＧＨｚ等が挙げられる。

図２は、本発明の実施形態に係る、複数のプロトコルを使用して２つのデバイス間で通信を行う方法を示したフローチャートである。図示の例では、２１０において、デバイスは、第２のデバイスと無線でデータを通信すべきかを判断する。このデータには、第２のデバイスに送信すべきデータだけでなく、第２のデバイスから受信されるデータも含まれていてもよい。このようなデータは、（双方向に）通信されるコンテンツ、コンテンツをどのように整理するかを規定するためのオーバーヘッドデータ、受信されたデータが壊れていないかを確認する認証データ、コントロールデータ等を含んでもよい。

２２０では、デバイスは、データの性質、現在のチャネルの状態、及び通信に複数のプロトコルが使用されるか否かを判断するのに使用されるその他の関連要素を検証する。幾つかの実施形態において、この時点では、マルチプロトコル通信が行われる可能性のみを判断し、実際に複数プロトコルを使用するか否かの判断は、後でその時の状況に応じて行うようにしてもよい。

２３０において、通信するデータを複数の部分に分割し、そのうち幾つかの部分を第１プロトコルを使用して通信し、残りの部分を第２プロトコルを使用して通信するようにしてもよい。他の実施例では、３つ以上のプロトコルを使用して上述のような通信を行ってもよい。データを複数の部分に分割することの本質は、これらに限定されないが、様々な条件に対する依存性があり、１）プロトコルが双方のデバイスに利用可能であり、双方のデバイスにサポートされているか、２）送信されるデータの種類、３）チャネル負荷、４）チャネル品質、５）利用可能なプロトコルによってサポートされるデータレート、６）２つのプロトコルのオーバーヘッド条件、７）その他、といった因子が挙げられる。また、幾つかの実施例では、データの複数部分への分割を、通信シーケンスが開始した後に、その時の状態に応じて行ってもよい。いくつかの実施形態では、データの複数部分への分割を、ＯＳＩ ＰＨＹ層で行ってもよく、他の実施形態では、ＯＳＩ ＭＡＣ層で行ってもよく、また、他の実施形態では、より上位層で行ってもよい。いくつかの実施形態では、複数の層に渡って、データの分割を行ってもよい。２４０及び２５０では、データの複数の異なる部分が、選択されたプロトコルを使用して通信される。無論、受信側は、複数のプロトコルでデータを受信した後、これらデータを元のデータへと再構築する。プロトコルの違いによって、データの異なる部分が異なる順序で受信される場合があるが、そのような場合は、適した識別技術を使用して正しい順番を判断し、データの再構築を行うようにしてもよい。

幾つかの実施形態では、利用可能なプロトコルのうち少なくとも１つは、ネットワークコントローラがネットワークにおける他のデバイスの通信をスケジュールするコントローラ中心プロトコルを主に使用するプロトコルであってもよい。加えて（又はこれに替えて）、利用可能なプロトコルのうち少なくとも１つは、送信許可を得る前に各デバイスが媒体へのアクセスを競うコンテンションベースの技術を使用するプロトコルであってもよい。幾つかのプロトコルは、上記の技術両方を使用してもよいが、同じ周波数帯を使用する場合には、スケジュールされていないコンテンションベースの通信とスケジュールされた通信とが互いに干渉してしまうのを防ぐ適切な予防手段を設けるのが望ましい。また、幾つかのプロトコルは、免許を受けた周波数帯用に設計されていてもよいし、免許を受ける必要がない周波数帯で動作するものであってもよい。コンテンションベースのプロトコルとスケジュールされたプロトコルと両方を使用する実施形態では、コンテンションベースのプロトコルの方に媒体へのアクセスの優先権を与えてもよく、スケジュールプロトコルをコンテンションベースのプロトコルとの調整を図ってスケジュールするようにしてもよい。

幾つかの実施形態では、特定の無線デバイスは、両方のプロトコルについて同じ無線機の全て又は一部を使用してもよい。例えば、デバイスは、同じ電力増幅器を送信に使用し、同じチューナーを受信に使用し、また、同じデジタル信号プロセッサ（ＤＳＰ）、同じアンテナ等を使用してもよい。これは、デバイスが両方のプロトコルで同時に通信可能か、又は並行オペレーションにおいて異なる時間に使用しなければならないかということに影響する。幾つかの実施形態では、特定のデバイスは、両方のプロトコルについて、同じ周波数スペクトルの全部又は一部を使用してもよい。この場合も、同一の又は同様な周波数帯が同時に使用されると、１つのプロトコルがもう１つのプロトコルと干渉する可能性があることから、デバイスが両方のプロトコルで同時に通信可能かということに影響する。

複数のプロトコルを使用して同時に又は並行に互いに通信を行う２つの異なるデバイスの概念は、様々な方法において有用な効果を得るのに応用可能である。以下に、幾つかの例について記載する。

［動的干渉低減］
図３は、本発明の実施形態に係る、チャネル状態に応じたマルチプロトコル通信をベースとする方法を示すフローチャートである。３１０及び３２０において、デバイスは両方のプロトコルについてチャネル状態を監視し、いずれのプロトコルを使用した方がより優れた性能を発揮できるかを判断する。この判断を、通信シーケンスを開始する前に行って、使用するプロトコルを決定してもよい。通信シーケンスの間に、他のプロトコルに切り替えるべきか否かを判断する通信シーケンスの間に、上記判断を行ってもよい。チャネル状態としては、起こり得るエラー率又は時間消費エラー確率の修正手順に影響するようなパラメータを全て含む。信号対干渉雑音比（ＳＩＮＲ）は、デバイスが直接測定する上記のようなパラメータうちの１つであり、及び／又は他のデバイスによって測定されたパラメータとして、デバイスがＳＩＮＲ情報を他のデバイスから受信してもよい。デバイスが使用する他のパラメータとして、受信信号強度インジケーター（ＲＳＳＩ）があり、これをデバイスが直接測定してもよいし、他のデバイスから取得してもよい。

ＳＩＮＲ及びＲＳＳＩは、直近に起こり得るエラー率を間接的に示す情報であり、デバイスは、過去の動作歴から実際のエラー率を導出してもよい。このようなエラー率には、ビット誤り率（ＢＥＲ）、パケット誤り率（ＰＥＲ）、及び過去の実際の動作暦に基づいて直近の未来の性能を示唆するその他のパラメータが含まれていてもよい。上述したように、これらのパラメータを、デバイス自身が測定を行うことにより取得してもよいし、他のデバイスの導出結果に基づいて他のデバイスから受信してもよい。これらのパラメータを両方のプロトコルについて比較することにより、デバイスは、どのプロトコルによれば直近の未来に最も優れた性能を提供できるかを判断してもよい。

この判断行った後、デバイスは、３３０において望ましい方のプロトコルを選択し、３４０において選択したプロトコルを使用して通信を行う。幾つかの実施形態では、３４０から３１０へ戻るループで示されるように、デバイスは、チャネル状態を継続して監視し、チャネルの状態に合わせて使用するプロトコルを動的に変更してもよい。あるプロトコルから別のプロトコルへと変更する際には一定量のオーバーヘッドトラフィックが生じることから、幾つかの実施形態では、最低限レベルの性能向上が図れるように、プロトコルを変更する前にヒステリシス効果を利用してもよい。

［冗長化］
図４は、本発明の実施形態に係る、通信冗長について複数のプロトコルを使用する方法を示したフローチャートである。ここで使用されている"冗長化（ｒｅｄｕｎｄａｎｃｙ）"という言葉は、同一データを両方のプロトコルで送信することに関連する。冗長化することにより、正しいデータを受信する確率が上がり、データが失われてしまう又は後で再送信しなければならなくなる確率を下げることができる。例示する実施形態では、４１０において、利用可能なプロトコルのうち、使用すべきプロトコルを判断する。この判断は、実行可能であればどのような方法で行ってもよく、これに限定されないが、本明細書に記載されたような方法で行うことができる。４２０において、冗長的に送信するべきデータを決定し、４３０において、送信機によりこのデータを両方のプロトコルで送信する。

冗長通信を行うべきデータは、様々な条件に応じて選択される。選択の結果が、次に記す選択肢のいずれかであってもよいし、別の選択肢があってもよい。１）コンテンツ全体を冗長的に両方のプロトコルで通信する、２）コンテンツのより重要な部分のみ冗長的に両方のプロトコルで通信する、３）制御情報、ヘッダ、アクノリッジメント、再送信要求等のオーバーヘッド情報を冗長的に両方のプロトコルで通信する。データは、様々なエラー修正符号化技術により符号化されていてもよく、符号化された冗長情報を複数のプロトコルで送信してもよい。

４４０において、冗長データが受信機によって受信され、４５０において、どの冗長データのセットを使用すべきかの選択が行われる。この選択は、様々な要件に基づいて行われてもよく、これらに限定されないが、例えば、１）両方のセットが正しく受信された場合は、予め決められた選択肢の方を選択する、２）１つのセットが正しく受信されず、受信機で修正が不可能な場合、もう１つのセットの方を選択する、３）１つのセットが正しく受信され、もう１つのセットは正しく受信されなかったが受信機で修正が可能な場合、正しく受信されたデータセットを使用してもよいし、受信機が修正したもう１つのセットの方を使用してもよい、４）両方のデータセットが正しく受信できず修正もできない場合、受信機は、どちらか一方又は両方のセット再送信を要求する、若しくはいずれのセットも再送信を要求しない、等の選択肢が考えられる。

図４では、４１０〜４３０が送信機によって実行され、４４０〜４５０が受信機によって実行されるように示されているが、他の実施形態では、これらの機能を別の態様で分担してもよい。例えば、使用すべきプロトコルの判断及び／又はどのデータを冗長化すべきかの判断を受信機で行い、選択した結果を送信機に伝達してもよい。

［ダイバーシチ］
図５は、本発明の実施形態に係る、通信のダイバーシチに複数プロトコルを使用する方法を示したフローチャートである。ここで使用される"ダイバーシチ"という言葉は、データを２つに分割し、一方の部分を１つのプロトコルで送信し、他方の部分をもう１つのプロトコルで送信することに関連する。いくつかの実施形態では、コンテンツを分割し、それぞれを異なるプロトコルで通信してもよい。他の実施形態では、オーバーヘッドデータを分割し、それぞれを異なるプロトコルで通信してもよい。また、他の実施形態では、コンテンツ及びオーバーヘッドデータの両方を分割し、それぞれ異なるプロトコルで通信してもよい。また、他の実施形態では、コンテンツを１つのプロトコルで通信し、オーバーヘッド情報又は制御情報を別のプロトコルで通信してもよい。

例示した実施形態では、５１０において、使用すべきプロトコルの判断が行われる。５２０では、送信すべきデータが複数部分に分けられ、５３０で、各部分が複数のプロトコルのうちのいずれか１つに割り当てられる。この割り当ては、様々な条件に基づいて行うようにしてもよく、これらに限定されないが、例えば、１）各プロトコルに対するチャネル品質、２）各プロトコルが利用可能な帯域幅、３）各部分の時間制限、４）その他、等の条件が挙げられる。複数部分に分けられたデータは、５４０においてそれぞれのプロトコルで送信され、５５０で受信される。受信機は、５６０において、データの複数部分を組み合わせて元のメッセージを再構成する。５６０から５２０へと戻る矢印は、このプロセスが継続的に繰り返されてもよいことを示し、各プロトコルで伝送されるデータ量を、状況の変化に応じて変化させてもよい。

図５では、５１０〜５４０が送信機によって実行され、５５０〜５６０が受信機によって実行されるように示されているが、他の実施形態では、これらの機能を別の態様で分担してもよい。例えば、使用すべきプロトコルの判断及び／又はどのデータをどのプロトコルで送信すべきかの判断を受信機で行い、選択した結果を送信機に伝達してもよい。

［高解像度］
本発明の一実施形態では、受信機において高い解像度を持つデータを達成するために、容量の大きいデータを送信するのにマルチプロトコル通信を使用してもよい。ここで使用されている"解像度"という言葉は、受信機において生成可能なデータの詳細度に関係する。例えば、基本の解像度を持つビットの動画データ（例えば、標準的な画質の動画）を１つのプロトコルで送信し、より高い解像度を達成する（高画質の動画）ためさらなるビットをもう１つのプロトコルで送信してもよい。これらの部分を、受信機で組み合わせて１つにし、高解像度の映像を形成するようにしてもよい。追加解像度のいくつかの部分が正常に受信できなかった場合は、その部分の動画を標準的な解像度で表示するようにしてもよい。例えば、相対的に必要な帯域幅を確保可能な免許を受けた周波数帯域を使用して標準的な解像度のデータを送信し、必要とする帯域幅が確保できるか否か、対象の媒体について競合する他のトラフィック量に依存する免許を必要としない周波数帯域を使用して追加の高解像度部分のビットデータを送信するよう構成すると、有用である。

他の実施例では、追加の誤り訂正符号（ＥＣＣ）を、異なるプロトコルを使用して送信してもよい。また、通常行われるように、一定のエラー数を修正するＥＣＣデータをコンテンツと共に送信してもよい。標準的なＥＣＣと組み合わせた場合に標準よりも多い数の修正を行うことが可能となる同じコンテンツに対する追加のＥＣＣ情報を、他のプロトコルを通じて利用可能としてもよい。このように、普通のメッセージを伝達するプロトコルでは、多くのＥＣＣ情報を必要とする場合が稀なため、それにより送信が遅くなることは通常ないが、追加のＥＣＣ情報が必要とされる状況ではこの追加ＥＣＣ情報を利用可能である。

図５は、高い解像度のデータを通信するプロセスを説明するのにも適用可能なフローチャートである。

［負荷分散］
図６は、本発明の実施形態に係る、負荷分散に複数のプロトコルを使用する方法を示したフローチャートである。ここで使用している、"負荷分散"という言葉は、あるプロトコルは輻輳状態の影響を受け、別のプロトコルは通信容量に空きがあるという状態が起こる可能性を減らすために、各プロトコルで送信するデータ量を調整することに関する。例えば、１つのプロトコルを使用するデータトラフィックが相対的に混雑した状態になった場合、さらなるデータの送信を他のプロトコルへと切り替えて行ってもよい。この切り替えは、各プロトコルのデータトラフィックを監視することにより動的に行ってもよい。

例示した実施形態では、６１０において使用するプロトコルの判断を行う。２つのプロトコルのみが利用可能である場合は、この２つのプロトコルを使用する。３つ以上のプロトコルが利用可能である場合は、プロトコルの選択に様々な基準を適用できる。６２０において、選択されたプロトコルを監視し、直近の未来に、各プロトコルがどれだけの利用可能な帯域幅を持つかの判断を行う。ある特定のプロトコルの監視は、実行可能であればどのような方法で行ってもよく、１）スケジュールされたプロトコルにおいて、要求された帯域幅に対してどれだけデバイスに割り当てられていないかを監視する、２）スケジュールされていないプロトコルについて、媒体へのアクセスにどれだけの時間が掛かっているかを監視する、３）ネットワークがビジー状態であると思われる時間の長さを監視する、４）デバイスによって観察される及び／又は他のデバイスにより報告される送信キューのサイズを監視する、５）その他、等の方法が考えられる。監視は、デバイスが直接観察を行うことにより実行してもよいし、１つ又は複数の他のデバイスから状態についての報告を受信することにより実行してもよい。

６３０において、送信すべきデータを複数部分に分割し、６４０において、各部分を選択されたプロトコルのうちの１つに割り当てる。この割り当ては、先に述べたように、負荷の不均衡が起きてしまうのを避けるために行い、各プロトコルが利用可能な帯域幅に基づいて行う。６５０において、両方のプロトコルでデータ送信を開始した後、６６０において、各プロトコルの状態の監視を繰り返し行ってもよい。監視した状況から、負荷の不均衡が（ある限界を超えて）起きていると判断される場合は、６３０又は６４０に戻り、送信すべきデータを２つのプロトコルに異なる割合で再び割り当て直してもよい。

ここで示した実施形態では、２つの異なるデバイス間の通信に基づいて負荷分散を行う例を示したが、負荷分散を、各プロトコルが他のデバイスでどの位使用されるかを考慮して行ってもよい。例えば、ネットークコントローラが第１の携帯デバイスとの通信に、第１プロトコルを多く使用し、第２プロトコルの使用が少ない場合、ネットワークコントローラは第２の携帯デバイスと通信を行うときに、第１プロトコルの使用を少なくすると同時に第２プロトコルを多く使用するようにして、両方のプロトコルが輻輳状態とならないようにしてもよい。

［エネルギー消費削減］
マルチプロトコル通信を、エネルギー消費を削減するのに利用することもできる。追加的にプロトコルを使用する場合、全通信が使用する周波数帯域を広げてしまうことが考えられる。送信を行う周波数帯域を広げることにより、所与のチャネルにおけるデータ転送速度は、周波数帯域を広げた分におよそ比例して低減される。しかしながら、送信に必要とされる電力は、データ転送速度の変化におよそ指数関数的に比例して変化するので、帯域が広がった効果以上に全体の消費電力を比例させて削減することができる。

［オーバーヘッドの削減］
マルチプロトコル通信を、オーバーヘッド通信の削減に利用することもできる。ネットワーク通信のほとんどにおいて、デバイス間でオーバーヘッド情報を通信する必要がある。コンテンツの通信に、２つの異なるプロトコルを使用する場合、通常、両方のプロトコルで同じオーバーヘッドを使用するといったように、オーバーヘッドの一部が重複している場合が多い。例えば、制御情報を、両方のプロトコルで通信されるデータに適用してもよい。幾つかの実施形態では、このような制御情報は、１つのプロトコルによってのみ送信されるようにしてもよく、コンテンツの通信のために他のプロトコルの帯域を残しておいてもよい。この構成は、例えば動画コンテンツのようにわずかな遅延であっても目立った結果となってしまう時間依存性の大きいコンテンツに対して有効である。周期的な制御情報に、低速のコンテンションベースのプロトコルを使用することにより、動画情報の伝達に、高速のスケジュールベースのプロトコルを使用することが可能となる。

以上の詳細な説明は、発明を例示するために記載されたものであり、発明を限定することを意図していない。様々な変更が当業者にとって明らかである。これらの変更は、本発明の様々な実施形態に含まれることを意図しており、本発明は、添付の特許請求の範囲によってのみ限定される。

Claims (15)

1. 無線ネットワークで通信を行う方法であって、
   無線デバイスにより、第１無線プロトコルを使用して、コンテンツを含むデータの第１部分を通信する段階と、
   前記第１無線プロトコルで、一定のエラーを修正する、前記コンテンツの第１誤り訂正符号情報を通信する段階と、
   前記無線デバイスにより、前記第１無線プロトコルとは異なり、前記第１部分と共に１つのアプリケーションと関連付けられている第２無線プロトコルを使用して、前記第１部分の通信と並行して前記データの第２部分を通信する段階と、
   前記第２無線プロトコルで前記コンテンツの追加の誤り訂正符号情報を通信する段階と、
   前記第１無線プロトコル及び前記第２無線プロトコルの両方の状態を監視して、前記第１無線プロトコル及び前記第２無線プロトコルの負荷の不均衡が所定の限界を超えて起きているか判断する段階と、
   前記第１無線プロトコル及び前記第２無線プロトコルの負荷の不均衡が所定の限界を超えたときに、前記第１無線プロトコル及び前記第２無線プロトコルでさらなるデータを送信する前に、前記監視に基づいて、前記データを、前記第１無線プロトコルと前記第２無線プロトコルとに異なる比率で再割り当てする段階と、
   を備え、
   前記追加の誤り訂正符号情報は、前記第１誤り訂正符号情報と組み合わせた場合に、前記第１誤り訂正符号情報よりも多い数の修正を行う、方法。
2. 前記第１無線プロトコル及び前記第２無線プロトコルの少なくとも１つは、ＷｉＦｉ、ＷｉＭａｘ、ＬＴＥ及びＢｌｕｅｔｏｏｔｈ（登録商標）からなる無線プロトコルのリストから選択される、
   請求項１に記載の方法。
3. 前記第１部分を通信する段階は、前記第２部分を通信する段階と同時に行われる、
   請求項１又は請求項２に記載の方法。
4. 前記第１無線プロトコルと前記第２無線プロトコルとを切り替える段階を備える、
   請求項１から請求項３までの何れか一項に記載の方法。
5. 前記切り替える段階は、より大きな空き容量を持つプロトコルへと切り替える段階を有する、
   請求項４に記載の方法。
6. 前記切り替える段階は、より高い品質を持つプロトコルへと切り替える段階を有する、
   請求項４に記載の方法。
7. 前記第１無線プロトコルで特定のデータを通信する段階と、前記第２無線プロトコルで前記特定のデータを再び通信する段階とを備える、
   請求項１から請求項６までの何れか一項に記載の方法。
8. 前記第１無線プロトコルで第１解像度のためのデータを送信する段階と、前記第２無線プロトコルでより高い解像度のための追加データを送信する段階とを備える、
   請求項１から請求項７までの何れか一項に記載の方法。
9. 前記第１無線プロトコルでコンテンツを通信する段階と、第２無線プロトコルで前記コンテンツの制御情報を通信する段階とを備える
   請求項１から請求項８までの何れか一項に記載の方法。
10. 前記第１無線プロトコルでビデオコンテンツを通信する段階と、第２無線プロトコルでのみ前記ビデオコンテンツの制御情報を通信する段階とを備え、
    前記第２無線プロトコルは、コンテンションベースのプロトコルであり、前記第１無線プロトコルは、スケジュールベースのプロトコルであって、
    前記制御情報は、前記第１無線プロトコル及び前記第２無線プロトコルの両方で通信されるデータに適用される
    請求項１から請求項８までの何れか一項に記載の方法。
11. 前記第１無線プロトコルは、コンテンションベースのプロトコルであり、前記第２無線プロトコルは、スケジュールベースのプロトコルであって、
    前記コンテンションベースのプロトコルは、前記スケジュールベースのプロトコルよりも優先順位が高く、前記スケジュールされる通信は、前記コンテンションベースの通信に合わせてスケジュールされる、
    請求項１から請求項８までの何れか一項に記載の方法。
12. ＭＡＣ層にて、前記データを前記第１部分及び前記第２部分に分割する段階をさらに備える、
    請求項１から請求項１１までの何れか一項に記載の方法。
13. ＰＨＹ層にて、前記データを前記第１部分及び前記第２部分に分割する段階をさらに備える、
    請求項１から請求項１２までの何れか一項に記載の方法。
14. 無線ネットワークで通信を行う装置であって、
    プロセッサ、メモリ及び無線機を有する第１デバイスを備え、
    前記第１デバイスは、請求項１から１３のいずれか一項に記載の方法を実行する装置。
15. コンピュータに、請求項１から１３のいずれか一項に記載の方法を実行させるためのプログラム。

Images