(57)【特許請求の範囲】
【請求項１】
マルチラジオデバイス内に埋め込まれるメディアアグノスティックＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）であって、
前記マルチラジオデバイス内の複数のラジオに接続されるメディアディペンデントアクセスサブレイヤであって、前記複数のラジオのそれぞれはそれの固有の物理媒体のアクセスを制御する専用のＭＡＣを有する、メディアディペンデントアクセスサブレイヤと、
メディアアグノスティックアクセスサブレイヤと、
を有し、
前記メディアアグノスティックアクセスサブレイヤは、
前記複数のラジオにより取得されたラジオリソース測定結果に基づき判定メトリックを収集するマルチラジオリソース測定ファンクションと、
前記ラジオリソース測定ファンクションにより収集されたメトリックに基づき、前記複数のラジオのアクティブ化及び／又は前記複数のラジオの２以上の集約化を実行するマルチラジオコネクションマネージメントファンクションと、
を有するマルチラジオリソースマネージメントファンクションを有し、
前記メディアアグノスティックＭＡＣは、前記複数のラジオの基礎となるラジオ動作から独立してプロトコルのスタックの上位レイヤにトランスペアレントなサービスを提供し、
前記マルチラジオリソースマネージメントファンクションはさらに、前記複数のラジオの各ラジオについて、所与のトラフィックロードのための各ラジオ無線インタフェースの要求されるアクティブ時間パターンと、前記複数のラジオのアクティブなラジオの間のコンフリクトを回避するための動作特性とを決定するマルチラジオリソース共有化及び共存コーディネーションファンクションを有し、
前記メディアアグノスティックアクセスサブレイヤはさらに、前記複数のラジオの各ラジオについて、前記上位レイヤのプロトコルに各ラジオ無線インタフェースの内外の共通のデータフォーマットを提供するジェネリックコンバージェンスファンクションを有し、
前記ジェネリックコンバージェンスファンクションは、前記上位レイヤに複数のラジオのトランスペアレントな処理を可能にするメディアアグノスティックＭＡＣ。
【請求項２】
前記マルチラジオリソースにより実行される判定メトリックは、サービス可用性、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）、ハードウェアリソースコンフリクト、干渉及びユーザ固有プロファイルを有し、
前記判定メトリックは、前記マルチラジオデバイスの前記複数のラジオのそれぞれから取得される測定結果に基づく、請求項１記載のメディアアグノスティックＭＡＣ。
【請求項３】
前記マルチラジオデバイスの複数のラジオのそれぞれから取得される測定結果は、ＣＩＮＲ（Ｃａｒｒｉｅｒ  ｔｏ  Ｉｎｔｅｒｆｅｒｅｎｃｅ−ｐｌｕｓ−Ｎｏｉｓｅ  Ｒａｔｉｏ）、ＳＩＮＲ（Ｓｉｇｎａｌ  ｔｏ  Ｉｎｔｅｒｆｅｒｅｎｃｅ−ｐｌｕｓ−Ｎｏｉｓｅ  Ｒａｔｉｏ）、ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ  Ｓｉｇｎａｌ  Ｓｔｒｅｎｇｔｈ  Ｉｎｄｉｃａｔｉｏｎ）、ＲｏＴ（Ｒｉｓｅ  ｏｖｅｒ  Ｔｈｅｒｍａｌ）、ネットワークロード、ラジオリンク故障、パケットエラーレート、ブロックエラーレート、データスループット、データ遅延及びＮＡＶ（Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）を含む、請求項２記載のメディアアグノスティックＭＡＣ。
【請求項４】
前記メディアアグノスティックアクセスサブレイヤはさらに、
マルチラジオネットワーク発見を実現するため、ラジオ間技術ネットワーク通知及びマルチラジオスキャニングをサポートするネットワーク通知及び発見ファンクションを有し、
前記複数のラジオの各ラジオのサービス可用性は、各自のラジオ無線インタフェース及び／又は他のラジオ無線インタフェースを介し通知される、請求項１記載のメディアアグノスティックＭＡＣ。
【請求項５】
前記複数のラジオを介したサービス可用性は、前記複数のラジオの１つに接続することによって取得される、請求項４記載のメディアアグノスティックＭＡＣ。
【請求項６】
前記複数のラジオの各ラジオは、前記ラジオについてサービスが利用可能であるか判断するため、前記対応するラジオ無線インタフェースをスキャンするためスイッチオンされる、請求項４記載のメディアアグノスティックＭＡＣ。
【請求項７】
前記マルチラジオリソースマネージメントファンクションはさらに、前記複数のラジオの１つのラジオから他のラジオへのハンドオーバ中に測定及び調整を提供するラジオ間モビリティサポートファンクションを有する、請求項１記載のメディアアグノスティックＭＡＣ。
【請求項８】
前記複数のラジオの各ラジオに対して明示的な共存アウェア処理を設定するマルチラジオコーディネーションインタフェースファンクションをさらに有し、
前記処理は、マルチラジオ同時処理の干渉及びリソースコンフリクトを回避するため、要求されるアクティブ時間パターンに基づく、請求項１記載のメディアアグノスティックＭＡＣ。
【請求項９】
前記ジェネリックコンバージェンスファンクションはさらに、
上位レイヤから前記複数のラジオの各アクティブなラジオへのデータパケットを分類及び配布するＭＡＣ分類ファンクションと、
前記複数のラジオの各ラジオからのデータパケットを集約化し、前記上位レイヤに送信するための所定のフォーマットに前記集約化したデータパケットを変換するＭＡＣアグリゲーション及びコンバージェンスファンクションと、
を有する、請求項１記載のメディアアグノスティックＭＡＣ。
【請求項１０】
前記ジェネリックコンバージェンスファンクションは、前記共通のデータフォーマットを計算する際に前記複数のラジオの１つのラジオを利用し、
当該メディアアグノスティックＭＡＣはさらに、前記複数のラジオの２つのラジオの間で通信するＭＡＣトンネルファンクションを有し、
前記ＭＡＣトンネルファンクションは、単一の上位レイヤスタックが前記複数のラジオの１つのラジオに関連付けされるときに利用される、請求項１記載のメディアアグノスティックＭＡＣ。
【請求項１１】
ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）及び物理（ＰＨＹ）レイヤを有する第１ラジオと、
第２ＭＡＣ及び第２ＰＨＹレイヤを有する第２ラジオと、
前記ＭＡＣと前記第２ＭＡＣとの間に接続される請求項１乃至１０何れか一項記載のメディアアグノスティックＭＡＣと、
を有するユーザ装置。
【請求項１２】
前記第１ラジオは、前記第２ラジオと異なる上位スタックを有し、
当該ユーザ装置はさらに、前記ラジオリソースマネージメントと適用可能なＱｏＳ要求と共に、前記第１及び第２ラジオの最良の動作モードを決定するため、前記第１及び第２ラジオと通信するコネクションマネージメントファンクションを有する、請求項１１記載のユーザ装置。
【請求項１３】
前記第１ラジオと前記第２ラジオとは、同一の上位スタックを有し、
当該ユーザ装置はさらに、前記第１ラジオと前記第２ラジオとの間でデータをトンネリングするＭＡＣトンネルファンクションを有する、請求項１２記載のユーザ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、マルチラジオアクセス、マルチラジオ共存及びラジオリソースマネージメント問題に関する。
【背景技術】
【０００２】
ハンドセット、モバイルインターネットデバイス（ＭＩＤ）、パームトップ及びラップトップなどの新たなモバイルデバイスは、高いデータレートを達成し、ユビキタスな接続を提供するための複数の無線技術をサポートすることが、明らかになりつつある。これらのモバイルデバイスは、ＷｉＦｉ、ブルートゥース（ＢＴ）、ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）、セルラ第２世代（２Ｇ）、及びＧＳＭ（登録商標）（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍｓ  Ｍｏｂｉｌｅ）、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）などの第３世代（３Ｇ）技術、モバイルＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ）及び／又はＬＴＥ（Ｌｏｎｇ−Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）などの新たな第４世代（４Ｇ）技術を含む。
【０００３】
ユーザの観点から、マルチラジオデバイスは、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）、コストなどの異なるニーズに従って利用可能なアクセス及びサービスから選択するフレキシビリティと共に、利用可能なネットワークにアクセスする自由度を拡張する。
【０００４】
オペレータの観点から、時間に関して各種段階でおいてマーケット及び規制を考慮した複数のアクセスシステムを組み合わせを利用することは、エンドユーザに提供されるサービスの可用性、信頼性及びキャパシティを向上させる可能性がある。
【０００５】
複数のアクセスシステムは、特定の端末能力、位置及びユーザプロファイルに依存して、配信機構の選択を介し各種コンテンツを受信するためユーザに対してシームレスにやりとりすべきである。複数のラジオはまた、同一のデバイス上で一緒に動作しなければならない。マルチラジオデバイスについて、最小の要求がシームレスなハンドオフであり、すなわち、ユーザは、サービスに影響を与えることなく１つのラジオから他のラジオにサービスをシームレスにスイッチしてもよい。複数のラジオがマルチメディアサービスを提供するため同時に動作することが予想されるシナリオがある。
【０００６】
現在のラジオアクセス技術は、独立した物理（ＰＨＹ）レイヤ及びＭＡＣレイヤ（ただし、ＭＡＣはメディアアクセスコントロールの略語である）処理を有し、モバイルスデバイス及びネットワーク側において複雑なプロトコルスタックを要求するクライアントベースモバイルインターネットプロトコル（ＩＰ）を利用する。１）無線周波数の近接性のため、アクティブな無線は互いに干渉し、２）無線周波数（ＲＦ）モジュールは、２以上の無線技術の間で共有され、３）プラットフォームとの物理インタフェースは、２以上の無線技術により共有される（例えば、パワードレイン制約が存在するなど）、という複数の理由のため、現在の状況下においてシームレスなハンドオフ又は同時のマルチラジオ処理をサポートすることは大変困難である。
【０００７】
従って、従来技術の問題点を解消するアーキテクチャが継続的に必要とされる。
【図面の簡単な説明】
【０００８】
本明細書の上記態様及び付随する効果の多くは、添付した図面に関連して行われるとき、以下の詳細な説明を参照してより良好に理解されるとき、より容易に理解されるであろう。同様の参照番号は、特段の断りがない場合、各種図面を通じて同様のパーツを参照する。
【図１】図１は、いくつかの実施例によるメディアアグノスティックＭＡＣを含むマルチラジオメディアアグノスティックアーキテクチャのブロック図である。
【図２】図２は、いくつかの実施例による図１のメディアアグノスティックＭＡＣのマルチラジオリソースマネージメントファンクションを示すブロック図である。
【図３】図３は、従来技術による複数の無線技術を含むプロトコルスタックのブロック図である。
【図４】図４は、いくつかの実施例による図１のメディアアグノスティックＭＡＣを含むプロトコルスタックのブロック図である。
【図５】図５は、いくつかの実施例による図１のメディアアグノスティックＭＡＣにより実行される処理のブロック図である。
【図６】図６は、いくつかの実施例による図１のメディアアグノスティックＭＡＣにより実行される処理のブロック図である。
【図７】図７は、いくつかの実施例による図１のメディアアグノスティックＭＡＣにより実行処理を示すフロー図である。
【図８】図８は、いくつかの実施例による図１のメディアアグノスティックＭＡＣにより実行処理を示すフロー図である。
【図９】図９は、いくつかの実施例による図１のメディアアグノスティックＭＡＣにより実行処理を示すフロー図である。
【図１０】図１０は、いくつかの実施例による図１のメディアアグノスティックＭＡＣを利用する送受信機のブロック図である。
【発明を実施するための形態】
【０００９】
ここに説明される実施例によると、マルチラジオアグノスティックアーキテクチャが開示される。マルチラジオメディアアグノスティックアーキテクチャは、ユーザ装置のラジオが同時に、シームレスに及び上位レイヤにトランスペアレントに動作するように、複数のラジオを有するラップトップコンピュータ又は携帯電話などのユーザ装置の物理レイヤとＴＣＰ／ＩＰとの間でインタフェースをとるメディアアグノスティックＭＡＣを対象とする。
【００１０】
以下の詳細な説明では、ここに説明される主題が実現可能な特定の実施例を例示的に示す添付した図面が参照される。しかしながら、他の実施例は本開示を参照した当業者に明らかになることが理解されるべきである。従って、以下の詳細な説明は、主題の範囲が請求項により規定されるため、限定的な意味で解釈されるべきでない。
【００１１】
背景セクションは、メディアアグノスティックアクセス、マルチラジオアクセス、マルチラジオ共存及びラジオリソースマネージメントに関する複数の問題を紹介した。これらの問題の解決は、１）近接した無線周波数で動作するラジオ間の干渉を回避し、２）共有されるハードウェア又は他のリソース（ＲＦ、電力など）におけるコンフリクトを回避し、３）可用性、コスト及びＱｏＳに基づきラジオのサブセットをアクティブ化し、４）ユーザにトランスペアレントな方法によりアクティブなラジオ間でサービスのロードを適切に分散し、５）マルチラジオ処理を上位レイヤにトランスペアレントにするため、同一のデバイス上に一緒に配置される複数のラジオのためのタイトクロスＭＡＣコーディネーションを要求する。
【００１２】
図１は、いくつかの実施例によるマルチラジオメディアアグノスティック（ＭＭＡ）アーキテクチャ１００の概略的なブロック図である。ＭＭＡアーキテクチャ１００は、ＴＣＰ／ＩＰレイヤ２０と物理（ＰＨＹ）レイヤ９０との間に配置されるメディアアグノスティックＭＡＣ５０を有する。メディアアグノスティックＭＡＣ５０は、メディアアグノスティックアクセス（ＭＡＡ）サブレイヤ３０とメディアディペンデントアクセス（ＭＤＡ）サブレイヤ８０とを有する。ＭＡＡサブレイヤ３０は、マルチラジオリソースマネージメントファンクション４０、マルチラジオコーディネーションインタフェースファンクション６０及びジェネリックコンバージェンスファンクション７０を有する。ＭＤＡサブレイヤ８０は、ＷｉＦｉ８２、ＷｉＭＡＸ８４、３Ｇ／ＬＴＥなどの現在の無線アクセス技術と、まだ未知の新たな技術８８の１以上とを含む。
【００１３】
いくつかの実施例では、マルチラジオアウェア処理を実現するため、メディアアグノスティックＭＡＣ５０は、各ラジオの動作を調整することが可能である。メディアアグノスティックＭＡＣ５０のＭＡＡサブレイヤ３０の部分は、基礎となる無線処理（ＭＤＡサブレイヤ８０における）から独立して、上位レイヤ（例えば、ＴＣＰ／ＩＰレイヤ２０又はアプリケーションレイヤなど）にトランスペアレントなサービスを提供する。いくつかの実施例では、ＭＡＡサブレイヤ３０は、
・不適切にガイドされる無線インタフェース動作を防ぎ、フレームロスを減少し、ラジオ間のシームレスなインタラクションを可能にすることによる無線媒体及びスペクトルの効率的な利用
・より多くのマルチラジオ同時利用をサポートし、機能及びパフォーマンスを犠牲にすることなくより安価／小型なデバイスを提供することにより向上したユーザ体感
・スペクトル／無線に提供される統一された無線リソース測定／管理
を提供する。
【００１４】
メディアアグノスティックＭＡＣ５０は、マルチラジオアウェアＭＡＣである。いくつかの実施例では、メディアアグノスティックＭＡＣ５０は、以下の性質を有する。
・予測可能性：各ラジオの活動（送信、受信、スイッチオフ）は、他のラジオがコンフリクトを回避するように予測可能なパターンに従う。
・圧縮可能性：各ラジオは、他のラジオが動作することを可能にするよう送信／受信期間及びデューティサイクルを最小化する。
・選択可能性：時分割多重的に他のラジオの活動に従って自らの動作をピアと連携させるための各ラジオ内の標準的なインタフェースが存在する。
【００１５】
ＭＤＡサブレイヤ８０の各ラジオは、自らのＭＡＣレイヤを有する。従って、図１では、ＷｉＦｉラジオ８２はＷｉＦｉ  ＭＡＣ８２Ａを有し、ＷｉＭＡＸラジオ８４はＷｉＭＡＸ  ＭＡＣ８４Ａを有し、３Ｇ／ＬＴＥラジオ８６は３Ｇ／ＬＴＥ  ＭＡＣ８６Ａを有し、何れかの新技術ラジオ８８はそれ自体のＭＡＣ８８Ａを有する。ラジオＭＡＣ８２Ａ、８４Ａ、８６Ａ、８８Ａはそれぞれ、それらがサポートするラジオに専用のものであり、すなわち、これらのＭＡＣは同様に動作する必要はない。各ラジオは、シームレスなマルチラジオ動作をサポートするため、異なる無線インタフェースを有するため、ＭＡＡサブレイヤ３０は、各ラジオ８２，８４，８６，８８のＭＡＣ８２Ａ，８４Ａ，８６Ａ，８８Ａと、ＴＣＰ／ＩＰレイヤ２０又はアプリケーションレイヤ（図示せず）などの１以上の上位レイヤとの間のインタフェースとして動作する。
【００１６】
図２は、いくつかの実施例によるメディアアグノスティックＭＡＣ５０の拡張されたマルチラジオリソースマネージメント（ＭＲＲＭ）ファンクション４０の概略的なブロック図である。ＭＲＲＭファンクション４０は、マルチラジオメディアアグノスティックアーキテクチャ１００のＭＡＡサブレイヤ３０の一部である（図１）。ＭＲＲＭファンクション４０は、以下のファンクション、すなわち、ネットワーク通知及び発見４２、マルチラジオリソースマネージメント４４、マルチラジオコネクションマネージメント４６、マルチラジオリソース共有及び共存コーディネーション４８及びラジオ間モビリティサポート５２をサポートする。これらのファンクションのそれぞれが、以下においてより詳細に説明される。
【００１７】
ネットワーク通知及び発見４２  マルチラジオネットワーク通知及び発見ファンクション４２は、マルチラジオネットワーク検出を実現するため、ラジオ間技術ネットワーク通知及びマルチラジオスキャニングをサポートする。
【００１８】
リソース測定４４  マルチラジオリソース測定ファンクション４４は、複数のラジオチャネルに対する測定及び判定メトリックを提供する。可能な程度まで、リソースマネージメントファンクション４４は、各ラジオにおける既存の測定結果の最大限の再利用を実現する。サービスの可用性と複数のラジオ間のＱｏＳのレベルを確実に予測するため、当該ファンクション４４により必要とされるような追加的なエンハンスメントに対してさらなる測定が規定されてもよい。また、スキャニング／測定手順は、マルチラジオコンフィギュレーションに従って当該ファンクション４４により調整されてもよい（期間及び持続期間など）。
【００１９】
いくつかの実施例では、リソースマネージメントファンクション４４により実行される判定メトリックは、限定することなく、ＣＩＮＲ（Ｃａｒｒｉｅｒ  ｔｏ  Ｉｎｔｅｒｆｅｒｅｎｃｅ−ｐｌｕｓ−Ｎｏｉｓｅ  Ｒａｔｉｏ）、ＳＩＮＲ（Ｓｉｇｎａｌ  ｔｏ  Ｉｎｔｅｒｆｅｒｅｎｃｅ−ｐｌｕｓ−Ｎｏｉｓｅ  Ｒａｔｉｏ）、ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ  Ｓｉｇｎａｌ  Ｓｔｒｅｎｇｔｈ  Ｉｎｄｉｃａｔｉｏｎ）、ＲｏＴ（Ｒｉｓｅ  ｏｖｅｒ  Ｔｈｅｒｍａｌ）、ロード、ＮＡＶ（Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）、ラジオリンク故障、スループット、遅延などを含む。
【００２０】
ラジオ８２，８４，８６，８８は、指定された動作チャネルに対して測定を実行する。チャネルクオリティ、信号強度、チャネルノイズ及び干渉などの測定結果は、ラジオによって定期的に取得される。これらの測定結果は、拡張されたＭＲＲＭ４０のマルチラジオリソースマネージメントファンクション４４により定期的に受信及び処理される。
【００２１】
マルチラジオコネクションマネージメント４６  コネクションマネージメントファンクション４６は、ラジオ環境アウェアラジオアクティブ化、スイッチング及びアグリゲーションファンクションである。利用可能なラジオリソース測定結果に基づき、当該ファンクション４６は、アクティブ化すべき最良のラジオを決定し、複数のラジオ間の高速スイッチング処理を実行し、所望の接続性及びＱｏＳを提供するため複数のラジオを集約する。
【００２２】
マルチラジオリソース共有及び共存コーディネーション４８  リソース共有ファンクション４８は、アクティブなラジオ間のコンフリクトを回避するため、所与のトラフィックロード及びアプリケーション特性のための各ラジオ無線インタフェースの要求されるアクティブ時間パターンを決定する。
【００２３】
ラジオ間モビリティサポート５２  モビリティサポート機能５２は、複数のラジオ技術間のシームレスなハンドオーバを実現するための測定及び連携を提供する。
【００２４】
図１を参照して、マルチラジオメディアアグノスティックアーキテクチャ１００のＭＡＡサブレイヤ３０はまた、マルチラジオコーディネーションインタフェースファンクション６０を有する。いくつかの実施例では、マルチラジオコーディネーションインタフェース６０は、マルチラジオ同時処理のリソースコンフリクト及び干渉を回避するため、要求されるアクティブ時間パターンに基づき、各ラジオインタフェースに対する明示的な共存アウェア処理を設定する。
【００２５】
マルチラジオメディアアグノスティックアーキテクチャ１００のＭＡＡサブレイヤ３０はまた、上位レイヤに対する複数のラジオのトランスペアレントな処理を可能にするため、各ラジオ無線インタフェースの内外に共通するデータフォーマットを上位レイヤプロトコルに提供するジェネリックコンバージェンスファンクション７０を有する。いくつかの実施例では、上位レイヤからのデータは分類され、複数のラジオインタフェースに分散される。いくつかの実施例では、複数のラジオインタフェースからのデータは、上位レイヤに配信される前に共通のフォーマットに収束される。
【００２６】
図３及び４は、図１のマルチラジオメディアアグノスティックアーキテクチャ１００と従来技術によるプロトコルスタック１２０とを対比するのに利用される概略ブロック図である。従来技術によるプロトコルスタック１２０は、アプリケーションレイヤ１２２、ＴＣＰ／ＩＰレイヤ２０、ＷｉＦｉ８２、ＷｉＭＡＸ８４、３Ｇ／ＬＴＥ８６及び新技術８８などの複数のラジオ１２６を有する。複数のラジオは、自らのＭＡＣ（８２Ａ，８４Ａ，８６Ａ，８８Ａ）とＰＨＹ（８２Ｂ，８４Ｂ，８６Ｂ，８８Ｂ）とを有する。１つのラジオのＰＨＹ及びＭＡＣは、他のラジオのＰＨＹ及びＭＡＣから独立して動作する。メディアアグノスティックアーキテクチャ１００において、メディアアグノスティックＭＡＣレイヤ５０は、ＴＣＰ／ＩＰレイヤ２０と複数のラジオ（８２，８４，８６，８８）との間のインタフェースとして機能する。メディアアグノスティックＭＡＣ５０は、複数のラジオ無線インタフェースをブリッジし、スタックの上位レイヤ（ＭＡＣの上位など）にユニバーサルインタフェースを提供する。
【００２７】
従来技術によるプロトコルスタック１２０のラジオは、メディアに依存した離散的な要素（４つの別々のオレンジボックス）であり、メディアアグノスティックＭＡＣ５０は、メディアから独立して統合されている（単一のブルーボックス）。ＷｉＦｉ  ＭＡＣ８２ＡとＰＨＹ８２Ｂとの間の接続７２はＲＦ／ＢＢコントロールである。ラジオ間インタフェース７４は、図３に示されるように、非ＷｉＦｉラジオの各種ＭＡＣ間を接続する。ラジオ間インタフェース７４は、メディアアグノスティックＭＡＣ５０より機能が限定されたラジオの異なるＭＡＣ間の外部の連携機能として利用される。
【００２８】
図５は、いくつかの実施例による２つのラジオ、ＷｉＦｉラジオ８２及び３Ｇ／ＬＴＥラジオ８６とを有するモバイルデバイス（ユーザ装置）２０の一例である。図は、複数のラジオをサポートする際にメディアアグノスティックＭＡＣ５０により実行される処理を示す。（ＷｉＦｉラジオ８２のための）アプリケーションレイヤ９２Ａ、ＴＣＰ／ＵＤＰレイヤ９４Ａ及びＩＰレイヤ９６Ａと共に、（ＬＴＥラジオ８６のための）アプリケーションレイヤ９２Ｂ、ＴＣＰ／ＵＤＰレイヤ９４Ｂ及びＩＰレイヤ９６Ｂを含むプロトコルスタックの上位レイヤがある。
【００２９】
図５に示されるように、これら２つのラジオは異なる内部アーキテクチャを有する。図１において紹介されたＭＡＣに加えて、ＷｉＦｉラジオ８２はＩＰレイヤ及びＭＡＣレイヤ８２Ａと物理レイヤ（ＰＨＹ８２Ｃ）との間に配置されたＮＤＩＳ  ＩＭ（Ｎｅｔｗｏｒｋ  Ｄｒｉｖｅｒ  Ｉｎｔｅｒｆａｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ／Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｄｒｉｖｅｒ）８２Ｂを有する。ＬＴＥラジオ８６は、ＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）レイヤ８６Ｂ、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ８６Ｃ、ＭＡＣレイヤ８６Ａ及び物理レイヤ８６Ｄを有する。
【００３０】
メディアアグノスティックＭＡＣ５０のリソース測定ファンクション４４（図２）は、複数のラジオチャネルに対して測定結果及び判定メトリックを収集及び伝達する。これらの測定結果は、ユーザ装置２０において検出されたラジオから取得される。いくつかの実施例では、リソース測定ファンクション４４は、ユーザ装置２０の動作の初期段階においてこれらのメトリックを取得するが、当該メトリックはまた定期的に取得されてもよい。リソース測定ファンクション４４により取得されるメトリックは、複数のラジオが干渉フリー及びハードウェアコンフリクトフリーに動作することを保証するため、複数のラジオのＭＡＣ処理を調整するリソース共有及び共存コーディネーションファンクション４８を含むメディアアグノスティックＭＡＣ５０の他の部分に伝達される。リソース測定ファンクション４４により取得されるメトリックは、ラジオアクティブ化／スイッチング／アグリゲーションファンクションを実行するコネクションマネージメントファンクション４６に伝達される。コネクションマネージメントファンクション４６は、ラジオリサーチ測定結果及びアプリケーションＱｏＳ要求に基づき、複数のラジオの最良の動作モードを決定するため、双方のラジオと通信する。
【００３１】
図６は、いくつかの実施例による２つのラジオであるＷｉＦｉラジオ８２及び３Ｇ／ＬＴＥラジオ８６を有するモバイル装置（ユーザ装置）２０の他の例を示す。本例では、双方のラジオは、アプリケーションレイヤ９２Ａ、ＴＣＰ／ＵＤＰレイヤ９４Ａ及びＩＰレイヤ９６Ａを含む同一の上位スタックを共有する。上位スタックはこれら２つのラジオにおいて異なっていないため、前の具体例と同様にコネクションマネージメントファンクション４６は必要でない。代わりに、本例では、ＭＡＣトンネル４７は、ＷｉＦｉラジオ８２からＬＴＥラジオ８６へのデータを制御し、その反対も行う。メディアアグノスティックＭＡＣ５０のリソースマネージメントファンクション４４は、複数のラジオチャネルに対して測定結果及び判定メトリックを収集及び伝達する。これらの測定結果は、ユーザ装置２０において検出されたラジオから取得される。いくつかの実施例では、リソース測定ファンクション４４は、ユーザ装置２０の動作の初期段階においてこれらのメトリックを取得するが、当該メトリックはまた定期的に取得されてもよい。リソース測定ファンクション４４により取得されたメトリックは、複数のラジオが干渉フリー及びハードウェアコンフリクトフリーに動作することを保証するため、複数のラジオのＭＡＣ処理を調整するリソース共有及び共存コーディネーションファンクション４８を含むメディアアグノスティックＭＡＣ５０の他の部分に伝達される。
【００３２】
リソース測定ファンクション４４により取得されるメトリックはまた、ＬＴＥ  ＰＤＣＰレイヤ（８６Ｄ）からＷｉＦｉ  ＭＡＣレイヤ（８２Ａ）にパケットをトンネリングすべきか判断するＭＡＣトンネルファンクション４７に伝達される。ジェネリックコンバージェンスファンクション７０（図１）の一部として、ＭＡＣトンネルファンクション４７は、ラジオリサーチ測定結果及びアプリケーションのＱｏＳ要求に基づき、複数のラジオの最良の動作モードを決定するため、双方のラジオと通信する。トンネリングによって、ＷｉＦｉ及びＬＴＥデータストリームは、ＬＴＥサイドのトンネルのエンドにおいて収束する。
【００３３】
図７，８，９は、いくつかの実施例によるユーザ装置２０において複数のラジオをサポートする際のメディアアグノスティックＭＡＣ５０の処理を示すフロー図である。図７はユーザ装置２０を初期化する際に実行される処理を示し、図８はクオリティイシューによりもたらされるユーザ装置２０のラジオスイッチング処理を示し、図９は定期的に行われるラジオスイッチング処理を示す。
【００３４】
図７において、初期化中、メディアアグノスティックＭＡＣ５０は、それのプライマリラジオをスイッチオンする（ブロック２０２）。いくつかの実施例では、プライマリ又はデフォルトラジオは、２Ｇ／３Ｇ／ＬＴＥラジオ８６などのワイドレンジセルララジオである。当該ラジオについてサービスが発見された場合（ブロック２０４）、デバイスはプライマリラジオにより提供されるサービスに接続する（ブロック２０６）。
【００３５】
いくつかの実施例では、プライマリラジオとの接続が確立されると、メディアアグノスティックＭＡＣ５０は、任意的には、他のラジオのサービス／ネットワーク通知を受信する（ブロック２０８）。受信した情報とユーザ装置２０のポリシー及びサービス要求とに基づき（ブロック２１０）、当該デバイスは、追加的なラジオとの接続を確立することを選択してもよい（ブロック２１２）。いくつかの実施例では、サービス／ネットワーク通知が他のラジオについて受信されていない場合、当該端末は、ネットワーク／サービスをスキャンするため、これらのラジオをスイッチオンし（ブロック２１４）、それのサービス及びポリシーニーズに基づき追加的なラジオとの接続（ブロック２１２）を確立してもよい（ブロック２１６）。
【００３６】
図８のフロー図は、いくつかの実施例によるラジオスイッチング処理がどのように実行されるかを示す。ラジオスイッチングは、いくつかのシナリオにおいてトリガーされてもよい。まず、既存のコネクションは、ＱｏＳイシュー、ユーザ装置モビリティ、チャネルフェージング、干渉又はネットワークの輻輳のため維持できない可能性がある。第２に、他のラジオはより良好なＱｏＳ又は低いコスト（セルラからＷｉＦｉなど）を提供してもよい。双方のシナリオにおいて、ラジオ及びサービスクオリティは、アクティブなラジオについてモニタリングされる。
【００３７】
図８は、既存の接続が維持できない第１シナリオ下でラジオ間をスイッチするためＭＡＣ５０により実行される処理を示す。まず、ＭＡＣ５０は、アクティブなラジオの無線及びサービスクオリティをモニタリングする（ブロック３０２）。無線又はサービスクオリティがある閾値以下に低下した場合（ブロック３０４）、ラジオスイッチアクションがトリガされる。第１の非アクティブラジオが、まず可用性について（ブロック３０８）、その後にクオリティについて（ブロック３１０）についてチェックされる（ブロック３０６）。可用性とクオリティとの双方が存在する場合、ＭＡＣ５０は、新たなラジオをスイッチオンする（ブロック３１２）。ラジオの可用性又はクオリティが適切でない場合、ＭＡＣ５０は、他の非アクティブなラジオが利用可能であるかチェックする（ブロック３１４）。利用可能である場合、当該処理は新たな非アクティブなラジオについて繰り返される。利用可能なラジオがクオリティ基準を充足しない場合、ユーザ装置のラジオサービスは破棄される（ブロック３１６）。
【００３８】
図９は、ユーザ装置２０の最適なラジオが定期的に確認される第２シナリオ下においてラジオ間をスイッチするためＭＡＣ５０により実行される処理を示す。当該処理は、ＭＡＣ５０がアクティブなラジオの無線及びサービスクオリティをモニタリングすることから開始される（ブロック４０２）。他のラジオをチェックするための発生すると（ブロック４０４）、ＭＡＣ５０は、非アクティブなラジオが利用可能であるか判断するため（ブロック４０８）、第１の非アクティブなラジオをチェックし（ブロック４０６）、その後、それのクオリティがアクティブなラジオを特定の閾値だけ超過するか判断する（ブロック４１０）。超過している場合、ＭＡＣ５０は、他のラジオにスイッチする（ブロック４１２）。これらの処理は、利用可能な各非アクティブラジオについて実行される（ブロック４１４）。当該閾値を超過していない場合、現在アクティブなラジオの処理が維持される（ブロック４１６）。
【００３９】
いくつかのシナリオでは、ユーザ装置の複数のラジオが、電力、メモリ又はアンテナなどのシステムリソースについて競合するように同時にアクティブである。あるいは、ラジオは、隣接する帯域上で動作しているときなど、互いに干渉する可能性がある。マルチラジオコーディネイションインタフェースファンクション（６０）は、リソースコンフリクト及び相互干渉を回避するため、複数のラジオの処理を調整する。
【００４０】
マルチラジオリソース測定ファンクション４４は、複数のラジオチャネルに対する測定結果を提供する。可能な程度まで、リソース測定ファンクション４４は、各ラジオにおいて既存の測定結果を最大限再利用する。追加的な測定結果が、当該ファンクション４４により必要とされるような追加的なエンハンスメントについて規定される。また、スキャニング／測定手順が、マルチラジオコンフィギュレーションに従って当該ファンクション４４により調整されてもよい（期間及び長さなど）。
【００４１】
物理レイヤ（ＰＨＹ）は、上位レイヤにおいて構成されるパケットを送受信するため無線波を利用する。いくつかの実施例では、ＰＨＹレイヤは、高周波数及びアナログデバイスを含むＲＦ送受信機を有し、システムの残りは、デジタル回路及び埋め込みソフトウェアにより実現される。ベースバンド部分は、ＲＦチップとシステムの残りとの間のインタフェースである。
【００４２】
従来技術は、無線技術に固有のものであり、無線技術の利用に依存してネットワークサイドとクライアントサイドとの双方において異なる手段が要求される。専用の手段が存在するが、それらは無線依存性が高く、他のラジオアーキテクチャにスケーラブルでない。他方、提案されるマルチラジオメディアアグノスティックアーキテクチャ１００は、スケーラブルな方法により各種ラジオの組み合わせの処理に対処するための共通のフレームワークを提供する。
【００４３】
そのアイデアは、デバイスにおいて又はネットワークサイドにおいて単一のアーキテクチャによるシームレスなマルチラジオ処理を可能にする汎用的な形態のソリューションフレームワークを提案する。提案されるソリューションは、
・不適切にガイドされる無線インタフェース動作を回避し、フレームロスを低減し、ラジオ間のシームレスなインタラクションを可能にすることによって、無線媒体及びスペクトルのより効率的な利用を提供し、
・マルチラジオ同時動作の利用をサポートし、機能及びパフォーマンスを犠牲にすることなくより安価／小型なデバイスを提供することによって、ユーザ体感を向上させ、
・各ラジオの特定のインタフェースを処理することなくマルチラジオシステムの可能性を上位レイヤ（アプリケーションなど）開発者がフル活用することがより容易になるように、上位レイヤとのインタフェースをシンプル化する。
【００４４】
図１０は、いくつかの実施例によるマルチラジオ動作をシームレスにサポートするため、図１のメディアアグノスティックＭＡＣ５０を利用する送受信機５００のブロック図である。送受信機５００は、送受信機５００により送受信されたデータパケットを処理するためプロセッサ５４０及びメモリ５６０を有する。１以上のアンテナ５１０は、リモート送信機により送信されたデータパケットを受信し、リモート受信機にデータパケットを送信するため利用される。
【００４５】
図１０の記載は、送受信機５００、ＭＡＣ５０及び省略されてもよい他のデバイス、回路及びロジック要素の簡略化された表示である。ＭＡＣ５０は、フロントエンド５２０、デジタル・アナログコンバータ／アナログ・デジタルコンバータ（図示せず）、１以上のラジオ５５０Ａ，．．．，５５０Ｎ（まとめてラジオ５５０）及びベースバンドデジタル信号プロセッサ（図示せず）という送信機及び受信機に通常あるロジックデバイスとインタフェースをとる。ＭＡＣ５０内のロジックデバイスは、ハードウェア、ソフトウェア又はハードウェア及びソフトウェアコンポーネントの組み合わせから構成されてもよい。
【００４６】
ターゲットモジュール５０は、大部分の送信機及び受信機に通常ある。フロントエンド５２０は、アンテナ５１０に接続され、パワーアンプ５３０（送信機用）、低ノイズアンプ（受信機用）及び送信モードと受信モードとの間でスイッチするためのアンテナスイッチ（図示せず）を有してもよい。各回路は、バス（図示せず）により一緒に接続されてもよい。
【００４７】
本出願が限定数の実施例に関して説明されたが、当業者は、そこから多数の改良及び変形を理解するであろう。添付した請求項は、本発明の真の趣旨及び範囲に属するものとしてこのような全ての改良及び変形をカバーすることが意図される。
【図１】
0005914665.tif 000002
【図２】
0005914665.tif 000003
【図３】
0005914665.tif 000004
【図４】
0005914665.tif 000005
【図５】
0005914665.tif 000006
【図６】
0005914665.tif 000007
【図７】
0005914665.tif 000008
【図８】
0005914665.tif 000009
【図９】
0005914665.tif 000010
【図１０】
0005914665.tif 000011