JP2013528976A - ラジオを選択し、無線デバイス上でラジオにアプリケーションをマッピングするための方法および装置 - Google Patents

Abstract

ラジオを選択し、無線デバイス上でのラジオへのアプリケーションをマッピングするための技法が説明されている。無線ネットワークは、アクティブである少なくとも１つのアプリケーションと、使用のために利用可能である複数のラジオを有しうる。一設計では、無線デバイスは、少なくとも１つのアプリケーションの要件を決定し、そしてそれは、スループット、レイテンシ、ジッタ等に関連していることがある。無線デバイスは、少なくとも１つのアプリケーションの要件と場合によっては他の要因に基づいて、複数のラジオの中から少なくとも１つのラジオを選択する。無線デバイスは、少なくとも１つのアプリケーションの要件、少なくとも１つのラジオの性能、および／または他の要因に基づいて、少なくとも１つのアプリケーションの、少なくとも１つのラジオへのマッピングを決定する。無線デバイスは、マッピングに基づいて少なくとも１つのラジオに少なくとも１つのアプリケーションをマッピングする。
【選択図】 図５Ｂ

Description

優先権の主張

本願は、「METHOD AND APPARATUS FOR FRACTIONAL SYSTEM SELECTION IN A WIRELESS SYSTEM」と題された米国仮出願番号第６１／３２０，０３５号と、「METHOD AND APPARATUS FOR CONNECTION MANAGER/COEXISTENCE MANAGER INTERACTION IN A WIRELESS SYSTEM」と題された米国仮出願番号第６１／３２０，０４１号の優先権を主張し、双方とも２０１０年４月１日に出願され、ここでの譲受人に譲渡され、参照によりここに組み込まれる。

本開示は、一般的には、通信に関し、より具体的には、無線通信デバイスによる通信をサポートするための技法に関する。

無線通信ネットワークは、音声、ビデオ、パケットデータ、メッセージング、ブロードキャスト等のような様々な通信コンテンツを提供するように幅広く展開されている。これらの無線ネットワークは、利用可能なネットワークリソースを共有することによって複数のユーザをサポートすることができる多元接続ネットワークでありうる。このような多元接続ネットワークの例は、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交ＦＤＭＡ（ＯＦＤＭＡ）ネットワーク、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）ネットワークを含む。

無線通信デバイスは、異なる無線通信ネットワークとの通信をサポートするために多数のラジオを含めうる。無線デバイスはまた、異なる要件を有しうる、多数のアプリケーションをサポートしうる。良好な性能が達成されることができるように無線デバイス上でアクティブなアプリケーションのための通信をサポートすることが望ましい場合がある。

ラジオを選択し、無線デバイス上でラジオにアプリケーションをマッピングするための技法がここにおいて説明されている。無線デバイスは、アクティブである少なくとも１つのアプリケーションと使用に利用可能である複数のラジオを有しうる。各ラジオは特定のラジオ技術をサポートし、送信機または受信機でありうる。無線デバイスは、少なくとも１つのアプリケーションのアカウント要件を考慮することによって、使用するために少なくとも１つのラジオを選択しうる。無線デバイスは、良好な性能が達成されることができるように、少なくとも１つのラジオに少なくとも１つのアプリケーションをマッピングしうる。

一設計では、無線デバイスは、無線デバイス上でアクティブな少なくとも１つのアプリケーションの要件を決定しうる。少なくとも１つのアプリケーションの要件は、スループット、レイテンシ、ジッタ、接続時間、呼出ドロップレート等に関連しうる。無線デバイスは、少なくとも１つのアプリケーションの要件、少なくとも１つのアプリケーションのラジオ優先度、利用可能なラジオのプライオリティ、ラジオの性能、ラジオ間の干渉、１つまたは複数の無線ネットワークに対する影響等に基づいて無線デバイス上で複数のラジオから少なくとも１つのラジオを選択しうる。

一設計では、無線デバイスは、少なくとも１つのアプリケーションの要件、少なくとも１つのラジオの性能、および／または他の要因に基づいて、少なくとも１つのアプリケーションの少なくとも１つのラジオへのマッピングを決定しうる。無線デバイスは、マッピングに基づいて少なくとも１つのラジオに少なくとも１つのアプリケーションをマッピングしうる。無線デバイスは、少なくとも１つのラジオを反復的に選択し、複数の反復についてのマッピングを決定し、性能を改善しうる。

一設計では、無線デバイスは、利用可能なラジオ間の干渉に関する少なくとも１つのメトリックに基づいて少なくとも１つのラジオの性能を決定しうる。無線デバイスは、ラジオ間の干渉および／または少なくとも１つのアプリケーションの要件に基づいて少なくとも１つのラジオの各々のオペレーティング状態を設定しうる。一設計では、無線デバイスは、少なくとも１つのラジオの性能に基づいて少なくとも１つのアプリケーションの要件を動的／適応的に変更しうる。

本開示の様々な態様および特徴が、下記でさらに詳述される。

図１は、様々な無線ネットワークと通信する無線デバイスを示す。 図２は、無線デバイスのブロック図を示す。 図３Ａは、複数のアプリケーションのためのフルシステム選択を図示する。 図３Ｂは、アプリケーションのためのフローモビリティを図示する。 図３Ｃは、アプリケーションのためのフローモビリティを図示する。 図３Ｄは、アプリケーションのためのフラクショナルフローモビリティを図示する。 図４Ａは、複数のアプリケーションのためのフラクショナルシステム選択を図示する。 図４Ｂは、アプリケーションのためのフラクショナルフローモビリティを図示する。 図４Ｃは、アプリケーションのためのフラクショナルハンドオーバを図示する。 図５Ａは、１つのアプリケーションのためのフラクショナルシステム選択を図示する。 図５Ｂは、複数のアプリケーションのためのフラクショナルシステム選択を図示する。 図６は、１つまたは複数のラジオにアプリケーションをマッピングするためのプロセスを図示する。 図７は、アプリケーションのためのシステム選択を実行するプロセスを図示する。 図８Ａは、無線デバイス上の共存マネージャと接続マネージャとの間の一方向および双方向インタラクションを図示する。 図８Ｂは、無線デバイス上の共存マネージャと接続マネージャとの間の一方向および双方向インタラクションを図示する。 図９Ａは、接続マネージャと共存マネージャとの間の反復的な双方向インタラクションの２つの設計を図示する。 図９Ｂは、接続マネージャと共存マネージャとの間の反復的な双方向インタラクションの２つの設計を図示する。 図１０は、アプリケーション要件に基づいてシステム選択を実行するプロセスを図示する。

詳細な説明

図１は、複数の無線通信ネットワークと通信することができる無線通信デバイス１１０を図示する。これらの無線ネットワークは、１つまたは複数の無線広域ネットワーク（ＷＷＡＮ）１２０および１３０、１つまたは複数の無線ローカルエリアネットワーク（ＷＬＡＮ）１４０および１５０、１つまたは複数の無線パーソナルエリアネットワーク（ＷＰＡＮ）１６０、１つまたは複数のブロードキャストネットワーク１７０、１つまたは複数の衛星測位システム１８０、図１に図示されていない他のネットワークおよびシステム、またはそれらのいずれの組み合わせを含めうる。用語「ネットワーク」および「システム」は、しばしば互換性をもって使用される。ＷＷＡＮはセルラネットワークでありうる。

セルラネットワーク１２０および１３０はそれぞれ、ＣＤＭＡネットワーク、ＴＤＭＡネットワーク、ＦＤＭＡネットワーク、ＯＦＤＭＡネットワーク、ＳＣ−ＦＤＭＡネットワークまたは他の何らかのネットワークでありうる。ＣＤＭＡネットワークは、ユニバーサル地上ブロードキャストアクセス（ＵＴＲＡ）、ｃｄｍａ２０００等のようなラジオ技術または無線インタフェースを実装しうる。ＵＴＲＡは、広域ＣＤＭＡ（ＷＣＤＭＡ）およびＣＤＭＡの他の変形を含む。ｃｄｍａ２０００は、ＩＳ−２０００，ＩＳ−９５，およびＩＳ−８５６規格をカバーする。ＩＳ−２０００は、ＣＤＭＡ １Ｘとも呼ばれ、ＩＳ−８５６は、エボリューションデータ最適化（ＥＶＤＯ）とも呼ばれる。ＴＤＭＡネットワークは、モバイル通信のためのグローバルシステム（ＧＳＭ（登録商標））、デジタルアドバンスドモバイル電話システム（Ｄ−ＡＭＰＳ）等のようなラジオ技術を実装しうる。ＯＦＤＭＡネットワークは、発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ）、ウルトラモバイルブロードバンド（ＵＭＢ）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ８０２．２０、フラッシュＯＦＤＭ（登録商標）等のようなラジオ技術を実装しうる。ＵＴＲＡおよびＥ−ＵＴＲＡは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）の一部である。３ＧＰＰロングタームエボリューション（ＬＴＥ）およびＬＴＥアドバンスド（ＬＴＥ−Ａ）は、Ｅ−ＵＴＲＡを使用するＵＭＴＳの新規リリースである。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＵＭＴＳ、ＬＴＥ、ＬＴＥ−ＡおよびＧＳＭは、「第３世代パートナーシッププロジェクト」（３ＧＰＰ）と名づけられた団体の文書の中で説明されている。ｃｄｍａ２０００およびＵＭＢは、「第３世代パートナーシッププロジェクト２」（３ＧＰＰ２）と名づけられた団体の文書の中で説明されている。セルラネットワーク１２０および１３０は、それぞれ、無線デバイスのための双方向通信をサポートすることができる、基地局１２２および１３２を含めうる。

ＷＬＡＮ１４０および１５０は各々、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ（登録商標））、Ｈｉｐｅｒｌａｎ等のようなラジオ技術を実装しうる。ＷＬＡＮ１４０および１５０は、それぞれ、無線デバイスのための双方向通信をサポートすることができる、アクセスポイント１４２および１５２を含めうる。ＷＰＡＮ１６０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）（ＢＴ），ＩＥＥＥ８０２．１５等のようなラジオ技術を実装しうる。ＷＰＡＮ１６０は、無線デバイス１１０、ヘッドセット１６２、コンピュータ１６４、マウス１６６等のような様々なデバイスのための双方向通信をサポートしうる。

ブロードキャストネットワーク１７０は、テレビ（ＴＶ）ブロードキャストネットワーク、周波数変調（ＦＭ）ブロードキャストネットワーク、デジタルブロードキャストネットワーク等でありうる。デジタルブロードキャストネットワークは、ＭｅｄｉａＦＬＯ（登録商標）、ハンドヘルド用のデジタルビデオブロードキャスティング (ＤＶＢ−Ｈ)、地上テレビブロードキャスティングのための統合サービスデジタルブロードキャスティング（ＩＳＤＢ−Ｔ）、アドバンスドテレビジョンシステムコミッティー−モバイル／ハンドヘルド（ＡＴＳＣ−Ｍ／Ｈ）等のようなラジオ技術を実装しうる。ブロードキャストネットワーク１７０は、一方向通信をサポートすることができる１つまたは複数のブロードキャスト局１７２を含めうる。

衛星測位システム１８０は、米国の全地球測位システム（ＧＰＳ）、欧州のガリレオシステム、ロシアのＧＬＯＮＡＳＳシステム、日本の準天頂衛星システム(Quasi-Zenith Satellite System)（ＱＺＳＳ）、インドの領域ナビゲーショナル衛星システム(Indian Regional Navigational Satellite System)（ＩＲＮＳＳ）、中国の北斗（Ｂｅｉｄｏｕ）システム等でありうる。衛星測位システム１８０は、位置決めに使用される信号を送信する多数の衛星１８２を含めうる。

無線デバイス１１０は、固定またはモバイルでありうる、また、ユーザ機器（ＵＥ）、移動局、モバイル機器、端末、アクセス端末、加入者ユニット、局等とも呼ばれる。無線デバイス１１０は、セルラ電話、携帯情報端末（ＰＤＡ）、無線モデム、ハンドヘルドデバイス、ラップトップコンピュータ、コードレス電話、無線ローカルループ（ＷＬＬ）局、スマートフォン、ネットブック、スマートブック、タブレット、ブロードキャスト受信機等でありうる。無線デバイス１１０は、セルラネットワーク１２０および／または１３０、ＷＬＡＮ１４０および／または１５０、ＷＰＡＮ１６０内のデバイス等と双方向で通信しうる。無線デバイス１１０はまた、ブロードキャストネットワーク１７０、衛星測位システム１８０等から信号を受信しうる。一般に、無線デバイス１１０は、所与の時間において、任意の数の無線ネットワークおよびシステムと通信しうる。

図２は、ホストサブシステム２１０とラジオサブシステム２３０を含む、無線デバイス１１０の設計のブロック図を図示する。図２で図示される設計では、ホストサブシステム２１０は、ホストプロセッサ２２０とメモリ２２２を含む。無線デバイス１１０は、Ｌ個のアプリケーション２２４ａ〜２２４ｌをサポートしうる、そしてそれは、音声、パケットデータ、ビデオ共有、ビデオ電話、ｅメール、ブロードキャスト受信、インスタントメッセージング、プッシュ・ツー・トーク等のような異なる通信サービスを提供しうる。一般に、Ｌは、任意の値でありうる。Ｌ個のアプリケーション２２４のいずれか１つは、任意の所与の時間においてアクティブでありうる。アプリケーションプログラミングインタフェース（ＡＰＩ）２２６は、無線デバイス１１０のためのオペレーティングシステム（ＯＳ）２２８とアプリケーション２２４との間の通信をサポートしうる。オペレーティングシステム２２８は、無線デバイス１１０のオペレーションを制御しうる、また、ハイレベルオペレーティングシステム（ＨＬＯＳ）または他の何らかのオペレーティングシステムでありうる。ホストプロセッサ２２０は、アクティブなアプリケーションを実行しうる、また、ＡＰＩとオペレーティングシステムを実行しうる。メモリ２２２は、ホストプロセッサ２２０のためのプログラムコードおよびデータを格納しうる。

図２で図示される設計では、ラジオサブシステム２３０は、接続マネージャ（ＣｎＭ）２４０、共存マネージャ（ＣｘＭ）２６０、プロセッシングコア２８０、ＣｎＭデータベース２５２、ＣｘＭデータベース２７２、およびＲ個のラジオ２９０ａ〜２９０ｒ（なお、Ｒは任意の値でありうる）を含む。ラジオサブシステム２３０は、モデムチップ、モデムチップセット、無線データカード等でありうる。Ｒ個のラジオ２９０は、３ＧＰＰ２セルラネットワーク（例えば、ＣＤＭＡ １Ｘ、ＥＶＤＯ等）、３ＧＰＰセルラネットワーク（例えば、ＧＳＭ、ＧＰＲＳ、ＥＤＧＥ、ＷＣＤＭＡ／ＵＭＴＳ、ＬＴＥ等）、ＷＬＡＮ，ＷｉＭＡＸネットワーク、ＧＰＳ、Ｂｌｕｅｔｏｏｔｈ，ブロードキャストネットワーク等のためのものでありうる。

接続マネージャ２４０は、利用可能なラジオを介してアクティブなアプリケーションのための通信をサポートするために様々な機能を実行しうる。接続マネージャ２４０内で、ＣｎＭ ＡＰＩ２４２は、接続マネージャ２４０および共存マネージャ２６０とアプリケーション２２４との間の通信を促進しうる。システムポリシーマネージャ２４４は、ラジオと関連づけられたポリシーを管理し、イベントに応じてラジオをアクティブまたは非アクティブ(de-activate)にし、無線ネットワーク間のハンドオフを管理しうる。ポリシーは、任意の所与のアプリケーションについてどのラジオ（１つまたは複数）を使用するかを決定するために使用されうる。システムポリシーマネージャ２４４は、ネットワークオペレータルールに基づいて動作しうる、そしてそれは、３ＧＰＰ２における好ましいローミングリスト（ＰＲＬ）、３ＧＰＰにおける好ましい公衆モバイルネットワーク（ＰＬＭＮ）のリスト等を介して提供されうる。システムリソースマネージャ２４６は、衝突解決（conflict resolution）、電力管理、リンクのサービス品質（ＱｏＳ）、アドミッション制御等のようなリソース管理を実行するために、システムポリシーマネージャ２４４とインタフェース接続しうる。ラジオインタフェースマネージャ２４８は、呼出を管理し、サービス継続性を管理し、電話設定を変更し、補足サービスを登録／登録解除し、呼出ステータス、電話状態／ステータスおよびサービスステータスに関するアプリケーションを通知しうる。ラジオ干渉マネージャ２４８はまた、無線デバイス１１０と他の無線デバイスとの間のピア・ツー・ピア通信をサポートしうる。ＣｎＭコントローラ２５０は、接続マネージャ２４０の全体的な制御を担うことがある。ＣｎＭコントローラ２５０は、ＣｎＭ ＡＰＩを介してアプリケーション２２４と通信して、どのアプリケーションがアクティブであるかを決定し、アクティブなアプリケーションの要件を取得し、そして、利用可能なおよび／または選択されたラジオについての情報を受信しうる。ＣｎＭコントローラ２５０はまた、接続マネージャ２４０内で他のマネージャおよびコントローラのオペレーションを調整しうる。

共存マネージャ２６０は、ラジオ２９０とインタフェース接続し、ラジオのオペレーションを制御しうる。共存マネージャ２６０は、ラジオ２９０から入力を受信し、また、接続マネージャ２４０からアクティブなアプリケーションの要件を受信しうる。共存マネージャ２６０は、アクティブなラジオのオペレーションを制御して、これらのラジオ間の干渉を緩和し、可能な限り多くのラジオに対してよい性能を達成しうる。共存マネージャ２６０内では、ＣｘＭコントローラ２７０は、共存マネージャ２６０の全体的な制御を担うことがある。ルックアップテーブル（ＬＵＴ）２６２は、現在のオペレーティングシナリオに基づいてデータベースの関連部分を取り出すためにＣｘＭデータベース２７２と関連づけられうる（およびインタフェース接続しうる）。ハードウェアアクセレータ（ＨＷＡ）２６４は、ある機能の効率的な処理を提供しうる、また、メモリストアに直接アクセスするためにダイレクトメモリアクセス（ＤＭＡ）モジュール２６６を使用しうる。

プロセッサコア２８０は、ラジオサブシステム２３０内のユニットのための処理を実行しうる。プロセッシングコア２８０内では、集中型プロセッシングユニット（ＣＰＵ）２８２は、接続マネージャ２４０および共存マネージャ２６０によって要求され、処理を実行しうる。ＣＰＵ２８２はまた、ラジオ２９０を介して送信または受信されているデータについて処理（例えば、符号化、復号、変調、復調、エンクリプション、ディクリプション等）を実行しうる。メモリ２８４は、接続マネージャ２４０および共存マネージャ２６０のためのプログラムコードおよびデータを格納しうる。ＤＭＡ／ファブリック２８６は、ローカルまたは外部システムメモリまたは他のサブシステムでデータ移送をサポートしうる。バスコントローラ２８８は、データバス２５８を介して通信を調整しうる、そしてそれは、ラジオサブシステム２３０内で様々なモジュールに相互接続しうる。

ＣｘＭデータベース２７２は、干渉データベースを格納しうる、そしてそれは、異なるオペレーティングシナリオにおいて異なる組み合わせのラジオの性能に関する情報を備えうる。ラジオのオペレーションは、ラジオの良好または受諾可能な性能を得るために干渉データベースに基づいて制御されうる。

ＣｎＭデータベース２５２は、アプリケーションのためのラジオを選択するために使用されうる様々なタイプの情報を格納しうる。例えば、ＣｎＭデータベース２５２は、（ｉ）接続を取得するために使用されうるプロファイルのプロファイルデータベース、（ｉｉ）異なる無線ネットワークのための情報のネットワークデータベース（例えば、ＰＲＬ、好ましいＰＬＭＮリスト等）、（ｉｉｉ）無線デバイス１１０のための接続を提供するために、ラジオを選択するために使用される情報のポリシーデータベース、（ｉｖ）現在のオペレーティングシナリオに基づいてアプリケーションのためのラジオを選択するために使用される情報の変換された干渉データベース、および／または（ｖ）無線デバイス１１０のための他の情報の他のデータベース、を格納しうる。

図２は、無線デバイス１１０のための、ラジオサブスシステム２３０、接続マネージャ２４０、共存マネージャ２６０、およびプロセッシングコア２８０の例示的な設計を図示する。ラジオサブシステム２３０、接続マネージャ２４０、共存マネージャ２６０、およびプロセッシングコア２８０はまた、より少数の、異なる、および／または、追加マネージャ、コントローラ、およびデータベースを含めうる。一般に、ラジオサブシステム２３０は、（ｉ）任意の数の機能に対する任意の数のマネージャおよびコントローラ、および（ｉｉ）通信をサポートするために使用されうる任意のタイプの情報に対する任意の数のデータベースを含めうる。

一設計では、プロファイルは、無線デバイス１１０上のアクティブなアプリケーションのための接続を提供するために使用されうる。プロファイルは、接続を取得するために無線デバイス１１０が実行すべき特定のアクションについての優先度を含めうる。例えば、プロファイルは、他のラジオに対するあるラジオの優先度、ある条件下の特定のラジオの優先度等を識別しうる。異なるプロファイルは、ユーザ、ネットワークオペレータ、相手先商標製造会社（ＯＥＭ）、または無線デバイス製造者等のような異なるエンティティによって定義されうる。プロファイルは、異なるエンティティの要件にあわせることを可能にしうる。

多数のプロファイルが定義されうる。一設計では、下記プロファイルのうち１つまたは複数が定義されうる。

・ユーザプロファイル−ユーザによって定義された接続についての優先度を格納する。

・オペレータファイル−ネットワークオペレータによって定義された接続優先度を格納する。

・ＯＥＭプロファイル−ＯＥＭによって定義された接続優先度を格納する。

・アプリケーションプロファイル−アプリケーションについての接続優先度を格納する。

・学習されたプロファイル(Learned profile)-無線デバイス１１０のビヘービア（behavior）と学習されたパターンに基づいて決定される接続優先度を格納する。

ユーザプロファイルは、コスト、プライバシー、バッテリー使用量等のような様々な考慮に基づいてユーザによって定義された接続についての優先度を格納しうる。オペレータプロファイルは、ネットワークオペレータによって定義された接続についての優先度、例えばいくつかのラジオが利用可能であるときの他のラジオに対するいくつかのラジオの優先度、を格納しうる。ＯＥＭプロファイルは、例えば無線デバイス１１０の機能、無線デバイス１１０上の利用可能なリソース等に基づいて、ＯＥＭによって定義された接続についての優先度を格納しうる。アプリケーションプロファイルは、無線デバイス１１０上でアプリケーションのための接続についての優先度を格納しうる。アプリケーションは、ある要件（例えばＱｏＳのためのもの）を有しうる、また、各ラジオは、ある機能を有しうる。優先度は、アプリケーションの要件、ラジオの機能、および／または他の要因に基づくことがある。優先度は、アプリケーションのための接続を提供するために、適切なラジオを選択するために使用されうる。学習されたプロファイルは、無線デバイス１１０のビヘービアまたは過去のアクティビティに基づいて決定された接続の優先度を格納しうる。５つのタイプのプロファイルが上述されている。より少数の、異なる、および／または追加のプロファイルもまた定義され、接続を提供するために使用されうる。

ラジオは、ラジオの性能を改善するためにおよび／またはラジオからの干渉を緩和するために調整されうる１つまたは複数の構成可能なパラメータを有しうる。構成可能なパラメータは、増幅器、フィルタ、アンテナ、アンテナアレイ等のようなラジオ内の物理コンポーネントのためのものでありうる。構成可能なパラメータはまた、送信電力レベル、周波数チャネル、トラフィックチャネル、スケジュールされた期間等のようなオペレーショナルパラメータのためのものでありうる。受信された電力レベルはまた、例えば異なるアンテナおよび／またはより多くのアンテナを選択することによりそれが異なることがある場合には、構成可能なパラメータでありうる。各構成可能なパラメータは、そのパラメータに適用可能な複数の起こりうる設定／値のうちの１つに設定されうる。ラジオは、各構成可能なパラメータについての特定の設定によって定義されうるオペレーティング状態を有しうる。構成可能なパラメータはまた、「ノブ(knob)」と呼ばれ、構成可能なパラメータ設定はまた、「ノブ設定(knob setting)」と呼ばれ、オペレーティング状態はまた、「ノブ状態(knob state)」と呼ばれる。

一設計では、干渉データベースは、所与のマルチラジオプラットフォームについて定義されうる、そしてそれは、無線デバイス１１０によってサポートされるすべてのラジオを含めうる。干渉データベースは、アクティブなアプリケーションのためのラジオを選択するために、そして、同時に動作しているアクティブなラジオ間の干渉を低減させるために、使用されうる。干渉データベースは、様々なフォーマットで提供されうる。

一設計では、干渉データベースは、異なる送信機ラジオおよび受信機ラジオについての多数のオペレーティング状態について多数のセルを有するカラーチャートを備えうる。カラーチャートは、送信機ラジオが動作することができる各周波数チャネルについての１セットの列を含めうる。各列のセットは、送信機ラジオの異なるオペレーティング状態についての複数の列を含めうる。カラーチャートはまた、受信機ラジオが動作することができる各周波数チャネルについての１セットの行を含めうる。各行のセットは、受信機ラジオの異なるオペレーティング状態についての複数の行を含めうる。セルは、送信機ラジオと受信機ラジオのオペレーティング状態の各固有の組み合わせについて定義されうる。Ｃｅｌｌ（ｉ，ｊ）は、送信機ラジオについてのオペレーティング状態ｉおよび受信機ラジオについてのオペレーティング状態ｊに対応しうる。Ｃｅｌｌ（ｉ，ｊ）は、送信機ラジオがオペレーティング状態ｉにあり受信機ラジオがオペレーティング状態ｊにある、受信機ラジオについての性能レベル（例えば、受諾可能、マージナル、または受諾不可能）で満たされうる。送信機ラジオのオペレーティング状態および／または受信機ラジオのオペレーティング状態は、所望の性能を取得するために、必要に応じて、変更されうる。

ラジオ間の干渉に関する情報はまた、他の方法で干渉データベースにおいてキャプチャされ、格納されうる。例えば、干渉情報は、他のフォーマットまたは構造などを使用して示される、他の方法で量子化されうる。ラジオ間の干渉はまた、（ｉ）リアルタイムで測定される、（ｉｉ）必要に応じて、アプリオリで計算され、格納され、検索される、および／または（ｉｉｉ）他の方法で決定される。

無線デバイス１１０は、アクティブアプリケーションのための接続を提供するために、ラジオを選択するシステム選択を実行しうる。システム選択は、１つまたは複数のアプリケーションにサービス提供する、１つまたは複数のシステムまたはラジオの選択を指す。システム選択はまた、アクティブなアプリケーションの選択されたラジオへのマッピングを含めうる。システム選択はまた、ラジオ選択、ラジオベアラ選択等と呼ばれうる。

無線デバイス１１０は、アクティブなアプリケーションのためのフルシステム選択をサポートしうる。フルシステム選択は、各方向についての全体のアプリケーションの単一ラジオの選択、例えば、送信方向について単一の送信機ラジオおよび受信方向について単一の受信機ラジオの選択を指す。アプリケーションのためのすべてのデータは、各方向について選択されたラジオを介して交換されうる（例えば、送信または受信される）。

一態様では、無線デバイス１１０は、アプリケーションのためのフラクショナルシステム選択をサポートしうる。フラクショナルシステム選択の場合、アプリケーションは、所与の方向について異なる複数ラジオにマッピングされうる異なる複数フラクション（fraction）（すなわち、部分(parts)またはポーション(portions)）に分割されうる、すなわちラジオあたりアプリケーションの１つのフラクションに分割されうる。フラクショナルシステム選択は、アプリケーションのための性能を改善するおよび／または他の利益を得るために使用されうる。

アプリケーションは、様々な方法で複数フラクションに分割されうる。一設計では、アプリケーションは、多数のフローを有しうる、そして、各フローは、アプリケーションの１フラクションに対応しうる。フローは、論理エンティティ、論理チャネル、物理チャネル、トラフィックチャネル、送信制御プロトコル（ＴＣＰ）フロー、インターネットプロトコル（ＩＰ）フロー、ＴＣＰ／ＩＰソケット等に対応しうる。一般に、フローは、ある特性を有する連続または不連続データのストリームを備えうる。フローに属するデータは、データのタイプ（例えばトラフィックデータまたは制御データ）、データの要件、データのソース、データのデスティネーション等に基づいて識別されうる。例えば、ボイス・オーバ・ＩＰ（ＶｏＩＰ）のためのアプリケーションは、トラフィックデータについて１つまたは複数のフロー、および、制御データについて１つまたは複数のフローを有しうる。一設計では、論理スイッチは、入力にてアプリケーションについてのデータを受信し、論理スイッチの複数の出力にて異なるフローにアプリケーションについてのデータの異なる部分を提供しうる。フローは、複数のサブフローにさらに分割されうる。アプリケーションは、他の方法で複数フラクションに分割されうる。

アプリケーションの異なる複数フラクションは、様々な方法で異なる複数ラジオにマッピングされうる。一設計では、アプリケーションの異なる複数フラクションは、アプリケーションの要件、ラジオの機能等に基づいて異なる複数ラジオにマッピングされうる。例えば、いくつかのラジオは、あるＱｏＳ保証を提供することが可能であるが、他のラジオは、ＱｏＳ保証を提供することが可能でないことがある。ＱｏＳ保証は、特定の最大遅延、特定の最小データレートまたはスループット、特定の平均データレート、特定のピークデータレート等に関連しうる。いくつかのフローは、ＱｏＳ要件を有し、フローのＱｏＳ要件を満たすことができるＱｏＳ保証でラジオにマッピングされうる。他のフローは、ＱｏＳ要件を有しておらず、ＱｏＳ保証のないものを含むいずれのラジオにマッピングされうる。アプリケーションはまた、後述されるように、他の要因に基づいてラジオにマッピングされうる。

図３Ａは、複数のアプリケーションをサポートしている単一ラジオのフルシステム選択の例を図示する。無線デバイス１１０は、アクティブである４つのアプリケーションＡＰＰ１〜ＡＰＰ４を有し、３つのラジオＲ１〜Ｒ３を含めうる。図３Ａで図示される例では、ラジオＲ１のみが時間Ｔ１において使用することが利用可能であり、ラジオＲ２およびＲ３は、利用不可能であることがある。すべての４つのアクティブアプリケーションＡＰＰ１〜ＡＰＰ４は、同時にラジオＲ１にマッピングされうる。４つのアクティブなアプリケーションのデータは多重化され、単一の利用可能なラジオを介して交換されうる（例えば、送信または受信される）。多くの従来の無線デバイスは、任意の所与の時間において単一のアクティブなラジオをサポートし、また、この単一のラジオにすべてのアクティブなアプリケーションをマッピングする。

図３Ｂは、フルシステム選択を用いるアプリケーションのためのフローモビリティの例を図示する。時間Ｔ１よりも遅い場合がある時間Ｔ２において、ラジオＲ２は、無線デバイス１１０上で利用可能となり、ラジオＲ１は利用不可能となることがある。すべての４つのアクティブアプリケーションＡＰＰ１〜ＡＰＰ４は、ラジオＲ１からラジオＲ２へと移動されうる。フローモビリティは、１つのラジオから別のラジオまでのアプリケーションのハンドオフを指す。各アプリケーションは、ハンドオフの前および後で同じ方法で動作し、ラジオＲ１またはラジオＲ２がアプリケーションにサービス提供しているかに気づいていないことがある。フルシステム選択によって、所与のラジオにマッピングされるすべてのアプリケーションは新規ラジオにハンドオフされうる。

図３Ｃは、フルシステム選択を用いるアプリケーションのためのフローモビリティの別の例を図示する。時間Ｔ２よりも遅い場合がある時間Ｔ３において、ラジオＲ３は、無線デバイス１１０上で利用可能となり、ラジオＲ２もまた利用可能でありうる。図３Ｃで図示される例では、アプリケーションＡＰＰ４は、ラジオＲ２からラジオＲ３に移動され、他の３つのアプリケーションＡＰＰ１〜ＡＰＰ３は、ラジオＲ２にマッピングされたままでありうる。フローモビリティは、変化するチャネル状態に起因してラジオのキャパシティの変化に取り組み、全体のスループットを増大させ、システムローティングのバランスを取り、および／または他の利点を得るために使用されうる。

図３Ｄは、アプリケーションのためのフラクショナルフローモビリティの例を図示する。時間Ｔ３よりも遅い場合がある時間Ｔ４において、ラジオＲ１は、無線デバイス１１０上で利用可能となり、ラジオＲ２およびＲ３もまた利用可能となることがある。図３Ｄで図示される例では、アプリケーションＡＰＰ１の８０％の第１のフラクションはラジオＲ１にマッピングされ、アプリケーションＡＰＰ１の２０％の第２のフラクションはラジオＲ２にマッピングされうる。フラクショナルフローモビリティは、アプリケーションのフラクションの任意のラジオへの緩和を指すので、アプリケーションは、同時に複数のラジオにマッピングされうる。フラクショナルフローモビリティは、アプリケーションのための全体的なスループットを増大させ、システムローディングのバランスを取り、および／または他の利益を得るために使用されうる。

図３Ｄは、フラクショナルフローモビリティの例を図示する。一般に、アプリケーションは、任意の数のラジオにマッピングされうる。さらに、アプリケーションのフラクションはいずれも、各ラジオにマッピングされうる。

図３Ｂおよび図３Ｃのフローモビリティおよび／または図３Ｄのフラクショナルフローモビリティは、（ｉ）デュアルスタックモバイルＩＰバージョン６（ＤＳＭＩＰｖ６）のような１つまたは複数のプロトコルを使用する無線デバイス１１０によって、また、（ｉｉ）例えばホームエージェント（ＨＡ）のような１つまたは複数のネットワークエンティティによって、サポートされうる。

一般的に、アプリケーションのフラクションｆは、１００％未満のいずれのアプリケーションの割合を指し、０≦ｆ＜１となるように、０から１の範囲内にある。全体のアプリケーションは、整数値１で表されるので、フラクションｆは、１(unity)を超えない。アプリケーションのすべてのフラクションは、合計に１になるべきであるので、

である、なお、ｆ_ｎは、アプリケーションのｎ番目のフラクションの割合であり、総和は、アプリケーションのすべてのフラクションにわたる。

ラジオは、ラジオの機能、アプリケーションの要件、および／または他の要因によって、１つまたは複数のアプリケーションをサポートしうる。ラジオは、１つのアプリケーションの１フラクションのみ、または１つのアプリケーションのすべて、または複数のアプリケーションの各々の１フラクションまたはすべてをサポートしうる。ラジオによってサポートされることができるアプリケーションの合計数は、１を超えることがある。例えば、図３ＤのラジオＲ２は、２．２アプリケーションをサポートする。一般に、ラジオによってサポートされることができるアプリケーションの数は、ラジオのキャパシティ、各アプリケーションの要件、そして場合によっては、無線デバイス１１０の他の制約によって制約されることがある。これらの他の制約は、無線デバイス１１０上の利用可能なバッテリー、ラジオによって観察される干渉およびチャネル状態等を含めうる。また、無線デバイス１１０の外に制約がある場合（例えば、輻輳を経験する１つまたは複数のネットワーク内）があり、そしてそれは、無線デバイス１１０上で多数の利用可能なラジオに影響を与えることがある。

図４Ａは、無線デバイス１１０が４つのアクティブなアプリケーションＡＰＰ１〜ＡＰＰ４を有し、３つの利用可能なラジオＲ１〜Ｒ３を含む場合のフラクショナルシステム選択の例を図示する。図４Ａで図示される例では、時間Ｔ１において、アプリケーションＡＰＰ１の８０％の第１のフラクションはラジオＲ１にマッピングされ、アプリケーションＡＰＰ１の２０％の第２のフラクションはラジオＲ２にマッピングされうる。アプリケーションＡＰＰ２の６０％の第１のフラクションはラジオＲ１にマッピングされ、アプリケーションＡＰＰ２の４０％の第２のフラクションはラジオＲ２にマッピングされうる。全体のアプリケーションＡＰＰ３は、ラジオＲ３にマッピングされ、全体のアプリケーションＡＰＰ４は、ラジオＲ１にマッピングされうる。ラジオＲ１は、そのキャパシティの９０％を使用して、３つのアプリケーションＡＰＰ１、ＡＰＰ２およびＡＰＰ４をサポートしうる。ラジオＲ２は、そのキャパシティの７０％を使用して、２つのアプリケーションＡＰＰ１とＡＰＰ２をサポートしうる。ラジオＲ３は、そのキャパシティの２０％を使用して、１つのアプリケーションＡＰＰ３をサポートしうる。

図４Ｂは、アプリケーションのためのフラクショナルフローモビリティの例を図示する。図４Ｂで図示される例では、時間Ｔ１よりも遅い時間Ｔ２において、アプリケーションＡＰＰ１の２０％のフラクションは、ラジオＲ１にマッピングされ、アプリケーションＡＰＰ１の８０％のフラクションは、ラジオＲ２にマッピングされうる。アプリケーションＡＰＰ２の５０％のフラクションはラジオＲ１にマッピングされ、アプリケーションＡＰＰ２の５０％のフラクションはラジオＲ２にマッピングされうる。全体のアプリケーションＡＰＰ３は、ラジオＲ３にマッピングされ、全体のアプリケーションＡＰＰ４は、ラジオＲ１にマッピングされうる。ラジオＲ１は、そのキャパシティの７０％を使用して、３つのアプリケーションＡＰＰ１、ＡＰＰ２およびＡＰＰ４をサポートしうる。ラジオＲ２は、そのキャパシティの９０％を使用して、２つのアプリケーションＡＰＰ１とＡＰＰ２をサポートしうる。ラジオＲ３は、そのキャパシティの２０％を使用して、１つのアプリケーションＡＰＰ３をサポートしうる。

図４Ｂで図示されるように、フラクショナルフローモビリティの場合、異なる複数ラジオにマッピングされたアプリケーションの複数フラクションは変化することが出来るので、アプリケーションの異なる割合は、異なる時間において所与のラジオにマッピングされうる。アプリケーションのラジオへのマッピング／割り当ては、変化するアプリケーション要件、ラジオ機能、チャネル状態等に基づいて変化しうる。

図４Ｃは、アプリケーションのためのフラクショナルハンドオーバの例を図示する。フラクショナルハンドオーバとは、古いラジオから新しいラジオへのアプリケーションのフラクションのハンドオーバを指す。図４Ｃで図示される例では、時間Ｔ２よりも遅い時間Ｔ３において、アプリケーションＡＰＰ１の２０％のフラクションは、ラジオＲ１にマッピングされ、アプリケーションＡＰＰ１の８０％のフラクションは、ラジオＲ２からラジオＲ３へと移動されうる。アプリケーションＡＰＰ２とＡＰＰ３は、図４Ｂについて上述されるようにラジオＲ１、Ｒ２、およびＲ３にマッピングされうる。アプリケーションＡＰＰ４は、非アクティブ(inactive)となり、ラジオＲ３から移動されうる。図４Ｃで図示されるように、アプリケーションのフラクションは、フラクショナルハンドオーバのために新規ラジオへと移動されうる。図４Ｃでも図示されているが、アプリケーションは、アプリケーションが非アクティブ(inactive)となるときにアプリケーションがマッピングされるすべてのラジオから取り除かれることがある。

一般に、フラクショナルフローモビリティは、（ｉ）アプリケーションのフラクションのための異なるラジオを選択すること（例えば図４Ｃで図示されている）、および／または、（ｉｉ）ラジオにマッピングされたアプリケーションの割合を変更すること（例えば図４Ｂで図示されている）を含めうる。

図５Ａは、１つのアプリケーションＡＰＰｍのためのフラクショナルシステム選択を図示する。無線デバイス１１０は、Ｎ個の利用可能なラジオＲ１〜ＲＮを有しうる、なお、Ｎは、１より大きい任意の整数値でありうる。アプリケーションＡＰＰｍの異なる複数フラクションは、異なる複数ラジオにマッピングされうる。各ラジオにマッピングされたアプリケーションＡＰＰｍのフラクションは、０〜１の範囲内でありうる。特定のラジオについてのフラクション０は、アプリケーションＡＰＰｍがそのラジオにマッピングされていないということを意味しうる。Ｎ個のラジオＲ１〜ＲＮにマッピングされたアプリケーションＡＰＰｍのＮ個のフラクションの和は、上述されるように１に等しいことがある。

図５Ｂは、複数のアプリケーションのためのフラクショナルシステム選択を図示する。無線デバイス１１０は、Ｍ個のアクティブなアプリケーションＡＰＰ１〜ＡＰＰＭと、Ｎ個の利用可能なラジオＲ１〜ＲＮを有しうる、なお、ＭとＮは各々１より大きい任意の整数値でありうる。一般に、アプリケーションＡＰＰｍのフラクションｆ_ｍ，ｎは、ラジオＲｎにマッピングされうる、なお、０≦ｆ_ｍ，ｎ＜１、

である。各アプリケーションのすべてのフラクションの和は、１または

に等しい。

Ｍ個のアプリケーションとＮ個のラジオとの間の相互接続またはマッピングは、トレリス(trellis)としてみなされうる。所与のアプリケーションＡＰＰｍと所与のラジオＲｎとの間の相互接続は特定の割合と関連づけられ、そしてそれは、トレリス割合(trellis percentage)と呼ばれうる。この割合は、０から１００の範囲内にあり、ラジオＲｎにマッピングされているアプリケーションＡＰＰｍのフラクションを示すことがある。十分に接続されたトレリスでは、図５Ｂで図示されるように、Ｍ個のアプリケーションとＮ個のラジオとの間のＭ＊Ｎ個の相互接続がありうる。しかしながら、いくつかの相互接続は、割合０と関連づけられうる、また、トレリスから取り除かれうる。

一般に、Ｍ個のアクティブなアプリケーションは、フルおよび／またはフラクショナルシステム選択に基づいて、Ｎ個の利用可能なラジオにマッピングされうる。例えば、いくつかのアプリケーションは、フラクショナルシステム選択に基づいてラジオにマッピングされうる、また、残りのアプリケーションは、フルシステム選択に基づいてラジオにマッピングされうる。アプリケーションは、フラクショナルシステム選択を用いて複数のラジオに、または、フルシステム選択を用いて単一ラジオに、マッピングされうる。

フラクショナルシステム選択の場合、各アプリケーションの複数フラクションは、マッピング関数に基づいて異なる複数ラジオにマッピングされうる、そしてそれは、ガンマ関数またはアルゴリズムと呼ばれうる。一設計では、マッピング関数は、（ｉ）使用するためにどのラジオを選択するかを決定するためのラジオ選択、および（ｉｉ）各アプリケーションのどのフラクションを各選択されたラジオにマッピングするかを決定するためのフラクショナルフロー割り当て、の両方を実行しうる。別の設計では、マッピング関数は、各アプリケーションのどのフラクションを各選択されたラジオにマッピングするかを決定するためのフラクショナルフロー割り当てを実行することのみしうる。両方の設計について、マッピング関数は、様々な方法で、また、任意の入力のセットに基づいて、定義されうる。一設計では、マッピング関数は、下記のうちの１つまたは複数に基づいて定義しうる。

・アプリケーションの要件
・アプリケーションの優先度
・ラジオの機能
・無線デバイス１１０のステータス
・無線デバイス１１０の制約
・無線ネットワークの機能
・例えばトラフィックおよび／またはシグナリングチャネル輻輳に関する、無線ネットワークのステータス
アプリケーションの要件は、最小スループット（例えば１００Ｋｂｐｓ）、最大レイテンシ（例えば、１ミリ秒（ｍｓ））、最大ジッタ、最大接続時間（例えば、２５０ｍｓ）、最大呼出ドロップ率（例えば、１０^−３）等のような様々なパラメータで量子化されうる。異なるアプリケーションは異なる要件を有しうる。例えば、ビデオストリーミングのようなアプリケーションは、最小スループットと最大レイテンシ要件を有しうる。これらのアプリケーションは、これらの要件がリアルタイムで満たされない場合には、ストール(stall)またはフェール（fail)することがある。ＦＴＰのような他のアプリケーションは、基本的な最小スループットまたは最大レイテンシ要件を有していないことがある。したがって、ユーザ／所望のスループットおよび最小ではないレイテンシ(no minimum latency)は、これらのアプリケーションについて特定化されうる、また、これらのアプリケーションについてのトラフィックは、ベストエフォートとみなされうる。

一般に、アプリケーションは、接続マネージャ２４０および／または無線デバイス１１０内の他のモジュールにその要件を提供することがある、または、提供しないこともある。アプリケーションがその要件を明示的に提供しない場合には、アプリケーションの１つまたは複数の要件は、アプリケーションに利用可能な任意の情報に基づいて決定されうる。例えば、アプリケーションのデータレート要件は、アプリケーションデータストリームフォーマットから決定されうる、そしてそれは、受信機にてエラーフリー受信を確実にするためのソース符号化オーバヘッドを含めうる。

一設計では、トラフィックおよび／またはシグナリングローディングの点でのアプリケーション要件および／またはネットワークの影響は、無線デバイス１１０とネットワークとの間で交換されうる。無線デバイス１１０は、ラジオを選択し、ラジオにアプリケーションをマッピングし、および／または他の機能を実行するために、ネットワークにおけるトラフィックおよび／またはシグナリングローディングに関する情報を使用しうる。

アプリケーションの優先度は、プロファイルデータベースによって提供されうる。例えば、アプリケーションは、いくつかのラジオが利用可能であるとき、他のラジオよりも特定のラジオを好むことがある。

無線デバイス１１０のステータスは、無線デバイスのバッテリー状態、無線デバイスにおける現在アクティブなアプリケーション、十分なバッテリー電力または十分なネットワーク機能のような状態に基づいているキュー実行待ち中のアプリケーション、無線デバイス１１０によってサポートされたラジオ技術に対するアプリケーションの実際または推定された影響等を含めうる。無線デバイス１１０の制約は、バッテリー寿命、無線デバイス１１０におけるアクティブなラジオのチャネル状態、無線デバイス１１０におけるアクティブなラジオ間の既知または決定された干渉または他の影響、無線デバイス１１０の処理機能、および／またはネットワークトラフィックおよび／またはシグナリング輻輳に対する複数の同時アプリケーションの既知または決定された影響等を含めうる。

ラジオの機能は、ラジオの性能、ラジオによってサポートされる機能または特徴等によって量子化されうる。ラジオの性能は、様々な性能メトリクスによって量子化され、そしてそれは、干渉関連メトリクスを含めうる。干渉関連メトリクスは、ラジオ間の干渉に依存しうる、そして（ｉ）無線デバイス１１０上の送信機ラジオからの送信電力に起因する受信機ラジオに対するデセンス(desense)量、（ｉｉ）時分割多重（ＴＤＭ）オペレーションにおける２つまたは複数のラジオの時間オーバラップの割合、（ｉｉｉ）周波数分割多重（ＦＤＭ）または同時オペレーションにおける周波数オーバラップ量、および／または（ｉｖ）干渉に関連する他のメトリクス、を含めうる。性能メトリクスはラジオの性能を示し、（ｉ）最大レートからのリンクの輻輳の割合レベル、（ｉｉ）公称からのリンクにおける遅延の割合レベル等を含めうる。

性能メトリクスは、時間の関数であり、どのラジオが利用可能で選択されるか、各ラジオのオペレーティング状態、アクティブなアプリケーションの要件、チャネル状態等のような様々な要因に依存することがある。ラジオのオペレーティング状態は、ラジオの異なる構成可能なパラメータの特定の設定の機能でありうる。性能メトリクスは、スカラ、ベクトル、マトリクス等のような様々な形式で表されうる。例えば、性能メトリックは、カラーチャートのセルの「カラー」によって与えられうる、そして、限定された数のカラーのうちの１つ（例えば、緑、黄、赤）を帯びることがある。性能メトリックは、干渉を緩和するために使用される技法に依存しうる形式で与えられうる。

いくつかの性能メトリクスは無線デバイス１１０によって直接測定されるが、他の性能メトリクスは、測定値から計算されうる。測定可能な性能メトリクスのいくつかの例は、スループット、レイテンシ、ジッタ、等に関するメトリクスを含めうる。計算可能な性能メトリクスは、ある量（例えば、送信機ラジオと受信機ラジオとの間の干渉レベル、受信機デセンス等）を測定し、測定された量を性能メトリクス（例えばスループット）に変換することによって取得されうる。

性能メトリクスは、無線デバイス１１０上の共存ラジオとの干渉環境の影響を考慮するために使用されうる。概して、アプリケーション要件は、増大した干渉を満たすことが一般的に困難である。干渉に起因する劣化の量（例えば、スループット対干渉）は、コンピュータシミュレーション、モデリング、経験測定値等によって量子化されうる、また、性能メトリクスを計算するために使用されうる。異なるアプリケーション要件は、干渉レベルに対して異なる依存性を有しうる。スループットおよびレイテンシのようないくつかのアプリケーション要件は、接続時間および呼出ドロップレートよりも干渉レベルに対してより免疫がありうる。これらの異なる免疫レベルが、異なるアプリケーションについての受諾可能な干渉レベルまたはトリガポイントを測る(gauge)ためにマッピング関数によって考慮されうる。

マッピング関数は、様々な方法で実装されうる。１つのアプリケーションのためのマッピング関数の例示的な実装が下記で説明される。

図６は、１つまたは複数のラジオにアプリケーションをマッピングするためのプロセス６００の設計を図示する。初めに、アプリケーションの要件が決定されうる（ブロック６１２）。第１の候補ラジオは、アプリケーションに潜在的にサービス提供するために、選択されうる（６１４）。第１の候補ラジオは、アプリケーション要件を満たすことができるピークレートを通知する最良ラジオでありうる、または、他の方法で選択されたラジオでありうる。第１の候補ラジオの機能（例えばスループット）は、例えば、第１の候補ラジオについての性能メトリクスに基づいて、決定されうる（ブロック６１６）。アプリケーション要件とラジオ機能に基づいて第１の候補ラジオによってアプリケーションがサービス提供されることができるかについて決定がなされる（ブロック６１８）。例えば、第１の候補ラジオによってサポートされるスループットは、１つまたは複数の性能メトリクスに基づいて計算されうるまたは直接測定されうる。ラジオによってサポートされるスループットがアプリケーションによって要求されるスループットを満たすまたは超える場合には、アプリケーションは、第１の候補ラジオによってサービス提供されることができる。第１の候補ラジオがアプリケーションにサービス提供することができる場合には、アプリケーションは、第１の候補ラジオにマッピングされうる（ブロック６２０）。

そうでなければ、第１の候補ラジオ自体がアプリケーションにサービス提供することができない場合には、アプリケーションに潜在的にサービス提供するために次の候補ラジオが選択されうる（ブロック６２４）。次の候補ラジオは、次の最良の利用可能ラジオでありうる、または、他の何らかの方法で選択されたラジオでありうる。次の候補ラジオの機能（例えば、スループット）が決定されうる（ブロック６２６）。次いで、アプリケーション要件とラジオ機能に基づいてすべての候補ラジオによってアプリケーションがサービス提供されることができるかについて決定がなされる（ブロック６２８）。答えが「Ｎｏ」である場合には、すべての利用可能なラジオが考慮されたかという決定が実行されうる（ブロック６３０）。少なくとも１つの利用可能なラジオが考慮されなかった場合には、プロセスは、ブロック６２４に戻り、別の候補のラジオを選択しうる。そうでない場合、ブロック６２８または６３０の答えが「Ｙｅｓ」の場合には、１セットのラジオがアプリケーションにサービス提供するために選択されうる（ブロック６２０）。このセットは、ブロック６１４および６２４で選択された候補ラジオのいくつかのすべてを含めうる。アプリケーションの複数フラクションは、ラジオの選択されたセットにおいて異なる複数ラジオにマッピングされうる（ブロック６３２）。

一設計では、アプリケーションのラジオへのマッピングは、アプリケーションがアクティブである全体の持続時間に対して適用可能であり静的でありうる。別の設計では、マッピングは、動的でありうる、また、上でリストされた要因のいずれかに対する変更に基づいて変更しうる。例えば、プロセス６００は、アプリケーションがアクティブである間周期的に実行されうる。

図６は、１つまたは複数のラジオに１つのアプリケーションをマッピングする簡単な場合を図示する。複数のアプリケーションはまた、同様な方法で複数のラジオにマッピングされうる。一般に、１つまたは複数のラジオは、１つまたは複数のアプリケーションにサービス提供するために、選択されうる。選択されたラジオがすべてのアクティブなアプリケーションにサービス提供することができる、または、すべての利用可能なラジオが選択されるまで、ラジオは選択されうる（例えば、一度に１つ）。

一設計では、アプリケーションのラジオへのマッピングは、（ｉ）Ｍ個のアクティブなアプリケーションに対応するＭ個の行と（ｉｉ）Ｎ個の利用可能なラジオに対応するＮ個の列とを有するマッピングマトリクスによって与えられうる。マッピングマトリクスのｍ番目の行とｎ番目の列におけるエントリは、ラジオＲｎにマッピングされているアプリケーションＡＰＰｍの割合を示すことがある。各行のＮ個のエントリは１に合計されるべきである。マッピングは、時間の関数、アプリケーション要件、ラジオ性能／機能等でありうる。マッピングマトリクスは、特定の時間間隔の間有効でありうる、また時間間隔ごとに変化しうる。マッピングマトリクスの変化は、ラジオ間のアプリケーションの複数フラクションまたは全体のアプリケーションのハンドオフ、異なる複数ラジオにマッピングされたアプリケーションの割合の変化等に反映しうる。

マッピング関数は、時間の関数として状態変数(state variable)を説明しうる。状態変数は、エレメントがアルゴリズムに応じて更新されうる、Ｍ×Ｎマッピングマトリクスに対応しうる。一設計では、アルゴリズムは、最小二乗平均（ＬＭＳ）アルゴリズムのような適応アルゴリズムでありうる。この設計では、時間ｔ＋１における状態変数（例えば、Ｍ×Ｎマッピングマトリクス）は、時間ｔおよび他のパラメータにおける状態変数の関数として更新されうる、そしてそれは、１つまたは複数の性能メトリクス、更新するためのステップサイズ等を含めうる。マッピング関数を更新するためのアルゴリズムはまた、他の何らかの適応アルゴリズムまたは他の何らかの適切なアルゴリズムでありうる。

ラジオの選択および／またはアプリケーションのラジオへのマッピングは、１つまたは複数の目的の機能を満たすために、周期的に、および／または、トリガされるとき、実行されうる。目的の機能は、アプリケーション要件を満たすまたは超えること、無線デバイス１１０の電力消費を最小化すること、１つまたは複数の無線ネットワークのトラフィックおよび／またはシグナリングチャネルに対する影響を最小化すること等を含めうる。動的／適応ラジオ選択および／またはアプリケーション・ツー・ラジオマッピングは、変化するチャネル状態に取り組むために特に望ましいことがある。チャネル状態は、例えば、チャネル品質インジケータ（ＣＱＩ）のフィードバック、チャネル状態情報（ＣＳＩ）、受信された信号強度インジケータ（ＲＳＳＩ）、信号対雑音比（ＳＮＲ）、ビットエラーレート（ＢＥＲ）、および／または、受信機から送信機までの他のメトリクスを介して、モニタ／測定するチャネルを通じて確定されうる。チャネル状態を変更することはラジオの機能／スループットにおける変動を引き起こし、周期的におよび／またはトリガされるときにフラクショナルシステム選択を実行することによって取り組まれうる。

図２で図示される設計では、接続マネージャ２４０と共存マネージャ２６０は、（ｉ）アプリケーションのためのラジオを選択し、ラジオにアプリケーションをマッピングするためのフルおよび／またはフラクショナルシステム選択、および（ｉｉ）ラジオ間でアプリケーションを移動させるためのフルおよび／またはフラクショナルフローモビリティ、をサポートしうる。共存マネージャ２６０と接続マネージャ２４０は、システム選択とフローモビリティをサポートするために様々な機能を実行しうる。

一設計では、共存マネージャ２６０は、無線デバイス１１０上で同時に動作している複数のアクティブなラジオ間の干渉を緩和しうる。共存マネージャ２６０は、下記のうち１つまたは複数に基づいて干渉を緩和しうる。
・送信均等化および電力バックオフ−受信機ラジオに対する干渉を減らすために、送信機ラジオの送信電力を減らす。

・プロトコルフレーム（時間）アライメント−ラジオ間の衝突を減らすために、異なるラジオ技術（例えばＬＴＥおよびＢｌｕｅｔｏｏｔｈ）のラジオのタイミングをアラインする。

・ＴＤＭアービトレーション−ラジオの同時動作を回避するために異なる時間間隔で動作するように異なる複数ラジオをスケジュールする。
・ノブ調整(Knob adjustment)−干渉を緩和するためにラジオのオペレーティング状態を調整する。

・干渉キャンセル−受信機ラジオにおける１つまたは複数の送信機ラジオから干渉を推定しキャンセルする。

共存マネージャ２６０はまた、他の技法に基づいて干渉を緩和しうる。干渉を緩和するために使用される技法は、性能メトリクスの形式に影響を与えうる。例えば、性能メトリクスは、送信電力バックオフの量、フレームアライメントにおけるラジオ間の衝突イベントの数、等の関数でありうる。

共存マネージャ２６０は、１つまたは複数の干渉緩和技法を使用して、ラジオの性能（例えば、性能メトリクスによって測定される）を改善することを試みることがある。共存マネージャ２６０は、アプリケーションのある性能測定値に対する直接的な影響（例えば、呼出接続時間および／または呼出ドロップレート）、そして、アプリケーションの他の性能測定値に対する間接的な影響（例えば、スループット、遅延、および／またはジッタ）を有しうる。

共存マネージャ２６０は、アプリケーションではなく、主にラジオに関する。しかしながら、共存マネージャ２６０は、使用するラジオを選択し、選択されたラジオを制御することにおいて、アプリケーション（例えば、アプリケーションの要件および／または優先度）を認識しうる。いくつかの設計では、共存マネージャ２６０は、接続マネージャ２４０から関連情報を受信しうる、そして、関連情報に基づいてラジオを選択し制御しうる。この情報は、アプリケーションＩＤ、アプリケーション要件、アクティブなラジオリスト、ラジオプライオリティ、ラジオイベントプライオリティ等を含めうる。この情報はまた、アプリケーションのラジオへのマッピングを含める、そしてそれは、ラジオを調整し、ラジオについての性能メトリクスを決定する等のために、共存マネージャ２６０によって使用されうる。

一設計では、接続マネージャ２４０は、アプリケーションの要件を受信しうる、また、アプリケーションの要件は、上述された要件を含めうる。接続マネージャ２４０は、アプリケーションのための好ましいラジオを決定するために、（例えば、ネットワークオペレータからの）適用可能なポリシーとプロファイルを適用しうる。プロファイルは、特定のアプリケーション上でユーザ要件を設定するユーザプロファイルを含めうる。接続マネージャ２４０は、ラジオおよび／またはそれらのイベントにプライオリティを割り当て、そしてそれは、共存マネージャ２６０のオペレーションに影響を及ぼしうる。接続マネージャ２４０は、ラジオ選択および／または干渉緩和を支援するために、共存マネージャ２６０に関連情報を送信しうる。

接続マネージャ２４０は、アプリケーションの要件、ラジオの機能等に基づいて、ラジオにアプリケーションをマッピングしうる。例えば、接続マネージャ２４０は、（例えばＣＤＭＡ １ＸセルラおよびＷＬＡＮの場合）アプリケーションＡＰＰ１からラジオＲ１およびＲ２にマッピングし、（高いＱｏＳを伴うＥＶＤＯの場合）アプリケーションＡＰＰ２からラジオＲ３へ、そして、（ＭＭＳのためのＣＤＭＡ １Ｘセルラの場合）アプリケーションＡＰＰ３からラジオＲ１へマッピングしうる。

一設計では、接続マネージャ２４０は、選択されたラジオ（１つまたは複数）のための、スループット、レイテンシ、および／または他のパラメータを推定するために、リンクベースのプローブおよび／またはパスベースのプローブをランチ（launched）しうる。リンクベースのプローブは、無線デバイス１１０上の選択されたラジオを介して無線ネットワークにおける基地局と無線デバイス１１０との間のラジオリンクの性能を推定するためにローンチされうる。パスベースのプローブは、選択されたラジオ、基地局、および他のネットワークエンティティを介して無線デバイス１１０からエンドポイントまでのエンド・ツー・エンド通信パスの性能を推定するためにローンチされうる。接続マネージャ２４０は、アプリケーション要件を受信する時に、または、アプリケーションについてラジオ（１つまたは複数）を選択した後で、または、他の時間において、リンクベースのプローブおよび／またはパスベースのプローブをローンチしうる。接続マネージャ２４０は、リンクベースのプローブおよび／またはパスベースのプローブから性能情報を受信し、ラジオにアプリケーションをマッピングするために性能情報を使用しうる。

図７は、アクティブなアプリケーションのためのシステム選択を実行するプロセス７００の設計を図示する。第１のアプリケーションＡＰＰ１ ２２４ａは、アクティブになりうる、そして、接続マネージャ２４０に接続要求を送信しうる（ステップ１ａ）。接続マネージャ２４０は、接続要求を受信し、アプリケーション２２４ａのための１つまたは複数のラジオを選択するために使用されたシステム選択情報を取得しうる（ステップ２ａ）。システム選択情報は、アプリケーション２２４ａによって提供されるおよび／またはＣｎＭデータベース２５２から取得される要件、アプリケーション２２４ａのためのプロファイルおよび／または優先度、無線デバイス１１０のステータス等を備えうる。

接続マネージャ２４０は、アプリケーション２２４ａに使用されることができる適用可能なラジオのリスト、および／または、アプリケーション２２４ａのための好ましいラジオのリストをシステム選択情報に基づいて生成しうる。接続マネージャ２４０は、適用可能および／または好ましいラジオおよびそれらのイベントにプライオリティを割り当てうる。例えば、ＬＴＥラジオは、１Ｘラジオよりも高いプライオリティを有し、そして１Ｘラジオは、アプリケーション２２４ａについてのＷＬＡＮラジオよりも高いプライオリティを有することがある。接続マネージャ２４０は、アプリケーションＩＤ、アプリケーション要件、アプリケーション２２４ａのための適用可能および／または好ましいラジオ、ラジオおよび／またはそれらのイベントのプライオリティ、および／または、他の情報を共存マネージャ２６０に提供しうる（ステップ３ａ）。

共存マネージャ２６０は、接続マネージャ２４０から情報を受信し、無線デバイス１１０上での使用に利用可能なラジオを決定しうる。共存マネージャ２６０は、利用可能なラジオ間の干渉を緩和しうる。共存マネージャ２６０は、接続マネージャ２４０にラジオ関連情報を提供しうる（ステップ４ａ）。ラジオ関連情報は、ラジオについての性能メトリクス、ラジオ間の干渉を示す情報、チャネル状態等を備えうる。

接続マネージャ２４０は、共存マネージャ２６０から、利用可能なラジオについてのラジオ関連情報を受信しうる。接続マネージャ２４０は、アプリケーション要件、ラジオ機能、ラジオおよび／またはそれらのイベントのプライオリティ等に基づいて、アプリケーション２２４ａのための１つまたは複数のラジオを選択しうる（ステップ５ａ）。接続マネージャ２４０はまた、選択されたラジオ（１つまたは複数）にアプリケーション２２４ａをマッピングしうる。フルシステム選択の場合、接続マネージャ２４０は、各方向についての単一のラジオ（例えば送信または受信）を選択し、各方向についての単一のラジオに全体のアプリケーション２２４ａをマッピングしうる。フラクショナルシステム選択の場合、接続マネージャ２４０は、所与の方向についてアプリケーション２２４ａについての複数のラジオを選択し、その方向について選択された各ラジオにアプリケーション２２４ａのフラクションをマッピングしうる。

接続マネージャ２４０は、アプリケーション２２４ａのための選択されたラジオ（１つまたは複数）を構成するために、共存マネージャ２６０に構成要求を送信しうる（ステップ６ａ）。接続マネージャ２４０はまた、アプリケーション２２４ａに接続情報を戻しうる（ステップ７ａ）。接続情報は、アプリケーション２２４ａについての選択されたラジオ（１つまたは複数）を示し、および／または、アプリケーション２２４ａによって使用される他の情報を提供して、アプリケーション２２４ａによって送信または受信されるべきデータについての接続性を取得しうる。アプリケーション２２４ａは、次いで、選択されたラジオ（１つまたは複数）を介して接続を取得しうる（ステップ８ａ）。

その後で、第２のアプリケーションＡＰＰ２ ２２４ｂは、アクティブになりうる、そして、接続マネージャ２４０に接続要求を送信しうる（ステップ１ｂ）。接続マネージャ２４０は、接続要求を受信しうる、そして、アプリケーション２２４ｂのための１つまたは複数のラジオを選択するために使用されるシステム選択情報を取得しうる（ステップ２ｂ）。接続マネージャ２４０は、アプリケーションＩＤ、アプリケーション要件、アプリケーション２２４ｂのための適用可能および／または好ましいラジオ、ラジオおよび／またはイベントのプライオリティ、および／または、他の情報を共存マネージャ２６０に提供しうる（ステップ３ｂ）。共存マネージャ２６０は接続マネージャ２４０から情報を受信し、無線デバイス１１０上での使用に利用可能なラジオを決定し、例えば接続マネージャ２４０から受信した情報に基づいて、利用可能なラジオの間の干渉を緩和しうる。共存マネージャ２６０は、接続マネージャ２４０にラジオ関連情報を提供しうる（ステップ４ｂ）。

接続マネージャ２４０は、共存マネージャ２６０から、利用可能なラジオについてのラジオ関連情報を受信しうる。接続マネージャ２４０は、アプリケーション２２４ｂのための１つまたは複数のラジオを選択しうる、そして、フルまたはフラクショナルシステム選択に基づいて、選択されたラジオ（１つまたは複数）にアプリケーション２２４ｂをマッピングしうる（ステップ５ｂ）。接続マネージャ２４０は、すべての利用可能なラジオとすべてのアクティブなアプリケーションを考慮することにより、ステップ５ｂでラジオにアプリケーションをマッピングしうる。例えば、接続マネージャ２４０は、アプリケーション２２４ａおよび２２４ｂの要件、および利用可能なラジオの機能に基づいて、ステップ５ｂでアプリケーション２２４ａのフラクションまたはすべてを再マッピングしうる。接続マネージャ２４０は、アプリケーション２２４ｂのための選択されたラジオ（１つまたは複数）を構成するために、共存マネージャ２６０に構成要求を送信しうる（ステップ６ｂ）。接続マネージャ２４０はまた、アプリケーション２２４ｂに接続情報を戻しうる（ステップ７ｂ）。アプリケーション２２４ｂは、次いで、選択されたラジオ（１つまたは複数）を介して接続を取得しうる（ステップ８ｂ）。

図７は、ステップの特定シーケンスでシステム選択を実行する例示的な設計を図示する。システム選択はまた、他の方法で、例えば図７のステップのシーケンスとは異なりうるステップの他のシーケンスを用いて、実行されうる。

接続マネージャ２４０と共存マネージャ２６０は、フローモビリティとシステム選択について様々な方法で相互作用しうる。接続マネージャ２４０と共存マネージャ２６０の間のインタラクションのための２つのスキームが後述されており、それらは、一方向ＣｘＭ／ＣｎＭインタラクションおよび双方向ＣｘＭ／ＣｎＭインタラクションと呼ばれる。

一方向ＣｘＭ／ＣｎＭインタラクションの場合、制御は、システム選択およびフローモビリティのために、共存マネージャ２６０から接続マネージャ２４０へとフローしうる。接続マネージャ２４０は、アプリケーションの要件を有し、アプリケーションとラジオとの間のマッピングを決定しうる。

図８Ａは、一方向ＣｘＭ／ＣｎＭインタラクションの設計を図示する。アクティブなアプリケーション２２４は、接続マネージャ２４０にそれらの要件を提供しうる（ステップ１）。接続マネージャ２４０は、アクティブなアプリケーションの要件を受信しうる、そして、アプリケーションのための好ましいラジオを決定するために、（例えば、ネットワークオペレータからの）適用可能なポリシーとプロファイルを適用しうる（ステップ２）。

共存マネージャ２６０は、どの無線ネットワークが利用可能かに基づいて無線デバイス１１０上での使用に利用可能であるラジオを決定しうる（ステップ３）。共存マネージャ２６０は、ラジオ間の干渉の影響、チャネル状態、スループット推定値等に起因して、他のラジオよりあるラジオを選択しうる。共存マネージャ２６０は、ラジオ間の干渉の影響を決定しうる、そして共存データベース２７２と相互作用し、ラジオのオペレーティングパラメータについての適切な設定を決定し、干渉を緩和しそして性能を改善しうる（ステップ４）。共存マネージャ２６０は、利用可能なまたは選択されたラジオのリストおよびそれらの機能（例、性能メトリクス）を接続マネージャ２４０に提供しうる（ステップ５）。

接続マネージャ２４０は、使用するためのラジオを選択しうる、そして、アプリケーションの要件、ラジオの機能、および／または、他の基準に基づいて、選択されたラジオにアクティブなアプリケーションをマッピングしうる（ステップ６）。接続マネージャ２４０は、アプリケーション要件が小さい共存の影響で満たされることができるように、共存マネージャ２６０からの選択されたラジオ間の共存影響に関する情報に基づいてアプリケーションのラジオへのマッピングを決定しうる。

一設計では、図８Ａのステップは、ラジオを選択し、選択されたラジオにアクティブなアプリケーションをマッピングするために一度実行されうる。この設計は、アプリケーションをラジオにマッピングするためにオーバヘッドを処理することを低減しうる。別の設計では、図８Ａのステップのいくつかまたはすべては、アプリケーション要件を満たすおよび／またはよりよい性能を得るために、（リアルタイムで）多数回反復されうる。

一方向ＣｘＭ／ＣｎＭインタラクションの場合、共存マネージャ２６０は、（ｉ）干渉情報および／または共存マネージャ２６０に利用可能な他の情報、および（ｉｉ）接続マネージャ２４０からの少ない情報または情報なし、に基づいて使用するラジオを選択しうる、および／または、ラジオを調整しうる。例えば、接続マネージャ２４０は、共存マネージャ２６０がラジオ間の干渉を緩和することを可能にするためにいくらかの情報を送信しうる。情報は、利用可能または好ましいラジオリスト、ラジオプライオリティ、ラジオイベントプライオリティ、周波数帯域およびチャネル、２．４ＧＨｚおよび５ＧＨｚ帯域の同時デュアルバンドＷＬＡＮオペレーションまたはＬＴＥおよび／またはＨＳＰＡのための同時セルラキャリアアグリゲーションオペレーションのようなラジオオペレーションのモード、アプリケーション要件、アプリケーションフロー分離識別子（アプリケーション内でアプリケーションフローを識別する方法）等を備えうる。アプリケーション要件は、接続マネージャ２４０に知られているが、共存マネージャ２６０に提供されないことがある。接続マネージャ２４０は、共存マネージャ２６０から選択されたラジオについての性能メトリクスを取得しうる、そして、選択されたラジオにアプリケーションをマッピングしうる。

双方向ＣｘＭ／ＣｎＭインタラクションの場合、制御は、システム選択およびフローモビリティのために、共存マネージャ２６０から接続マネージャ２４０へとフローしうる、また逆も然りである。双方向ＣｘＭ／ＣｎＭインタラクションの一設計では、接続マネージャ２４０は、共存マネージャ２６０がラジオを選択し、場合によっては、ラジオのオペレーティングパラメータを調整して良好な性能を取得することを可能にする関連情報（例えば、アプリケーションの要件）を提供しうる。共存マネージャ２６０は、選択されたラジオのリストおよびそれらの機能を接続マネージャ２４０に提供しうる。接続マネージャ２４０は、そのあとで、アプリケーションの要件、ラジオの機能、および／または、他の基準に基づいて、選択されたラジオにアクティブなアプリケーションをマッピングしうる。双方向ＣｘＭ／ＣｎＭインタラクションの場合、共存マネージャ２６０は、（ｉ）接続マネージャ２４０からの関連情報、および（ｉｉ）干渉情報、チャネル情報、および／または共存マネージャ２６０に利用可能な他の情報、に基づいてラジオを調整しうる、および／または、使用するためのラジオを選択する。

図８Ｂは、双方向ＣｘＭ／ＣｎＭインタラクションの設計を図示する。アクティブなアプリケーション２２４は、接続マネージャ２４０にそれらの要件を提供しうる（ステップ１）。接続マネージャ２４０は、適用可能なポリシーおよびプロファイルを適用して、アプリケーションのための好ましいラジオを決定しうる（ステップ２）。接続マネージャ２４０は、アプリケーション要件および場合によっては、好まれるラジオを共存マネージャ２６０に提供しうる（ステップ３）。

共存マネージャ２６０は、接続マネージャ２４０から受信された情報に部分的に基づいて使用するために利用可能であるラジオを決定しうる（ステップ４）。共存マネージャ２６０は、ラジオの中の干渉の影響を決定し、チャネル状態を決定し、スループットを推定する等を行なうことがある。共存マネージャ２６０は、干渉を緩和し性能を改善するために、ラジオのオペレーティングパラメータの適切な設定を決定するために共存データベース２７２と相互作用しうる（５）。共存マネージャ２６０は、利用可能なまたは選択された複数ラジオのリストおよびそれら機能（例、性能メトリクス）を接続マネージャ２４０に提供しうる（ステップ６）。接続マネージャ２４０は、使用するためのラジオを選択しうる、そして、アプリケーションの要件、ラジオの機能、および／または、他の基準に基づいて、選択されたラジオにアクティブなアプリケーションをマッピングしうる（ステップ７）。

一設計では、図８Ｂのステップは、ラジオを選択し、選択されたラジオにアクティブなアプリケーションをマッピングするために一度実行されうる。この設計は、アプリケーションをラジオにマッピングするためにオーバヘッドを処理することを低減しうる。

別の設計では、図８Ｂのステップのいくつかまたはすべて（例えば、ステップ２〜７）は、よりよい性能を得るために、および／または、アプリケーション要件を満たすために、（例えば、ＬＭＳアルゴリズムまたは他の何らかの適応アルゴリズムに基づいて）複数回反復されうる。第１の反復の場合、共存マネージャ２６０は、接続マネージャ２４０からのアプリケーション要件に基づいてラジオを調整すること、および／または、最初に選択することがある。接続マネージャ２４０は、次いで、選択されたラジオとそれらの機能に基づいて、選択されたラジオにアクティブなアプリケーションをマッピングしうる。第２の反復の場合、共存マネージャ２６０は、アプリケーションのラジオへの現在のマッピング、場合によっては、他の情報（例えば、接続マネージャ２４０からの更新されたアプリケーション要件、無線デバイス１１０の電力消費等）に基づいて、ラジオのオペレーション（例えば、オペレーティング状態）を選択および／または調整しうる。接続マネージャ２４０は、選択されたラジオにアクティブなアプリケーションをマッピングしうる、そして、場合によっては、選択されたラジオとそれらの機能に基づいてアプリケーション要件を変更しうる。各後続反復は、同様な方法で実行されうる。接続マネージャ２４０と共存マネージャ２６０との間の交換は、異なる複数ラジオの選択、ラジオについての異なるオペレーティング状態の選択、アプリケーション要件の変更等をもたらすことがある。接続マネージャ２４０および／または共存マネージャ２６０は、アプリケーション要件を適合させる、または必要に応じてそれらを変更するために、利用可能なリソースを均等化または割り付けるアクションをとることがある。接続マネージャ２４０および共存マネージャ２６０は、出来るだけ少ないラジオ間の干渉に対する影響で、可能な限り最良にアプリケーション要件が満たされることができるように複数の反復を実行しうる。

アプリケーションの要件は、様々な方法で変更されうる。例えば、要件は、符号レートを変化させることによるアプリケーションについて送信するための符号化された情報量を変化させることによって変更されうる。ラジオがアプリケーションの公称要件(nominal requirements)を満たすことが出来ない場合には、送信帯域幅要件を減らすために符号レートを変更することが実行されうる。符号レートを変更することは、データ送信の信頼性に影響を与え、さらなる再送信を結果としてもたらすことがある。実際、接続マネージャ２４０は、１つまたは複数のラジオとアプリケーションソース符号化との間のプロキシとしてサービス提供しうる。アプリケーションの他の特性（符号レートを除く）はまた、アプリケーションの要件を変更するように、変化しうる。

図８Ａおよび図８Ｂは、一方向および双方向ＣｘＭ／ＣｎＭインタラクションの例示的な設計を図示し、そしてそれはまた、他の方法で実装されうる。一設計では、接続マネージャ２４０は、例えば、スループットプローブまたは干渉測定を介して、共存マネージャ２６０からの性能メトリクスの収集をイニシエートしうる。別の設計では、共存マネージャ２６０は、干渉情報（例えばカラーチャート）、チャネル情報、測定されたラジオ性能（例えばスループット推定値）、および／または他の情報を接続マネージャ２４０に提供しうる。接続マネージャ２４０は、共存マネージャ２６０から受信された情報に基づいて性能メトリクスを計算しうる、そして、アプリケーションの要件、接続マネージャ２４０によって計算された性能メトリクス等に基づいてラジオにアプリケーションをマッピングしうる。さらに別の設計では、共存マネージャ２６０は、接続マネージャ２４０から受信されたアプリケーション要件と共存マネージャ２６０によって決定された性能メトリクスに基づいて、アプリケーションのラジオへのマッピングを決定しうる。

図９Ａは、反復的な双方向ＣｘＭ／ＣｎＭインタラクションの設計を図示する。本設計では、接続マネージャ２４０は、共存マネージャ２６０にアプリケーション要件を初めに提供しうる。共存マネージャ２６０は、ラジオの性能メトリクスを決定しうる、また性能メトリクスとアプリケーション要件に基づいてアプリケーションのラジオへのマッピングを決定しうる。接続マネージャ２４０は、共存マネージャからマッピングを受信し、そのマッピングに基づいてラジオにアプリケーションをマッピングしうる。複数の反復は、性能を改善するために、アプリケーションのラジオへのマッピングとラジオの選択を精製するために実行されうる。

図９Ｂは、反復的な双方向ＣｘＭ／ＣｎＭインタラクションの別の設計を図示する。本設計では、接続マネージャ２４０は、共存マネージャ２６０にアプリケーションのラジオへの初期マッピングを提供しうる。初期マッピングは、（ｉ）アクティブなアプリケーションのための好ましいラジオ、（ｉｉ）接続マネージャ２４０からの入力なしに、共存マネージャ２６０によって選択されたラジオ、または（ｉｉｉ）他の方法で決定されるラジオ、に基づいていることがある。共存マネージャ２６０は、初期のアプリケーション・ツー・ラジオマッピングに基づいて、ラジオの性能メトリクスを決定しうる。接続マネージャ２４０は、共存マネージャ２６０から性能メトリクスを受信しうる、そして、アプリケーション要件と性能メトリクスに基づいて、アプリケーションのラジオへのマッピングを更新しうる。複数の反復は、性能を改善するために、アプリケーションのラジオへのマッピングとラジオの選択を精製するために実行されうる。

図９Ａおよび図９Ｂは、反復的な双方向ＣｘＭ／ＣｎＭインタラクションの２つの設計を図示する。双方向ＣｘＭ／ＣｎＭインタラクションはまた、他の方法で、反復的に実行されうる。ラジオの性能メトリクスは、共存マネージャ２６０によって決定されうる。アプリケーションのラジオへのマッピングは、接続マネージャ２４０および／または共存マネージャ２６０によって決定されうる。

図１０は、アプリケーション要件に基づいてシステム選択を実行するプロセス１０００の設計を図示する。プロセス１０００は、無線デバイス（下記で説明される）によって、または、他の何らかのエンティティによって、実行されうる。無線デバイスは、無線デバイス上でアクティブな少なくとも１つのアプリケーションの要件を決定しうる（ブロック１０１２）。少なくとも１つのアプリケーションの要件は、スループット、レイテンシ、ジッタ、接続時間、呼出ドロップレート等に関連しうる。無線デバイスは、少なくとも１つのアプリケーションの要件に基づいて無線デバイス上で複数のラジオから少なくとも１つのラジオを選択しうる（ブロック１０１４）。無線デバイスはまた、少なくとも１つのアプリケーションのためのラジオの優先度、ラジオのプライオリティ、ラジオの性能または機能、ラジオ間の干渉、および／または他の要因にさらに基づいて少なくとも１つのラジオを選択しうる。

無線デバイスは、少なくとも１つのラジオの性能、少なくとも１つのアプリケーションの要件、および／または他の要因に基づいて、少なくとも１つのアプリケーションの少なくとも１つのラジオへのマッピングを決定しうる（ブロック１０１６）。少なくとも１つのラジオの性能と少なくとも１つのアプリケーションの要件は、スループット、遅延、ジッタ等に関連しうる。無線デバイスは、マッピングに基づいて少なくとも１つのラジオに少なくとも１つのアプリケーションをマッピングしうる（ブロック１０１８）。無線デバイスは、少なくとも１つのラジオを反復的に選択し、複数の反復のためのマッピングを決定し、性能を改善する。

無線デバイスは、ラジオ間の干渉に関する少なくとも１つのメトリックに基づいて少なくとも１つのラジオの性能を決定しうる。例えば、少なくとも１つのラジオの性能はスループットによって与えられうる。無線デバイスは、ラジオ間の干渉に関する測定値を取得しうる、そして干渉に関連する測定値に基づいて各ラジオのスループットを計算しうる。無線デバイスはまた、各ラジオのスループット等を直接測定しうる。

一設計では、無線デバイスは、ラジオ間の干渉および／または少なくとも１つのアプリケーションの要件に基づいて少なくとも１つのラジオの各々のオペレーティング状態を設定しうる。一設計では、無線デバイスは、少なくとも１つのラジオの性能に基づいて少なくとも１つのアプリケーションの要件を変更しうる。

一設計では、１：Ｎマッピングの場合、無線デバイスは、単一のアプリケーションの要件を決定し、アプリケーションの要件に基づいて複数ラジオを選択し、アプリケーションの異なる複数フラクションを複数のラジオにマッピングしうる、つまり複数ラジオの各々に対し各アプリケーションの１フラクションをマッピングしうる。一設計では、Ｍ：１マッピングの場合、無線デバイスは、複数のアプリケーションの要件を決定し、アプリケーションの要件に基づいて単一のラジオを選択し、複数のアプリケーションの複数フラクションをラジオにマッピングしうる、つまりラジオに対し各アプリケーションの１フラクションをマッピングしうる。一設計では、Ｍ：Ｎマッピングの場合、無線デバイスは、複数のアプリケーションの要件を決定し、アプリケーションの要件に基づいて複数ラジオを選択し、複数のアプリケーションの複数フラクションを複数のラジオにマッピングしうる、つまり複数ラジオの各々に対し各アプリケーションの１フラクションをマッピングしうる。

一設計では、ブロック１０１２、１０１６、および１０１８は、接続マネージャによって実行されうる、また、ブロック１０１４は、無線デバイス上で共存マネージャによって実行されうる。別の設計では、ブロック１０１２は、接続マネージャによって実行されうる、また、ブロック１０１４、１０１６、１０１８は、共存マネージャによって実行されうる。一般的に、ブロック１０１２〜１０１８は、無線デバイス内の１つまたは複数のエンティティによって実行されうる。

当業者は、情報および信号は、様々な異なる技術および技法のうちのいずれかを使用して表されうるということを理解するであろう。例えば、上記の説明の全体にわたって参照されうる、データ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場あるいは磁粒子、光場あるいは光学粒子、あるいはそれらのいずれの組み合わせ、によって表わされうる。

当業者は、ここにおける開示に関連して説明された様々な説明の論理ブロック、モジュール、回路およびアルゴリズムのステップが電子ハードウェア、コンピュータソフトウェア、または両方の組み合わせとして実装されうるということをさらに理解するであろう。ハードウェアとソフトウェアのこの互換性を明確に説明するために、様々な説明のためのコンポーネント、ブロック、モジュール、回路およびステップがそれらの機能という点から一般的に上述されてきた。このような機能がハードウェアまたはソフトウェアとして実装されるかは、全体のシステムに課せられた設計の制約と特定のアプリケーションに依存する。当業者は、各特定のアプリケーションについての様々な方法で、説明された機能性を実装しうるが、そのような実装の決定は、本発明の範囲からの逸脱を生じさせるものとして解釈されるべきでない。

ここでの開示に関連して説明された様々な説明のための論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、あるいは他のプログラマブル論理デバイス、ディスクリートゲートあるいはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここに説明された機能を実行するように設計されたそれらのいずれの組み合わせ、で実装または実行されうる。汎用プロセッサは、マイクロプロセッサでありうるが、代わりに、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンでありうる。プロセッサはまた、コンピューティングデバイスの組み合わせ、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと併用しての１つまたは複数のマイクロプロセッサ、あるいはいずれの他のそのような構成のもの、として実装されうる。

ここにおける開示に関連して説明される方法またはアルゴリズムのステップは、直接ハードウェアにおいて、プロセッサによって実行されるソフトウェアモジュールにおいて、または、それら２つの組み合わせにおいて具現化されうる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭ、メモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または当技術分野で知られている記憶媒体のいずれの他の形式において存在しうる。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み出し、記憶媒体に情報を書き込むように、プロセッサに結合される。あるいは、記憶媒体は、プロセッサに不可欠でありうる。プロセッサと記憶媒体は、ＡＳＩＣにおいて存在しうる。ＡＳＩＣは、ユーザ端末において存在しうる。あるいは、プロセッサと記憶媒体は、ユーザ端末においてディスクリートコンポーネントとして存在しうる。

１つまたは複数の例示的な設計では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらのいずれの組み合わせにおいて実装されうる。ソフトウェアで実装される場合には、機能は、コンピュータ可読媒体上で１つまたは複数の命令またはコードとして格納または送信されうる。コンピュータ可読媒体は、１つの場所から別の場所へとコンピュータプログラムの移送を容易にするいずれの媒体をも含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、汎用または専用コンピュータによってアクセスされることができるいずれの利用可能な媒体でありうる。例として、また限定されないが、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭあるいは他の光学ディスクストレージ、磁気ディスクストレージあるいは他の磁気ストレージデバイス、あるいは、命令あるいはデータ構造の形態において所望のプログラムコード手段を搬送または格納するために使用されることができる、また、汎用または専用コンピュータ、または、汎用または専用プロセッサによってアクセスされることができる、いずれの他の媒体をも備えることができる。また、いずれの接続もコンピュータ可読媒体と適切に名づけられる。例えば、ソフトウェアがウェブサイト、サーバ、あるいは、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者ライン（ＤＳＬ）、あるいは赤外線、無線、およびマイクロ波のような無線技術を使用している他の遠隔ソース、から送信される場合には、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、あるいは赤外線、無線、およびマイクロ波のような無線技術は、媒体の定義に含まれている。ここで使用される、ディスク（Disk）とディスク（disc）は、コンパクトディスク（ＣＤ）、レーザディスク、光学ディスク、デジタルバーサタイルディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、およびブルーレイ（登録商標）ディスクを含み、ディスク（Disk）はしばしばデータを磁気的に再生し、ディスク（disc）は、レーザで光学的に再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれるべきである。

本開示の先の説明は、当業者が本開示を行なうまたは使用することを可能にするために提供される。本開示に対する様々な変更は、当業者にとって容易に明らかであろう、また、ここで定義される一般的な原理は、本開示の範囲または精神から逸脱することなく他の変更に適用されうる。したがって、本開示は、ここで説明される例および設計に限定するように意図されておらず、ここで開示される原理および新規の特徴と一致して幅広い範囲が与えられるべきである。

Claims (28)

1. 無線通信のための方法であって、
   無線デバイス上でアクティブな少なくとも１つのアプリケーションの要件を決定することと、
   前記少なくとも１つのアプリケーションの要件に基づいて、前記無線デバイス上で複数のラジオから少なくとも１つのラジオを選択することと、
   前記少なくとも１つのラジオに前記少なくとも１つのアプリケーションをマッピングすることと、
   を備える方法。
2. 前記マッピングすることは、
   前記少なくとも１つのラジオの性能と、前記少なくとも１つのアプリケーションの要件と、に基づいて、前記少なくとも１つのアプリケーションの前記少なくとも１つのラジオへのマッピングを決定することと、
   前記決定された前記少なくとも１つのアプリケーションの前記少なくとも１つのラジオへのマッピングに基づいて、前記少なくとも１つのラジオに前記少なくとも１つのアプリケーションをマッピングすることと、
   を備える、請求項１に記載の方法。
3. 前記複数のラジオ間の干渉、または、チャネル状態、またはスループット、またはそれらの組み合わせに関連する少なくとも１つのメトリックに基づいて、前記少なくとも１つのラジオの性能を決定することと、
   をさらに備える請求項２に記載の方法。
4. 前記少なくとも１つのラジオの性能は、スループットによって与えられ、前記方法は、
   前記複数のラジオ間の干渉、または、チャネル状態、またはその両方に関連する測定値を取得すること、
   前記測定値に基づいて、前記少なくとも１つのラジオの各々のスループットを計算すること、
   をさらに備える請求項２に記載の方法。
5. 前記少なくとも１つのラジオの性能と前記少なくとも１つのアプリケーションの要件は、スループット、または遅延、またはジッタ、またはそれらの組み合わせに関連する、請求項２に記載の方法。
6. 前記少なくとも１つのラジオを選択すること、および、前記複数の反復についてのマッピングを決定すること、を実行すること、をさらに備える請求項２に記載の方法。
7. 前記少なくとも１つのアプリケーションの要件は、スループット、レイテンシ、ジッタ、接続時間、呼出ドロップレート、または、それらの組み合わせに関連する、請求項２に記載の方法。
8. 前記少なくとも１つのラジオの性能を決定することと、
   前記少なくとも１つのラジオの性能に基づいて、前記少なくとも１つのアプリケーションの要件を変更することと、
   をさらに備える請求項１に記載の方法。
9. 前記少なくとも１つのラジオを選択することは、前記少なくとも１つのアプリケーションのためのラジオ優先度、または前記複数のラジオのプライオリティ、または前記複数のラジオの性能、または、前記複数のラジオ間の干渉、またはチャネル状態、またはスループット、またはそれらの組み合わせにさらに基づいて前記少なくとも１つのラジオを選択することを備える、請求項１に記載の方法。
10. 前記少なくとも１つのアプリケーションの要件、または、前記複数のラジオ間の干渉、またはチャネル状態、またはスループット、またはそれらの組み合わせに基づいて、前記少なくとも１つのラジオの各々のオペレーティング状態を設定すること、
    をさらに備える請求項１に記載の方法。
11. 前記決定することは、単一のアプリケーションの要件を決定することを備え、前記選択することは、前記単一のアプリケーションの要件に基づいて複数のラジオを選択することを備え、前記マッピングすることは、前記複数のラジオに前記単一のアプリケーションの異なる複数フラクションをマッピングすること、前記複数のラジオの各々に前記単一アプリケーションの１つのフラクションをマッピングすることを備える、請求項１に記載の方法。
12. 前記決定することは、複数のアプリケーションの要件を決定することを備え、前記選択することは、前記複数のアプリケーションの要件に基づいて単一のラジオを選択することを備え、前記マッピングすることは、前記単一のラジオに前記複数のアプリケーションの複数フラクションをマッピングすること、前記単一のラジオに前記複数のアプリケーションの各々の１つのフラクションをマッピングすることを備える、請求項１に記載の方法。
13. 前記決定することは、複数のアプリケーションの要件を決定することを備え、前記選択することは、前記複数のアプリケーションの要件に基づいて複数のラジオを選択することを備え、前記マッピングすることは、前記複数のラジオに前記複数のアプリケーションの複数フラクションをマッピングすることを備える、請求項１に記載の方法。
14. 前記決定することと前記マッピングすることは、接続マネージャによって実行され、前記選択することは、前記無線デバイス上で共存マネージャによって実行される、請求項１に記載の方法。
15. 前記決定することは、接続マネージャによって実行され、前記選択することと前記マッピングすることは、前記無線デバイス上で共存マネージャによって実行される、請求項１に記載の方法。
16. 無線通信のための装置であって、
    無線デバイス上でアクティブな少なくとも１つのアプリケーションの要件を決定するための手段と、
    前記少なくとも１つのアプリケーションの要件に基づいて、前記無線デバイス上で複数のラジオから少なくとも１つのラジオを選択するための手段と、
    前記少なくとも１つのラジオに前記少なくとも１つのアプリケーションをマッピングするための手段と、
    を備える装置。
17. 前記マッピングするための手段は、
    前記少なくとも１つのラジオの性能と、前記少なくとも１つのアプリケーションの要件と、に基づいて、前記少なくとも１つのアプリケーションの前記少なくとも１つのラジオへのマッピングを決定するための手段と、
    前記決定された前記少なくとも１つのアプリケーションの前記少なくとも１つのラジオへのマッピングに基づいて、前記少なくとも１つのラジオに前記少なくとも１つのアプリケーションをマッピングするための手段と、
    を備える、請求項１６に記載の装置。
18. 前記少なくとも１つのラジオを選択すること、および、前記複数の反復についてのマッピングを決定すること、を実行するための手段、をさらに備える請求項１７に記載の装置
19. 前記少なくとも１つのラジオの性能を決定するための手段と、
    前記少なくとも１つのラジオの性能に基づいて、前記少なくとも１つのアプリケーションの要件を変更するための手段と、
    をさらに備える請求項１６に記載の装置。
20. 前記少なくとも１つのラジオを選択するための手段は、前記複数のラジオの性能、または、前記複数のラジオ間の干渉、またはチャネル状態、またはスループット、またはそれらの組み合わせに基づいて前記少なくとも１つのラジオを選択するための手段を備える、請求項１６に記載の装置。
21. 前記少なくとも１つのアプリケーションの要件、または、前記複数のラジオ間の干渉、またはチャネル状態、またはスループット、またはそれらの組み合わせに基づいて、前記少なくとも１つのラジオの各々のオペレーティング状態を設定するための手段、
    をさらに備える請求項１６に記載の装置。
22. 無線通信のための装置であって、
    無線デバイス上でアクティブな少なくとも１つのアプリケーションの要件を決定し、前記少なくとも１つのアプリケーションの要件に基づいて、前記無線デバイス上で複数のラジオから少なくとも１つのラジオを選択し、前記少なくとも１つのラジオに前記少なくとも１つのアプリケーションをマッピングするように構成された少なくとも１つのプロセッサ、
    を備える装置。
23. 前記少なくとも１つのプロセッサは、前記少なくとも１つのラジオの性能と、前記少なくとも１つのアプリケーションの要件と、に基づいて、前記少なくとも１つのアプリケーションの前記少なくとも１つのラジオへのマッピングを決定し、前記決定された前記少なくとも１つのアプリケーションの前記少なくとも１つのラジオへのマッピングに基づいて、前記少なくとも１つのラジオに前記少なくとも１つのアプリケーションをマッピングするように構成される、請求項２２に記載の装置。
24. 前記少なくとも１つのプロセッサは、前記少なくとも１つのラジオを選択すること、および、前記複数の反復についてのマッピングを決定すること、を実行するように構成される、請求項２３に記載の装置。
25. 前記少なくとも１つのプロセッサは、前記少なくとも１つのラジオの性能を決定し、前記少なくとも１つのラジオの性能に基づいて、前記少なくとも１つのアプリケーションの要件を変更するように構成される、請求項２２に記載の装置。
26. 前記少なくとも１つのプロセッサは、前記複数のラジオの性能、または、前記複数のラジオ間の干渉、またはチャネル状態、またはスループット、またはそれらの組み合わせに基づいて前記少なくとも１つのラジオを選択するように構成される、請求項２２に記載の装置。
27. 前記少なくとも１つのプロセッサは、前記少なくとも１つのアプリケーションの要件、または、前記複数のラジオ間の干渉、またはチャネル状態、またはスループット、またはそれらの組み合わせに基づいて、前記少なくとも１つのラジオの各々のオペレーティング状態を設定するように構成される、請求項２２に記載の装置。
28. ノントランジトリコンピュータ可読媒体を備えるコンピュータプログラムプロダクトであって、前記ノントランジトリコンピュータ可読媒体は、
    少なくとも１つのコンピュータに、無線デバイス上でアクティブな少なくとも１つのアプリケーションの要件を決定させるためのコードと、
    前記少なくとも１つのコンピュータに、前記少なくとも１つのアプリケーションの要件に基づいて、前記無線デバイス上で複数のラジオから少なくとも１つのラジオを選択させるためのコードと、
    前記少なくとも１つのコンピュータに、前記少なくとも１つのラジオに前記少なくとも１つのアプリケーションをマッピングさせるためのコードと、
    を備える、
    コンピュータプログラムプロダクト。

Images