JP2013535938A - デバイス内干渉軽減のための方法およびシステム - Google Patents

Abstract

デバイス内干渉を軽減するための方法および装置を説明する。これらの方法は、デバイス内干渉イベント（例えば、干渉状況）を含んでもよく、イベントの処理は、技術の優先度によって決まってもよい。別の周波数または無線アクセス技術（ＲＡＴ）へのハンドオーバは、共存する技術がアクティブ化されうる場合に起こってもよい。ネットワークは、デバイスに対し、測定し、かつ、それにハンドオフすることが可能にされうる周波数またはＲＡＴのリストを、シグナリングしてもよい。ネットワークは、デバイスが干渉に対する反応を加速するために使用することができる、スケーリング値を提供してもよい。デバイスは、スケーリング係数を、ＲＬＦプロシージャのために使用される「非同期」カウンタおよび／または無線リンク障害（ＲＬＦ）タイマに適用してもよい。デバイスは、測定値、および、イベントをトリガするべき時間に対して、異なるスケーリング係数を適用してもよい。デバイスは、代替ＲＡＴのためのギャップを要求するネットワークへの報告をトリガしてもよい。

Description

本出願は、無線通信に関する。

本出願は、その開示が参照により本明細書に組み込まれている、米国仮特許出願第６１／３７３５３９号、第６１／３８９０３０号、第６１／４１０６４５号、第６１／４３０７０４号、第６１／４４１９６３号および第６１／４７１０６０号の、米国特許法１１９条（ｅ）に基づく利益を主張するものである。

今日、多数の無線デバイスは、複数の無線技術および／またはアプリケーションをサポートしている。例えば、現在使用可能な無線デバイスは、トランシーバ、送信器または受信器を含む、複数のコンポーネントまたはデバイスを含むことがある。そのようなコンポーネントは、ＬＴＥおよびＬＴＥアドバンスト（ＬＴＥ−Ａ）など、ロングタームエボリューション（ＬＴＥ）技術と、Ｂｌｕｅｔｏｏｔｈ（登録商標）技術、および、Ｗｉ−ＦｉなどのＷＬＡＮ（wireless local access networks）技術を含む、ＩＳＭ（Industrial, Scientific and Medical）技術と、ＧＰＳ（global positioning system）技術とを含む、異なる無線技術および／またはアプリケーションをサポートすることができる。

複数の無線技術およびアプリケーションのサポートは、無線デバイスの能力を増大させているが、そのようなサポートはまた、無線デバイス内の干渉にもつながっている。例えば、ＬＴＥ時分割複信（ＴＤＤ）など、ＬＴＥ技術は、無線デバイス内で、２．３〜２．４ＧＨｚ周波数を含む、帯域４０で動作することができる。ＩＳＭ技術および／またはＧＰＳ技術は、同じ無線デバイス内で隣接した帯域および周波数上で動作することができる。このように、ＬＴＥ技術、Ｂｌｕｅｔｏｏｔｈ技術およびＷｉ−Ｆｉを含むＩＳＭ技術、ならびに／または、ＧＰＳ技術は、同じ無線デバイス内で隣接した帯域上で動作することができ、それにより、ＬＴＥ技術のための信号を受信または送信するトランシーバに、Ｂｌｕｅｔｏｏｔｈ技術およびＷｉ−Ｆｉを含むＩＳＭ技術ならびに／またはＧＰＳ技術のための信号を受信または送信するトランシーバへの干渉を発生させることがあり、その逆も同様である。加えて、無線技術および／またはアプリケーションはまた、それらの間で干渉を引き起こすこともある。例えば、ＬＴＥおよびＬＴＥ−Ａなど、無線デバイス内の複数のＬＴＥ技術は、隣接した帯域上で動作することができ、それにより、例えば、無線デバイス内でそのようなＬＴＥ技術のために使用されるトランシーバなど、デバイスまたはコンポーネント間で干渉を引き起こすことがある。

そのような無線デバイスによってサポートされた複数の無線技術およびアプリケーションによって引き起こされる、そのような相互干渉を軽減するために、アクティブバンドパスフィルタなどのフィルタ技術が採用されている。残念ながら、そのようなフィルタ技術は、無線デバイス内で複数の無線技術および／またはアプリケーションによって使用される、隣接した帯域および周波数の十分なリジェクション（rejection）を提供しないので、そのようなフィルタ技術は、無線デバイス内で複数の無線技術および／またはアプリケーションによって生じる相互干渉を適切に軽減していない。

デバイス内技術間の干渉を回避または軽減するためのシステムおよび方法を開示する。一実施形態では、無線デバイス内の無線アクセス技術（ＲＡＴ）コンポーネント間の干渉を、軽減することができる。例えば、無線デバイス内の第１のＲＡＴコンポーネントと第２のＲＡＴコンポーネントの間の干渉状況が、検出されてもよい。

一実施形態では、干渉状況の通知は次いで、ネットワークへ送信されてもよい。この通知は、先行的で、例えば、実際の干渉状況に先立って判定されてもよく、または、反応的で、干渉状況が検出された後に判定されてもよい。ネットワークへの干渉状況の通知は、干渉状況を軽減するために使用されるように構成された情報を含んでもよい。ネットワークは次いで、干渉状況を軽減するために処理かつ／または実行される必要がある、１つまたは複数のアクション、方法、ルール、プロシージャ、構成および／またはプロトコルを判定してもよい。そのようなアクション、方法、ルール、プロシージャ、構成および／またはプロトコルのインジケーションを含む構成情報などの情報が、無線デバイスによって受信されてもよく、アクションが無線デバイスによって干渉を軽減するために実行されるように、処理されてもよい。

別の実施形態によれば、干渉状況の通知は、ネットワークに提供されないことがある（例えば、無線リンク障害（radio link failure：ＲＬＦ）が発生することがある）。そのような実施形態では、無線デバイスは、ネットワークからの支援なしに、１つまたは複数のアクション、方法、ルール、プロシージャ、構成および／またはプロトコルを実行して、干渉（または、例えば、ＲＬＦ）を軽減してもよい。

以下の詳細な説明は、添付の図面と共に読まれるとき、より良く理解されるであろう。例示のために、図面に例示的実施形態を示すが、主題は、本明細書で開示された特定の要素および手段に限定されない。

１つまたは複数の開示された実施形態を実装することができる、通信システムの例を示すシステム図である。 図１Ａに例示された通信システム内で使用することができる、無線送信／受信ユニット（ＷＴＲＵ）の例を示すシステム図である。 図１Ａに例示された通信システム内で使用することができる、無線アクセスネットワークの一例およびコアネットワークの例を示すシステム図である。 本明細書で開示された実施形態によって使用することができる、限定的でない周波数範囲およびチャネルの実施形態の例を示す図である。 無線送信／受信ユニット（ＷＴＲＵ）など、無線デバイス内のコンポーネント間の干渉を軽減するための方法の実施形態の例を示す図である。 潜在的な干渉技術デバイスアプリケーションコントローラおよびプロトコルスタックの実施形態の例を示す図である。 オン継続時間（On Duration）の期間を有する、ロングタームエボリューションのための間欠受信（ＤＲＸ）パターンの例を示す図である。 ダウンリンク（ＤＬ）再送信およびＤＬフィードバックの例を示す図である。 スケジューリング要求（ＳＲ）図の例を示す図である。 ＳＲが送信された後の動きの例を示す図である。 間欠受信（ＤＲＸ）動作の例を示す図である。 ＤＲＸ動作の別の例を示す図である。 ＤＲＸ動作の別の例を示す図である。 ＤＲＸ動作の別の例を示す図である。 低減されたアップリンクモード動作の例を示す図である。

図１Ａは、１つまたは複数の開示された実施形態を実装することができる、通信システム１００の例を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、およびブロードキャストなどのコンテンツを、複数の無線ユーザに提供する、多重アクセスシステムであってもよい。通信システム１００は、無線帯域幅を含むシステムリソースの共有を通じて、複数の無線ユーザがそのようなコンテンツにアクセスできるようにしてもよい。例えば、通信システム１００は、ＣＤＭＡ（code division multiple access）、ＴＤＭＡ（time division multiple access）、ＦＤＭＡ（frequency division multiple access）、ＯＦＤＭＡ（orthogonal FDMA）、およびＳＣ−ＦＤＭＡ（single-carrier FDMA）などの、１つまたは複数のチャネルアクセス方法を採用してもよい。

図１Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、ならびにその他のネットワーク１１２を含んでもよいが、開示された実施形態が任意の数のＷＴＲＵ、基地局、ネットワークおよび／またはネットワーク要素を企図することは理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの各々は、無線環境内で動作かつ／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄは、無線信号を送信かつ／または受信するように構成可能であり、ユーザ機器（ＵＥ）、移動局、固定またはモバイルの加入者ユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサおよび家庭用電化製品などを含んでもよい。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。基地局１１４ａおよび１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのうち少なくとも１つと無線でインタフェースして、コアネットワーク１０６、インターネット１１０および／またはネットワーク１１２など、１つまたは複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスであってもよい。例として、基地局１１４ａおよび１１４ｂは、無線基地局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１１４ａおよび１１４ｂは、それぞれ単一の要素として示されるが、基地局１１４ａおよび１１４ｂが任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことは理解されよう。

基地局１１４ａは、ＲＡＮ１０４の一部であってもよく、ＲＡＮ１０４はまた、基地局コントローラ（ＥＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードおよびその他の基地局および／またはネットワーク要素（図示せず）をも含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的地域内で無線信号を送信かつ／または受信するように構成されてもよく、この地理的地域は、セル（図示せず）と呼ばれることがある。セルは、さらにセルセクタに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。このようにして、一実施形態では、基地局１１４ａは３つのトランシーバを、すなわち、セルのセクタごとに１つずつ含んでもよい。別の実施形態では、基地局１１４ａは、ＭＩＭＯ（multiple-input multiple output）技術を採用してもよく、したがって、セルのセクタごとに複数のトランシーバを利用してもよい。

基地局１１４ａおよび１１４ｂは、エアインタフェース１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのうち１つまたは複数と通信してもよく、エアインタフェース１１６は、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）および可視光線など）であってもよい。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる

より具体的には、上述のように、通信システム１００は、多重アクセスシステムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡおよびＳＣ−ＦＤＭＡなど、１つまたは複数のチャネルアクセス方式を採用することができる。例えば、ＲＡＮ１０４内の基地局１１４ａ、ならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、ＵＴＲＡ（Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access）などの、無線技術を実装することができ、この無線技術は、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用して、エアインタフェース１１６を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／またはＨＳＰＡ＋（Evolved HSPA）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）、および／または、高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでもよい。

別の実施形態では、基地局１１４ａならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access）などの無線技術を実装することができ、この無線技術は、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用して、エアインタフェース１１６を確立することができる。

他の実施形態では、基地局１１４ａならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access））、ＣＤＭＡ２０００、ＣＤＭＡ２０００−１Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、ＩＳ−２０００（Interim Standard 2000）、ＩＳ−９５（Interim Standard 95）、ＩＳ−８５６（Interim Standard 856）、ＧＳＭ（Global System for Mobile communications：登録商標）、ＥＤＧＥ（Enhanced Data rates for GSM Evolution）、およびＧＳＭ−ＥＤＧＥなどの無線技術を実装することができる。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢまたはアクセスポイントであってもよく、職場、家庭、車両、およびキャンパスなどの局所的なエリア内の無線接続性を容易にするための任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂならびにＷＴＲＵ１０２ｃおよび１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、ＷＬＡＮ（wireless local area network）を確立することができる。別の実施形態では、基地局１１４ｂならびにＷＴＲＵ１０２ｃおよび１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、ＷＰＡＮ（wireless personal area network）を確立することができる。さらに別の実施形態では、基地局１１４ｂならびにＷＴＲＵ１０２ｃおよび１０２ｄは、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥおよびＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。このように、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスする必要がない。

ＲＡＮ１０４は、コアネットワーク１０６と通信していてもよく、コアネットワーク１０６は、音声、データ、アプリケーション、および／または、ＶｏｉＰ（voice over internet protocol）サービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのうち１つまたは複数に提供するように構成された、任意のタイプのネットワークであってもよい。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、およびビデオ配信などを提供し、かつ／または、ユーザ認証など、高レベルのセキュリティ機能を行うことができる。図１Ａに図示しないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用するその他のＲＡＮと、直接的または間接的に通信していてもよいことが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用している、ＲＡＮ１０４に接続されることに加えて、コアネットワーク１０６はまた、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信していてもよい。

コアネットワーク１０６はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄが、ＰＳＴＮ１０８、インターネット１１０および／またはその他のネットワーク１１２にアクセスするための、ゲートウェイとしての機能を果たすこともできる。ＰＳＴＮ１０８は、一般電話サービス（ＰＯＴＳ）を提供する、回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコル群における、ＴＣＰ（transmission control protocol）、ＵＤＰ（user datagram protocol）およびＩＰ（internet protocol）などの共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスのグローバルなシステムを含んでもよい。ネットワーク１１２には、他のサービスプロバイダによって所有かつ／または運用される、有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、１つまたは複数のＲＡＮに接続された別のコアネットワークを含んでもよく、これらのＲＡＮは、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用してもよい。

通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの一部または全部は、マルチモード機能を含んでもよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含んでもよい。例えば、図１Ａに示すＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用することができる基地局１１４ａと、かつ、ＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと、通信するように構成されてもよい。

図１Ｂは、ＷＴＲＵ１０２の例を示すシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送受信素子１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、ＧＰＳ（global positioning system）チップセット１３６、および、その他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２は、一実施形態との整合性を維持したまま、前述の要素の任意のサブコンビネーションを含んでもよいことは理解されよう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、また、ＤＳＰコア、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意のその他のタイプの集積回路（ＩＣ）、および状態マシンなどに関連した、１つまたは複数のマイクロプロセッサであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／または、ＷＴＲＵ１０２が無線環境内で動作することを可能にする任意のその他の機能性を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合されてもよく、トランシーバ１２０は、送受信素子１２２に結合されてもよい。図１Ｂは、プロセッサ１１８およびトランシーバ１２０を別々のコンポーネントとして示すが、プロセッサ１１８およびトランシーバ１２０は、電子パッケージまたはチップ内で共に統合可能であることが理解されよう。

送受信素子１２２は、エアインタフェース１１６を介して、基地局（例えば、基地局１１４ａ）へ信号を送信し、または、基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、送受信素子１２２は、ＲＦ信号を送信かつ／または受信するように構成されたアンテナであってもよい。別の実施形態では、送受信素子１２２は、例えば、ＩＲ、ＵＶまたは可視光信号を送信かつ／または受信するように構成されたエミッタ／ディテクタであってもよい。さらに別の実施形態では、送受信素子１２２は、ＲＦおよび光信号を共に送信かつ受信するように構成されてもよい。送受信素子１２２は、任意の組み合わせの無線信号を送信かつ／または受信するように構成されてもよいことが理解されよう。

加えて、送受信素子１２２は、図１Ｂで単一の素子として示されるが、ＷＴＲＵ１０２は、任意の数の送受信素子１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。このようにして、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６を介して無線信号を送信かつ受信するための、２つ以上の送受信素子１２２（例えば、複数のアンテナ）を含んでもよい。

トランシーバ１２０は、送受信素子１２２によって送信される信号を変調するように、かつ、送受信素子１２２によって受信される信号を復調するように構成されてもよい。上述のように、ＷＴＲＵ１０２は、マルチモード機能を有してもよい。このようにして、トランシーバ１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信を可能にする、複数のトランシーバを含んでもよい。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）表示ユニット、もしくは、有機発光ダイオード（ＯＬＥＤ）表示ユニット）に結合されてもよく、それらからユーザ入力データを受信することができる。プロセッサ１１８はまた、ユーザデータを、スピーカ／マイクロフォン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８に出力することもできる。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスし、そのメモリにデータを格納することができる。着脱不能メモリ１３０は、ＲＡＭ（random-access memory）、ＲＯＭ（read-only memory）、ハードディスク、または、任意のその他のタイプのメモリ記憶装置が含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含んでもよい。その他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に位置していないメモリからの情報にアクセスし、そのメモリにデータを格納することができる。

プロセッサ１１８は、電源１３４から電力を受信することができ、ＷＴＲＵ１０２内のその他のコンポーネントへの電力を分配かつ／または制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）その他）、太陽電池、および燃料電池などを含んでもよい。

プロセッサ１１８はまた、ＧＰＳチップセット１３６にも結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、エアインタフェース１１６を介して、基地局（例えば、基地局１１４ａおよび１１４ｂ）から位置情報を受信し、かつ／または、信号が２つ以上の近くの基地局から受信されるタイミングに基づいて、その位置を判定することができる。ＷＴＲＵ１０２は、一実施形態との整合性を維持したまま、任意の適切な位置判定方法によって位置情報を取得することができることは理解されよう。

プロセッサ１１８は、その他の周辺機器１３８にさらに結合されてもよく、その他の周辺機器１３８は、追加の特徴、機能性、および／または、有線もしくは無線接続性を提供する、１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含んでもよい。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ＵＳＢ（universal serial bus）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈモジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含んでもよい。

図１Ｃは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０６を示すシステム図である。上述のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信することができる。ＲＡＮ１０４はまた、コアネットワーク１０６と通信してもよい。

ＲＡＮ１０４は、ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃを含んでもよいが、ＲＡＮ１０４は、一実施形態との整合性を維持しながら、任意の数のｅＮｏｄｅＢを含んでもよいことが理解されよう。ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信するための、１つまたは複数のトランシーバをそれぞれ含んでもよい。一実施形態では、ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、ＭＩＭＯ技術を実装してもよい。このようにして、ｅＮｏｄｅＢ１４０ａは、例えば、複数のアンテナを使用して無線信号をＷＴＲＵ１０２ａへ送信し、無線信号をＷＴＲＵ１０２ａから受信してもよい。

ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃの各々は、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、およびアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１Ｃに示すように、ｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、Ｘ２インタフェースを介して互いに通信してもよい。

図１Ｃに示すコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、および、パケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含んでもよい。前述の要素の各々は、コアネットワーク１０６の一部として示されるが、これらの要素のいずれか１つは、コアネットワークオペレータ以外のエンティティによって所有かつ／または操作されうることが理解されよう。

ＭＭＥ１４２は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅＢ１４２ａ、１４２ｂおよび１４２ｃの各々に接続されてもよく、制御ノードとしての機能を果たすことができる。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、およびＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃの初期のアタッチ中に特定のサービングゲートウェイを選択すること、などを担うことができる。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなど、その他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための、制御プレーン機能を提供することもできる。

サービングゲートウェイ１４４は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃの各々に接続されてもよい。サービングゲートウェイ１４４は一般に、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃへ／からルーティングかつ転送することができる。サービングゲートウェイ１４４はまた、ｅＮｏｄｅＢ間ハンドオーバ中のユーザプレーンのアンカリング、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃのために使用可能であるとき、ページングのトリガ、ならびにＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃのコンテキストの管理および格納などの、その他の機能を実行することもできる。

サービングゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６にも接続されてもよく、ＰＤＮゲートウェイ１４６は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、インターネット１１０など、パケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃとＩＰ対応デバイスの間の通信を容易にすることができる。

コアネットワーク１０６は、その他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、ＰＳＴＮ１０８など、回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと従来の固定電話通信デバイスの間の通信を容易にすることができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインタフェースとしての機能を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、または、ＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃに、ネットワーク１１２へのアクセスを提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有かつ／または運用される、その他の有線または無線ネットワークが含んでもよい。

実施形態の一例によれば、例えば、図１Ａ乃至１Ｃに示すＷＴＲＵ、ルータ、コンピューティングデバイス（ラップトップ、テーブル、ｅリーダなど）、ならびにｅＮｏｄｅＢ（ｅＮＢ）などを含む、ＷＴＲＵすなわちＵＥなどの無線デバイスは、上記で説明したような複数の無線技術および／またはアプリケーションをサポートし、複数の無線技術が無線デバイス内で互いに共存することを可能にすることができる。したがって、そのような無線技術のためのスペクトルは、そのような技術をサポートする無線デバイス内のコンポーネント間の干渉の結果となることがある。例えば、ＬＴＥ技術と、ＢｌｕｅｔｏｏｔｈおよびＷｉＦｉ技術を含むＩＳＭ（Industrial, Scientific and Medical）技術と、ＧＰＳ（Global Positioning Satellite）技術と、または、任意のその他の適切な無線技術および／もしくはアプリケーションとは、隣接または重複する周波数帯域内に配置されることがあり、例えば、そのような無線技術をサポートするコンポーネントまたはデバイスによって、隣接もしくはオーバーラップする周波数または帯域を使用して、同時に信号を受信および／または送信しているときに、それらのコンポーネントまたはデバイス間に干渉が存在する場合がある。

例えば、無線デバイス内に含まれるＩＳＭ技術は、世界的に無認可のＩＳＭ２．４ＧＨｚの短距離の無線周波数帯域を使用することができる。そのような無認可のＩＳＭ２．４ＧＨｚの短距離の無線周波数帯域を使用して、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ技術およびその他のＩＳＭ技術をサポートすることができる。例えば、無線デバイス内のＢｌｕｅｔｏｏｔｈ技術は、時分割複信（ＴＤＤ）による範囲２４０２〜２４８０ＭＨｚの範囲内のそれぞれ１ＭＨｚの７９個のチャネルにわたる周波数ホッピングスペクトル拡散を使用して、２４５０ＭＨｚ帯域内に配置されてもよい。無線デバイス内のＷｉＦｉ技術もまた、図２に示すように、約２．４〜約２．５ＧＨｚの周波数スペクトル内のチャネル上に配置されてもよい。例えば、ＷｉＦｉ技術は、チャネル上に配置されてもよい。図２に示すように、そのようなチャネルをサポートすることができる周波数帯域は、周波数スペクトル（約２．４〜約２．５ＧＨｚ）内でオーバーラップしていることがある。そのような周波数帯域がオーバーラップしていることがあるので、無線デバイス内のチャネルの割り当てを、特定のチャネル（例えば、５個ごとのチャネル）に制限して、十分な分離（例えば、５ＭＨｚ）を可能にする。したがって、一実施形態では、無線デバイスによってＷｉＦｉをサポートするために使用されるチャネルは、図２に示すように、チャネル１（２．４１２ＧＨｚを中心とする２２ＭＨｚ周波数帯域を使用する）、チャネル６（２．４３７ＧＨｚを中心とする２２ＭＨｚ周波数帯域を使用する）、および、チャネル１１（２．４６２ＧＨｚを中心とする２２ＭＨｚ周波数帯域を使用する）であってもよい。いくつかの実施形態では、そのようなチャネルで生成された信号はまた、そのスペクトルマスク（spectral mask）により、中心周波数から１１ＭＨｚで、そのピークエネルギーから少なくとも５０ｄＢｒだけ減衰されてもよい。

加えて、無線デバイス内に含まれるＬＴＥ技術は、上記で説明したＢｌｕｅｔｏｏｔｈおよびＷｉＦｉ技術など、無線デバイス内に含まれうるＩＳＭ技術のように、隣接した帯域上に配置されてもよい。例えば、無線デバイスは、キャリアアグリゲーションを有するＬＴＥ−Ｒ１０（Release 10）におけるＬＴＥ−ＴＤＤ帯域４０をサポートすることができる。キャリアアグリゲーションを有するＬＴＥ−Ｒ１０におけるＬＴＥ−ＴＤＤ帯域４０は、最大１００ＭＨｚの帯域全体を使用することができ、あるいは、２３８０〜２４００ＭＨｚ帯域を受信して、それに関連付けられた信号を送信および／または受信することができる。

実施形態の一例では、無線デバイス内に含まれうる、コンポーネントまたはデバイスが、２３８０〜２４００ＭＨｚ帯域を使用して、ＬＴＥ−Ｒ１０におけるＬＴＥ−ＴＤＤ帯域４０をサポートするとき、そのコンポーネントまたはデバイスと、ＢｌｕｅｔｏｏｔｈおよびＷｉＦｉなど、約２．４ＧＨｚで配置されたＩＳＭ技術をサポートするために無線デバイス内に含まれうるコンポーネントまたはデバイスとの共存は、周波数または帯域が近い（例えば、隣接または重複している）ことにより、問題になりうる。例えば、ある無線デバイスが、ＬＴＥ−Ｒ１０におけるＬＴＥ−ＴＤＤ帯域４０をサポートする第１のコンポーネント、および、ＢｌｕｅｔｏｏｔｈまたはＷｉＦｉをサポートする第２のコンポーネントを含む場合、第１のコンポーネントが２３８０〜２４００ＭＨｚ帯域上でデータもしくは情報を、送信または受信しており、かつ、第２のコンポーネントが、２．４ＧＨｚ帯域を使用してデータもしくは情報を、送信または受信するためにアクティブ化されるときに、干渉が発現するか、または生じることがある。

別の実施形態では、無線デバイスは、ＧＰＳ受信器など、ＧＰＳコンポーネントを含んでもよい。ＧＰＳコンポーネントは、第二高調波成分を通じて７６８ＭＨｚ周波数の範囲内で動作する送信器など、その他の無線アクセス技術をサポートするその他のコンポーネントによって、容易に感度低下（de-sensed）されることがある。例えば、ＴＤＤ技術をサポートする１つまたは複数のコンポーネント（同じ周波数上で動作する受信器（Ｒｘ）および送信器（Ｔｘ）など）は、干渉の傾向がある領域または周波数分割複信（ＦＤＤ）技術内で動作することがあり、送信器（干渉者）または受信器（被干渉者）が高調波誘導干渉領域（harmonic induce interference region）内で動作する。無線デバイス内のＴＤＤ技術をサポートするコンポーネントまたはその他のコンポーネントは、それらの対となるアクセスポイント（ＡＰ）／基地局との通信能力を完全に失うことにつながるか、または、キャリア検知（ＣＳ）技術に基づくシステムの通信チャネルを混乱させ、それにより妨害器として働く、起こりうる低雑音増幅器（ＬＮＡ）の飽和を軽減するために、迅速に反応しなければならないことがある。一実施形態では、ＧａｌｉｌｅｏおよびＧｌｏｎａｓｓシステムを含む、ＧＰＳ技術をサポートするＧＰＳコンポーネントは、例えば、ＴＤＤおよびＦＤＤ技術をサポートするコンポーネントによって生じた、そのような高調波の結果として妨害されることがある。

別の実施形態によれば、無線デバイスは、異なるＬＴＥ技術をサポートすることができる複数のコンポーネントまたはデバイスを含んでもよい。無線デバイス内のそのようなコンポーネントの共存は、その中でサポートされた様々なＬＴＥ技術の間で干渉を生じることがある。例えば、あるＬＴＥ技術をサポートするために無線デバイス内に含まれる第１のコンポーネントは、異なるＬＴＥ技術をサポートするための無線デバイス内の第２のコンポーネントへの干渉を、第１のコンポーネントおよび第２のコンポーネントが同時に信号を送信および／または受信しているときに、生じることがある。

本明細書で説明するものは、複数の無線アクセス技術をサポートする無線デバイス（「マルチＲＡＴデバイス」）内で生じ、または存在する可能性のある、そのような干渉の軽減を可能にする方法、プロシージャ、ルールおよび／またはプロトコルであり、例えば、マルチＲＡＴデバイス内の干渉状況（例えば、潜在的な干渉、または、実際の測定された干渉）の予測または検出、ネットワークへの干渉状況の報告または通知、マルチＲＡＴデバイス内の干渉状況を防止するための解決策または機構、マルチＲＡＴデバイス内の干渉状況からの回復、およびマルチＲＡＴ内の干渉状況に対して使用される、デバイス内の無線アクセス技術（ＲＡＴ）間の共存動作プロシージャを含む。本明細書で説明する以下の方法、プロシージャ、ルールおよび／またはプロトコルは、任意の変形形態および／または組み合わせで使用されてもよい。

提案する解決策を、簡単にするために、例として、既知のＬＴＥおよびＩＳＭおよび／またはＧＰＳデバイス相互干渉の場合に関して説明する。しかし、これらの解決策は、この場合に限定または制限されず、その他の無線技術に適用可能である。

加えて、マルチキャリアシステムのための以下の専門用語が本明細書で使用されることがあり、すなわち、ＲＡＴ−無線アクセス技術）、Ｐセル−プライマリセル（ただし、主な制御シグナリングは、セル（Ｓセルなど）アクティブ化／非アクティブ化プロシージャ、ＤＬ割り当ておよびＵＬグラント、ＵＬ−ＨＡＲＱおよびＣＱＩフィードバックを含んで行われ、モビリティアンカーであってもよい）、Ｓセル−セカンダリセル（トラフィックを搬送し、定期的に測定されてもよく、構成かつアクティブまたは非アクティブ化されてもよい）、ＩＳＭデバイスまたはその他のＲＡＴデバイス−干渉側の送信器（場合によっては、非認可のＩＳＭ帯域内）、および、ＷＴＲＵまたは無線デバイス受信器−オペレータにより認可されたスペクトル関連技術である。

加えて、ＬＴＥデバイス、ＬＴＥまたはＬＴＥ技術は、ＬＴＥ、ＬＴＥ−Ａ、ＵＭＴＳ（Universal Mobile telecommunications System）、ＧＳＭ（Global System for Mobile Communications）、ＷＩＭＡＸ（Worldwide Interoperability for Microwave Access）、ＡＭＰＳ（Advanced Mobile Phone System）、およびＣＤＭＡ（Code division multiple access）など、スペクトルにより開発された技術を指すことがある。加えて、以下で言及されるとき、ＧＰＳ（Global Positioning System）デバイス、ＧＰＳ受信器またはＧＰＳは、ＧＰＳ、ＧａｌｉｌｅｏまたはＧｌｏｎａｓｓなど、任意のグローバルポジショニング技術を指す。

図３は、図１Ａ乃至１Ｃに示すＷＴＲＵ、ルータ、ｅＮｏｄｅＢ、ならびにラップトップ、デスクトップ、サーバ、タブレット、およびｅリーダなどのコンピューティングデバイスなど、ＷＴＲＵすなわちＵＥなどの無線デバイス（「マルチＲＡＴデバイス」）内で異なる無線アクセス技術および／またはアプリケーションをサポートすることができる、トランシーバ、受信器、モデム、コントローラ、アプリケーション、およびプロセッサなどの、１つまたは複数のコンポーネント間の干渉を軽減または低減するための方法３００の実施形態の一例を示す。図３に示すように、３０２で、ある無線アクセス技術をサポートする第１のデバイスまたはコンポーネントと、別の無線アクセス技術をサポートする第２のデバイスまたはコンポーネントとの間の、無線デバイス内の干渉状況が検出または識別されてもよい。

例えば、上記で説明したように、無線デバイスは、ＬＴＥ、ＬＴＥ−Ａ、ＵＭＴＳ、ＧＳＭ、ＷＩＭＡＸ、ＡＭＰＳ、ＣＤＭＡ、およびＥ−ＵＴＲＡＮなどを含むＬＴＥ技術、例えば、ＢｌｕｅｔｏｏｔｈおよびＷｉＦｉなどを含むＩＳＭ技術、ＧＰＳ、Ｇａｌｉｌｅｏ、およびＧｌｏｎａｓｓなどを含むＧＰＳ技術、ならびに／または、任意の他の無線アクセス技術など、複数の無線アクセス技術および／またはアプリケーションをサポートすることができる、トランシーバ、受信器、モデム、コントローラ、アプリケーション、およびプロセッサなどの、複数のデバイスまたはコンポーネントを含んでもよい。図４は、複数の無線技術をサポートする複数のコンポーネントを有する、ＷＴＲＵ、ルータ、ｅＮｏｄｅＢ、ならびに、例えば、ラップトップ、デスクトップ、サーバ、タブレットおよびｅリーダなどを含むコンピューティングデバイスなど、無線デバイス４００（「マルチＲＡＴデバイス」）の実施形態の一例を示す。図４に示すように、無線デバイス４００は、ＩＳＭデバイス４０２を含んでもよい。ＩＳＭデバイス４０２は、ＩＳＭ技術に関連付けられた周波数または帯域上で信号を送信および／または受信することを含む、ＩＳＭ技術をサポートすることができる、トランシーバ、受信器、モデム、コントローラ、プロセッサ、およびアプリケーションなどの、１つまたは複数のコンポーネントを含んでもよい。ＩＳＭデバイス４０２は、ＩＳＭデバイスがＩＳＭ技術に関連付けられた周波数または帯域上で信号を送信および／または受信することができるように、ＩＳＭデバイス４０２をアクティブ化するように構成されうる、ＩＳＭアプリケーションコントローラ４０４と通信してもよい。ＩＳＭアプリケーションコントローラ４０４は、一実施形態では、そのような送信および／または受信された信号を処理するようにさらに構成されてもよい。

図４に示すように、無線デバイス４０２は、例えば、ＩＳＭコントローラ４０４と通信することができるＬＴＥデバイス４０６など、１つまたは複数のＬＴＥデバイスまたはコンポーネントをさらに含んでもよい。ＬＴＥデバイス４０６など、１つまたは複数のＬＴＥデバイスまたはコンポーネントは、例えば、１つまたは複数のトランシーバ、モデム、アプリケーション、プロセッサ、スタック、およびストレージもしくはメモリデバイスなどを含む、様々なモジュール、デバイスおよび／またはコンポーネントを含んでもよい。例えば、図４に示すように、ＬＴＥデバイス４０６は、ＬＴＥモデム４０６、ならびにＬＴＥモデム４０６に関連付けられたプロトコルおよびスタックモジュール４０８を含んでもよい。一実施形態によれば、ＬＴＥモデム４０８ならびにプロトコルおよびスタックモジュール４０８を含む、ＬＴＥデバイス４０６など、１つまたは複数のＬＴＥデバイスまたはコンポーネントは、ＬＴＥ技術に関連付けられた周波数または帯域上で送信および／または受信された信号を送信し、受信および／または処理するように構成されてもよい。

無線デバイス４００はまた、図４に示すように、干渉検出および回避モジュール４１０をも含んでもよい。干渉検出および回避モジュール４１０は、無線アクセス技術をサポートするコンポーネント間の干渉状況を検出し、そのような干渉状況に関連付けられた情報を含む通知を生成し、そのような通知を送信し、または送り、そのような干渉状況を軽減するように構成された動作を含む情報を受信し、その動作が実行されるように受信された情報を処理することができ、かつ、無線デバイスによって信号を送信し、または受信することができないとき、軽減動作を実行することができる、ストレージモジュール、プロセッサ、およびトランシーバなどの、１つまたは複数のコンポーネントを含んでもよい。

実施形態の一例では、無線デバイス４００は、ＧＰＳコンポーネント（図示せず）など、無線アクセス技術をサポートする、その他のコンポーネントまたはデバイスをさらに含んでもよい。無線デバイス４００はまた、例えば、無線リンクを介して、ネットワーク４１２とも通信してもよい。実施形態の例によれば、ネットワーク４１２は、１つまたは複数の周波数帯域上で、エアインタフェースなど、１つまたは複数の通信リンクを介した無線デバイス４００へのデータ送信および／または受信（セルラー、テキスト、ビデオ、ＩＰ、およびマルチメディアなどの送信および／または受信など）を可能にする、図１Ａ乃至１Ｃに示すＲＡＮ１０４、基地局１１４ａおよび１１４ｂ、ならびにその他のものなど、無線アクセス技術に関連付けられた任意の適切なネットワーク（または、そのコンポーネント）であってもよい。

再び図３を参照すると、上記で説明したように、３０２で、ある無線技術をサポートする第１のコンポーネントまたはデバイスと、別の無線技術をサポートする第２のコンポーネントまたはデバイスとの間の干渉状況が検出または識別されてもよい。例えば、３０２で、図４に示す無線デバイス４１０など、無線デバイス、または、干渉検出および回避モジュール４１０など、その中のコンポーネントは、ＬＴＥデバイス４０６など、ＬＴＥ技術をサポートする第１のコンポーネントまたはデバイスと、ＩＳＭデバイス４０２など、例えば、ＢｌｕｅｔｏｏｔｈまたはＷｉＦｉを含むＩＳＭ技術をサポートする第２のコンポーネントまたはデバイスとの間の干渉状況を、検出または予測することができる。３０２で、無線デバイスはまた、ＬＴＥ技術をサポートする第１のコンポーネントまたはデバイスと、ＧＰＳ技術をサポートする第２のコンポーネントまたはデバイスとの間の干渉状況を検出または予測することもできる。３０２で、検出または予測されうる干渉状況は、実施形態の一例によれば、隣接またはオーバーラップする周波数帯域上で動作する第１のコンポーネントおよび／または第２のコンポーネントによって引き起こされた、潜在的または実際の干渉であってもよい。

実施形態の一例によれば、無線デバイスは、３０２で、先行的なトリガおよび反応的なトリガなどを含む、１つまたは複数のトリガに基づいて、干渉状況を検出または予測することができる。そのようなトリガに応答して、無線デバイスは次いで、（例えば、３０８で）そのような干渉状況をネットワークまたはＲＡＮに通知してもよく、これについては以下でより詳細に説明する。

例えば、無線デバイスは、（例えば、３０２で）識別されるとき、干渉状況が発生しうること（例えば、潜在的な干渉状況）を指示することができる、先行的なトリガのセットを含むか、または認識してもよい。そのようなトリガは、干渉デバイスが同じ物理的ノード（すなわち、無線デバイス）内で動作している可能性があり、したがって、同じ無線デバイス内の２つのデバイスまたはコンポーネント（例えば、第１のコンポーネントおよび第２のコンポーネント）間のある通信に依拠するという事実に、依拠することができる。

より具体的には、無線デバイスまたはＵＥが、ＩＳＭまたはＧＰＳが受信の目的のためにアクティブ化される必要があると判定すると、無線デバイスまたはＵＥは、一方の無線技術の送信が、他方の共存する無線技術の受信への干渉を引き起こす可能性があることを、ネットワークに通知してもよい。例えば、無線デバイスは、ＬＴＥのアップリンク送信が、他方の技術（ＩＳＭまたはＧＰＳ）の無線受信への干渉を引き起こす可能性があることを、ネットワークに通知してもよい。別の例では、ＵＥは、共存する他の技術の無線送信がＬＴＥへの干渉を引き起こす可能性があることを、ネットワークに通知してもよい。

実施形態の一例によれば、ネットワークに通知するための先行的なトリガは、以下の１つまたは組み合わせを含んでもよく、すなわち、共存する技術がアクティブ化される可能性があり、もしくはアクティブ化されることになること（例えば、他方の無線技術が、その送信および／または受信機能をアクティブ化できることを、同じデバイス内のＬＴＥなど、ＲＡＴに通知することができること）、および／または、共存する技術が、ダウンリンク（ＤＬ）内でデータを受信する必要があり、もしくはそのようにスケジュールされうるというインジケーション、または、ＵＬ内でデータを送信している可能性があり、したがって、ＬＴＥの受信を潜在的に干渉する可能性があるというインジケーションを、提供することができることである。

干渉イベントをトリガするために使用されうる別の許可された先行的なトリガは、技術またはコンポーネントが信号を再取得または取得する必要があるときであってもよく、ＧＰＳデバイスが、例えば、衛星状態問題インジケーションまたはアルマナックデータタイマ満了のために、衛星またはアルマナックデータを再取得または取得しなければならない場合があるときなどである。

無線デバイスはまた、（例えば、３０２で）干渉状況が発生している可能性があること（例えば、干渉状況）を指示することができる、反応的トリガのセットを含むか、または認識してもよい。そのような反応的トリガは、測定値を被干渉デバイスに依拠してもよく、同じ無線デバイス内の２つの技術間の通信に依拠してもよく、必ずしも依拠しなくてもよい。

一実施形態によれば、反応的トリガは、測定された干渉を閾値と比較すること、スケーリング係数が、測定された干渉など、１つまたは複数の測定値に適用されること、ならびに事前定義されたレベルの干渉が、ある技術のダウンリンクチャネル上で発生かつ識別されることなどに基づいてもよい。例えば、一実施形態では、無線デバイスは、無線デバイスまたはその中に含まれたコンポーネントによって測定された干渉が閾値を超えうるとき（例えば、ＲＳＲＱ、ＲＳＲＰおよび／またはＣＱＩ値が閾値を超えうるとき）、（例えば、３０２で）干渉状況を検出してもよい。加えて、無線デバイスは、異なるスケーリング係数が測定値に適用され、結果として値または閾値を超えることがあるとき、干渉状況を検出してもよい。無線デバイスは次いで、（例えば、３０８で）そのような干渉状況の通知を続いてネットワークに提供または送信してもよい。

反応的トリガはまた、１つまたは複数のイベントに基づく（例えば、干渉技術がアクティブであるという、デバイス内の知識に基づく）か、または、１つまたは複数の条件に基づいてもよい。例えば、無線デバイスは、干渉技術がアクティブ化されうるという、デバイス内の知識が認識されうるか、ならびに／または、ある期間にわたって（例えば、被干渉サブフレーム、または、被干渉サブフレームおよび被干渉でないサブフレームの平均中に）ＲＳＲＱ、ＲＳＲＰおよび／もしくはＣＱＩが閾値未満であるとき、（例えば、３０２で）干渉状況を検出してもよい。

さらに他の実施形態によれば、追加のトリガもまた、無線デバイスによって（例えば、３０２で）干渉状況を検出また報告するために使用されてもよく、例えば、ハンドオーバが開始されること、および／または、干渉状況がハンドオーバ後に持続すること、動作のモードが変更されること、使用シナリオ変更、サービスシナリオ変更、干渉シナリオ変更、タイマ満了、被干渉技術または干渉技術内で所定の量の負荷が発生すること、ならびにバッファサイズが干渉技術内で事前定義された閾値を上回ること、などが含まれ、次いで（例えば、３０８で）、干渉状況の通知を生成または送信するために使用されてもよく、これについては以下でより詳細に説明することができる。実施形態の一例によれば、使用シナリオは、上記で説明したように、１つまたは複数のどのサービスがどのように各技術上で実行中でありうるか、および、どのタイプの干渉が発生しているかを記述することができる、事前定義されたセットの使用シナリオであってもよい。そのような使用シナリオには、限定されないが、ＬＴＥ＋ＢＴイヤホン（ＶｏＩＰ）、ＬＴＥ＋ＢＴイヤホン（マルチメディアサービス）、ＬＴＥ＋ＷｉＦｉポータブルルータ、ＬＴＥ＋ＷｉＦｉオフロード、およびＬＴＥ＋ＧＮＳＳなどが含まれてもよい。

３０８で、干渉状況に関連付けられた通知が、送信または報告されてもよい。例えば、３０８で、図４に示す無線デバイス４００など、無線デバイス、または、干渉検出および回避モジュール４１０、もしくは、干渉されているかもしくは干渉している技術など、その中のコンポーネントは、干渉状況の通知を、ネットワーク４１２など、ネットワークへ送信、提供または報告してもよい。このようにして、３０８で、無線デバイスは、複数の無線アクセス技術をサポートする１つまたは複数のコンポーネント間に、潜在的に存在する可能性があるか、または、実際に存在する可能性がある干渉状況の存在を、ネットワークに通知してもよい。上記で説明したように、３０２で干渉状況を検出するために使用される１つまたは複数のトリガに基づいて、３０８で通知が送信されてもよい。

一実施形態では、図３に示すように、３０４で、ネットワークと共にデータを送信および／または受信するために使用される通信リンクまたはインタフェースリンクが確立されるときに、３０８で、通知がネットワークへ送信、提供または報告されてもよい。例えば、干渉状況は、ネットワークとの通信またはインタフェースリンクが確立されることを妨げるために十分な干渉を生じることがある（例えば、無線リンク障害（ＲＬＦ）が起こることがある）。３０４で、通信もしくはインタフェースリンクが確立されないことがある場合、またはそのとき（例えば、ＲＬＦが起こることがあるとき）、３０６で、少なくとも通信またはインタフェースリンクを確立するために十分な干渉を軽減または低減するために、アクションが無線デバイスによって実行されてもよく、これについては以下でより詳細に説明する。３０４で、通信またはインタフェースリンクが確立されうる（例えば、ＲＬＦが解決されうる）ようになると、本明細書で説明するように、３０８で、通知が次いでネットワークに提供されてもよい。

一実施形態によれば、無線デバイスもしくはＵＥがアイドルモードである間に、干渉状況を検出することができる場合に、または、無線デバイスがデバイス共存プロシージャにおいて可能であることをネットワークに通知するために、３０８で、無線デバイスは、ＲＲＣ接続確立プロシージャを介して、または、無線デバイス能力の一部として、ＲＲＣメッセージ内の新しいフィールドを介して、通知をネットワークへ送信、提供または報告してもよい。例えば、無線デバイスは、ＲＲＣ接続要求メッセージもしくはＲＲＣ接続セットアップ完了メッセージ、または、無線デバイス能力のより綿密なリストを含むか、もしくは提供することができる、別のＲＲＣメッセージを使用して、ネットワークに干渉状況を通知（すなわち、通知をネットワークに提供）してもよい。通知はまた、ルーティングエリア更新メッセージにより、または、ＭＡＣ制御要素を介して、登録時間または再選択において、ネットワークに提供されてもよい。この通知は、上述のトリガのうち１つであるとき、送信されてもよく、または、上記の条件がなお当てはまる場合、他の理由により、ＲＲＣ確立プロシージャがＵＥによってトリガされるときに、送信されてもよい。

一実施形態によれば、新しいデバイス内干渉イベント（以下で「イベントＣ１」と呼ばれる）または新しいＲＲＣメッセージ（例えば、デバイス内干渉報告）もしくはＲＲＣ報告が、（例えば、３０８で）無線デバイス内の干渉状況を指示する通知または報告を送信するために、導入または使用されてもよい。イベントＣ１は、無線デバイス内の１つの技術とネットワークの間で発生しうるイベントであってもよい。例えば、例は、ＬＴＥ環境内で、イベントＣ１は、干渉状況が上記で説明したように検出されうるとき、ネットワークによって構成され、トリガされてもよい。そのような状況は、（例えば、３０８で）このイベントがトリガされたことを指示する測定報告を送信するために、無線デバイスまたはＵＥをトリガしてもよい。新しいＲＲＣメッセージが使用されうるか、または、既存のＲＲＣメッセージが拡張される場合、同じことが適用可能であってもよい。

実施形態の一例によれば、イベントＣ１によるＲＲＣ測定報告、または、任意の新しいＲＲＣメッセージもしくは任意の既存のＲＲＣメッセージをトリガするための基準は、上記で説明した実施形態のいずれかによって、ＵＥが干渉状況を検出または予測することに関係付けられてもよい。例えば、通知は、既に報告されていない場合、干渉中でありうるか、または干渉状況を引き起こす可能性がある、コンポーネントまたはデバイスのタイプ、および、随意に、干渉デバイスまたはコンポーネントがアクティブ化されうる時間を含んでもよい。あるいは、通知は、そのようなコンポーネントデバイスがアクティブ化されるか、もしくはアクティブ化されうるというインジケーション、検出された干渉状況が反応的でありうるか、先行的でありうるか（例えば、干渉が実際の干渉でありうるか、潜在的な干渉でありうるか）、そのコンポーネントもしくはデバイスによってサービスされる周波数帯域、または、以下で説明するような任意の他の適切な情報を含んでもよい。既存のイベントはまた、無線デバイスによって、デバイス内干渉情報を通知に含めるために拡張されてもよい。

加えて、一実施形態では、通知は、デバイス内干渉状況が存在するか、または存在するようになるというインジケーションを含んでもよい。例えば、無線デバイスまたはＵＥは、干渉技術もしくは被干渉技術がオンにされるか、もしくはアクティブ化される必要がありうる（例えば、潜在的な干渉状況が存在する可能性がある）ということ、または、干渉デバイスがアクティブである（例えば、実際の干渉状況が存在する可能性がある）ということを、ネットワークに通知してもよい。無線はまた、干渉状況が現在のサービング周波数内または別のサービング周波数内に存在することをも、ネットワークに通知してもよい。通知情報は、ネットワークへの支援情報としての機能を果たして、ＵＥ内の干渉を緩和するための最良の機構をネットワークが判定することを支援することができる。通知は、干渉状況トリガに関連付けられた情報と、以前の干渉状況が停止した可能性があるというインジケーションと、干渉状況を引き起こす技術のタイプ（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、ＧＰＳ）を識別する情報、ならびに、無線デバイス内の他の共存する干渉コンポーネントまたは技術の存在に関連付けられた情報であって、そのようなコンポーネントまたはデバイスが電源オンにされるか、オフにされるか、アクティブに送信しているか、受信しているか、干渉が発生しているか、発生していないか、特定の動作のモードで、データを連続的に（例えば、所定の期間にわたって）送信しているか、バッファ内のデータが閾値を超えているか、およびしきい値未満であるか、などを含む情報と、デバイス内共存および／もしくは干渉軽減方法、ルール、プロトコルおよび／もしくはプロシージャを扱うかもしくは処理するための無線デバイスの能力の情報もしくはインジケーション、または、ネットワークによって干渉状況（実際のもの、もしくは潜在的なもの）を軽減もしくは低減する助けとするために使用されうる任意の他の適切なインジケーションもしくは情報とを含んでもよく、これらについては以下でより詳細に説明する。

上記で説明したように、通知は、干渉状況を介して干渉を引き起こす可能性があるデバイスまたはコンポーネントのステータスを誘導する、デバイスまたはコンポーネントタイプに関連付けられた情報を含んでもよい。例えば、一実施形態では、オンにされるべきコンポーネントまたはデバイスがＧＰＳ受信器であり、かつ、無線デバイスが、動作中の問題のある周波数帯域のうちの１つにおいて（例えば、ＵＬ高調波が被干渉側のＧＰＳ受信器を妨害する可能性があるとき、周波数帯域内で）ＬＴＥのためのコンポーネントまたはデバイスを操作するように構成される場合、無線デバイスは、通知を介して、デバイスタイプ（この特定の場合はＧＰＳ）を、随意に、コールド、ウォームもしくは定常状態のＧＰＳ状態もしくはステータスなど、デバイスもしくはコンポーネントの状態もしくはステータス、および／または、場合によっては定常状態に入るための時間もしくは推定時間と共に、シグナリングしてもよい。

通知はまた、ホッピング周波数、および／または、周波数帯域適合を提供するために使用されうる他のビットをも含んでもよい。例えば、一実施形態では、Ｂｌｕｅｔｏｏｔｈトランシーバなど、コンポーネントまたはデバイスが、例えば、ＬＴＥをサポートするコンポーネントまたはデバイスと同時にアクティブ化されることがあり、またはアクティブ化される必要がある場合がある。アクティブ化されると、無線デバイスは、通知を介して、ホッピング周波数範囲、もしくは、Ｂｌｕｅｔｏｏｔｈ技術に関連付けられた周波数ホッピング適合範囲のための能力ビット、または、デバイス内技術に関連付けられた同等の問題のある周波数（例えば、干渉を起こす状況が存在するようになる周波数）を、シグナリングしてもよい。一実施形態では、そのような情報を受信した後、ネットワークは、ＬＴＥによりサポートされたネットワークであってもよく、それ自体の周波数割り振り範囲を適合させて、ＬＴＥ技術をサポートするコンポーネントまたはデバイスと、Ｂｌｕｅｔｏｏｔｈトランシーバなど、Ｂｌｕｅｔｏｏｔｈ技術をサポートするコンポーネントまたはデバイスとの間の相互干渉を回避、軽減または低減してもよい。あるいは、ネットワークは、ＢｌｕｅｔｏｏｔｈまたはＩＳＭネットワークであってもよく、受信された周波数ホッピング範囲を使用して、それに関連付けられたコンポーネントまたはデバイスを適合させ、したがって、Ｂｌｕｅｔｏｏｔｈコンポーネントまたはデバイスと、他のＩＳＭデバイスまたはコンポーネント、ＬＴＥコンポーネントまたはデバイス、および、ＧＰＳコンポーネントまたはデバイスとの間の相互干渉を回避、軽減または低減してもよい。

上記の情報に加えて、通知はまた、無線デバイスによって使用されたＬＴＥ、ＩＳＭおよびＧＰＳ技術など、無線アクセス技術のコンポーネントまたはデバイスによってサポートまたは影響を受ける、周波数帯域のリストをも含んでもよい。例えば、無線デバイスはまた、３０６で、コンポーネントもしくはデバイスのためにそれがサポートする周波数もしくは周波数帯域のリスト（例えば、共存する技術からの干渉なしにサポートされうる周波数）、または、そのデバイス上で干渉を引き起こす可能性がある周波数もしくは周波数帯域のリスト（例えば、共存する技術によって発生した干渉のため、コンポーネントもしくはデバイスのためにサポートすることができない周波数、例えば、問題のある周波数のリスト）をも、ネットワークにシグナリングしてもよい。一実施形態では、無線デバイスが特定のコンポーネントまたはデバイスのためにサポートすることができる周波数または周波数帯域のリストは、ＬＴＥ側で引き起こさないか、もしくは干渉されない、ＷＴＲＵがサポートする周波数のリスト、または、ＬＴＥによって干渉されない可能性がある他の技術のためにサポートされる周波数のリスト、および／または、他の技術によってサポートされうる周波数のリストに対応してもよい。周波数のリストが、３０８で、通知を介して、範囲として、帯域内の周波数として、ＲＡＴ内の周波数として報告されてもよいこともまた理解されよう。

通知はまた、干渉コンポーネントまたはデバイスを必要としているか、または、干渉コンポーネントまたはデバイスをオンにしている、アプリケーションの緊急性のインジケーションをも含んでもよく、例えば、サービスのタイプ（例えば、あるＱｏＳ優先度）またはアプリケーションのタイプ（例えば、送信が含まれる）。

ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User datagram protocol）、ＶｏＩＰ（Voice over Internet Protocol）、およびＲＴＰ（real-time transport protocol）など）。無線デバイスによってネットワークに提供される通知または情報はまた、アクティブ化されるか、またはアクティブ化されるようになる所与の技術のためのバッファサイズをも含んでもよい。他の実施形態では、通知または情報はまた、干渉無線アクセス技術がダウンリンク（ＤＬ）ＬＴＥ受信を干渉しているかどうか、もしくは、アップリンク（ＵＬ）ＬＴＥが他の無線アクセス技術に干渉されているかどうかについてのインジケーションと、例えば、干渉技術によって送信もしくは受信中の（または、送信もしくは受信が要求されている）データのタイプに関連付けられた情報（例えば、使用シナリオ）であって、データが音声、ビデオ、テキスト、およびマルチメディアなどを含む情報と、または、干渉技術もしくは被干渉側の技術に関連付けられた任意の他の情報であって、送信もしくは受信中であるか、もしくはそのように要求されているデータ、ならびに、コンポーネントもしくはデバイスタイプ、ならびに特徴およびセットアップなどについての追加の情報を含む情報を含んでもよい。例えば、ネットワークは、Ｂｌｕｅｔｏｏｔｈイヤホン音声およびＬＴＥ音声、または、Ｂｌｕｅｔｏｏｔｈ音声およびＬＴＥビデオ、マルチメディアサービス、およびＬＴＥ＋ＷｉＦｉポータブルルータなど、事前定義されたセットのサービスまたはシナリオを有してもよい。検出または要求された使用シナリオに応じて、無線は、干渉技術または干渉を受けた技術によって提供された、事前定義された使用シナリオのセットへのインデックスを、シグナリングしてもよい。

加えて、通知は、干渉状況の解決策に対処かつ／または処理するための、無線デバイスの能力に関連付けられた情報またはインジケーションを含んでもよい。例えば、通知は、無線デバイスが、干渉解決策によって引き起こされた干渉を軽減することができる、以下で説明する方法、ルール、プロトコルおよび／またはプロシージャなど、解決策のいずれかをサポートすることができるというインジケーションを含んでもよい。あるいは、通知は、無線デバイス内でＴＤＭ（time division multiplexing）方式のためのサポートを指示することができる、別個の能力のインジケーションを含んでもよい。例えば、上記で説明したように、デバイス内干渉または干渉状況の存在を指示する能力／通知が、ネットワークへシグナリングされるか、または送信されてもよい。この能力／通知は、無線デバイスが、無線デバイスおよび／またはＴＤＭ方式動作の干渉状況の報告に関連付けられたプロシージャをサポートするという、インジケーションを含んでもよい。

上記で説明したように、３０８で、追加のイベントまたはアクションが、ネットワークへの通知の送信をトリガしてもよい。例えば、上記で説明したような無線デバイスのコンポーネント間の干渉状況の検出に加えて、３０８で、ネットワークへの通知がまたトリガされてもよく、例えば、ハンドオーバ動作が開始されるか、動作のモードが変更されるか、サービスもしくは使用シナリオの変更が検出されるか、タイマもしくは事前定義された期間が経過したか、ＧＰＳデバイスが、衛星状態問題インジケーションもしくはアルマナックデータタイマ満了のために、衛星もしくはアルマナックデータを再取得しなければならないときなど、デバイスもしくはコンポーネントが信号を再取得する必要があるとき、または、無線デバイスもしくは無線アクセス技術の任意の他の適切な変更および修正などとしてである。

そのようなトリガはまた、３０８で送信される通知に追加の情報が含まれるようにしてもよい。例えば、無線デバイスによってネットワークへ送信される通知は、ＧＰＳ受信器など、コンポーネントまたはデバイスを少なくともウォーム状態にすることができる、アルマナックおよび／または他の重要なデータを検索するために、Ａ−ＧＮＳＳ支援を求める要求を含んでもよい。そのような要求を受信すると、ネットワーク（ポジショニングサーバ）は、例えば、サポートされる場合、要求された情報により、無線デバイスに回答してもよい。一実施形態によれば、そのような要求を、ポジショニングデバイス状態（コールド、ウォーム、定常、または衛星状態データの問題）に基づいて、ネットワークのポジショニングサーバへのＮＡＳメッセージ（例えば、ＵＬ直接転送メッセージ）を使用して搬送してもよい。

別の実施形態では、通知または報告は、ソースセルに関連付けられた情報を含んでもよい。無線デバイスは次いで、ハンドオーバが実行され、かつ、干渉状況がなお存在する可能性があるとき、例えば、ネットワーク、ターゲットｅＮｏｄｅＢ、および／または、新しいセルへの別の通知または報告をトリガしてもよい。例えば、無線デバイスが、他の技術と共存するためのパターンを使用している場合、無線デバイスは、加えて、使用中のパターンを新しいセルに報告してもよい。別の実施形態によれば、通知または報告は、ソースセルによって（例えば、干渉状況または要求に応答して）一度トリガされてもよい。無線デバイスは次いで、ハンドオーバ情報交換において、ソースセルからターゲットセルへ情報を中継するために、ネットワークノードに依拠してもよい。

加えて、通知は、動作のモードの変更に関連付けられた情報を含んでもよい。例えば、上記で説明したように、通知または報告は、動作のモードの変更が検出されうるとき、トリガされてもよい。ＷｉＦｉコンポーネントもしくはデバイス、または、Ｂｌｕｅｔｏｏｔｈコンポーネントもしくはデバイスなど、無線デバイスまたはアクティブなＩＳＭデバイスが、スリープモードまたは省電力モードに移る可能性がある場合、無線デバイスは、無線デバイスまたはアクティブなＩＳＭデバイスがスリープモードまたは省電力モードに入ったことを指示する通知または報告を、ネットワークへ送信する。無線デバイスまたはアクティブなＩＳＭデバイスが、スリープモードまたは省電力モードから出るとき、そのような変更を指示する通知または報告が、ネットワークにさらに送信されてもよい。加えて、スリープモードとアクティブモードとの間の移行もまた、干渉状況にあるためのトリガとして使用されてもよい。例えば、無線デバイスが省電力モードまたはスリープモードから出るとき、ＷｉＦｉネットワークに関連付けられたアクセスポイント（ＡＰ）は、通知を受信してもよく、ＷｉＦｉデバイスは、アクセスポイント（ＡＰ）から、それがその局のためのデータを有することを指示する、ポーリングを検出してもよく、または、その局（ＳＴＡ）がＡＰをポーリングし、データが無線デバイスのために使用可能であると判定する。

あるいは、通知は、サービスまたは使用シナリオの変更に関連付けられた情報を含んでもよい。例えば、一実施形態では、無線デバイスは、Ｂｌｕｅｔｏｏｔｈ（ＢＴ）＋ＬＴＥ（音声）使用シナリオから、ＢＴ＋ＬＴＥ（マルチメディア）使用シナリオへの変更を検出してもよく、または、無線デバイスは、より低い優先度から、音声もしくは新しいウェブ閲覧セッションなど、新しい、より高い優先度のサービスへの変更を検出してもよく、その両方が、変更に関連付けられた情報を含みうる通知または報告が無線デバイスによってネットワークへ送信されることをトリガしてもよい。

一実施形態では、通知または報告は、その通知または報告が無線デバイスによってネットワークへ送信されることをトリガしてもよい（また、タイマの満了に関連付けられた情報を含んでもよい）。例えば、ＷＴＲＵが最後にデバイス内報告を送信してから、事前定義された期間ｘが経過している場合、報告が送信されてもよい。より具体的には、禁止タイマが実装または使用されてもよい。禁止タイマは、構成可能パラメータまたは事前定義された値であってもよい。無線デバイスが通知または報告をトリガした後、通知禁止タイマが起動されてもよく、無線デバイスは、禁止タイマの継続時間にわたって別の報告をトリガすることを許可されないことがある。通知禁止タイマが満了した後、トリガリング条件がなお存在する可能性がある場合、通知がネットワークへ送信される。そのような概念は、例えば、通知または報告が、ＲＲＣおよびＭＡＣなどを使用して送信または生成されうるとき、適用可能であってもよい。

加えて、別の実施形態では、通知は、サポートされたＲＡＴ技術に関連付けられたコンポーネントまたはデバイスのうち１つまたは複数のバッファサイズに関連付けられた情報、ならびに、ＵＬまたはＤＬが送信／受信中に干渉されうるかどうかにかかわらず、チャネルに関連付けられたインジケーションまたは情報を含んでもよい。

本明細書で開示した方法３００は、３０８で通知を送信または提供することを含むが、しかし、３０８でそのような初期機能通知を送信すること、または干渉状況通知が提供されることなしに、以下で説明する方法、解決策、ルールおよび／またはプロトコルが等しく適用可能でありうることは、当業者には理解されよう。加えて、無線デバイスは、デバイス内共存インジケーションを報告するように、または、報告を停止するように明示的に構成されてもよい。より具体的には、無線デバイスは、連続的に通知を報告または送信してもよい。ネットワークが、そのような通知のさらなるトリガリングを回避することを望む場合、ネットワークは、無線デバイスから報告構成を除去するか、あるいは、そのような通知の報告を停止するように無線デバイスに対して明示的に指示してもよい。

無線デバイスは、上述のトリガのいずれかに基づいて通知または報告をトリガすることができるが、トリガの理由を指示しないことがあることは、さらに理解されよう（例えば、干渉状況の通知は、ネットワークに提供されることがあり、本明細書で説明する情報を含みうるが、干渉状況が潜在的な干渉状況であるか、実際の干渉状況であるかを指示しないことがある（例えば、干渉が反応的トリガに基づくか、先行的トリガに基づくかを指示しないことがある）。本明細書で説明する解決策は、ＬＴＥ技術によって干渉されうるか、または、ＬＴＥ技術を干渉しているその他の技術に対して、等しく適用可能でありうることもまた理解されよう。同様に、無線デバイスが、ＬＴＥ技術が電源を投入されることを望むと判定することがあるか、または、ＲＲＣ接続の確立を要求しているとき、メッセージ（通知）がトリガされ、他の技術のネットワークに送信され、ＬＴＥ技術、および、ＬＴＥ技術がサポートするように現在構成されうる周波数帯域、ならびに、それによってサポートされうる他の周波数が指示されてもよい。このように、干渉側のＲＡＴおよび被干渉側のＲＡＴを、無線デバイスによって制御することができる。本明細書で説明する解決策を、個々に、または、組み合わせて使用することができる。

再び図３を参照すると、３１０で、例えば、干渉状況を軽減、低減または回避するように構成されたアクションを含む情報が、受信されてもよい（例えば、無線デバイスのための構成情報が受信されてもよい）。この情報は次いで、３１２で、干渉状況が軽減、低減、防止または回避されうるように、処理されてもよい。例えば、一実施形態では、３０８で、干渉状況の通知をネットワークに提供した後、ネットワークは、１つまたは複数の解決策またはプロシージャを介して関連付けられた、予想されるか、または潜在的な、または干渉を防止することにおいて、無線デバイスを支援してもよく、これについては以下でより詳細に説明されうる。そのような支援を提供するため、図４に示すネットワーク４１２など、ネットワークは、１つまたは複数のアクション、プロシージャ、ルールまたはプロトコルを含む情報または解決策を、無線デバイスに提供してもよく、無線デバイスは、３１０で、この情報または解決策を受信してもよい。無線デバイス４００など、無線デバイス、および／または、干渉検出および回避モジュール４１０など、その中の１つもしくは複数のコンポーネントは次いで、３０８でネットワークに報告された干渉状況を軽減、回避または低減するための情報または解決策を、処理してもよい。

より具体的には、一実施形態では、ネットワークが通知または能力を、例えば、３０８で受信するとき、ネットワークは、３１０で無線デバイスによって受信され、例えば、干渉状況によって生じた干渉を軽減、低減または回避するために無線デバイスまたはその中のコンポーネントもしくはモジュールによって処理されうる、以下のプロシージャのうち１つまたは複数を送信し、または実行してもよい。

ネットワークは、無線デバイス（または、ＷＴＲＵすなわちＵＥ）を、デバイス内干渉を起こす状況報告および監視のために構成してもよい。例えば、無線デバイスは、イベントＣ１、または、拡張されている既存のイベントと共に構成されてもよい。そのような構成をすると、無線デバイスは、上記で説明したトリガによる干渉状況通知の監視および報告を開始してもよい。そのようなイベントに関連付けられた情報は、３１０で、無線デバイスによって受信され、３１２で、そのイベントが実行され、または構成されるように、無線デバイスによって処理されてもよい。

ネットワークはまた、無線デバイスに、ネットワークがデバイス内干渉機構を扱うことが可能であるかどうかに関するインジケーションを含む、ネットワーク能力に関連付けられた情報をも提供してもよい。そのような情報は、無線デバイスによって、３１０で、ＲＲＣ接続セットアップメッセージ、または、任意のその他のＲＲＣメッセージ内で提供され、かつ受信され、３１２で処理されてもよい。そのような情報はまた、報告イベントまたはメッセージの構成の欠如または存在を用いて、判定されてもよい。

ネットワークは、３１０で受信されうるバックオフまたはスケーリング値を、無線デバイスにさらに提供してもよい。無線デバイスは次いで、３１２で、バックオフまたはスケーリング値を処理して、以下でより詳細に説明するように、無線デバイスがバックオフまたはスケーリング値を使用して、干渉が発生した後に干渉に対する反応を限定することができるようにしてもよい。

あるいは、ネットワークは、新しい測定構成メッセージを無線デバイスへ、無線デバイスが測定を開始できる他の周波数および／またはＲＡＴのリストと共に送信してもよく、そのような新しい測定構成メッセージは、３１０で受信されてもよい。新しい測定構成メッセージは次いで、３１２で処理されて、リストに含まれた周波数および／またはＲＡＴの測定が開始されてもよい。

別の実施形態によれば、ネットワークは、干渉ＲＡＴコンポーネントまたはデバイスの制御されたアクティブ化を実行してもよい。例えば、被干渉側のＲＡＴコンポーネントもしくはデバイス、および干渉ＲＡＴコンポーネントもしくはデバイスは共に、既にアクティブ化されている必要があり、または既にアクティブ化されていることがある。そのような状況では、ネットワークは、以下の方法、ルール、プロシージャおよび／またはルールのうち１つまたは複数を実行してもよく、また、それに関連付けられた情報を無線デバイスに提供してもよく、この情報は、３１０で受信され、３１２で処理されてもよい。

例えば、一実施形態では、共存するＲＡＴデバイスからのアクティブ化要求または干渉状況が検出されうる（例えば、３０２で、干渉状況の結果となる）とき、ＲＡＴデバイス（送信中の場合、干渉が発生するようになる）は、即時にアクティブ化されないことがある。他のデバイス（例えば、被干渉側のＲＡＴデバイス）が干渉を回避するために適切な動作を取るための時間を可能にするために、共存するＲＡＴデバイスまたはトラフィックアクティブ化は、事前定義された期間だけ遅延されてもよい。実施形態の一例によれば、ネットワークは、無線デバイスに、（例えば、３１０で）それによって受信された情報においてそのような遅延を通知してもよい。無線デバイスは次いで、（例えば、３１２で）ＲＡＴデバイスのアクティブ化を遅延させてもよい。共存するデバイス内の接続要件が、技術（例えば、技術がＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、ＬＴＥ、およびＧＰＳなどであるかどうか）によって決まることがあることを考えると、遅延タイマの値は、技術によって、または、一実施形態によれば、デバイスのアクティブ化を要求しているアプリケーションもしくはサービスによって決まることがある。本明細書で説明する遅延タイマが実装または構成されないことがあることもまた、理解されよう。そのような状況では、デバイスは、いかなる遅延もなしにアクティブ化されてもよい。

別の実施形態によれば、ネットワークはまた、無線デバイスに、ＩＳＭデバイスなど、ＲＡＴデバイスが起動できるようにするための通知をも送信してもよく、この通知は、（例えば、３１０および３１２で）無線デバイスによって受信かつ処理されてもよい。この通知は、既存のＲＲＣメッセージまたは新しいＲＲＣメッセージにピギーバックされた、ＭＡＣ制御要素（ＣＥ）指令であってもよい。あるいは、ネットワークは、無線デバイスに、ＩＳＭデバイスが起動することを拒否するための通知を送信してもよく、この通知は、例えば、代替解決策または基地局バッファ内の保留中のデータが送信されないときに、（例えば、３１０および３１２で）無線デバイスによって受信かつ処理されてもよい。実施形態の一例によれば、このことはまた、ＬＴＥデバイスなど、他のＲＡＴデバイスによって送信中であるデータの優先度によって決まってもよい。

あるいは、ネットワークは、無線デバイスに、ＩＳＭアクティブ化時間通知を送信してもよく、この通知は、（例えば、３１０および３１２で）無線デバイスによって受信かつ処理されてもよい。ＩＳＭアクティブ化時間通知は、送信されるバッファ内の残りのデータの推定値およびチャネル条件に基づいて、いくつかのフレーム、サブフレーム、または、ｍｓもしくは秒単位の値の倍数であってもよい。このアクティブ化時間は、上記でリストした解決策（ハンドオーバ、キャリア非アクティブ化、ＲＡＴリダイレクト）のいずれかであってもよい、再構成メッセージと結合されてもよい。この通知は、既存のＲＲＣメッセージまたは新しいＲＲＣメッセージにピギーバックされた、ＭＡＣ−ＣＥ指令であってもよい。無線デバイスは、シグナリングされたアクティブ化時間の満了後にのみ、ＩＳＭデバイスをアクティブ化することができる。

本明細書で説明する方法、ルール、プロシージャおよび／またはプロトコルなど、解決策、ならびに、イベントのトリガリングおよび構成はまた、無線アクセス技術の優先度によって決まってもよい（例えば、ＬＴＥは、ＧＰＳより高い優先度を有してもよく、逆もまた同様である）。加えて、技術によって提供されているサービスのタイプもまた、追加の基準であってもよい。より具体的には、緊急呼び出しがある技術上で実行されている場合、共存する技術に対し、ある期間にわたって送信しないように命令することは、有益であり、その命令は、例えば、３１０で受信され、３１２で処理されてもよい。無線デバイスはまた、本明細書で説明するように、報告をトリガしないこともある。例えば、３１０で、ある期間にわたって送信しないため、または、共存する技術のコンポーネントをアクティブ化しないための情報または命令を受信した後、この命令または情報は、例えば、３１２で処理され、無線デバイスが、共存する技術に関連付けられたコンポーネントのアクティブ化を一時停止できるようにしてもよく、これについては以下でより詳細に説明する。

加えて、限定されないが、緊急呼び出し、地震津波警報システム（ＥＴＷＳ）、または、任意のタイプの緊急警報メッセージなど、高優先度トラフィックが送信されている場合、他の技術が送信しないようにすることは、有益でありうる。一実施形態では、このことは、無線デバイス内で自律的に行われてもよい。例として、そのようなタイプのトラフィックが検出されるときに、無線デバイスは、ＩＳＭに対し、送信を停止するように命令してもよい。あるいは、（例えば、３１０で受信された）ネットワークから無線デバイスへ送信された明示的メッセージまたは情報もまた、（例えば、３１２で）処理され、使用されてもよい。より具体的には、メッセージは、無線デバイスに対し、ＩＳＭ送信を停止するように命令してもよく、ＬＴＥ技術は、他の技術に対し、停止するように命令してもよい。同じことは、高優先度サービスが行われている場合、他の技術に適用可能であってもよい。ＬＴＥ技術は次に、この状況をネットワークに報告し、ネットワークが、報告内でシグナリングされうる事前定義された期間にわたって無線デバイスをスケジュールしないことを把握するようにしてもよい。

例えば、一実施形態では、無線は、（例えば、３１０で）ネットワークから受信され、（例えば、３１２で）無線デバイスによって処理された情報に基づいて、ＩＳＭデバイスなど、ＲＡＴコンポーネントまたはデバイスのアクティブ化（または、送信／スケジューリング）を、事前定義された期間にわたって遅延させてもよい。満了すると、ＩＳＭデバイスは次いで、ＬＴＥ側で実行されたオペレーションまたは動作にかかわらず、オンにされてもよい（または、送信／受信のためにスケジュールされてもよい）。アクティブ化遅延タイマは、ＩＳＭデバイス側で要求されているサービス、または、ＩＳＭデバイスのタイプによって決まってもよい。同様の概念またはプロシージャはまた、ＬＴＥに対しても適用可能であってもよく、ただし、あるＩＳＭアクティビティまたはプロシージャが実行されている場合、ＬＴＥ側は、定義された期間にわたってアクティブ化（例えば、ネットワークによってスケジュールされる場合であっても、データの送信）を遅延させる。この時間が経過すると、ＷＴＲＵは、標準のＬＴＥ動作を再開してもよい。

あるいは、無線デバイス内に含まれたＬＴＥデバイスは、ＩＳＭに対し、オフにされたままであるように明示的に命じてもよい。ＬＴＥデバイスがＩＳＭデバイスに対し、オフにされたままであるように明示的に命ずる場合、無線デバイスは、遅延アクティブ化タイマおよびバックオフを、事前定義された期間にわたってキャンセルしてもよい（例えば、少なくともバックオフ時間にわたって再試行しない）。バックオフタイマが満了すると、無線デバイスは、別のインジケーションまたは通知をトリガし、上記で説明したように、そこから受信されたか、または、その中に含まれた動作を実行してもよい。一実施形態によれば、限定されないが、ＥＴＷＳなど、緊急呼び出しまたは高優先度メッセージなど、あるＬＴＥアプリケーションタイプのために、他の技術が有効にされないアクションが必要とされ、実施されてもよい。

加えて、ハンドオーバコマンドまたはリダイレクトがＬＴＥ側で発生する場合、ＩＳＭデバイスは、遅延タイマ満了に先立ってアクティブ化されてもよい。または、本明細書で説明するようなＴＤＭパターンが無線デバイスに提供される場合、デバイスは、アクティブモードに入り、提供されたパターンに従って送信／受信プロシージャを実行してもよい。上記の動作の１つまたは組み合わせがうまく完了すると、無線デバイスは次いで、ＩＳＭデバイスを起動するか、または、ネットワークからの拒否指令が受信されている場合、要求をアボートしてもよい。

加えて、実施形態によれば、無線デバイスは、（例えば、３０８で）その通知に対するネットワークからの指令または適切な動作を含みうる情報を（例えば、３１０で）受信しないことがあり、ＩＳＭデバイスアクティブ化遅延タイマなど、無線アクセス技術をサポートする１つまたは複数のコンポーネントに関連付けられたタイマが満了することがある。そのような実施形態では、無線デバイスは、以下の動作のうちの１つまたは複数を実行してもよく（そのような動作はまた、３０６で、ならびに、ＲＬＦがネットワークへの接続を妨げる可能性があるときにも実行されてもよく）、すなわち、ＩＳＭデバイスアクティブ化を拒否してユーザに通知すること、ＩＳＭデバイスアクティブ化遅延タイマが、最後にＡｃｋされ、パックされた後に満了することを待機し、かつ、無線デバイスバッファ内に送信すべきデータがない場合、ＩＳＭデバイスアクティブ化を可能にすること、および／または、無線デバイス実装によって定義され、または（ＤＲＸサイクルと同様に）ネットワークによりシグナリングされた、限定された期間にわたってＩＳＭアクティブ化を可能にすることである。

干渉軽減動作に障害があると、無線デバイスは、ＩＳＭデバイスなど、無線アクセス技術をサポートするコンポーネントまたはデバイスのアクティブ化を拒否してもよい。アクティブ化は、ネットワークによりシグナリングされてもよく、または、例えば、その実装において無線デバイスによって定義されうる、定義された期間にわたって拒否されてもよい。あるいは、無線デバイスは、そのようなコンポーネントに関連付けられた通知プロシージャを再開してもよく、例えば、ＩＳＭデバイス通知プロシージャ（例えば、３１２で処理された可能性のあるプロシージャ）が含まれる。リトライの回数は、ネットワーク内のシグナリング負荷の増大を回避するために、ネットワークによりシグナリングされてもよく、または、（例えば、その実装において）無線デバイスによって決まる値によって、限定されてもよい。上記で説明したそのような状況は、随意に技術間ハンドオーバをトリガさせてもよい。例えば、一実施形態では、そのような状況は、無線デバイスに、ＬＴＥからＩＳＭ技術へ（例えば、ＷｉＦｉへ）ハンドオフさせてもよい。そのような状況はまた、ＩＳＭがオンにされることを要求しているデータまたはアプリケーションの優先度によって決まってもよい。

別の実施形態では、干渉ＲＡＴの共存は、（例えば、ＲＡＴの周波数分割多重化を介して）干渉を許容可能なレベルへ低減するために、十分な周波数分離が干渉技術間に存在することを保証することによって、可能にする。そのような状況では、この通知または報告を受信すると、ネットワークは、以下の１つまたは組み合わせを行ってもよく、それに関連付けられた情報を無線デバイスに提供してもよく、その情報は、３１０で受信され、３１２で処理されてもよい。

例えば、十分な周波数分離を介して、干渉ＲＡＴの共存を可能にするために、別の周波数またはＲＡＴへのハンドオーバが実行されてもよく、そのようなハンドオーバのインジケーションが、無線デバイスによって、３１０で受信され、３１２で処理されてもよい。

あるいは、無線デバイスは、（無線デバイスによって提供された通知によれば、問題が全くないか、または少ないと見なされる）他の周波数および／またはＲＡＴの測定制御情報と共に構成されてもよく、その情報は、例えば、３１０で受信され、３１２で処理されてもよい。これにより、無線デバイスが、無線リンク障害（ＲＬＦ）を回避するために前もって、測定された他の周波数を有することを可能にすることができ、または、無線デバイスが、ネットワークへ報告を返すこと、および、干渉が他の技術によって経験されない可能性があるか、または、そのような干渉が迅速に軽減されうるようにサポートされた別の周波数へ、周波数を低下させることに先立って、ハンドオーバを実行することを可能にする。

加えて、ＲＬＦが無線デバイス内で発生する場合、無線デバイスは、デバイス内干渉が進行中であると判定してもよく、共存する技術によって干渉されない別の周波数内でＲＲＣ再確立を（すなわち、現在の問題のあるサービング周波数内でセルへの再確立を実行する代わりに）実行してもよい。あるいは、無線デバイスは、アイドルモードへ即時に（例えば、再確立を試行することなく）移行し、ＲＲＣ接続確立プロシージャを新しい干渉されていない周波数内で開始してもよい。そのような場合、セル選択および再選択プロシージャは、デバイス内干渉が起こっている周波数帯域を回避するように、修正されてもよい。

あるいは、ネットワークは、即時の測定値または結果を求める要求を送信してもよく、その要求は、無線デバイスによって（例えば、３１０で）受信され、ハンドオーバを行う前に（例えば、３１２で）処理されて（例えば、ＵＥｉｎｆｏｒｍａｔｉｏｎＲｅｑｕｅｓｔを有するＲＲＣメッセージ）、ハンドオーバ障害、および、ＷＴＲＵが以前のセル上に後退することが回避されてもよい。

さらに、十分な周波数分離を有する共存を可能にするために、アクティブキャリアを除去する（例えば、セカンダリセルを無効にするか、または、構成を全体として除去する）再構成（例えば、３１０で受信される）が、報告された干渉の傾向がある領域内の周波数（例えば、問題のある周波数のリスト内）のために（例えば、３１２で）実行されてもよく、または、プライマリキャリアとセカンダリキャリアの間の周波数間ハンドオーバが、（例えば、問題のある周波数から問題のない周波数へと）実行されてもよい。再構成は、（例えば、３１０で）無線デバイスによって受信されてもよく、無線デバイスは、（例えば、３１２で）補足のＲＦフィルタリングを、残りの動作キャリアに適用してもよい。

Ｐセルが干渉の傾向がある領域内にある（かつ、Ｓセルがそうでない）場合の、構成されたＳセルによるＰセルの高速変更が実行されてもよく、高速変更の情報またはインジケーションが無線デバイスに提供されて、無線デバイスが、例えば、３１０でその情報またはインジケーションを受信し、３１２でその情報を処理して、高速セル変更を実行することができるようにしてもよい。

また、別の周波数（例えば、ハンドオーバ）またはＲＡＴへのリダイレクトが実行されてもよい。このリダイレクトは、ＲＲＣ接続リジェクトまたは解放メッセージにより実行されてもよく、そのメッセージは、（例えば、３１０および３１２で）無線デバイスによって受信かつ処理されてもよい。加えて、セル変更指令が、無線デバイスへ送信されて（例えば、３１０で受信されて）、周波数またはＲＡＴの変更が実行されてもよい（例えば、３１２で処理される）。

一実施形態によれば、ハンドオーバがうまく完了すると、無線デバイスは、ピンポン効果を回避するか、または、候補リストから問題のある周波数を除去するために、ＩＳＭデバイスアクティビティなど、無線アクセス技術をサポートするコンポーネントアクティビティの期間にわたって、異なる周波数、ＲＡＴ優先度のリストを維持することが可能になってもよい。あるいは、上記で説明したように、無線デバイスは、問題のある周波数をネットワークに報告し、ネットワークが、それらの周波数上で測定するためのインジケーションを提供しないように、または、そのように無線デバイスを構成しないようにしてもよい。さらに別の実施形態では、そのようなリストは、システム情報要素（system information element）またはＲＲＣ測定構成メッセージ、および、これらの特定の状況において適用されたルール内で、ネットワークによってシグナリングされてもよい。

別の実施形態では、干渉ＲＡＴの共存は、ＲＡＴデバイスまたはコンポーネント上の送信および／または受信間の時間調整が存在できることを保証すること、および、したがって、あるＲＡＴデバイスから別のＲＡＴデバイスへ発生した干渉を（例えば、ＲＡＴの時分割多重化を介して）限定することによって、可能になってもよい。そのような状況では、デバイス内干渉状況を検出、または、通知もしくは報告を受信すると、以下の１つまたは組み合わせがＵＥによって、または、ネットワークによって行われてもよく、ネットワークは、それに関連付けられた情報を無線デバイスに提供してもよく、その情報は、３１０で受信され、３１２で処理されてもよい。

例えば、（本明細書で論じるような）このＲＡＴ間の無線デバイス内のＴＤＭ動作を可能にする間欠受信（ＤＲＸ）サイクルまたはギャップ／パターンが構成されてもよく、これについては以下でより詳細に説明する。無線デバイスは、無線デバイス内のＴＤＭ動作、または、無線デバイス通知／機能信号もしくはその中に含まれた情報がそのような動作をサポートする場合にＴＤＭデバイス動作共有方式を可能にするためのＦＤＤ半二重動作を可能にする、半永続的スケジューリングにより、さらに構成されてもよい。無線デバイスは、そのような構成を、例えば、３１０で受信し、そのような構成を、３１２で処理してもよい。

別の方法では、同じ無線デバイス内の２つ以上のＲＡＴコンポーネントまたはデバイス上の同時通信（例えば、動作が、１つまたは複数のＲＡＴコンポーネント上で適合され、各ＲＡＴ上の送信障害が最小化されるか、または除去される）が実行されて、時間調整が保証され、したがって、ＲＡＴコンポーネントまたはデバイスの共存が可能になってもよい。そのような状況では、干渉ＲＡＴがモバイル端末またはネットワーク内で検出かつ／または報告されるとき、送信および受信のタイミングが調節されて、モバイル端末の既存の接続を維持しながら干渉ＲＡＴの動作が可能になってもよい。

例えば、ＬＴＥシステム内で、無線デバイスまたはｅＮＢがデバイス内干渉状況を認識することができるとき、プロシージャが適用されて、間欠送信（ＤＴＸ）／ＤＲＸもしくはＬＴＥによりスケジュールされた／スケジュールされていないギャップ、または、無線デバイスとｅＮＢとの間のデバイス内パターンが調整されて、ＬＴＥ接続への影響を最小化するか、または除去しながら、代替ＲＡＴ上の通信が可能になってもよい。一実施形態では、アップリンク（ＵＬ）およびダウンリンク（ＤＬ）送信が一意に判定されて、ＵＬおよび／またはＤＬ送信を有効にすることおよび無効にすることを独立であるようにしてもよい。

時間調整を介して共存を可能にするための１つの方法では、代替ＲＡＴ干渉を実現することができるときに、デバイスにおける時間パターン上の周期的ＤＴＸ／ＤＲＸサイクルは、無線デバイスとｅＮＢとの間で調整され、３１０で無線に提供され、３１２で処理されてもよい。構成された特定のサイクルおよび送信／受信の長さは、特定の代替ＲＡＴの送信／受信要件に一意に関連付けられてもよい。例えば、無線デバイスは、代替ＲＡＴのためのギャップを要求するネットワークへの報告をトリガしてもよい。この要求（例えば、３１０で受信される）は、限定されないが、以下の情報の１つまたは組み合わせを含んでもよく、すなわち、技術のタイプ、他の技術が受信／送信しようとするサービスのタイプ、および／または、他のＲＡＴが適切に機能できるようにするために必要とされる、要求されたパターン（例えば、長さおよび周期性）であり、このパターンは、例えば、ＬＴＥにおいて許可されたＤＲＸパターン、もしくは、異なる共存使用シナリオもしくはサービスのために使用されるべき事前定義されたパターンのセットへのインデックスの形式、または、より明示的な形式であってもよい。

実施形態の一例によれば、８０２．ｘ−ＷＬＡＮの場合、アクセスポイントの探索および関連付けを行うと、ＬＴＥシステムは、８０２．ｘ−ＲＡＴ上での動作を可能にする、明確に設計されたＤＴＸ／ＤＲＸまたはデバイス内パターンを有効にしてもよく、アクセスポイント関連付けが解放されるとき、ＬＴＥシステムは、デバイス内パターンまたはＴＤＭ方式のＤＴＸ／ＤＲＸ動作または拡張ＤＴＸ／ＤＲＸ動作を無効にしてもよい。ＬＴＥ送信ギャップは、上位層ＩＰプロトコルを維持するために、周期的に成功する８０２．ｘ−ＭＡＣレベル送信を保証するように設計されてもよい。例えば、ネットワークによるギャップの解放を支援するために、無線デバイスはまた、ネットワークに、他の技術が無効化／非アクティブ化されているか、または、干渉を発生し続けていないことを報告してもよい。

より具体的には、実施形態の一例では、無線デバイスは、８０２．ｘスタックにおける送信時間推定のためのアルゴリズムを使用してもよい。より正確には、８０２．ｘ−ＩＰスタック、バッファサイズおよび８０２．ｘ無線条件に基づいて、無線デバイスは、８０２．ｘ関連バッファを空にするために、いくつの送信サイクルが必要とされるかを評価してもよい。これを、例えば、ＬＴＥサブフレームまたはフレームの倍数として表すことができる。無線デバイスは、８０２．ｘの推定されたアクティビティ要件を含むイベントまたはＭＡＣ−ＣＥを送信してもよい。加えて、８０２．ｘ関連サービスが周期的送信を必要とする場合、特定のサービス周期性フラグがｅＮＢ通知のために使用されてもよい。

別の実施形態では、無線デバイスは、サポートされたサービスが変更されると、または、送信もしくは受信要件が判定されると、パターンを要求するか、または、パターン変更を要求してもよい。無線ベアラの確立、または、特定のサービスの確立もしくは解放のための上位層からのインジケーションが使用されて、あるＴＤＭパターンの設定がトリガされてもよい。これらのパターンはまた、送信するべきＵＬデータの量、または、受信するべきＤＬデータの推定値に基づいて、動的に調節されてもよい。

通知または要求を（例えば、３０８で）受信すると、ネットワークは、それに応じて、要求されたサービス送信を満たすＤＲＸサイクルまたはパターンを認可し、場合によっては、フレームおよび／もしくはサブフレーム内のアクティブ化時間、ならびに／または、認可されたＤＲＸサイクルの数における継続時間を認可してもよく、これらは（例えば、３１０で）受信され、（例えば、３１２で）処理されてもよい。加えて、無線デバイスに提供される情報は、認可されたＤＲＸサイクルの数における継続時間を含んでもよい。そのような情報は、ＭＡＣ−ＣＥ指令、ＲＲＣ再構成メッセージもしくは新しいＲＲＣメッセージ、または、物理層インジケーションを介して提供されてもよい。

あるいは、無線デバイスは、ネットワークが、干渉技術を備えたＷＴＲＵのための専用のシグナリングを介してブロードキャストし、または提供することができる、セカンダリＤＲＸ構成を使用してもよく、この構成は、無線デバイスによって（例えば、３１０で）受信され、（例えば、３１２で）処理され、ｅＮＢからの指令に基づいてアクティブ化されてもよい。

加えて、ネットワークは、ｅＮＢバッファがＷＴＲＵのためのデータを有している可能性がある場合、無線デバイスＤＲＸ要求を拒否してもよい。ＲＡＴアクティビティが終了すると、無線デバイスは、上記の方法を使用してｅＮＢに通知し、標準の動作を再開してもよい。あるいは、ネットワークは、無線デバイスに、代替ＤＲＸ構成（３１０で受信され、３１２で処理されうる）を除去するＲＲＣ再構成メッセージまたはＭＡＣ−ＣＥ指令を送信してもよい。

ＤＲＸ／ＤＴＸまたはＬＴＥによりスケジュールされた／スケジュールされていないパターンもまた、時間調整を使用して共存を保証するために事前構成されてもよく、および使用されてもよい。例えば、特定のパターンのためのトリガリング基準が検出されるときに、事前構成されたパターンが選択されてもよい。各パターンは、特定の構成された構成インデックスによって知られてもよい。選択された構成インデックスは次いで、無線デバイスとｅＮＢの間でシグナリングされて、パターンが同期されてもよい。

トリガリング基準を検出することができる場所に応じて、無線デバイスまたはｅＮＢは、要求された新しいＤＲＸ／ＤＲＸパターンが含むことができる、エンティティ信号を判定してもよい。適切なスケジューラ動作のため、無線デバイスとｅＮＢとの間でＤＲＸ／ＤＴＸまたはＬＴＥによりスケジュールされた／スケジュールされていないパターンを調整するために、決定論的なシグナリング方法が必要とされることがある。ＭＡＣ−ＣＥシグナリングが使用されて、例えば、特定の事前構成されたＤＲＸ／ＤＴＸパターンインデックスが識別されてもよい。

加えて、パターンの変更、または、パターンを変更する必要性が検出されるときに、無線デバイスは、パターンの変更を自律的に実行し、変更および時間のインジケーションを送信してもよい。あるいは、無線デバイスは、そのような変更が実行されたこと（例えば、必要とされたパターンの変更）をネットワークに通知し、パターンを推奨し、または、どのような変更が実行されたかを指示し、その変更を実行するためのネットワークからの明示的指令を待機してもよく、この指令は、３１０で受信され、３１２で処理されてもよい。そのような動的な通知が、ＭＡＣ−ＣＥを介して実行されて、変更またはパターンが識別されてもよく、ネットワークは、別のＭＡＣ−ＣＥを介して、もしくは、Ｌ１シグナリングを介して、または、ＲＲＣメッセージングを介して、新しいパターン信号で送信し返すか、または、確認応答してもよい。

時間調整を介してＲＡＴの共存を可能にするための別の方法では、高速ＭＡＣまたはＰＨＹシグナリングが使用されて、動的な要求された送信／受信ギャップが作成されて、代替ＲＡＴ上の送信を可能にしてもよい。この方法では、送信／受信要件が代替ＲＡＴ上で検出されるときに、ＬＴＥ接続は、既知の期間にわたってパターンを迅速に開始して、代替ＲＡＴ上の通信を可能にしてもよい。１つの解決策では、これらのパターンは、ＲＲＣによって事前構成されてもよい。このことは、共存する技術の存在の報告の結果としてのもの、または、この技術がアクティブ化される結果としてのものであってもよい。事前構成されると、これらのパターンは、代替ＲＡＴのパターンおよび要件に従って、ＭＡＣまたはＰＨＹシグナリングを使用して、高速なベースでアクティブ化／非アクティブ化されてもよい。

非バッファステータス報告（すなわち、Ｅｍｐｔｙ−ＢＳＲ）もまた、ＲＡＴの共存を可能にするために使用することができる。そのような状況では、（例えば、３０８で）この通知または報告を受信すると、ネットワークは、以下の１つまたは組み合わせを実行してもよく、それに関連付けられた情報を無線デバイスに提供してもよく、その情報は、３１０で受信され、３１２で処理されてもよい。

例えば、無線デバイスは、例えば、ＮＳＲ（Non Scheduling Request）と呼ばれる、新しいタイプの要求をネットワークへ送信することによって、ネットワークに対し（例えば、３０８で通知を介して）、共存するＲＡＴへの干渉を回避するためにスケジュールされることを望まない場合があることを指示してもよい。このＮＳＲは、ＭＡＣパケットデータユニット（ＰＤＵ）内に、または、既存のＭＡＣ−ＣＥ、もしくは、定義される新しいＭＡＣ−ＣＥの一部として、含まれてもよい。

ＮＳＲは、下記で説明する以下の情報のうち１つまたは複数を含んでもよい。ＮＳＲは、アップリンクスケジューリングが回避されるべきであるか、ダウンリンクスケジューリングが回避されるべきであるか、両方が回避されるべきであるかを指示するエニューメレーション（enumeration）と、スケジューリング回避が開始または停止するべきであることを示すブール（boolean）と、その間にスケジューリングを回避することができる期間であって、その間に無線デバイスが、他の共存するＲＡＴへの干渉が起こりうると推定することができる期間に対応する期間と、それに対してスケジューリング回避が開始することができる（あるいは、スケジューリング回避が、ネットワークがＮＳＲを受信するとすぐに開始することができる）開始フレームおよびサブフレームと、それに対してスケジューリング回避を終了することができる（あるいは、スケジューリング回避が最上にあることを示す別のＮＳＲをネットワークが受信するとき、スケジューリング回避を終了することができる）終了フレームおよびサブフレームと、および／または、無線デバイスがそこから選択することができる、事前定義されたパターンのリストへのインデックスとを含んでもよい。

無線デバイスは次いで、ＮＳＲのトリガリングに関して、または、ＮＳＲの使用に基づいて、以下のルールの１つまたは組み合わせに従ってもよい。無線デバイスが、Ｅｍｐｔｙ−ＢＳＲをネットワークへ送信し、無線デバイスバッファが同じＴＴＩ内または最後のＸ個のＴＴＩ内で空であったことを指示することができる場合、無線デバイスは、ＵＬスケジューリング回避を要求するために、このＴＴＩ内でＮＳＲをネットワークへ送信する必要がないことがある。あるいは、または加えて、無線デバイスは、ＮＳＲを周期的に送信してもよい。周期的ＮＳＲタイマもまた定義されてもよく、その値は、固定であるか、または、ネットワークによって構成されてもよい。

ＮＳＲはまた、Ｅｍｐｔｙ−ＢＳＲ報告と組み合わせて使用されてもよい。より具体的には、無線デバイスはなお、実際のバッファステータスを報告してもよいが、加えて、上記で説明したＮＳＲ情報の１つまたは組み合わせを含めて、事前定義されたか、または既に構成されたパターンに従って、送信しないこと、または、送信しないことを開始することを選択することを指示してもよい。ネットワークは、例として、新しいＭＡＣ−ＣＥのように、ＲＲＣ構成またはＭＡＣ構成を介して、ＷＴＲＵ内のＮＳＲを有効または無効にしてもよい。

無線デバイスはまた、代替ＲＡＴのバッファ推定サイズおよび無線条件（変調および符号化レート）に基づいて、物理層上の高速シグナリングメッセージ、または、代替ＲＡＴ送信のためのＬＴＥ−ｅＮＢギャップを要求するＭＡＣ−ＣＥをも（例えば、３０８で）送信してもよい。これらのギャップは、フレームまたはサブフレームの倍数におけるものであってもよい。ｅＮＢは次いで、グラント送信ギャップの長さを、フレームまたはサブフレーム内の可能な開始オフセットと共に送信してもよく、これらは、３１０で受信され、３１２で処理されてもよい。

あるいは、ｅＮＢは、いかなるギャップも許可せず、拒否通知を無線デバイスへ送信してもよい。サービスの拒否を受信すると、かつ、ネットワークシグナリング負荷の増大を回避するために、無線デバイスは、（例えば、３１２で）代替ＲＡＴのためのバックオフタイマを実装してもよい。このバックオフタイマが満了すると、無線デバイスは、代替ＲＡＴサービス要求を再度送信してもよい。加えて、限定された数のリトライが、ネットワークによってシグナリングされるか、または、無線デバイス実装で定義されてもよい。

実施形態の一例によれば、送信ギャップを開始するための基準は、各８０２．ｘ−ＭＡＣ層送信についてのものでないことがある。送信／受信を有効にすることは、加えて、上位層ＴＣＰまたはＦＴＰ転送によって決まってもよい。代替ＲＡＴへ／代替ＲＡＴからの切り替えは、上位層プロトコルへの影響を考慮に入れてもよい。例えば、送信速度を低減するか、または、サービス配信のために必須ではない可能性のある低優先度データを考慮に入れるために、送信があるＲＡＴ上に意図的にドロップされてもよい。

加えて、本明細書で説明するすべての要求は、禁止タイマによって限定されて、無線デバイスによる頻繁な要求が回避されてもよい。より具体的には、ある要求またはインジケーションが、本明細書で説明する実施形態のいずれかによってトリガされうる場合、無線デバイスは、（例えば、３１２で）禁止タイマを開始してもよい。変更が起こり、別のインジケーションがトリガである可能性があり、かつ、禁止タイマを実行している場合、無線デバイスは、その要求を送信せずに、タイマの満了を待機してもよい。タイマが満了した後、トリガのための条件がなお当てはまる場合、無線デバイスは、保留中の要求を送信してもよい。あるいは、禁止タイマが実行中である間に、ある要求がトリガされる場合に、無線デバイスは、その要求をキャンセルしてもよい。

別の実施形態では、ネットワークは、ＴＤＭ方式のためのＤＲＸを介して、干渉ＲＡＴの共存を可能にしてもよい。そのような状況では、この通知または報告を受信すると、ネットワークは、以下の１つまたは組み合わせを実行してもよく、それに関連付けられた情報を無線デバイスに提供してもよく、その情報は、３１０で受信され、３１２で処理されてもよい。

例えば、デバイス内共存（例えば、ＩＣＯ）の問題を解決するための１つの潜在的な解決策は、ある無線信号の送信が別の無線信号の受信と一致しないことを保証することを含む、ＴＤＭ（Time Division Multiplexing）方式を採用することであってもよい。ＬＴＥでは、ＴＤＭパターンは、ネットワークによって構成されたか、または、無線デバイスによって示唆された、スケジュールされた期間およびスケジュールされていない期間を有することにつながる。

ＴＤＭを達成するための１つの方法は、ＤＲＸの使用を介することである。一実施形態によれば、他の技術がＬＴＥの非アクティブ時間（スケジュールされていない期間）中に送信している可能性があり、ＬＴＥのアクティブ時間（スケジュールされた期間）中に送信しない可能性があることは、想像されよう。

ＬＴＥのためのＤＲＸパターンは、図５に示すように、ＷＴＲＵが物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を監視しなければならない、オン継続時間の期間、および、ＷＴＲＵがスリープすることができる、ＤＲＸのための機会の期間により、定義されてもよい。

ＤＲＸについての重要な概念は、最小の長さのオン継続時間の期間を有し、ネットワークスケジューリングおよび無線デバイストリガに従って無期限に延長することができる、アクティブ時間でありうる。アクティブ時間中に、無線デバイスは、ＰＤＣＣＨを監視しなければならず、送信または受信を実行してもよい。そのため、問題は、無線デバイスが、ＤＲＸのための機会の期間中に非アクティブ（すなわち、スリープ）のままでいることができないことがある、ということであり、その理由は、異なるイベントが、無線デバイスをアクティブ時間内にとどまるように強制するか、または、ＷＴＲＵを、非アクティブ時間からウェイクアップしてアクティブ時間へ移行するように強制することさえあるためである。いくつかの例は、新しいＤＬ送信、ＵＬグラント、保留中のスケジューリング要求、ランダムアクセス競合解決、および、ハイブリッド自動再送要求（ＨＡＲＱ）再送信である。アクティブ時間が無期限に延長される、極端な場合には、無線デバイスは、スリープする機会を有していないことがあり、ＴＤＭ方式においてＩＳＭ技術と共存することができないことがある。加えて、ＷＴＲＵがＰＤＣＣＨを監視中であるかどうかにかかわらず、ＷＴＲＵは、そのようなものが予期されるとき、ＨＡＲＱフィードバックを受信かつ送信してもよい。このことは、無線デバイスがアクティブ時間内でない場合であっても、確認応答／否定確認応答（ＡＣＫ／ＮＡＣＫ）を物理ＨＡＲＱインジケーションチャネル（ＰＨＩＣＨ）上で受信し、ＡＣＫ／ＮＡＣＫを物理アップリンク制御チャネル（ＰＵＣＣＨ）上で送信する可能性があるというリスクが、いまだに存在することを意味する。

本明細書で説明する１つまたは複数の解決策を、ＤＲＸのために使用することができる。例えば、一実施形態では、ＤＲＸ方式を使用して、異なる各ＲＡＴにわたる共存調整を可能にしてもよい。ＤＲＸ方式が使用されるために、しかし、いくつかの修正、拡張および限定が修正され、または含まれる必要がある。

例えば、異なるＲＡＴ間の共存の目的のために、以下で言及するとき、スケジュールされた時間は、ＬＴＥをネットワークによってスケジュールすることを可能にする時間（例えば、送信／受信）に対応することがあり、ＬＴＥによりスケジュールされていない（または、ＩＳＭによりスケジュールされる）ものは、送信するため（問題がＤＬにあるとき）、または、ＬＴＥがＵＬ内で干渉を引き起こしている可能性があるときは、受信するための時間がＩＳＭデバイスに割り振られる時間に対応することがある。

共存は、ＤＲＸサイクルの非アクティブ時間が、保証された、ＬＴＥによりスケジュールされていない期間に対応し、かつ、ＤＲＸのアクティブ時間が、ＬＴＥによりスケジュールされた期間に対応するように、設計されてもよい。これには、異なる技術間のより動的な調整が必要となることがある。あるいは、共存は、ＬＴＥによりスケジュールされた期間がオン継続時間に対応するように、設計されてもよい。あるいは、特定のスケジュールされた／スケジュールされていない期間／サブフレームが、本明細書で説明する方法のいずれかによって、無線デバイス内で構成または判定されてもよく／構成または判定される。

そのような方法の利益は、ＬＴＥによりスケジュールされていない期間をより有効に利用できることである。他のＲＡＴが、ＬＴＥによりスケジュールされていない期間にあらかじめ気づいている場合、ＬＴＥ非アクティビティの検出と、他のＲＡＴ上の送信の開始の間に、アイドル期間はない。加えて、他のＲＡＴは、ＬＴＥによりスケジュールされていない期間の既知の終了まで、進行中の送信が中断されることなく、送信を継続することができる。このことは、スケジュールされていない期間が短い、ＲＡＴ間の高速切り替えの場合に、特に重要である。

本明細書で説明する実施形態は、上記で論じた方式のいずれかを使用して、ＴＤＭ動作を達成するための方法を論じる。また、ＤＲＸアクティブ時間および／またはオン継続時間が、ＷＴＲＵ内でスケジュールされた／スケジュールされていない期間に関係付けられない場合では、ＤＲＸが実行中であり、かつ、関連付けられたパターンが構成される間の、ＷＴＲＵの動きを説明する。

スケジューリング要求もまた、ＲＡＴＳの共存を可能にするために使用することができ、本明細書で説明する。ＵＬ−ＬＴＥ−＞ＩＳＭ−ＤＬ干渉では、ＵＬ送信−遅延送信のみにとっての問題となる。ＵＬ−ＩＳＭ−＞ＬＴＥ−ＤＬ干渉では、ＷＴＲＵは、送信された場合に、ＰＤＣＣＨの受信が損なわれるときは常に、いかに損なわれうるものであろうと、スケジューリング要求を送信することができる。

非アクティビティタイマもまた、ＲＡＴの共存を可能にするために使用することができ、本明細書で説明する。例えば、一実施形態では、無線デバイスが新しいＵＬまたはＤＬ送信を受信する場合、ｄｒｘ−非アクティビティタイマが起動されてもよい。非アクティビティタイマ中に、無線デバイスは、ＰＤＣＣＨを連続的に監視するアクティブモードのままであってもよい。ネットワークが、この時間中に無線デバイスをスケジュールする場合、無線デバイスは、アクティブ時間内に残り続けてもよい。

ＴＤＭ方式で動作するように構成された無線デバイスでは、連続的な期間にわたってアクティブ時間内にとどまることを回避するため、無線デバイスは、（例えば、３１２で）以下の１つまたは組み合わせを実行してもよい。

新しいＤＬまたはＵＬ送信が受信されるときに、ｄｒｘ−非アクティビティタイマは、開始されないことがある。あるいは、このことは、ゼロに設定されたｄｒｘ−非アクティビティタイマのための新しい値を導入することによって、達成されうる。このことは、無線デバイスおよびネットワークが、無線デバイスのオン継続時間中に、または、ｄｒｘ−非アクティビティ以外のトリガによる他のアクティブ時間中に、スケジュールしてもよいことを暗示する。

別の実施形態では、ｄｒｘ−非アクティビティタイマは、事前定義された期間および／またはＮ回にわたって起動かつ再起動されてもよい。

現在の経過したアクティブ時間が、ＬＴＥによりスケジュールされたタイマ（または、指定された最大アクティブ時間）よりも大きくない限り、ｄｒｘ−非アクティビティタイマはまた起動／再起動されてもよく、無線デバイスはアクティブモードのままであってもよい。現在の経過したアクティブ時間は、無線デバイスがアクティブ時間へ移行する最初のＴＴＩ（例えば、オン継続時間の開始時）に対して計算されてもよい。

あるいは、現在の経過したアクティブ時間が、（ＬＴＥによりスケジュールされたタイマ−ｄｒｘ−非アクティビティ）（または、指定された最大アクティブ時間−ｄｒｘ−非アクティビティ）よりも大きくない可能性がある限り、ｄｒｘ−非アクティビティタイマはまた起動／再起動されてもよく、無線デバイスはアクティブモードのままであってもよい。

あるいは、新しいＤＬまたはＵＬ送信が、ＬＴＥによりスケジュールされた送信に対応するか、またはそれと重複する時間である場合、ｄｒｘ−非アクティビティタイマは起動／再起動されてもよい。

あるいは、ｄｒｘ−非アクティビティタイマが起動されてもよいが、無線デバイスのアクティブ時間中のサブフレームのいずれかが（構成されたパターンによって判定されるように）スケジュールされていないサブフレームに対応する場合、無線デバイスは、それらのサブフレーム中にいかなるＵＬ送信をも実行しないことがある。無線デバイスはさらに、それらのサブフレーム中に、ＰＤＣＣＨの監視を停止してもよい。別の解決策では、無線デバイスは、標準ＤＲＸプロシージャに従ってＰＤＣＣＨを監視してもよいが、それらの時間中にスケジュールされないように、ネットワークに依拠してもよい。第３の解決策では、無線デバイスは、ＰＤＣＣＨを監視してもよく、スケジュールされていないサブフレーム内でＵＬ送信のためにスケジュールされる場合、無線デバイスは、ＵＬ送信を実行しないことがある。

図６は、ＤＬ再送信およびＤＬフィードバックの一例の図を示す。図６に示すように、無線デバイスは、ＬＴＥによりスケジュールされた期間中にＤＬ送信が発生する場合、ＤＲＸ非アクティビティタイマを起動または再起動してもよいが、ＤＲＸ非アクティビティタイマは、無線デバイスがＬＴＥによりスケジュールされていない期間に入ることがあるとき、実行中であれば停止されてもよく、また、無線デバイスは、ＬＴＥによりスケジュールされていない期間中にＤＬ送信が発生する場合、ＤＲＸ非アクティビティタイマを起動しないことがある。

無線デバイスはまた、ＨＡＲＱ往復時間（ＲＴＴ）タイマが満了し、かつ、ＤＲＸ再送信タイマを起動するときにも、アクティブモードへ移行してもよい。無線デバイス内のアクティブ時間を限定し、したがって、誤りの確率を減らすために、（例えば、３１２で）以下の１つまたは組み合わせが実行されてもよい。

一実施形態では、再送信タイマが起動または使用されないことがある。そのような実施形態では、再送信は、進行中のアクティブ期間（例えば、オン継続時間）または次のアクティブ期間中に送信されてもよい。このことは、データの送信にいくつかの遅延を引き起こすことがあり、いくつかのサービスのためのＱｏＳ要件が満たされないことがある。代替として、再送信遅延を回避するために、ネットワークは、ＷＴＲＵがそのようなモードで動作しているときに、ＤＬ送信のために送信時間間隔（ＴＴＩ）バンドリングを使用してもよい。

別の実施形態によれば、アクティブモードが、許可された、ＬＴＥによりスケジュールされた期間または最大ＬＴＥ期間に対応またはオーバーラップする場合にのみ、再送信タイマが起動されてもよく、無線デバイスはＰＤＣＣＨを監視してもよい。より具体的には、１つの解決策では、ＤＲＸ再送信タイマが実行中である間にＬＴＥによりスケジュールされた期間が満了する場合、無線デバイスは、タイマを停止し、もはやＰＤＣＣＨを監視しないことがある。

あるいは、第２の解決策では、ＷＴＲＵは、ＤＲＸ期間に従ってＰＤＣＣＨをなお監視してもよいが、ＩＳＭによりスケジュールされた期間／サブフレームが開始すると、他の技術がＵＬ送信を開始してもよい。ＬＴＥによりスケジュールされていない期間に基づくネットワークは、再送信を遅延させることを判定するか、あるいは、再送信を、無線デバイス内で適切にデコードされない高いリスクで、なおスケジュールしてもよい。ｅＮＢは、干渉がこの期間中に問題になりうることを知りながら、再送信の送信信頼性を増すことができる。

加えて、ＡＣＫ／ＮＡＣＫ反復が構成される場合、無線デバイスは、反復バンドルサイズ、すなわち、そのスケジュールされていない期間とオーバーラップするＰＵＣＣＨ送信を回避することが必要とされる場合に、それに対して無線デバイスがフィードバックを反復しなければならない可能性がある連続的なＡＣＫ／ＮＡＣＫスロットの数を、自律的に低減してもよい。より正確には、無線デバイスは、スケジュールされた期間中に上位層によって構成されるようにＡＣＫ／ＮＡＣＫ反復を使用してもよいが、ＡＣＫ／ＮＡＣＫ反復が、スケジュールされた期間の最終サブフレームにオーバーラップしている可能性があり、かつ、この限定を超えると想定される場合、無線デバイスは、スケジュールされた期間の間隔に適合するために、ＡＣＫ／ＮＡＣＫ反復数を低減することを可能にしてもよい。あるいは、無線デバイスは、スケジュールされた期間外で、ＰＵＣＣＨ上で単一のＡＣＫ／ＮＡＣＫのみを使用し、スケジュールされた期間内でＡＣＫ／ＮＡＣＫ反復を使用してもよい。あるいは、無線デバイスは、次にスケジュールされた期間にわたってＡＣＫ／ＮＡＣＫを遅延させ、上位層によって構成されるように反復をなお使用してもよい。ネットワークは、ＷＴＲＵがデバイス内干渉回避モードに入るとき、無線デバイスに対し、これらの２つの異なるＡＣＫ／ＮＡＣＫ反復オペレーションモードをシグナリングしてもよい。

ＵＬフィードバック（ＡＣＫ／ＮＡＣＫ）およびＵＬ再送信もまた、ＲＡＴの共存を可能にするために、本明細書で説明するように使用することができる。

ＷＴＲＵが、（例えば、３１０で）ＡＣＫ／ＮＡＣＫをネットワークから受信し、（例えば、３１２で）ＡＣＫ／ＮＡＣＫを処理し、ＷＴＲＵデータを再送信するとき、干渉を回避するために、以下の方法の１つまたは組み合わせが使用されてもよい。

無線デバイスＬＴＥは、同じＬＴＥによりスケジュールされた期間内または将来のＬＴＥによりスケジュールされた期間内のサブフレームｎ＋４で、（適応ＨＡＲＱのための）フィードバックおよびＵＬグラントを受信するための時間がありうると知っているときにのみ、サブフレームｎでデータを送信してもよい。このことは、次のように指定されてもよく、すなわち、サブフレームｎについて、無線デバイスが、サブフレームｎ＋４でＬＴＥによりスケジュールされた期間内である場合、無線デバイスはデータを送信してもよい。例えば、ＬＴＥによりスケジュールされた期間がオン継続時間の期間に対応する場合、無線デバイスは、ＵＬデータを送信する前にオン継続時間タイマがサブフレームｎ＋４で実行中でありうることをチェックしなければならないことがある。

実施形態の一例によれば、ＩＳＭは、ＡＣＫ／ＮＡＣＫが適切に受信されうることを保証するために、最後のＬＴＥによりスケジュールされた期間後に４個のサブフレームを送信しないことがある。

ＮＡＣＫの場合、無線デバイスは、必要に応じて、次にＬＴＥによりスケジュールされた期間まで、再送信を遅延させてもよい。無線デバイスはまた、再送信を送信している同一のサブフレーム内で、ＰＵＣＣＨ上でＨＡＲＱ処理ＩＤをネットワークに指示し、ネットワークが再送信を特定のＨＡＲＱ処理に関連付けることを可能にしてもよい。

あるいは、再送信をアクティブ時間またはＬＴＥによりスケジュールされた期間内で実行することができない場合、無線デバイスは、ＨＡＲＱ処理をフラッシュ（flush）してもよい。

あるいは、無線デバイスは、ＨＡＲＱ処理においてデータを維持してもよく、再送信時間がウィンドウの外側で生じる場合、データを送信しなくてもよく、無線デバイスが送信しないことがある（例えば、サブフレームが、スケジュールされていないサブフレームに対応する）たびに、無線デバイスはなお、ＨＡＲＱ再送信カウンタ、および、再送信ごとに変更される任意の他の物理層パラメータを増分させ続けてもよい。非アクティブ時間中に再送信の最大数に到達する場合、ＷＴＲＵは、ＨＡＲＱバッファをフラッシュし、データを廃棄してもよい。

加えて、ＴＴＩバンドリングがアップリンク送信のために構成されている場合、ＷＴＲＵは、バンドルからのサブフレームのいくつかが、ＬＴＥによりスケジュールされた期間外で生じる場合、ＴＴＩ＿ＢＵＮＤＬＥ＿ＳＩＺＥを自律的に低減してもよい。

スケジューリング要求（ＳＲ）もまた、ＲＡＴの共存を可能にするために、本明細書で説明するように使用することができ、これを図７に示すことができる。例えば、ＳＲがトリガされるときに、ＳＲは、第１の使用可能な割り当てられたＰＵＣＣＨリソースにおいて送信されてもよい。送信されると、無線デバイスは、アクティブ時間へ移り、（例えば、３１０で）グラントを受信するまで、ＰＤＣＣＨを連続的に監視してもよい。無線デバイスが、無線デバイスの次のＳＲ機会の前にＵＬグラントを受信しないことがある場合、かつ、ｓｒ−ｐｒｏｈｉｂｉｔＴｉｍｅｒが実行していない場合、無線デバイスは、新しいＳＲを送信してもよい。

共存する技術に受信機会を提供するために、どのＵＬ送信も他の技術の受信を干渉しない場合、ＳＲの送信は、以下のルールうち１つまたは複数に従って実行されてもよい。

例えば、ＳＲがトリガされる可能性があり、かつ、最初のＰＵＣＣＨリソースが無線デバイス内で非アクティブ期間中（例えば、オン継続時間中、または、非アクティビティタイマによるアクティブ期間中に）に発生する場合、ＳＲは送信されないことがある。無線デバイスは、無線デバイスのアクティブ時間中に使用可能であるＰＵＣＣＨリソースに対応する次の機会において、ＳＲを送信してもよい。

どのＰＵＣＣＨリソースも、アクティブまたはＬＴＥによりスケジュールされた時間中に使用可能でない可能性がある場合、無線デバイスは、どの有効なＰＵＣＣＨリソースも使用可能でないことを、ネットワークに知らせるために、ランダムアクセス（ＲＡ）プロシージャを開始してもよい。

あるいは、ＳＲがトリガされる可能性があり、かつ、最初のＰＵＣＣＨリソースが、ＬＴＥによりスケジュールされていない期間中に生じる場合、ＳＲは送信されないことがある。無線デバイスは、ＬＴＥによりスケジュールされた期間中に使用可能であるＰＵＣＣＨリソースに対応する次の機会において、ＳＲを送信してもよい。

無線デバイスは、ＰＵＣＣＨリソースがＷＴＲＵアクティブ時間またはＬＴＥによりスケジュールされた期間のいずれか一方に対応する場合、ＳＲを送信してもよい。

あるいは、ｅＮＢは、ＰＵＣＣＨリソース割り当てがＷＴＲＵアクティブ時間またはＬＴＥによりスケジュールされた時間に整合されることを保証してもよい。

加えて、別の実施形態では、ｅＮＢは、ＵＬのための半永続的スケジューリング（ＳＰＳ）により、ＷＴＲＵを構成してもよい。ＳＰＳ周期性は、無線デバイスのアクティブ時間またはＬＴＥによりスケジュールされた時間に対応してもよい。

ＳＲが上記のルールに従って、または、既存のルールに従って送信された可能性があると、無線デバイスは、（例えば、３１２で）アクティブ時間へ移行し、ＵＬグラントを受信するためにＰＤＣＣＨを連続的に監視しなければならないことがある。しかし、ＰＤＣＣＨ送信が無線デバイスによって正しく受信されること、および、どのＩＳＭ干渉も受信を損なうことがないことを保証するために、以下の１つまたは組み合わせが実行されてもよい。

ＳＲが送信されるようになると、無線デバイスは、ＷＴＲＵがアクティブ時間になるまで、または、ＬＴＥによりスケジュールされた期間が開始するまで、（非アクティブであった場合）非アクティブにとどまり続けてもよい。ｅＮＢはまた、ＬＴＥによりスケジュールされた、および／または、オン継続時間がアクティブになるまで、ＳＲの送信後、デバイス内共存モードのＷＴＲＵがＰＤＣＣＨを監視中でないことがあることに気づいてもいる。図８は、そのような動きの一例を示す。

あるいは、無線デバイスは、（例えば、３１２で）アクティブモードへ移ってもよく、ＩＳＭデバイスは、ＵＬ送信を継続してもよいが、ｅＮＢは、ＬＴＥによりスケジュールされた期間またはオン継続時間の期間中に無線デバイスをスケジュールする（例えば、ＰＤＣＣＨを送信する）ことによって、衝突が起こらないことを保証してもよい。同じルールはまた、ＳＲ禁止タイマ（sr-prohibit timer）が満了した後、保留中のＳＲに対しても適用されてもよい。

無線デバイスが、本明細書で説明するプロシージャに従って、ＳＲまたはＲＡＣＨを開始しないことがある場合、無線デバイスが、ＳＲまたはＲＡＣＨプリアンブルを送信するために、非アクティブ期間またはスケジュールされていないサブフレーム中に、どのタイプのデータ送信をウェイクさせることができるかについて、いくつかのルールが無線デバイス内で構成または事前定義されてもよい。より具体的には、ネットワークは、以下の１つまたは組み合わせのためにのみ、データを送信するためにウェイクアップするように、ＷＴＲＵを構成してもよく、すなわち、特定の論理チャネル優先度、論理チャネル優先度のリスト、最小論理チャネル優先度、すなわち、そのために無線デバイスが送信すべきデータを有する論理チャネル優先度が、この最小を上回る場合、ＷＴＲＵがウェイクアップを可能にすること、特定の論理チャネルグループ、論理チャネル識別情報、論理チャネル識別情報のリスト、および、特定のアクセスクラスのためのＮＡＳサービス要求である。後者の場合、アクセスクラスが、緊急呼び出しなど、高優先度アクセスクラスに属する場合、無線デバイスは、ＩＣＯルールにかかわらず、ウェイクアップし、ＳＲをトリガしてもよい。これらのタイプのトラフィックは、他の技術への干渉を発生する潜在性に取って代わる。さらに、ＩＳＭ送信は、その送信がＤＬ−ＬＴＥ受信に干渉する可能性がある場合、一時停止されてもよい。

ランダムアクセスプロシージャもまた、ＲＡＴの共存を可能にするために、本明細書で説明するように使用することができる。例えば、ランダムアクセスプロシージャがトリガされうる場合、無線デバイスは、構成されたｐｒａｃｈＣｏｎｆｉｇＩｎｄｅｘによって可能にされたランダムアクセスリソースフレームおよびサブフレーム中に、プリアンブルを送信してもよい。プリアンブルが送信されるようになると、無線デバイスは、以下のシナリオのためにアクティブ時間内であり、かつ、ＰＤＣＣＨを監視することが必要とされることがあり、すなわち、１）ランダムアクセス応答ウィンドウ（ＲＡプリアンブルが送信された後、３個のサブフレームを開始する）、または、無線デバイスがＤＬ割り当てをＲＡ−無線ネットワーク一時識別子（ＲＮＴＩ）と共に受信するまで、および、２）競合解決タイマが実行中である間のＭｓｇ３の送信後、ＵＬグラントが受信され、または、競合解決メッセージが受信されることである。

ＵＬ送信が他の技術への干渉を引き起こす場合、かつ、構成された物理ＲＡＣＨ（ＰＲＡＣＨ）リソースの場合、または、Ｍｓｇ３グラント時間が、無線デバイスの非アクティブまたはＬＴＥによりスケジュールされていない時間に対応する場合、以下のうち１つまたは複数が実行されてもよい。

プリアンブルは、無線デバイスのアクティブ時間またはＬＴＥによりスケジュールされた期間と重複することがある次のＰＲＡＣＨリソースまで、遅延されてもよい。ｅＮＢは、ＬＴＥによりスケジュールされた期間またはアクティブ期間によって、Ｍｓｇ３グラントが提供されることを保証してもよい。

加えて、プリアンブルまたはｍｓｇ３の送信機会になると、無線デバイスは、今度の送信にかかわらず、他の技術に通知してもよく、無線デバイスは、アクティブ期間またはスケジュールされた期間とオーバーラップするかどうかにかかわらず、データを送信してもよい。

ＲＡＲおよびＭｓｇ４のダウンリンク受信では、無線デバイスは、（例えば、３１２で）以下のうち１つまたは複数を実行してもよい。無線デバイスは、ランダムアクセスウィンドウが無線デバイスのアクティブ期間またはスケジュールされた期間に入る場合、ＰＤＣＣＨを監視してもよい。無線デバイスは、ＲＡＲウィンドウまたはスケジュールされた（アクティブ）期間の終了時に（または、ＲＡＲが受信されうる場合）、ＰＤＣＣＨの監視を停止してもよい。

加えて、無線デバイスは、競合解決時間がＷＴＲＵアクティブ期間またはスケジュールされた期間に入る場合にのみ、ＰＤＣＣＨを監視してもよい。ＷＴＲＵは、競合解決タイマまたはスケジュールされた（アクティブ）期間の終了時に（または、ｍｓｇ４が受信されうる場合）、ＰＤＣＣＨの監視を停止してもよい。

ＲＡＲウィンドウが非アクティブ時間またはスケジュールされていない時間内に入る場合、ＲＡＲウィンドウは、ＲＡプロシージャルールおよびスケジュールされた／アクティブ時間によってＲＡＲウィンドウが開始する最も早い機会に開始されるように修正されてもよい。ｅＮＢが、無線デバイスがスケジュールされた時間中に受信可能でありうること、および、ＲＡＲウィンドウが移動されることを知るために、ソースｅＮＢは、ハンドオーバ準備時間に、デバイス内情報およびパターンを提供しなければならない。専用のプリアンブルがＷＴＲＵに割り振られた可能性があり、かつ、ｅＮＢが、このＷＴＲＵがデバイス内干渉の動作のモードであることを知る場合、この解決策は功を奏する。

保証された非アクティブ時間を有するＤＲＸ動作もまた、ＲＡＴの共存を可能にするために、本明細書で説明するように使用することができる。例えば、保証された非アクティブ時間を有するＤＲＸを達成するための１つの方法は、オン継続時間およびサイクルと共に構成されたＤＲＸに加えて、最大のスケジュールされた期間およびスケジュールされていない期間の構成を有することである。実施形態の一例では、スケジュールされた時間またはスケジュールされていない時間の継続時間は、オン継続時間の期間より大きくなってもよく、その間に、無線デバイスはなお、普段のＤＲＸプロシージャを実行すること、すなわち、異なるＤＲＸタイマおよびトリガに従って不連続的かつ連続的にＰＤＣＣＨを監視することを可能にしてもよい。図９乃至１２に示すように、スケジュールされた期間およびスケジュールされていない期間の継続時間は、変化することがあり、シナリオおよび共存する技術要件によって決まることがある。

しかし、最大のスケジュールされた継続時間が経過すると（例えば、スケジュールされていない時間中）、無線デバイスは、ＤＬの監視を停止し、ＩＳＭに送信の機会を提供してもよい。あるいは、スケジュールされていない期間中、無線デバイスはなお、オン継続時間の期間中にウェイクアップしてもよいが、オン継続時間の期間を超えてアクティブ時間を延長することを可能にしないことがあり、ＬＴＥによりスケジュールされていない期間中に、上記で説明した異なるトリガについてのプロシージャのいずれかを実装してもよい。あるいは、無線デバイスはなお、ＤＲＸルールに従って、ＬＴＥによりスケジュールされていない期間中にＰＤＣＣＨを監視してもよいが、ＬＴＥによりスケジュールされていない期間に対応するサブフレーム内で、ＵＬ送信を必要とする何か（例えば、ＵＬフィードバックまたはＵＬデータ）が、ＰＤＣＣＨ内で検出される場合、無線デバイスはＰＤＣＣＨを送信せず、無視することがある。ＤＬ送信がＰＤＣＣＨ上でスケジュールされる場合、ＷＴＲＵは、ＩＳＭからの干渉のリスク、および、データを不正確に受信するリスクがあるとしても、ＤＬデータを受信してもよい。

一実施形態では、そのような解決策は、ネットワークがなお、ＷＴＲＵを短いオン継続時間の期間と共に構成して、バッテリー節約（例えば、３１０で受信されうる）を最適化することを可能にするが、なお、オン継続時間の期間を過ぎて延長するＤＬデータをスケジュールするために十分な柔軟性および機会を提供する。

図９は、スケジュールされた期間が、オン継続時間の期間より大きくなるが、ＤＲＸサイクルより小さくなる、かつ、オン継続時間の期間が、スケジュールされた期間中にのみ生じる場合の一例を示す。

図１０は、スケジュールされた継続時間およびスケジュールされていない継続時間が、ＤＲＸサイクルより大きく、かつ、無線デバイスが、スケジュールされていない期間中にＰＤＣＣＨを監視しないことがある場合の一例を示す。

図１１は、スケジュールされた継続時間およびスケジュールされていない継続時間が、ＤＲＸサイクルより大きく、かつ、無線デバイスが、スケジュールされていない期間中に生じるオン継続時間の期間中にＰＤＣＣＨを監視することがある場合の一例を示す。

加えて、図１２は、スケジュールされた継続時間およびスケジュールされていない継続時間が、ＤＲＸサイクル内で変化する場合の例を示す。図１２では、ＤＲＸサイクルは、構成されたパターンの周期性より小さいことがあるが、別の例では、ＤＲＸサイクルは、より大きくなることがある。

ＬＴＥによりスケジュールされた期間は、本明細書で言及するとき、ＬＴＥが干渉されることなくデータを送信／受信できる時間として定義されうる。ＬＴＥによりスケジュールされていない期間では、サブフレームまたはＴＴＩは、他の技術によって使用されるように、あらかじめ予約または構成されてもよい。（他の技術のスケジューラが、それらのサブフレームが他の技術のために予約されると仮定する、という事実を考えると）これらのサブフレーム中に、ＬＴＥによるいかなるＤＬ送信も正しく受信されないことがあり、いかなるＵＬ送信も、他の技術による受信に干渉することがある。上記で説明したように、ＬＴＥによりスケジュールされた／スケジュールされていないパターンは、スケジュールされた継続時間タイマおよびサイクルを含んでもよい。スケジュールされた継続時間タイマが実行中であるときに、無線デバイスは、通常のＤＲＸプロシージャに従い、ＰＤＣＣＨを不連続的に監視してもよい。スケジュールされた継続時間タイマが満了すると、無線デバイスは、（例えば、３１２で）ＰＤＣＣＨの監視を停止し、スリープしてもよい。あるいは、スケジュールされた継続時間タイマが実行中でないことがあるが、オン継続時間タイマが実行中であるときに、無線デバイスはＰＤＣＣＨを監視してもよい。これをタイマに関して説明することができるが、ＬＴＥによりスケジュールされた／スケジュールされていないパターンは、より明示的な形式を取ることができ、その場合、タイマは定義されなくてもよい。

一実施形態によれば、ＬＴＥの非アクティビティの期間を構成するために、例えば、スケジュールされていない継続時間タイマと呼ばれる、別のタイマが定義されてもよい。あるいは、ＬＴＥによりスケジュールされていないものに対して、タイマが定義されなくてもよく、ＬＴＥによりスケジュールされていないものは、ＬＴＥによりスケジュールされたタイマが実行中でない期間、または、他の技術のために予約されるＴＴＩとして定義される。

スケジュールされた継続時間およびスケジュールされていない継続時間の値は、ネットワークによって構成されてもよい。あるいは、無線デバイスＬＴＥは、ＩＳＭおよび他の技術との調整後に、ネットワークに値を指示または示唆してもよい。あるいは、無線デバイスは、オン継続時間の倍数であってもよく、また、オン継続時間に対して長く、かつ、ＤＲＸサイクルより短い値に対応してもよい。あるいは、ＬＴＥによりスケジュールされた／スケジュールされていないサイクルは、ＤＲＸと、ＤＲＸから独立して構成されたサイクルと、または、ＤＲＸサイクルの倍数と、同一のサイクルに対応してもよい。加えて、ＬＴＥによりスケジュールされた／スケジュールされていない期間が始まる時間を判定するためのサブフレームオフセットは、ＤＲＸと同じ、ＤＲＸから独立してネットワークによって事前定義かつ／または構成された新しいサブフレームオフセットであってもよい。本明細書で説明する実施形態はまた、ＤＲＸから独立しても適用可能である。

一実施形態では、無線デバイスがデバイス内共存干渉回避モードで構成されるとき、本明細書で説明するスケジュールされた／スケジュールされていないパターンが使用されてもよい。例えば、スケジュールされていない期間中（例えば、スケジュールされた継続時間タイマが実行中でないとき、または、ＩＳＭスケジューリングのために使用されたサブフレーム中）の１つの解決策では、ＤＲＸが構成されないことがある場合（例えば、ＬＴＥによりスケジュールされていない無線デバイスが非アクティブでありうるか、アイドル時間内でありうる間）、ＤＲＸのためのいかなるアクティブ時間もないか、または、アクティブ時間がないことがある。別の解決策では、スケジュールされていない期間中に、無線デバイスは、オン継続時間中にアクティブであることを可能にしてもよいが、無線デバイスがアクティブ時間に移ることを可能にするための追加のトリガは、適用可能でないことがある。

スケジュールされた継続時間タイマを維持することができる、実施形態の別の例では、無線デバイスは、以下の条件のうち１つまたは複数の下で、スケジュールされた継続時間タイマを起動または再起動してもよい。

ネットワークは、無線デバイスに対し、無線デバイスがデバイス内干渉回避モードで作動し始めなければならないことがあることを指示してもよい。このことは、例として、ＩＣＯ−ＭＡＣ−ＣＥまたはＲＲＣシグナリングと呼ばれる、新しいＭＡＣ−ＣＥ（制御要素）コマンドを実装することによって、達成されてもよい。

無線デバイスＬＴＥはまた、１）無線デバイスＬＴＥが、ＩＳＭ技術がアクティブ化されることを検出することがある場合、および／または、２）ＩＳＭ技術がＬＴＥと共に調整して、ＩＳＭ技術がすぐに動作を開始する可能性があることをＬＴＥが知るようにすることがある場合も、ＩＳＭ技術と共存しなければならないことを検出してもよい。

無線デバイスは、サイクルおよびサブフレームオフセットに従って、ＬＴＥによりスケジュールされたタイマが起動されると判定してもよい。

加えて、あるタイマが維持される場合、スケジュールされていない継続時間タイマが満了してもよい。例えば、スケジュールされた継続時間タイマが起動／再起動されるときに、スケジュールされていない継続時間タイマは、実行中であれば、停止されてもよい。

無線デバイスは、以下の条件下で、スケジュールされた継続時間タイマを停止してもよい。例えば、ネットワークがＷＴＲＵに対し、それがデバイス内干渉回避モードで作動することを停止する可能性があることを指示することがある場合、無線デバイスは、スケジュールされた継続時間タイマを停止してもよい。このことは、新しいＭＡＣ−ＣＥ（制御要素）コマンドを実装することによって、達成されてもよい。

加えて、無線デバイスＬＴＥが、ＩＳＭ技術（または、他のＲＡＴ技術）との共存を停止する可能性があることを検出することができるとき（例えば、１）無線デバイスＬＴＥが、ＩＳＭ技術がオフであることを検出することができるとき、または、２）ＩＳＭ技術がＬＴＥと共に調整して、ＩＳＭ技術が動作を停止することをＬＴＥが知ることができるとき）、無線デバイスは、スケジュールされた継続時間タイマを停止してもよい。上記の概念は、より明示的な形式で（例えば、あるサイクル内で異なるスケジュールされた／スケジュールされていないサブフレームを含む、ビットマップの形式で）無線デバイスに提供されるパターンに対して、等しく適用可能である。

実施形態の例では、スケジュールされた継続時間タイマが満了することがあるとき、または、無線デバイスが、明示的パターンに従って、ＬＴＥによりスケジュールされていないサブフレームに入ることがあるとき、無線デバイスＭＡＣは、以下の１つまたは組み合わせを実行してもよく、すなわち、ＰＤＣＣＨの監視を停止すること、あるいは、オン継続時間タイマが実行中でない場合にのみ、ＰＤＣＣＨの監視を停止すること、オン継続時間タイマが実行中であれば、停止すること、ＤＲＸ非アクティビティタイマが実行中であれば、停止すること、ＤＲＸ再送信タイマが実行中であれば、停止することを実行してもよい。

無線デバイスＭＡＣはさらに、ＨＡＲＱ−ＲＴＴタイマが実行中であれば、停止してもよい。あるいは、ＨＡＲＱ−ＲＴＴタイマは、実行し続けてもよい。ＨＡＲＱ−ＲＴＴタイマの満了時に、無線デバイスが、ＬＴＥによりスケジュールされた期間内であると判定する（または、スケジュールされた継続時間がオンであると判定する）場合、無線デバイスは、ＤＲＸ再送信タイマを起動することを選択してもよく、そうでない場合、ＤＲＸ再送信タイマは起動されない。

無線デバイスＭＡＣはさらに、ＤＲＸサイクルの使用を停止し、かつ／または、すべての保留中のＳＲ（スケジューリング要求：Scheduling Requests）をキャンセルし、ＳＲがキャンセルされたことを上位層に知らせてもよい。あるいは、問題がＤＬ内にのみある可能性があるが、ＰＤＣＣＨがＬＴＥによりスケジュールされた期間および／またはオン継続時間まで監視されない場合、ＳＲが送信されてもよい。

別の実施形態では、無線デバイスＭＡＣは、ランダムアクセスプロシージャが進行中であれば中断し、ランダムアクセスプロシージャが中断されたことを上位層に知らせること、ランダムアクセス応答ウィンドウがアクティブであれば、中断すること、および／または、ＭＡＣ競合解決タイマが実行中であれば停止し、ランダムアクセスプロシージャが中断された可能性があることを上位層に知らせることを実行してもよい。

加えて、無線デバイスＭＡＣはさらに、スケジュールされた継続時間タイマが停止された可能性があることを上位層に指示して、ＵＬ送信をトリガできないことを上位層に知らせること、スケジュールされた継続時間タイマが再起動されうる時間を上位層に指示すること、ＨＡＲＱバッファをフラッシュすること、あるタイマが維持される場合、スケジュールされていない継続時間タイマを起動すること、いかなるＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）を送信することも停止すること、および／または、いかなる再送信を送信することも停止することを実行してもよい。

一実施形態では、スケジュールされた継続時間タイマが起動されるときに、または、ＬＴＥによりスケジュールされたＴＴＩが進行中であるときに、無線デバイスは、ＤＲＸ−ＭＡＣ−ＣＥコマンドを受信したかのようにＤＲＸを使用し始めるか、または、最後のＤＲＸサイクルを再開してもよい。無線デバイスＭＡＣは、スケジュールされた継続時間タイマが実行中であることを上位層に指示して、ＵＬデータ送信をトリガしてもよいことを上位層に知らせてもよい。無線デバイスＭＡＣはまた、その間にスケジューリング継続時間タイマがアクティブであることができるサブフレームの数、すなわち、タイマが満了する前のサブフレームの数を含んでもよい。

スケジュールされた継続時間を再度開始できるようになると、ＤＲＸ再送信タイマは、停止される前の最後の値を使用して起動されてもよい。あるいは、このタイマは、停止されるときにリセットされ、ＬＴＥによりスケジュールされる開始時に再起動されてもよい。あるいは、ＤＲＸ再送信タイマは、ＬＴＥによりスケジュールされた継続時間がオンであるとき、再度起動されないことがある。

別の実施形態では、スケジュールされた継続時間が再度開始すると、非アクティビティタイマは、停止される前の最後の値を使用して起動されてもよい。あるいは、このタイマは、停止されるときにリセットされ、ＬＴＥによりスケジュールされた継続時間の開始時に再起動されてもよい。あるいは、非アクティビティタイマは、ＬＴＥによりスケジュールされた継続時間がオンであるときに、再度起動されないことがある。

他のＤＲＸ動作もまた、ＲＡＴの共存を可能にするために、本明細書で説明するように使用することができる。例えば、別の実施形態では、無線デバイス内のＤＲＸルールおよび監視基準は、修正されないままであってもよい。無線デバイスは次いで、他の技術が送信中であるかどうかにかかわらず（例えば、ＬＴＥによりスケジュールされた／スケジュールされていないパターンにかかわらず）、アクティブ時間ルールに従ってウェイクアップして、ＰＤＣＣＨを監視してもよい。そのような実施形態はまた、無線デバイスがＤＲＸと共に構成されないことがある場合にも、適用可能になる。

調整を行い、干渉および衝突が起こることのないように保証するための負荷は、一実施形態では、ｅＮＢ側に移されてもよい。より具体的には、無線デバイスに、（例えば、３１０で）ＤＲＸパラメータ、および、加えて、ＬＴＥによりスケジュールされた／スケジュールされていないパターンが提供されてもよい。これらのパターンのサイクルは、ＤＲＸサイクルと整合されてもよく、あるいは、新しいサイクルおよびオフセットが無線デバイスに提供されてもよく、または、ＤＲＸサイクルの機能であってもよい。本明細書で説明するパターンは、他の技術へ提供されてもよく、次に調整のためにそれ自体のネットワークへ中継されてもよい。デバイスは、このパターンに基づいて、次いで、構成された、ＬＴＥによりスケジュールされていない期間（または、サブフレーム）、サイクルおよびオフセットに基づいて、送信または受信できる時間を判定してもよい。ＬＴＥによりスケジュールされた期間中に、ネットワークは、無線デバイスをＵＬおよびＤＬの両方で自由にスケジュールする。

本明細書で説明する実施形態のいずれかによって、このパターンを無線デバイスに提供することができるｅＮＢは、ＬＴＥによりスケジュールされていない期間中に無線デバイスをスケジュールしないことがある。しかし、ｅＮＢはなお、送信が無線デバイス側で干渉されうるという認識の下で、無線デバイスをスケジュールしてもよい。このことは、無線デバイスがなお、ＤＲＸルールに従って、または、ＤＲＸが構成されないことがある場合は連続的に、ＬＴＥによりスケジュールされていない期間中にＰＤＣＣＨを監視してもよいことを暗示する。

ネットワークがこの期間中に送信することを選択する場合、この期間中の送信の信頼性を増大させるために、ｅＮＢは、ＭＣＳ、ＲＶおよび電力などを変更してもよい。どのように送信を修正するかについての選択は、ＣＱＩ報告に基づいてもよい。例えば、無線デバイス内のチャネル状態を正確に見るために、無線デバイスは、ＬＴＥによりスケジュールされた期間中にＣＱＩを報告して、干渉されていない期間内、および、ＬＴＥによりスケジュールされていない期間中のチャネル状態を指示してもよい。無線デバイスは、スケジュールされた／またはスケジュールされていない期間の開始後、ｎ個のサブフレームごとにＣＱＩをトリガしてもよく、あるいは、周期的ＣＱＩがトリガされてもよい。周期的ＣＱＩは、無線デバイスのスケジュールされた期間中にＣＱＩを搬送してもよく、非周期的ＣＱＩは、スケジュールされていない期間中に測定されたＣＱＩを搬送してもよい。スケジュールされていない期間中に報告されたＣＱＩはまた、周期的に、または、ｅＮＢによる特定の要求時にのみ、提供されてもよい。

そのような方式では、ＵＬ−ＬＴＥが、ある技術に関する問題を引き起こしている方向である場合に、ＧＰＳの一例では、無線デバイスは、ＬＴＥによりスケジュールされた期間中にのみＰＵＣＣＨを送信することが可能になる。ＰＵＣＣＨの特性を考慮すると、他の技術に対して生じた干渉は、著しくない場合がある。したがって、ネットワークは、ＤＬ送信を連続的にスケジュールしてもよく、無線デバイスは、スケジュールされていないＬＴＥの間にＰＵＣＣＨフィードバックを提供してもよく、かつ、スケジュールされたＬＴＥの間に、無線デバイスは、ＰＵＣＣＨフィードバックを提供し続けてもよく、ネットワークはまた、ＰＵＳＣＨ上でＵＬ送信をスケジュールしてもよい。スケジュールされていない期間中に、無線デバイスは、ＰＵＳＣＨまたはＰＵＣＣＨ上でＵＬデータを送信することが許可されないことがある。より具体的には、ネットワークがＤＬ送信をスケジュールし、対応するＡＣＫ／ＮＡＣＫフィードバックがスケジュールされていない期間に入る場合であっても、ＷＴＲＵは、ＰＵＣＣＨ−ＡＣＫ／ＮＡＣＫを送信しないことがある。さらに、同じことは、ＵＬ−ＰＵＳＣＨ送信に対して適用可能である。ＳＲが、スケジュールされていない期間（ＴＴＩまたはサブフレーム）中にトリガされる場合、無線デバイスは、次に使用可能なＰＵＣＣＨリソース、および、次に使用可能な許可されたサブフレーム（例えば、スケジュールされた期間）まで、ＳＲを送信しないことがある。同じことは、ＲＡＣＨ送信に適用可能である。加えて、スケジュールされていない期間中のＵＥの動きは、個々に、または、任意の組み合わせで使用された、上記で説明した実施形態のいずれかに従ってもよい。

動的な二重ＤＲＸ方式もまた、ＲＡＴの共存を可能にするために、本明細書で説明するように使用することができる。例えば、一実施形態では、複数の技術のうちいずれか１つがデータを送信または受信するための十分な機会を許可にするために、動的な二重ＤＲＸ方式または二重のスケジュールされた／スケジュールされていない方式が使用されてもよい。より具体的には、無線デバイスは、２つのＤＲＸタイマ、または、２つのスケジュールされた／スケジュールされていないタイマと共に、構成されてもよい。サイクルは同じでありうるが、オン継続時間のような継続時間（非アクティビティタイマ、再送信タイマ）、または、スケジュールされたもの／スケジュールされていないものの間の比は、変わることがある。無線デバイスは、サイクルごとにタイマを変更または交互にしてもよい。あるいは、１つの完全サイクル内で２つのパターンが指定される。無線デバイスは、オン継続時間およびオフ継続時間（off duration）を提供するパターン１で開始してもよく、次いで、異なるオンおよびオフ継続時間からなることがあるパターン２へと移ってもよい。

無線デバイスとネットワークの間の同期の欠如を回避するために、２つのサイクルの合計であってもよい完全なメインサイクルは、第１のパターンが開始されるシステムフレーム番号（ＳＦＮ）を判定してもよい。各メインサイクル内で、ネットワークによって構成される、異なるタイマを有する２つのサイクル、または、２つのパターンが行われてもよい。あるいは、Ｎ個のサイクルごとに、無線デバイスは、第２のパターンを使用して、Ｍ個のサイクルのためのアクティブ期間を判定し、次いで、パターン１へ戻ってもよい。

高速パターン切り替えおよび動的調整もまた、ＲＡＴの共存を可能にするために、本明細書で説明するように使用することができる。例えば、そのような解決策のセットでは、パターンの変更を動的にトリガし、シグナリングするための方法が、（例えば、３１２で）行われてもよい。より具体的には、無線デバイスが、高速／動的な変化するトラフィックパターンおよび動作のモードに適合できるようにするための方法が採用され、以下で説明される。

以前に論じたように、無線デバイスは、同じデバイス内の所与の技術のために可能にされたパターンのセットと共に構成されてもよい。あるいは、サービスまたは使用シナリオパターンの有限のセットが定義され、そこから、ネットワークおよび／または無線デバイスがそれと共に動作してもよい。

加えて、他の技術が最初にアクティブ化されるとき、または、無線デバイスが、２つの干渉技術の共存、もしくは、デバイス内干渉状況の検出、および、随意に示唆されたパターンを含むものを、ネットワークに報告するときに、ネットワークは、無線デバイスに１つのパターン（あるいは、可能にされたパターンのセット、および、随意に、現在使用中でありうるものへのインデックス）（例えば、３１０で受信される）を提供してもよい。無線デバイスは、その構成を受信すると、そのパターンを使用して開始してもよく、あるいは、（例えば、３１２で）このパターンを使用してすぐに開始するように、または、追加のトリガが満たされることを待機するように、ＷＴＲＵを構成するための明示的インジケーションが、ネットワークによって提供される。この解決策は、ネットワークがそのパターンを構成するが、他の技術がまだアクティブ化されていない場合、有益でありうる。

そのような実施形態では、無線デバイスは、干渉技術または被干渉技術のステータスを、ネットワークに動的に報告することが可能になる。より具体的には、無線デバイスは、以下の条件のうち１つまたは複数が満たされるときに、ネットワークへのインジケーションをトリガしてもよく、すなわち、他の技術がアクティブ化されており、送信もしくは受信の準備ができていること、他の技術が非アクティブ化されていること、他の技術がスリープモードもしくは省電力モードに入っていること、他の技術がスリープモードもしくは省電力モードから出ていること、現在のアプリケーションもしくはサービスが非アクティブ化もしくは終了されていること、新しいアプリケーションもしくはサービスがユーザによって開始されていること、新しい、より高優先度のアプリケーションもしくはサービスが起動されていること、使用シナリオの変更が検出されていること、トラフィック量の変化が検出されていること（例えば、例では、バッファされたデータの量が閾値を超えるか、もしくは、閾値未満になる場合、報告がトリガされうる）、および／または、干渉状況を指示する、ネットワークへの報告をトリガするための、本書の全体を通して説明する条件のいずれかである。

インジケーションをトリガすると、無線デバイスは、Ｌ２シグナリングを使用して、ステータスの変化をネットワークに指示してもよい。ＭＡＣ−ＣＥまたはＲＲＣメッセージが使用されてもよく、ただし、このメッセージは、他の技術のステータスを指示すること、アクティブ（非スリープモード）もしくは非アクティブ化（スリープモード）されること、他の技術のタイプ、サービスもしくは使用シナリオへのインデックス、示唆された、事前定義されたパターンへのインデックス、および／または、バッファステータス閾値もしくはカテゴリへのインデックスのうち１つまたは複数をシグナリングしてもよい。この報告は、以前の実施形態で説明したような追加の情報を含んでもよいこともまた理解されよう。

このインジケーションを受信すると、ネットワークは、構成されたパターンの使用をアクティブ化または非アクティブ化してもよい。アクティブ化／非アクティブ化指令は、Ｌ２またはＭＡＣ−ＣＥシグナリングまたはＬ１−ＰＤＣＣＨシグナリングまたはＲＲＣシグナリングを介して実行されてもよい。メッセージは、構成されたパターンの簡単なアクティブ化／非アクティブ化、または、使用を開始するべきインデックスもしくは明示的パターン、および、随意に時間基準をシグナリングすることによる、パターンの変更を含んでもよい。時間基準は、本書で説明するすべての解決策に含まれて、ＷＴＲＵおよびネットワークが共に同期されるようにしてもよいこともまた理解されよう。この時間基準は、以下の１つまたは組み合わせに対応してもよく、すなわち、ＳＦＮ、サブフレームオフセット、フレームまたはサブフレームの単位であればサイクル長、絶対時間、フレームインデックスであり、パターンは、以下が真であるフレームごとに開始され、すなわち、ＳＦＮ ｍｏｄサイクル長＝フレームインデックスである。サブフレームオフセットもまた、提供されてもよい。

本明細書で説明する動的な方法の使用により、ネットワークは、無線デバイス内の構成を除去する必要はないが、いつパターンがアクティブ化または非アクティブ化されうるかを動的に制御してもよい。あるいは、ネットワークは、新しいパターン、および、そのパターンのアクティブ化時間または時間基準をシグナリングすることによって、ネットワークによって使用されうるパターンを変更してもよい。

一例では、ＲＡＴデバイスが、ＷｉＦｉデバイス、または、スリープモードに入る任意のデバイスである場合、ＷＴＲＵは、このことをネットワークに指示してもよく、ネットワークは、パターンの使用を非アクティブ化するか、あるいは、ビーコン受信のために、無線デバイスがスリープモードで動作できるようにするか、もしくは、局がデータについてポーリングできるようにするための、パターンを提供してもよく、このパターンは、３１０で受信され、３１２で処理されてもよい。無線デバイスがウェイクアップするとき、無線デバイスは、ネットワークに通知してもよく、ネットワークは、無線デバイスに対し、他の技術のためにより多くの送信機会を提供する別のパターンの使用を開始するように指示してもよい。

別の実施形態では、無線デバイスは、他の技術におけるデータの送信を可能にするために、ＬＴＥにおいて自由時間の短いバーストを動的に要求してもよい。例えば、他の技術がスリープモードであり、ＡＰがこの無線デバイスのためのデータをバッファしていると判定するシナリオでは、無線デバイスは、ｘ個のＴＴＩにわたって送信しないようにＬＴＥに要求して、バッファされたデータを受信できることを保証してもよい。このことは、ＵＬスケジューリングのないｘ個のＴＴＩを要求するインジケーション、または、ＬＴＥ−ＷＴＲＵがそれらの期間中に送信していないというインジケーションを、ネットワークに送信することによって達成されてもよい。ｘ個のＴＴＩが終了すると、ネットワークは、ＵＬ内でデバイスのスケジューリングを開始してもよい。同じことは、ＤＬに対して適用可能である。他のデバイスが、データを送信しなければならないと判定する場合、無線デバイスは、Ｘ個のＴＴＩにわたってＷＴＲＵをスケジュールしないように、ネットワークにシグナリングしてもよい。ＴＴＩの数は、インジケーションの一部として含まれてもよい。この要求は、ＭＡＣ−ＣＥを使用することによって、または、上位層シグナリングによって行われてもよい。無線デバイスがＭＡＣ−ＣＥを使用して要求する、スケジュールされていないＴＴＩの数は、動的、最大値まで、または、固定数であってもよい。短い期間のスケジュールされていない時間を求める要求もまた、所定または構成されたパターンのセットの一部であってもよく、それに対して、無線デバイスは、インデックスを用いて参照してもよい。

ユーザがアクセスポイントまたはネットワーク側に、情報についてポーリングする技術では、アクセスポイントに、許可された送信パターンが提供され、ポーリングの結果としてデータが局へ送信されなければならない場合、アクセスポイントは許可された機会中に送信し、したがって、データを損失する可能性を低減するようにしてもよい。加えて、パターン、および、これらのパターンの動的な制御が、スケジュールされた／スケジュールされていない期間／サブフレーム、ＤＲＸ／ＤＴＸパターン、および半永続的なスケジューリングパターンなどの、任意のＩＣＯ固有のパターンを参照することは理解されよう。

そのような高速パターン切り替え方式では、ＷＴＲＵ内のＩＳＭは、あるＩＳＭトラフィックがトリガされたと判定すると、即時にＩＳＭトラフィックを送信し始めてもよい。これにより、要求を送信するように、ＬＴＥをトリガしてもよい。あるいは、このインジケーションは、以前の実施形態で論じたように、先行的な方法で（例えば、干渉が発生する前に）送信されてもよい。ＷＴＲＵがＵＬグラントを有する場合、ＷＴＲＵは、最初の識別された機会において、ＭＡＣ−ＣＥを使用して、短いスケジュールされていないＴＴＩ要求をネットワークへシグナリングしてもよい。あるいは、リソースを求める要求もまた、ＰＵＣＣＨ内でＳＲを使用して送信されてもよい。

あるいは、無線デバイスがグラントを有していない場合、（例えば、３０８で）メッセージがネットワークへ送信されないことがある。しかし、最初のＵＬグラントを受信すると、ＩＳＭ送信／受信がなお進行中である場合に、無線デバイスは、このグラントを使用して、短いスケジュールされていないＴＴＩ報告をネットワークへ送信してもよい。

あるいは、無線デバイス内のＬＴＥは、ＩＳＭ（または、他のＲＡＴ）が送信を開始する前でさえ、パターンをネットワークへシグナリングしてもよい。ネットワークは、要求を確認応答すること、または、ＷＴＲＵがこのトリガの結果としてスケジュールされないことがあるＴＴＩの正確な量を指示する応答を提供することによって、無線デバイスに対して要求を認可してもよい。無線デバイスが確認応答またはパターンを受信すると、ＩＳＭは、認可されたサブフレーム内で、または、そのパターンに従って、その送信を開始してもよい。

ＲＡＴの共存を可能にするために有用なＴＤＭ動作を可能にするための実施形態の例もまた、本明細書で説明するように（個々に、または、組み合わせて）使用することができる。より具体的には、ＴＤＭ動作を可能にする、独立した方法をすべて組み合わせて使用して、デバイスが異なる使用シナリオのためのそのサービス要件を満たすことができるようにしてもよい。一例では、このことは、無線デバイスが、通知報告において特定のＬＴＥによりスケジュールされた、および／または、ＬＴＥによりスケジュールされていないサブフレームのパターンを要求または示唆することによって、達成することができる。以前に説明したように、ＬＴＥによりスケジュールされたサブフレームは、ＬＴＥスケジューリングのために使用または予約されたサブフレームを指すことがあり、ＬＴＥによりスケジュールされていないサブフレームは、他の技術をスケジュールするために使用されるべきサブフレームを指すことがある。

パターンは、以下の形式の１つまたは組み合わせを取ってもよく、すなわち、所与の周期性もしくはサイクルを有するビットマップ、サイクルおよび／もしくはサブフレームオフセットであって、ビットマップは、ある技術（例えば、ＬＴＥ）のために予約されるべきであるかもしくはＬＴＥ技術によって使用されるべきである、特定の示唆されたサブフレーム、もしくは、干渉状況が起こるかもしくは起こらない（例えば、パターンがあらかじめ知られている場合）サブフレームを含みうるものと、サイクル内のいくつかの連続的なＬＴＥによりスケジュールされたサブフレーム（あるいは、スケジュールされていないサブフレーム）、サイクルおよび／もしくはサブフレームオフセットと、サイクル内のＬＴＥによりスケジュールされたサブフレームの時間の継続時間、サイクルおよび／もしくはサブフレームオフセットと、ならびに／または、無線による１回の短いスケジュールされていない要求のためのいくつかのＴＴＩ（例えば、無線がネットワークに、いくつかの連続的なＴＴＩにわたって無線デバイスをスケジュールしないように要求している場合）とである。これは、別個の要求を用いて、または、上記と同じ要求を用いて指示されてもよいが、サイクル値は、無限大に、または、特殊な値に設定される）。

別の例では、事前定義されたパターンのセットへのインデックスが、ネットワークへシグナリングされてもよく、サブフレームオフセットはシグナリングされる。事前定義されたパターンのセットは、ビットマップ内でスケジュールされた／スケジュールされていないパターンを含む、少なくとも１つのビットマップなど、上記で説明したようなすべての可能なパターンを含んでもよい。これらのパターンはまた、連続的なスケジュールされたサブフレームおよび連続的なスケジュールされていないサブフレームを含む、少なくとも１つのビットマップをも含んでもよい。これらのパターンの周期性は、より長いことがあり、したがって、スペースを節約するために、パターンは、サイクル内の連続的なスケジュールされたサブフレームの数を含んでもよい。サイクル内の残りのサブフレームは、スケジュールされていないサブフレームであると見なされる。パターンはまた、無線デバイスが１回の動作を求めて要求中でありうる、１回のスケジュールされていないサブフレームの数を含む、少なくとも１つのエントリをも含んでもよい。

要求されたパターンに応答して、無線デバイスは、同じパターン、新しいパターン、または、ＷＴＲＵに対し、要求されたパターンを使用できることを指示するインジケーション（例えば、１ビット）のみを含む、構成を受信してもよい。

無線デバイスは、（例えば、３１２で）ビットマップ、周期性（または、サイクル）およびタイミングオフセットに従って、構成されたパターンの適用を開始してもよい。ＬＴＥによりスケジュールされたサブフレーム中に、無線デバイスは、レガシーＬＴＥプロシージャに従って動作してもよい。ＬＴＥによりスケジュールされていないサブフレーム中に、無線デバイスは、以下の１つまたは組み合わせを実行してもよい。ＷＴＲＵは、ＰＤＣＣＨを監視しないことがある。あるいは、ＰＤＣＣＨはなお、ＤＲＸプロシージャに従って監視される。ＰＤＣＣＨがＤＬデータをスケジュールする場合、無線デバイスは、ＰＤＳＣＨをデコードしないことがある。あるいは、ＰＤＳＣＨはなおデコードされる。ＡＣＫ／ＮＡＣＫフィードバックタイミングが、スケジュールされていないサブフレームとオーバーラップする場合、ＷＴＲＵは、ＰＵＣＣＨを送信しないことがある。ＰＤＣＣＨがＵＬデータをスケジュールする場合、無線デバイスは、構成された、スケジュールされていないサブフレームに対応する場合、ＵＬ−ＰＵＳＣＨ送信を実行しないことがある。

無線デバイスはまた、いかなるＵＬ送信をも実行しないことがある。例えば、ＵＬ再送信（例えば、非適応）が、スケジュールされていないサブフレームに対応する場合、ＷＴＲＵは、データをＨＡＲＱバッファ内に保持してもよい。ＨＡＲＱ ＲＴＴごとに、無線デバイスがスケジュールされていないサブフレームのためにデータを送信できないたびに、再送信カウンタが増加されてもよい。

ＳＲがトリガされる場合、無線デバイスは、実行しないことがあり、ＰＵＣＣＨ送信は、ＰＵＣＣＨリソースを有する、次に使用可能なスケジュールされたサブフレームまで、送信されないことがある。加えて、ＳＲＳがトリガされる場合、無線デバイスは、次のトリガリングを待機してもよく、または、次に使用可能なスケジュールされたサブフレーム内でＳＲＳを送信してもよい。

ＲＡＣＨプリアンブルが送信される必要がある場合、無線デバイスは、ＲＡＣＨ構成インデックスに従って、次に使用可能なスケジュールされたサブフレーム、および、可能にされたＲＡＣＨサブフレームを待機してもよい。

周期的ＣＳＩがトリガされる場合、無線デバイスは、ＣＳＩを送信しないことがある。加えて、非周期的要求が無線デバイスによって受信されることがあり、かつ、ＵＬ−ＣＳＩ報告時間送信がスケジュールされていないサブフレームに対応する場合、無線デバイスは、ＣＳＩ報告を送信しないことがある。

さらに別の実施形態では、ＵＬ内の干渉を低減するための方法が実行されて、本明細書で説明するようにＲＡＴの共存を可能にしてもよい。例えば、ＬＴＥおよび被干渉側の技術は、時間多重化方法を介して、共に共存することができる。より具体的には、被干渉側の技術への干渉は、ＷＴＲＵ内のＵＬ−ＤＴＸ、または、低減されたアップリンク送信モードを用いて、最小化または制御されてもよい。

この方法の一部として、共存する技術の受信器への干渉を最小化し、同時に無線デバイスがＬＴＥによるその送信を続けることを可能にする、新しいＵＬ送信モードが導入されてもよい。同様の方法をまた、ＬＴＥ受信器への干渉を回避するために、他の技術に対して使用することもできることは理解されよう。

加えて、ＵＬ−ＬＴＥは、図１３に示すように、２つの状態、通常ＵＬモードおよび低減されたＵＬモードで動作してもよい。通常ＵＬモードまたは状態（以下で、互換的に使用される）は、ＬＴＥ−ＵＬが標準／レガシーＵＬおよびＤＬ−ＬＴＥ受信プロシージャを実行することを指すものであり、限定されないが、周期的ＣＱＩ報告、ＤＬトラフィックに対する標準レイテンシ要件を満たすＡＣＫ／ＮＡＣＫ報告、および、標準スケジューリング要求など、通常ＰＵＣＣＨ送信、ならびに、ネットワークによる送信およびスケジュールされたリソースの必要性による、ＰＵＳＣＨ送信などである。

無線デバイスは、共存する技術の受信器がアクティブである可能性があり、かつ、ＬＴＥ−ＵＬ送信がその受信器への干渉を引き起こしている可能性があるとき、低減されたＵＬモードであってもよい。いくつかのトリガによって、２つの動作のモード間で移行するためのトリガを、本明細書で説明する。低減されたＵＬ動作のモードは、無線デバイスが連続的に送信中でないことがある、動作のモードを指す。ＵＬ送信への修正には、ＰＵＳＣＨ送信パターンおよびＰＵＣＣＨ送信パターンが含まれる。この動作のモードに関連付けられたいくつかのプロシージャを、以下で説明する。動作の一例を、図１３に示し、説明することができる。

低減されたＵＬ送信モードは、ＵＬ送信を特定の時間またはＳＦＮおよび／またはサブフレームでのみ実行していることがある無線デバイスを含んでもよい。ＷＴＲＵがＵＬバースト送信を実行することができる期間は、ネットワークにより構成されたパターンに従って判定されてもよく、ただし、ネットワークは、ＤＴＸサイクルごとに、サイクル期間およびバースト期間（例えば、無線デバイスがＵＬ内で送信することを可能にする、いくつかの連続的なＴＴＩ）を含む。あるいは、ＵＬ送信パターンおよび時間は、ＷＴＲＵによって自律的に判定されてもよい。

本明細書で説明するパターンは、ＰＵＳＣＨ送信またはＰＵＣＣＨ送信のために使用されてもよい。

ＰＵＳＣＨ送信では、無線デバイスは、アップリンク共用チャネル（ＵＬ−ＳＣＨ）またはＰＵＳＣＨを、事前定義されたパターン（以下で、ＵＬ−ＤＴＸパターンと呼ばれる）、または、ネットワークが無線デバイスに提供している期間に従って、送信してもよい。ネットワークによって提供されたこの周期性は、以下の１つまたは組み合わせからなるものであってもよい。周期性は、サイクルおよびバースト期間などを含みうる、ＤＴＸパラメータから構成されてもよい。バースト期間中に、無線デバイスは、グラントと共に構成されてもよく（例えば、割り振られたリソース、ＭＣＳ、およびＴＢ情報などを有する）、したがって、このグラントに従ってデータを送信してもよい。このグラントは、ＤＴＸサイクルに従って与えられたＳＦＮでただ１つのＴＴＩに対して適用可能であってもよく、または、バースト期間内でいくつかのサブフレームに対して適用可能であってもよい。グラントは、ＤＴＸパラメータの一部として無線デバイスに与えられてもよく、無線デバイスがバーストの継続時間にわたって使用することができるグラントであってもよい。ＢＳＲまたは電力ヘッドルーム報告（ＰＨＲ）によって、ネットワークが、無線デバイスがバッファを空にするためにさらなるグラントを必要とすると判定する場合、このグラントは変わってもよい。しかし、次回に無線デバイスがウェイクアップすることがあるときに、無線デバイスは、元のデフォルトのグラントまで戻ってもよい。あるいは、無線デバイスは、必ずしもグラントを有するとは限らない。ＤＴＸパラメータによるウェイクアップ期間で、無線デバイスは、ＳＲをＰＵＣＣＨ上で送信して、ＷＴＲＵがバースト期間中にバッファを空にすることを可能にする、正しい量のリソースを要求してもよい。

一実施形態では、ネットワークは、無線デバイスに、この動作のモードの継続時間にわたって使用されるべき半永続的グラントを提供してもよい。標準モードへ戻されるとき、無線デバイスは、半永続的グラントの使用を中止してもよい。グラントがバースト期間中に動的に変化する場合、無線デバイスは、次回にウェイクアップするとき、元の構成された半永続的グラントまでフォールバック（fall back）してもよい。

加えて、無線デバイスは、ｘ個のサブフレームまたはバースト期間にわたって、ＤＴＸサイクルごとにウェイクアップしてもよく、その時間中に、半永続的グラントに従って送信することができる。

半永続的グラントまたはＤＴＸグラントは、ウェイクアップ期間内のいくつかのサブフレームにわたって、無線デバイスに提供されてもよい。より具体的には、無線デバイスが、ＤＴＸサイクルによるＳＦＮでウェイクアップするとき、無線デバイスは、事前定義されたルールによるいくつかのサブフレーム内、または、いくつかの構成されたサブフレーム中に、許可されたまたは割り振られたリソースを使用してもよい。

上記で説明した解決策の両方について、半永続的グラントおよびＤＴＸサイクルは、あるアプリケーションのために、ＱｏＳ要件をなお満たしながら、データがＵＬ内で送信されるように、十分に長いものであってもよい。しかし、無線デバイスは、異なる要件と共に構成された数個の論理チャネルを有してもよい。干渉をなお最小化し、データの適時の送信を可能にするために、二重のＤＲＸまたは半永続的グラントが可能になってもよい。例えば、より短いＤＴＸサイクルまたは半永続的グラントサイクルが、遅延の影響を受けやすいかまたはより緊急のデータに対して構成されてもよく、より長いＤＴＸサイクルまたは半永続的グラントサイクルが、より大きい帯域幅を必要とすることがある、より遅延耐性のある論理チャネルに対して構成されてもよい。あるいは、そのような論理チャネルがそれらのバッファ内でデータを受信する場合、無線デバイスは、通常の送信モードへ戻ってもよい。

あるいは、無線デバイスは、（例えば、３１２で）緊急呼び出し、または、ステータス報告の配信など、高優先度のプロシージャが実行される必要があると判定する場合、ＤＴＸ期間の間で自律的にウェイクアップしてもよい。長いＤＴＸサイクルは、ＲＬＣステータス報告の配信を遅延させることがある。報告の配信に関連付けられた遅延を低減するために、ＷＴＲＵは、ＤＴＸサイクルにかかわらず、ＵＬ送信を実行してもよい。ＷＴＲＵは、ウェイクアップして、ＳＲを送信し、このデータの送信のためのグラントを受信してもよい。

別の実施形態では、ＵＬ−ＳＣＨのタイミングは、無線デバイスによって自律的に制御されてもよい。より具体的には、ＬＴＥと被干渉側の受信器の間のインタラクションは、無線デバイスがＵＬ送信を開始するための最良の時間を判定することを可能にする。この判定は、他の技術の受信アクティビティによって決まってもよい（例えば、アイドル期間が検出される場合、無線デバイスが起動してもよい）。この判定は、ＵＬ内で送信されているＬＴＥ論理チャネルまたはアプリケーションによって可能にされた最大の遅延によって決まってもよい。この判定は、上記の２つの黒丸の関数によって決まってもよい。

より具体的には、無線デバイスが、データを送信できると判定する場合、無線デバイスは、ＳＲを送信して、送信することを望むことをネットワークに指示してもよい。無線デバイスがこのデータを送信するための時間が限定されている可能性があるという事実を考えると、干渉時間を最小化するために、ネットワークがより多くのリソースをこの無線デバイスに割り振り、無線デバイスが最小の時間量でそのバッファを空にするか、または送信できるようにした場合、有益でありうる。ネットワークは、上記で説明したように、無線デバイスが低減されたＵＬモードであることを知ることによって、この状況を認識してもよい。このモードでＳＲが受信されるときに、ネットワークは、無線デバイスをスケジュールするとき、このことを考慮に入れる。あるいは、無線デバイスは、ＳＲ内で干渉状況を指示してもよい。より具体的には、ＳＲは、無線デバイスが、別の共存する技術上の受信器がＵＬから干渉されていると判定しているときに設定される、通知またはビットを含むように修正されてもよい。これには、スケジューリング要求のフォーマットへの修正、または、ビットの再解釈が必要となることがある。

ＤＴＸサイクル中、または、低減されたＵＬモード中に、無線デバイスは、受信されたＵＬグラントを無視してもよい。あるいは、半永続的グラントの変化がＰＤＣＣＨ内で検出される場合、ＷＴＲＵは、グラント値を変更し、ウェイクアップ時間でのみ使用してもよい。

ＰＵＣＣＨ送信では、ＬＴＥアップリンク送信はまた、ＤＬトラフィックのためのＡＣＫ／ＮＡＣＫフィードバック、チャネル品質インジケーション（ＣＱＩ）、および、スケジューリング要求を含む、ＰＵＣＣＨをも含んでもよい。共存する技術への干渉を最小に保つために、低減されたＵＬ状態はまた、低減されたＰＵＣＣＨ動作のモードから構成されてもよい。低減されたＰＵＣＣＨは性能を高めることができるが、無線デバイスは、ＵＬ送信の時間を低減しながら、標準ＰＵＣＣＨ送信を継続してもよい。

低減ＰＵＣＣＨ送信を可能にするために、ＷＴＲＵが低減されたＵＬモードである間、ＨＡＲＱ−ＡＣＫ／ＮＡＣＫフィードバックは提供されなくてもよい。この時間中に、ｅＮｏｄｅＢは、自律的なＨＡＲＱ再送信を行ってもよく、ＷＴＲＵは、ＤＬデータをデコードしてもよく、いかなるＨＡＲＱ−ＡＣＫ／ＮＡＣＫをも送信しない。

ＰＵＣＣＨを送信する必要性をさらに低減するために、ＣＱＩ報告の数が限定されてもよい。より具体的には、ＣＱＩ報告周期性は、ＵＬ−ＤＴＸパターンの周期性に、または、半永続的グラントの周期性に変わってもよい。ＤＴＸパターンの一部として、バースト送信が数個のＴＴＩで続く場合、無線デバイスは、ＣＱＩ報告をより頻繁に送信してもよい。

最後に、スケジューリング要求は、ＤＴＸパターンのうち１つに従ってトリガされるように限定されてもよい。しかし、いくつかのトリガが満たされ、かつ、上記で説明したようにＳＲが送信される必要がある場合、ＷＴＲＵはなお、ＰＵＣＣＨを送信してもよい。

あるいは、ＳＲがトリガされると、無線デバイスは、タイマが満了すること（例えば、ＷＴＲＵがＳＲを保つことができる最大時間）、および、ウェイクアップ期間のいずれかを待機してもよい。

加えて、別の実施形態では、ＰＵＣＣＨはなお、通常モードトリガに従って送信されてもよい。しかし、ＰＵＣＣＨが引き起こす可能性のある潜在的な干渉を低減するために、ＰＵＣＣＨは、１つの周波数のみで送信されてもよい。現在、ＰＵＣＣＨは、ネットワークによって提供されたインデックスによる周波数ホッピングを使用して、送信されてもよい。

ＰＵＣＣＨは、２つの周波数上でＵＬ帯域幅の端で主に送信される、狭帯域信号（１ＲＢ）であってもよい。したがって、これらの周波数が、干渉を引き起こす周波数の１つに対応する場合、干渉を低減するために、ＷＴＲＵは、その周波数への周波数ホッピングを実行しない。次いで、ＰＵＣＣＨの第２のスロットが、次の機会に、同じ非干渉の端で送信されてもよい。このことは、以下の１つまたは組み合わせによって達成されてもよい。ネットワークは、ＷＴＲＵに、それによってＰＵＣＣＨを送信するただ１つの周波数割り振りを与えてもよい。

加えて、無線デバイスは、ネットワークによって指示された２つの周波数上で周波数ホッピングを実行することを自律的に停止し、干渉を引き起こさない可能性がある周波数上でのみ送信してもよい。ネットワークは、この暗示的な動きが、状態送信時に実行されることを知ってもよい。あるいは、ネットワークは、無線デバイスを、ＰＵＣＣＨを送信するために２つの非干渉周波数と共に構成してもよい。

実施形態の一例では、無線デバイスは、そのＰＵＣＣＨを単一の非干渉領域上で送信することを可能にしてもよい。しかし、同じリソースを使用する他の無線デバイスとの衝突、および、それらへの干渉を回避するために、ネットワークは、これらの無線デバイスに対して符号分割多重化を使用してもよい。無線デバイスのために必要とされた情報は、ネットワークによって明示的に提供されてもよい。ＳＲＳ送信もまた、同じ狭帯域領域内で送信されてもよい。

無線デバイスは、それがＤＲＸパターンのスケジュールされていない期間にあることを検出する場合、ＳＲＳをネットワークへ自律的に送信せず、スケジュールされた期間を待機して、その周期的ＳＲＳ報告を再開してもよい。あるいは、このことは、ネットワークによって構成可能であってもよく、すなわち、ネットワークは、無線デバイスがスケジュールされていない期間中にＳＲＳを報告しないことを可能にする場合、無線デバイスに指示してもよい。あるいは、無線デバイスは自律的に、または、ネットワークは構成によって、スケジュールされた期間中の報告と比較して、スケジュールされていない期間中のＳＲＳ報告の周期性を低下させてもよい。このことは、非常に長いスケジュールされていない期間の場合、有用でありうる。

いつ２つの動作のモード間で移行すべきかを判定するために、無線デバイスは、そのようなモード間の移行をトリガするための以下の方法のうち１つまたは複数を使用してもよい。しかし、トリガ基準は、低減されたＵＬ−ＤＴＸモードに関して説明されるにもかかわらず、ＤＲＸなど、同様のＤＬ動作のモードに対して使用されてもよいことは理解されよう。

例えば、無線デバイスが通常ＵＬモードで動作中である間、被干渉側の受信器が有効にされるか、またはＤＬ受信を開始し、かつ、無線デバイスが、ＵＬ−ＬＴＥが他の技術の受信器に干渉中であるか、または干渉中であると判定するときに、ＷＴＲＵは、以下の１つまたは組み合わせを実行してもよい。無線デバイスは、低減されたＵＬ状態へ自律的に移ってもよい。低減されたＵＬ状態へ移った後、無線デバイスは、ＵＬ動作のモードにおける移行をネットワークに通知してもよい。あるいは、無線デバイスは、ネットワークに明示的に通知しないことがあるが、ネットワークは、無線デバイスの動きに基づいて、無線デバイスが低減されたＵＬモードで動作中であると、自律的に判定してもよい。あるいは、無線デバイスは、ネットワークからの明示的構成時にのみ、低減されたＵＬ状態へ移行する。より具体的には、無線デバイスは、被干渉側の受信器が、上記で説明したプロシージャのいずれかを使用して有効にされているか、または有効にされうることを、ネットワークに通知してもよい。ネットワークは次いで、無線デバイスに対し、低減されたＵＬ状態へ移るように明示的にシグナリングしてもよく、また、新しい構成パラメータをも提供してもよい。

低減されたＵＬモードになると、無線デバイスは、以下のトリガの１つまたは組み合わせによって、通常モードへ戻るように移行してもよい。無線デバイスは、ネットワークによって明示的に指示されると、戻るように移行してもよい。あるいは、または加えて、無線デバイスは、被干渉側の受信器または技術がある期間にわたって無効にされるか、または、アクティブでなかったとき、戻るように移行してもよい。この条件が満たされる場合、無線デバイスは、通常モード送信を開始し、次いで、通知をネットワークへ送信してもよい。あるいは、無線デバイスは、上記で説明したプロシージャに従って、デバイスがもはやアクティブでないという通知をネットワークへ送信し、明示的インジケーションを待機してもよい。

あるいは、または加えて、無線デバイスは、周波数間またはＲＡＴ間ハンドオーバが、もはや他の技術の受信器への干渉を引き起こさない周波数またはＲＡＴに対して実行されるときに、戻るように移行してもよい。無線デバイスはまた、高優先度サービス、論理チャネル、または、高優先度アクセスクラスサービス（緊急呼び出しなど）が開始されるとき、戻るように移行してもよい。

低減されたＵＬモード送信を開始することに先立って、無線デバイスによって満たされうる追加の条件は、ＬＴＥ技術側で進行中のアクティビティを含んでもよい。より具体的には、データ、または、それらのサービスのＱｏＳを含む、論理チャネルの優先度。例として、遅延の影響を受けやすいアプリケーションがアクティブである場合、ＷＴＲＵは、通常ＵＬモードのままであってもよい。無線デバイスはまた、この情報をネットワークに提供し（例えば、論理チャネルのバッファサイズ）、ネットワークがＤＴＸパターンを適切にスケジュールできるようにしてもよい。追加の条件にはまた、ＬＴＥと他の技術の間のアプリケーションの相対的優先度も含まれてもよい。例として、ＬＴＥアプリケーションがより高い優先度であると見なされる場合、ＬＴＥは、通常ＵＬモードのままであってもよく、そうでない場合、低減されたＵＬモードへ送信してもよい。

これらのセクションで説明したパターンは、送信および受信の時間を調整するために、他の技術に提供されてもよい。他の技術もまた、この情報をそのネットワークに提供し、他のネットワーク（例えば、送信側ノード）に、送信してはならない時間を知らせてもよい。

電力バックオフまたはスケーリング方式もまた、無線デバイス内でＲＡＴの共存を可能にするために、本明細書で説明するように使用することができる。例えば、送信がＲＡＴ間で調整されて、同時に起こる送信が保証または最小化される、時間領域解決策の代替で、送信が１つまたは複数のＲＡＴ上でスケールバックされて、いかなる一瞬の時間にも送信を完全にブロックすることなく、干渉のレベルが低減されてもよい。

１つのそのような方法は、無線デバイスが、代替ＲＡＴへの干渉を既知の閾値に維持する、ある周波数帯域に適用されうる電力の量を概算するためのものでありうる。送信が、共通または重複する周波数帯域内で実現されるとき、無線デバイスは、代替ＲＡＴ上で送信障害を最小化するか、または除去する、各ＲＡＴ上に適用されうる電力の量を判定してもよい。このことを達成するために、無線デバイスは、送信が同時に起こっている送信時間間隔においてＲＡＴ間で電力を分配する、ＩＣＯ機能を組み込んでもよい。

代替ＲＡＴへの干渉が閾値を上回って検出されうるとき、無線デバイスは、電力バックオフを適用し、進行中の送信における送信電力をスケーリング（scale）して、干渉が閾値未満で維持されるようにしてもよい。電力スケーリングは、ＨＡＲＱ再送信の数、および、残りのＨＡＲＱ誤り率を増大させる結果となりうることに留意されたい。

一実施形態では、無線デバイス電力スケーリングは、送信失敗の結果となりうる。したがって、ＵＬグラントが、低減された使用可能なＷＴＲＵ送信電力まで調節されることは、重要でありうる。ＵＬグラントのサイズを低減するために、ＵＥは、電力バックオフまたはスケーリング条件、および、潜在的に、特定の帯域上の電力低減のレベルを識別する、スケジューラへの明示的信号を生成してもよい。

電力スケーリングイベントを識別するために適用されうる、ＬＴＥ内の１つの方法は、既存のＭＡＣ−ＣＥ電力ヘッドルーム報告（ＰＨＲ）を利用することである。ＬＴＥ−Ｒ１０では、ＭＰＲまたはＰ−ＭＰＲによる電力バックオフの原因は、ＰＨＲ内で識別される（すなわち、どの係数がＰｃｍａｘ，ｃの計算を左右するか）。デバイス内干渉による電力バックオフまたはスケーリングを指示する、ＭＡＣ−ＰＨＲ−ＣＥ内の追加のフィールドまたはコードポイントが指定されてもよい。ＬＴＥ−Ｒｅｌｅａｓｅ１０（Ｒ１０）では、アクティブ化されたＳセルごとに、ＰＨＲは、電力ヘッドルーム（ＰＨ）を含み、実装固有の電力低減は、他のセルにおけるグラントのために電力低減を必要とした（Ｐｃａｍｘ，ｃ）。帯域またはコンポーネントキャリアごとに他のＲＡＴへの干渉を最小化するために必要とされた特定量の電力バックオフまたはスケーリングは、追加のパラメータとして、シグナリングされたＰＨおよびＰｃｍａｘ，ｃに追加されるか、または、アクティブ化されたＳセルごとにＰｃｍａｘ，ｃを計算する際に、追加の係数として使用されてもよい。

加えて、他のＲＡＴへの干渉を最小化するために必要とされた追加の電力バックオフまたはスケーリングの量もまた、周波数帯域またはコンポーネントキャリアのための他の電力バックオフまたはスケーリング係数に追加されてもよい。実際のバックオフまたはスケーリング係数がシグナリングされうる場合、無線デバイスは、電力スケーリングを引き起こすソースを識別してもしなくてもよい。特定のソースを識別することは、スケジューラが後続の送信時間間隔内の潜在的な電力バックオフまたはスケーリングを予測するために、有用でありうる。したがって、追加の電力バックオフが既存のバックオフまたはスケーリング係数に追加される場合、報告された電力バックオフの原因の指示を含むことは、なお有用でありうる。

ＬＴＥ−Ｒｅｌｅａｓｅ１０（Ｒ１０）では、無線デバイスは、送信されている信号に応じて、その最大出力電力を低減して、帯域外放出リミット（out of band emission limits）を超えることを回避することが許可されてもよい。無線デバイスは、その実装に基づいて、完全に許可された電力低減、または、より少ない値を使用してもよい。各サブフレームｉ内で、所与のコンポーネントキャリア（ＣＣ）について、無線デバイスは、ＬＴＥ構成およびグラントに基づいて、その必要とされた電力低減を判定してもよい。これは、ＭＰＲ_{ａｃｔｕａｌ，ｃ}（ｉ）と呼ばれることがあり、そのサブフレーム内で最大の可能にされた出力電力は、以下のようになる。
Ｐ_{ＣＭＡＸ，ｃ}（ｉ）＝ＭＩＮ｛Ρ_{ΕΜΑΧ，ｃ}，Ｐ_{ＰｏｗｅｒＣｌａｓｓ}−ＭＰＲ_{ａｃｔｕａｌ，ｃ}（ｉ）−ΔＴ_Ｃ，ｃ｝（式１）

ただし
Ρ_{ΕΜΑΧ，ｃ}は、（ＣＣについて）上位層によってシグナリングされた最大電力であってもよい。

Ｐ_{ＰｏｗｅｒＣｌａｓｓ}は、ＷＴＲＵのクラスのための最大ＷＴＲＵ出力電力であってもよい。

ＭＰＲ_{ａｃｔｕａｌ，ｃ}は、（ＣＣについて）最大の電力低減（ＭＰＲ）／追加のＭＰＲ（Ａ−ＭＰＲ）の影響のために、ＷＴＲＵが取った実際の電力低減であってもよい。

ΔＴ_Ｃ，ｃは、（ＣＣについて）送信帯域幅（ＢＷ）の関数である固定電力オフセットであってもよい。

加えて、ＬＴＥ−Ｒｅｌｅａｓｅ１０（Ｒ１０）、無線デバイスは、ＬＴＥスケジューラにとって未知の電力要件のため、電力管理のためにその最大出力を低減することが許可されてもよい。各サブフレームｉ内で、所与のコンポーネントキャリア（ＣＣ）について、無線デバイスは、ＬＴＥ構成およびグラントに基づいて、その必要とされた電力低減を判定してもよい。これは、Ｐ−ＭＰＲ_{ａｃｔｕａｌ，ｃ}（ｉ）と呼ばれることがあり、そのサブフレーム内で最大の許可された出力電力は、以下のようになる。
Ｐ_{ＣＭＡＸ，ｃ}（ｉ）＝ΜＩΝ｛Ρ_{ΕΜΑΧ，ｃ}，Ｐ_{ＰｏｗｅｒＣｌａｓｓ}−ＭＡＸ（ＭＰＲ_{ａｃｔｕａｌ，ｃ}（ｉ），Ｐ−ＭＰＲ_{ａｃｔｕａｌ，ｃ}（ｉ））−ΔＴ_Ｃ，ｃ（ｉ）｝（式２）

１つの可能性は、他のＲＡＴへの干渉を最小化することによる電力バックオフが、追加の項、例えば、ＲＡＴｂａｃｋｏｆｆ，ｃ（ｉ）でありうる、ということである場合があり、最大に許可された出力電力は、以下のようになる。
Ｐ_{ＣＭＡＸ，ｃ}（ｉ）＝ΜＩΝ｛Ρ_{ΕΜΑΧ，ｃ}，Ｐ_{ＰｏｗｅｒＣｌａｓｓ}−ＭＰＲ_{ａｃｔｕａｌ，ｃ}（ｉ）−Ｐ−ＭＰＲ_{ａｃｔｕａｌ，ｃ}，−ＲＡＴｂａｃｋｏｆｆ，ｃ（ｉ）−ΔＴ_Ｃ，ｃ｝（式３）

より高い可能性として、しかし、電力バックオフは、他のＲＡＴへの干渉を最小化するためのものであってもよく、ＭＰＲ低減に加えたものではなく、むしろＭＰＲ低減と並行したものであり、実際には、３つの低減のうちより大きいものが使用されうるようにしてもよい。そのような場合、最大出力電力は、以下のようになる。
Ｐ_{ＣＭＡＸ，ｃ}（ｉ）＝ΜＩΝ｛Ρ_{ΕΜΑΧ，ｃ}，Ｐ_{ＰｏｗｅｒＣｌａｓｓ}−ＭＡＸ（ＭＰＲ_{ａｃｔｕａｌ，ｃ}，Ｐ−ＭＰＲ_{ａｃｔｕａｌ，ｃ}，ＲＡＴｂａｃｋｏｆｆ，ｃ（ｉ））−ΔＴ_Ｃ，ｃ｝（式４）

適時なＰＨＲ情報をｅＮＢスケジューラに提供するために、様々な報告トリガが指定されてもよい。他のＲＡＴに影響を及ぼす干渉をあらかじめ予測することは困難であるため、他のＲＡＴに影響を及ぼす干渉を検出するとすぐにＰＨＲを提供するために、特定のトリガを提供することが必要であることがある。Ｒ１０におけるＰ−ＭＰＲトリガリングと同様に、このことを達成するための１つの方法は、特定のＳセルのＲＡＴｂａｃｋｏｆｆ，ｃ（ｉ）が、構成された閾値よりも大きく変化するとき、ＰＨＲをトリガすることでありうる。他の係数の中でも、構成されたバックオフ閾値は、配置シナリオ、および、実装に固有のｅＮＢスケジューラ設計によって決まってもよい。

他のＲＡＴへの適用された電力バックオフまたは干渉が、他のバックオフ係数と並行して計算されうるものであり、ただし、電力の低減が、ＭＡＸ（ＭＰＲ_{ａｃｔｕａｌ，ｃ}，Ｐ−ＭＰＲ_{ａｃｔｕａｌ，ｃ}（ｉ），ＲＡＴｂａｃｋｏｆｆ，ｃ（ｉ））によって判定されうる場合、ＲＡＴ干渉によるバックオフが構成された閾値を越えたとしても、実際の電力バックオフがＭＰＲ／Ａ−ＭＰＲの影響またはＰ−ＭＰＲの影響によって左右される場合、実際の電力バックオフへの影響がないことがある、という場合がありうる。したがって、不要な報告を最小限にするために、ＲＡＴバックオフの変化によるＰＨＲトリガリングは、この係数が、そのセルに対して適用されたバックオフ（Ｐｃｍａｘ，ｃ）の計算を左右するときに、限定されてもよい。

実施形態の一例によれば、ＬＴＥ−Ｒ１０における電力管理と同様に、デバイス内干渉および他の原因によるＷＴＲＵ内の電力バックオフまたはスケーリングは、送信時間間隔に基づいてではなく、時間領域ウィンドウ内で適用されうる。このための１つの理由は、ＵＬグラントのスケジューリングが即時に調節されないことがあることである。電力バックオフまたはスケーリングを、特定の送信に対してではなく、ある期間にわたって適用することによって、電力バックオフまたはスケーリングのレベルに合致するＵＬグラントが増加される。加えて、電力バックオフまたはスケーリングイベントの識別は、ＭＡＣ−ＣＥ−ＰＨＲを遅延させる禁止タイマを受けてもよい。この場合、電力バックオフまたはスケーリングの適用は、ＭＡＣ−ＣＥ−ＰＨＲが送信されうるか、または、ｅＮＢスケジューラによって理解されるまで、遅延されてもよい。同様の方法が、電力バックオフまたはスケーリングが除去されうるとき、適用されてもよい。この場合、低減されたバックオフまたはスケーリングが報告されるか、または、スケジューラによって理解されるときにのみ、電力バックオフまたはスケーリングは実際に低減される。この解決策は、ＬＴＥ−ＵＬグラントを適切にサポートし、かつ、他のＲＡＴにおける送信が急速に再アクティブ化されるとき、他のＲＡＴへの干渉を最小化する、電力管理の場合のように、利益を得ることができる。

電力低減値および理由もまた、ＵＥがデバイス内干渉状況を検出し、かつ、上記で説明したような電力管理プロシージャが実行されるとき、トリガされうる、通知メッセージを介して、ネットワークに報告されてもよい。

アイドルモードにおける追加の防止機構もまた、例えば、そのような機構に関連付けられた情報が（例えば、３１０および３１２で）無線デバイスによって受信かつ処理されることに応答して、実行されてもよい。

無線デバイスがアイドル状態である可能性があり、かつ、無線デバイスのバッファ内に保留中のデータがない可能性がある場合、無線デバイスは、ＩＳＭデバイス（または、ＲＡＴをサポートする別のコンポーネント）を制限または調整して、無線デバイスの実際の動作を保護し、ページングおよび測定期間中にデータが送信されることのないようにしてもよい。このことは、例として、共存する技術がアクティブ化されうる（例えば、ＩＳＭまたはＧＰＳがアクティブ化されうる）が、無線デバイスがＬＴＥシステムに既に接続されうるとき、実行されてもよい。

無線デバイスがアイドルでありうることを考えると、別の周波数に変更するべき時間は重要でないことがある。ＩＳＭ技術など、ＲＡＴ技術がアクティブ化されうる間、無線デバイスは、アイドルモードのままであってもよい。しかし、この解決策の一部として、無線デバイスは、ＩＳＭ技術など、ＲＡＴがアクティブ化されていることを、ネットワークに通知してもよい。これにより、無線デバイスが前もって周波数から出ることが可能になりうる。アイドルモードでネットワークに通知するために、無線デバイスは、ＲＲＣ接続要求メッセージを使用してもよい。ＲＲＣ接続要求内の１ビットインジケーションを使用して、デバイス内で（デバイス内干渉を発生する可能性がある）共存する技術がアクティブ化されることを要求中であるか、または、アクティブ化されていることを、ネットワークに指示してもよい。あるいは、ＲＲＣ接続要求内の新しい確立条項（clause）が導入されてもよい（例えば、デバイス内技術アクティブ）。ネットワークは、原因リダイレクトを有するＲＲＣリジェクションメッセージを介して、無線デバイスに応答してもよい。

あるいは、無線デバイスは、ＲＲＣ接続確立プロシージャが開始された後、ＩＳＭデバイスなど、ＲＡＴコンポーネントまたはデバイスがアクティブであることを、ネットワークに通知してもよい。この通知は、ＲＲＣ接続要求内またはＲＲＣ接続セットアップ完了内に存在してもよい。ネットワークは次いで、（例えば、３１０で受信された情報を介して）無線デバイスを接続モードへ送信し、かつ、（例えば、３１２での処理を介して）上記で説明したアクションのうち１つを実行すること、あるいは、無線デバイスにリダイレクト情報を与えることを選んでもよい。

上記で論じた情報を有するインジケーションまたは報告と共に、無線デバイスは、ネットワークに対し、無線デバイスがＲＲＣ接続セットアップメッセージの適切な受信を可能にするために使用中でありうる、一時的パターンを提供してもよい。このパターンと共に、無線デバイスは、基準タイミングを指定して、ＩＳＭデバイスが送信中ではなく、したがって、ｅＮＢがダウンリンク送信のために使用することができるダウンリンクサブフレームに、ネットワークが気づいていることを可能にしてもよい。無線デバイスによって使用され、シグナリングされるパターンは、明示的パターンであってもよい。あるいは、事前定義され、無線デバイスおよびネットワークの両方によって知られるデフォルトパターンが、ＲＲＣ接続セットアップメッセージの受信のために使用されてもよい。ネットワークがＲＲＣ接続要求内のインジケーションを受信するとき、ネットワークは、このデフォルトパターンを使用して、ＲＲＣ接続セットアップまたはＲＡＣＨ−ｍｓｇ４がＤＬ内でスケジュールされるサブフレームを判定してもよい。

あるいは、ＷＴＲＵは、新しいパターンまたはアクションがネットワークによって要求されるまで、一時的に使用中でありうる、事前定義されたパターンのセットへのインデックスを提供してもよい。無線デバイス側では、無線デバイスは、シグナリングされたパターンを使用して、ＤＬ内で監視することができるサブフレームを判定してもよい。例として、ｍａｃＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎタイマが実行中である間、無線デバイスは、パターンに従って、他のデバイスが送信中でないサブフレーム、または、ＬＴＥによりスケジュールされた期間を監視してもよい。あるいは、無線デバイスは、連続的な受信を実行してもよく、正しいサブフレーム上でメッセージを送信するために、ネットワークに依拠する。このことは、ネットワークがこの特徴をサポートしないことがあり、サブフレームのうちいずれかにおいて実際に応答を送信することがあることを考えると、有益でありうる。

上記との組み合わせでも使用されうる代替解決策では、ＲＡＣＨアクセスプリアンブルが送信されるとき、ＲＡＲの適切な受信を保証するために、無線デバイスは、他の技術に対し、ランダムアクセス応答（ＲＡＲ）ウィンドウの継続時間にわたって（例えば、ＷＴＲＵがＲＡＲを受信することを予期している時間にわたって）いかなるＵＬ送信をも実行しないように知らせてもよいことが、提案される。加えて、同じことは、メッセージ３が送信され、かつ、ＭＡＣ競合解決タイマが開始されている時間から、競合タイマが満了するか、または、ｍｓｇ４が無線デバイスによってうまく受信されるまで、当てはまることがある。

別の実施形態では、無線デバイスは、（例えば、３１２で）別の周波数またはＲＡＴを再選択するか、またはそれに向けてリダイレクトされて、無線デバイス内のＩＳＭデバイスなど、ＲＡＴコンポーネントまたはデバイスの独立した完全な動作を可能にしてもよい。以下の方法の例は、無線デバイス内のＩＳＭデバイスの完全な独立した動作を可能にしてもよい。例えば、一実施形態では、ネットワークは、共存する技術がアクティブ化されうる場合にデバイスが測定かつそれにハンドオフすることを可能にする周波数またはＲＡＴのリストを、デバイスにシグナリングしてもよい。このリストは、デバイス内で共存する技術を有するＬＴＥ無線デバイス向けであってもよく、あるいは、ネットワークは、無線デバイスが再選択することを許可されない周波数のリストを、無線デバイスにシグナリングしてもよい。あるいは、無線デバイスは、再選択または接続の目的のために使用することができる、使用可能な周波数を自律的に判定してもよいが、被干渉周波数をネットワーク使用可能周波数のリストから除く。

この情報が、例えば、ＩＳＭデバイスを備える無線デバイスに特有に、ブロードキャストされうる（例えば、３１０で受信される）場合、無線デバイスは、セルにおけるキャンピングの直後に、これらの特定の周波数またはＲＡＴの測定を開始してもよい。あるいは、無線デバイスは、そのバッテリーを保ち、測定負荷を低減するために、ＩＳＭデバイスがアクティブでありうるものであり、ならびに、別の技術によって干渉される傾向および／または別の技術への干渉を発生する傾向がありうると判定した後にのみ、これらの特定の周波数およびまたはＲＡＴの測定を開始してもよい。

あるいは、ネットワークがこれらの特定の周波数および／またはＲＡＴをシグナリング中でないことがある場合、ＩＳＭ技術アクティブ化要求など、ＲＡＴのための技術アクティブ化要求を受信すると、無線デバイスは、ＩＳＭデバイス（もしくは、他のＲＡＴデバイス）のアクティブ化を可能にする前に、他の周波数および／もしくはＲＡＴの探索／走査を自律的に開始してもよく、または、ＩＳＭデバイスがアクティブ化されている間、もしくは、干渉が検出されうるようになると、それらを行うことを開始してもよい。より具体的には、無線デバイスは、他のＲＡＴおよび周波数の測定を開始するための基準が満たされない場合であっても、システム情報ブロック（ＳＩＢ）内で、指示された周波数およびＲＡＴの測定を開始してもよい。

あるいは、無線デバイスは、干渉技術がアクティブ化されうるとき、干渉の傾向がある周波数を自律的に優先させないようにしてもよい（例えば、何が実際にＳＩＢ内で送信されるかにかかわらず、それらの周波数を、リスト内の最低優先度の周波数であると見なす）。例として、このルールは、ＬＴＥ無線デバイスが任意の周波数内にある可能性があり、かつ、セル再選択測定を実行している間に適用され、ＬＴＥ無線デバイスが、干渉の傾向がある周波数に再選択することを回避できるようにしてもよい。ＩＳＭデバイス（または、他のＲＡＴデバイス）が、所与の期間にわたって、非アクティブ化されると、ブロードキャストまたはシグナリングされた周波数およびＲＡＴの優先度は、元に戻されてもよい。あるいは、別個の優先度リストが、共存するデバイスに対して別々にブロードキャストされてもよい。例えば、上記の基準が満たされるとき、無線デバイスは、専用のリストを使用してもよく、そうでない場合、すべての無線デバイスのための標準リストが使用されてもよい。あるいは、別の例では、このリストは、共存するデバイスを有するＬＴＥ無線デバイスによって使用されてもよい。

別の代替的実施形態では、上記の基準が満たされるとき、ＬＴＥ無線デバイスは、セルが除外されたと見なしてもよい。ＩＳＭデバイス（もしくは、他のＲＡＴデバイス）が非アクティブ化されうるか、または、構成された期間にわたって非アクティブ化されるまでは、セルが除外されたと見なされてもよい。無線デバイスが、他のいかなる周波数またはＲＡＴ内でいかなる適切なセルも発見できない場合、無線デバイスは、除外制限を解除し、そのセルに接続してもよい。

成功したＲＡＴまたは別の安全な周波数が再選択されると、無線デバイスは、ＩＳＭデバイスアクティブ化（または、他のＲＡＴデバイスコンポーネントアクティブ化）を可能にしてもよい。あるいは、ＩＳＭデバイス（または、他のＲＡＴデバイスもしくはコンポーネント）はなお、アクティブ化されてもよく、ＬＴＥデバイスまたはコンポーネントは、本明細書で説明するプロシージャに従ってもよい。別の実施形態では、ＩＳＭデバイスアクティブ化要求（または、他のＲＡＴデバイスアクティブ化要求）を受信すると、無線デバイスは、例えば、新しい原因「ＩＳＭデバイスアクティブ化」と共に接続要求メッセージを送信してもよい。このメッセージを（例えば、３０８で）受信すると、ネットワークは、安全な周波数上で別の周波数またはＲＡＴへのリダイレクトを有する接続リジェクトを送信し（例えば、３１０で受信されうる）、両方のＲＡＴの独立した動作を可能にしてもよい。

安全な周波数／ＲＡＴへの再選択／リダイレクトが成功した後、無線デバイスは、ＩＳＭデバイスアクティビティ（または、他のＲＡＴデバイスアクティビティ）中に、異なる周波数／ＲＡＴ優先度リストを維持して、セル再選択ピンポン効果を回避してもよい。加えて、無線デバイスは、干渉の傾向がある周波数上のセルに対して一時的除外を適用してもよい。セルおよび周波数除外は、ＩＳＭデバイス（または、他のＲＡＴデバイス）が所与の期間にわたって非アクティブ化されうるようになると、解除されてもよい。無線デバイスは、ＩＳＭデバイス（または、他のＲＡＴデバイス）が定義された時間量にわたってオフにされるとき、（例えば、通知を介して）ネットワークに報告または通知し、ネットワークが無線デバイス（例えば、３１０で受信され、３１２で処理されうる）を、標準の（以前の）周波数を測定するように構成できるようにしてもよい。

実施形態の一例では、ＩＳＭデバイスアクティブ化要求（または、他のＲＡＴデバイスアクティブ化要求）があると、無線デバイスは、ネットワークによりシグナリングされうるか、または、無線デバイスにより実装されうる（例えば、無線デバイス内で実装される）、遅延アクティブ化タイマを起動してもよい。このタイマは、代替周波数／ＲＡＴ再選択またはリダイレクトを可能にするために十分長いものであってもよい。あるいは、動作ごとに２つの異なるタイマ、または、１つのタイマおよびスケーリング係数があってもよい。

別の実施形態では、アイドルモードである間、無線デバイスは、その動作をＩＳＭデバイス（または、他のＲＡＴデバイス）と同期させて、その測定およびページングの機会を保護してもよい。現在のＲＡＴ上で送信されるべきデータがある場合、現在のＲＡＴは、そのデータをバッファリンングし、最初にＩＳＭデバイスアクティブ化条項と共に接続要求を送信してもよく、次いで、ネットワークによってリダイレクトされ、次いで、安全な周波数上で接続およびデータ転送を開始してもよい。加えて、無線デバイスまたは現在のＲＡＴがページングを受信することができる場合、無線デバイスまたは現在のＲＡＴは、ＩＳＭデバイス上の送信を非アクティブ化または一時停止し、ページングメッセージを進めてもよい。また、無線デバイスまたは現在のＲＡＴがデータまたは呼を受信しなければならない場合、無線デバイスまたは現在のＲＡＴは、接続モードへ移り、次いで、上記で説明した接続状態プロシージャのうち１つを適用してもよい。

ピンポンを最小限にするため、かつ、無線デバイスが最終的にその周波数に戻ることができるようにするための、解決策（または、プロシージャ、方法、ルール、および、本明細書で説明するもののいずれかによって、無線デバイスが干渉の傾向がある周波数から出た後、無線デバイスは、共存するデバイスが非アクティブ化されるまで（無線デバイスがなお干渉の傾向がある周波数に戻ろうとする可能性がある場合に、他の周波数が使用可能になる可能性がないことでない限り）、その周波数上で測定を実行することを、または、その周波数に戻るために防止されてもよい。その技術が事前定義された期間にわたって非アクティブ化された後、無線デバイスは、（例えば、３０８で）デバイスが非アクティブ化されているという報告を、ネットワークへ送信してもよい。この報告は、ＲＲＣメッセージを介して、測定イベントを介して、または、新しい測定イベントを介して送信されてもよい。無線デバイスは、干渉の傾向がある周波数の測定もまた開始してもよい。

一実施形態では、無線デバイス自体が、検出された干渉状況から回復してもよい。例えば、再び図３を参照すると、一実施形態では、無線デバイスは、（例えば、３１０で）干渉状況を軽減するための情報を、ネットワークから受信しないことがある。むしろ、無線デバイスは、３０２で干渉イベントを検出すると処理されうる、または行われうる、１つまたは複数のアクション、ルール、方法、プロシージャおよび／またはプロトコルを内部に含んでもよい。例えば、上記で説明したように、３０２で干渉イベントを検出すると、３０４で、通信またはインタフェースリンクが確立されないことがある（例えば、ＲＬＦが起こりうる）。そのような状況では、無線デバイスは、内部で１つまたは複数のアクション、ルール、方法、プロシージャおよび／またはプロトコルを処理し、または実行して、（例えば、３０６で）本明細書で説明するようにデバイス内干渉状況から回復し、その状況を軽減、低減または防止してもよい。

より具体的には、干渉デバイスがアクティブ化されて、干渉状況が生じうるようになると、共存するデバイス内の干渉が激しく、無線デバイス内でデータの正しい受信を妨げることがある（例えば、ＲＬＦが起こりうる）。デバイスがこの状況を和らげ、検出できるようにするために、以下で説明するものなど、ＲＬＦに対処するいくつかの方法（ＲＬＦＯ、報告、測定、および同様のもの）が採用されてもよい。

一実施形態では、ＲＬＦプロシージャが、無線デバイス、または、内部の１つもしくは複数のコンポーネントによって実行されて、無線デバイスが干渉状況を検出し、かつ、本質的にＷＴＲＵにセルまたは周波数を変更させることができるようにしてもよい。しかし、ＲＬＦを宣言するために必要とされる時間はかなり長いことがあり、したがって、無線デバイスによって実行されるように構成されたＲＬＦプロシージャを使用することは、許容可能なＱｏＳを維持するために十分でないことがある。加えて、干渉技術から発生した干渉が（例えば、生成されているデータのタイプに応じて）本質的に散発的でありうることを考えると、ＲＬＦをトリガするための条件は、十分に長く続かないことがある。したがって、受信器の低雑音増幅器（ＬＮＡ）の飽和の影響を軽減するために、より低いレイテンシ反応を有する、改善されたＲＬＦプロシージャが使用されてもよい。

チャネル品質インジケータ（ＣＱＩ）および／または信号品質（ＬＴＥの基準信号受信品質（ＲＳＲＱ）、もしくは、ＵＭＴＳのＥｃ／Ｎｏ）もまた、無線デバイスによって、そのような干渉状況を検出するために使用されてもよい。

一実施形態では、ＩＳＭデバイスのアクティブ化（例えば、３０２で、干渉状況の検出）があると、無線デバイスは、（例えば、３０６で）スケーリング係数を、ＲＬＦプロシージャのために使用される「非同期」カウンタ（例えば、Ｎ３１０）および／またはＲＬＦタイマ（例えば、Ｔ３１０）に適用してもよい。スケーリング係数は、ネットワークによりシグナリングもしくは提供され、または、（例えば、その実装を介して）無線デバイスにより定義されてもよい。構成されたＮ３１０および／またはＴ３１０に、このスケーリング係数を掛けて、「非同期」が共存する干渉デバイスにより引き起こされる場合に使用されるべき新しいカウンタおよび時間を判定してもよい。あるいは、共存するコンポーネントまたはデバイスに固有の新しいセットのＮ３１０またはＴ３１０が、無線デバイス内で提供または構成されてもよい。

一実施形態によれば、いつスケーリング係数を適用するかを判定するために、無線デバイスは、共存するデバイスが存在する可能性があり（例えば、ＩＳＭ）、アクティブ化されうるという知識を、使用してもよい。ＩＳＭデバイス（または、他のＲＡＴデバイスもしくはコンポーネント）がアクティブ化されうるとき、無線デバイスは、ＲＬＦを検出かつ宣言するためのスケーリングされた、または、新しいセットのパラメータの使用を開始してもよい。以下で説明する基準と組み合わせたこの条件を使用して、干渉通知または報告がネットワークへ送信されるか否かを判定してもよいことは理解されよう。例えば、上記の基準と組み合わせて、無線デバイスはまた、スケーリングされた、または、新しいセットのパラメータの使用を開始する判定を、ＣＱＩが閾値未満であることに基づかせてもよい。したがって、非同期が検出される可能性があり、かつ、ＣＱＩが閾値未満である可能性があり、ならびに／または、ＲＳＲＱが閾値未満でありうるとき、無線デバイスは、スケーリングされた値を使用してもよい。

散発的な干渉の検出に対処するために、ＣＱＩ報告またはイベント報告を含む、（例えば、３０６で）無線デバイスによってトリガされたＲＬＦプロシージャおよび／または他のプロシージャは、（同じく、例えば、３０６で）無線デバイスによって実行されるべき以下の検出機構につながることがある。例えば、無線デバイスは、トリガを断続的な干渉パターンの検出に基づかせてもよい。あるいは、または加えて、無線デバイスは、Ｔｘ期間にわたって、Ｎｘの連続的な「非同期」Ｎｙ時間を検出してもよい。より具体的には、干渉の性質を考えると、無線デバイスは、異なる時間間隔で同期および非同期になりうる。したがって、無線デバイスがそのような動きを検出することが、有益でありうる。したがって、無線デバイスが、Ｎｘの連続的な「非同期」を受信する可能性があるようになると、無線デバイスは、タイマＴｘを起動させてもよい。この条件のためのトリガが満たされうる場合、無線デバイスは、（例えば、３０２および３０４で）無線リンク障害を検出するか、または、（例えば、３０８で）このイベントをネットワークに報告してもよい。

上記のことはまた、一実施形態によれば、ＣＱＩ値またはＲＳＲＱ値にも適用されうる。例えば、新しいイベントは、ＣＱＩまたはＲＳＲＱが事前定義された期間にわたって閾値を下回る、ウィンドウまたは測定サンプル内の時間量をカウントするように構成されてもよい。構成された期間内でこれが起こる時間量が、構成された値を超え（すなわち、このパターンが検出される場合）、かつ、無線デバイスが、干渉技術が有効にされ、干渉を発生中であることに気づいている場合、無線デバイスは、（例えば、３０８で）新しい測定イベントもしくは新しいＲＲＣメッセージを介して、このイベントをネットワークに報告してもよく、または、（例えば、３０６で）内部のプロトコル、プロシージャ、ルールもしくは方法を実行して、干渉イベントを軽減してもよい。実施形態の例によれば、上記で説明したＲＳＲＱ／ＣＱＩ閾値、期間およびカウンタは、ネットワークによって構成されるか、または、無線デバイス内で事前定義されてもよい。

一実施形態では、無線デバイスは、（例えば、３０６で）ＩＳＭデバイスバッファ負荷（もしくは、他のＲＡＴデバイスバッファ負荷）、または、受信および／もしくは送信速度に基づいて、誤りカウンタおよびＲＬＦタイマを調節してもよい。あるいは、無線デバイスは、現在のＲＡＴに対するＩＳＭからのサービスの品質またはサービスのタイプに基づいて、そのＲＬＦ宣言パラメータを調節してもよい。

追加の実施形態では、ネットワークが本明細書で説明するような適切なアクションを取ることができるように、無線デバイスがより早い段階で干渉をネットワークに報告できるようにするため、または、無線デバイスが干渉状況自体に対処できるようにするために、新しいイベント／トリガが定義されてもよい。そのようなイベントは、被干渉サブフレーム、または、被干渉サブフレームおよび干渉されないサブフレームの平均中に、構成された期間にわたって、干渉技術がアクティブ化される可能性があり、かつ、以下の条件が満たされうる、というデバイス内の知識に基づいてもよく、それらの条件は、ＲＳＲＱが閾値未満でありうること、ＲＳＲＰが閾値未満でありうること、および／または、ＣＱＩ値が閾値未満でありうることである。

さらに別の実施形態では、無線デバイスは、（例えば、３０６で）構成される場合は、イベントをトリガするための測定値および時間に対して、異なるスケーリング係数を適用して、デバイス内ＩＳＭ送信器（または、他のＲＡＴ送信器）からの継続された干渉を加速してもよい。この問題に固有の、新しい定義されたイベント、または、特定のパラメータを有する既存のイベントがあってもよい。

加えて、ＩＳＭ送信器（または、他のＲＡＴ送信器）によるＬＮＡの飽和を軽減するために、無線デバイスが（例えば、３０６で）あるアクションを行い、かつ／または、（例えば、３０８で）問題（ＲＬＦ、もしくは、上記の段落で説明したようなイベント）を報告し、（例えば、３１０で）ネットワーク反応メッセージを受信し、（例えば、３１２で）ネットワーク指令を（その指令が何であろうと、すなわち、ハンドオーバ、リダイレクトによる接続解放、もしくは、キャリア（複数可）再構成）完了する間、ＩＳＭデバイス（または、他のＲＡＴコンポーネントもしくはデバイス）は、一時的に送信を一時停止してもよい。

随意に、上記のトリガが満たされうるとき、無線デバイスはまた、他の周波数またはＲＡＴの測定をも自律的に開始してもよい。これにより、ＲＬＦが実際に起こるとき、適切なセルおよび周波数の発見の遅延を低減することができる。

別の実施形態によれば、無線デバイスは、（例えば、３０６および／または３１２で）以下を行って、干渉状況を軽減、防止、低減または回避してもよく、すなわち、一時的にＩＳＭ送信器を一時停止すること、ネットワークとの同期が失われた場合、再び獲得すること、干渉通知をネットワークへ送ること、ある定義された時間にわたってネットワーク反応を待機すること、ネットワーク指令（再構成、ハンドオーバ、別の周波数もしくはＲＡＴへのリダイレクトによる接続解放、および同様のもの）を受信すること、ネットワーク指令をうまく実行すること、ピンポン効果を回避するために周波数／ＲＡＴ優先度を変更すること、ＩＳＭアクティビティを再起動すること、および／または、ＩＳＭデバイスアクティビティが停止するか、もしくはＩＳＭデバイスがオフにされるとき、以前の優先度に戻し、標準の動作について再構成することである。

特徴および要素を特定の組み合わせにより上記で説明しているが、各特徴もしくは要素を単独で、または、他の特徴および要素との任意の組み合わせで使用できることは、当業者には理解されよう。加えて、本明細書で説明した方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれた、コンピュータプログラム、ソフトウェアまたはファームウェアにおいて実装可能である。コンピュータ可読媒体の例には、電子信号（有線またはワイヤレス接続を介して送信される）およびコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例には、限定されないが、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびに、ＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体が含まれる。ソフトウェアに関連したプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または、任意のホストコンピュータにおいて使用するための、無線周波数トランシーバを実装するために使用可能である。

Claims (23)

1. 無線デバイス内の無線アクセス技術（ＲＡＴ）コンポーネント間の干渉を軽減するための方法であって、
   前記無線デバイス内の第１のＲＡＴコンポーネントと第２のＲＡＴコンポーネントの間の干渉状況を検出するステップと、
   前記干渉状況の通知をネットワークへ送信するステップと
   を備え、
   前記通知は、前記干渉状況を軽減するために使用されるように構成された情報を備えることを特徴とする方法。
2. 前記無線デバイス内の前記第１のＲＡＴコンポーネントと前記第２のＲＡＴコンポーネントとの間の前記検出された干渉状況についての構成情報を受信するステップであって、前記構成情報は、前記検出された干渉状況に応答して、前記無線デバイスによって実行されるように構成された動作のインジケーションを備えるステップと、
   前記検出された干渉状況を軽減するように構成された前記動作を含む、前記構成情報を処理するステップと
   をさらに備えることを特徴とする請求項１に記載の方法。
3. 前記構成情報を処理するステップは、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに対するハンドオーバと、
   別の周波数へのリダイレクトと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントのアクティブ化と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントの遅延されたアクティブ化と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオフにすることと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオンにすることと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられた周波数帯域を電力スケーリングすること
   のうちの少なくとも１つを実行するステップを備えることを特徴とする請求項２に記載の方法。
4. 前記構成情報は、
   デバイス内干渉イベントについての構成と、
   ネットワークの性能に関連付けられた情報と、
   スケーリング値と、
   新しい測定構成メッセージと、
   新しい周波数帯域と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに対するアクティブ化遅延と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントを起動するためのインジケーションと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントについてのアクティブ化時間通知と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによって送信または受信されるその優先度を含むトラフィックのタイプのインジケーションと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオフに保つためのコマンドと、
   ハンドオーバコマンドと、
   測定制御情報と、
   別の周波数内のＲＣＣ再確立に関連付けられた情報と、
   再構成メッセージと、
   高速変更に関連付けられた情報と、
   異なるＲＡＴへのリダイレクトと、
   間欠受信（ＤＲＸ）動作に関連付けられた情報と、
   ＴＤＭ動作に関連付けられた情報と、
   ＦＤＤ半二重動作に関連付けられた情報と、
   パターンまたはパターンに関連付けられた変更に関連付けられた情報と、
   非バッファステータス報告（ＢＳＲ）に関連付けられた情報と、
   １つまたは複数のスケジューリング要求と、
   ダウンリンク（ＤＬ）再送信およびフィードバックに関連付けられた情報と、
   アップリンク（ＵＬ）再送信およびフィードバックに関連付けられた情報と、
   ランダムアクセスプロシージャに関連付けられた情報と、
   前記干渉状況が軽減されたというインジケーションと、
   周波数帯域の電力スケーリングに関連付けられた情報と
   のうちの少なくとも１つを備えることを特徴とする請求項２に記載の方法。
5. 前記干渉状況は、１つまたは複数のトリガに基づいて検出されることを特徴とする請求項１に記載の方法。
6. 前記１つまたは複数のトリガは、
   先行的トリガと、
   反応的トリガと、
   ハンドオーバが開始されることと、
   動作のモードの変更と、
   使用シナリオ変更における変更と、
   サービスシナリオ変更における変更と、
   タイマの満了と、
   所定の負荷の発生と、
   バッファのサイズと
   のうちの少なくとも１つを備えることを特徴とする請求項５に記載の方法。
7. 前記通知は、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントがアクティブ化される必要があるか、またはアクティブ化されるというインジケーションと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントが回転される必要があるか、またはオンにされるというインジケーションと、
   前記１つまたは複数のトリガに関連付けられた情報と、
   前記干渉状況を引き起こす技術のタイプに関連付けられた情報と、
   前記干渉状況に対処するための前記無線デバイスの性能のインジケーションと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられた情報と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによって要求された使用シナリオと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによって要求されたサービスシナリオと、
   タイマに関連付けられた情報と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントの動作のモードに関連付けられた情報と、
   いつ前記第１のＲＡＴまたは前記第２のＲＡＴがオンにされるべきであるかについてのインジケーションと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられた測定値と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられたホッピング周波数と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによってサポートされた周波数のリストと、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオンにすることに関連付けられた緊急性のインジケーションと、
   Ａ−ＧＮＳＳを求める要求と、
   ソースセルに関連付けられた情報と、
   前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントのブザーサイズに関連付けられた情報と
   のうちの少なくとも１つを備えることを特徴とする請求項６に記載の方法。
8. 前記通知を、
   ＲＲＣ接続確立プロシージャを介して、ＲＲＣメッセージ内の新しいフィールドを介して、
   ＲＲＣ接続要求メッセージを介して、ＲＲＣ接続セットアップ完了メッセージを介して、
   ルーティングエリア更新メッセージを介して、
   ＭＡＣ制御要素を介して
   のうちの少なくとも１つによって送信することができることを特徴とする請求項１に記載の方法。
9. 前記第１のＲＡＴコンポーネントは、第１の無線技術をサポートし、前記第２のＲＡＴコンポーネントは、第２の無線技術をサポートし、前記第１の無線技術および前記第２の無線技術は、異なることを特徴とする請求項１に記載の方法。
10. 内部に含まれた共存する無線アクセス技術（ＲＡＴ）コンポーネント間の干渉を軽減するための無線送信／受信ユニット（ＷＴＲＵ）であって、
    前記無線デバイス内の２つ以上のＲＡＴコンポーネント間の検出された干渉状況についての構成情報を受信し、前記構成情報は、前記検出された干渉状況に応答して、前記無線デバイスによって行われるように構成されたアクションを備え、
    前記検出された干渉状況を軽減するように構成された前記アクションを含む、前記構成情報を処理する
    ように構成されたプロセッサ
    を備えることを特徴とするＷＴＲＵ。
11. 前記プロセッサは、前記構成情報を処理するとき、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに対するハンドオーバと、
    別の周波数へのリダイレクトと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントのアクティブ化と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントの遅延されたアクティブ化と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオフにすることと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオンにすることと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられた周波数帯域を電力スケーリングすることと
    のうち少なくとも１つを実行するようにさらに構成されることを特徴とする請求項１０に記載のＷＴＲＵ。
12. 前記構成情報は、
    デバイス内干渉を起こすイベントについての構成と、
    ネットワークの性能に関連付けられた情報と、
    スケーリング値と、
    新しい測定構成メッセージと、
    新しい周波数帯域と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに対するアクティブ化遅延と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントを起動するためのインジケーションと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントについてのアクティブ化時間通知と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによって送信または受信されるその優先度を含むトラフィックのタイプのインジケーションと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオフに保つためのコマンドと、
    ハンドオーバコマンドと、
    測定制御情報と、
    別の周波数内のＲＣＣ再確立に関連付けられた情報と、
    再構成メッセージと、
    高速変更に関連付けられた情報と、
    異なるＲＡＴへのリダイレクトと、
    間欠受信（ＤＲＸ）動作に関連付けられた情報と、
    ＴＤＭ動作に関連付けられた情報と、
    ＦＤＤ半二重動作に関連付けられた情報と、
    パターンまたはパターンに関連付けられた変更に関連付けられた情報と、
    非バッファステータス報告（ＢＳＲ）に関連付けられた情報と、
    １つまたは複数のスケジューリング要求と、
    ダウンリンク（ＤＬ）再送信およびフィードバックに関連付けられた情報と、
    アップリンク（ＵＬ）再送信およびフィードバックに関連付けられた情報と、
    ランダムアクセスプロシージャに関連付けられた情報と、
    前記干渉状況が軽減されたというインジケーションと、
    周波数帯域の電力スケーリングに関連付けられた情報と
    のうちの少なくとも１つを備えることを特徴とする請求項１０に記載のＷＴＲＵ。
13. 前記プロセッサは、
    前記無線デバイス内の前記２つ以上のＲＡＴコンポーネント間の干渉状況を検出し、
    前記干渉状況の通知をネットワークへ送信する
    ようにさらに構成され、
    前記通知は、前記干渉状況を軽減するために使用されるように構成された情報を備えることを特徴とする請求項１０に記載のＷＴＲＵ。
14. 前記干渉状況は、１つまたは複数のトリガに基づいて検出されることを特徴とする請求項１３に記載のＷＴＲＵ。
15. 前記１つまたは複数のトリガは、
    先行的トリガと、
    反応的トリガと、
    ハンドオーバが開始されることと、
    動作のモードの変更と、
    使用シナリオ変更における変更と、
    サービスシナリオ変更における変更と、
    タイマの満了と、
    所定の負荷の発生と、
    バッファのサイズと
    のうちの少なくとも１つを備えることを特徴とする請求項１４に記載のＷＴＲＵ。
16. 前記通知は、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントがアクティブ化される必要があるか、またはアクティブ化されるというインジケーションと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントが回転される必要があるか、またはオンにされるというインジケーションと、
    前記１つまたは複数のトリガに関連付けられた情報と、
    前記干渉状況を引き起こす技術のタイプに関連付けられた情報と、
    前記干渉状況に対処するための前記無線デバイスの性能のインジケーションと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられた情報と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによって要求された使用シナリオと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによって要求されたサービスシナリオと、
    タイマに関連付けられた情報と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントの動作のモードに関連付けられた情報と、
    いつ前記第１のＲＡＴまたは前記第２のＲＡＴがオンにされるべきであるかについてのインジケーションと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられた測定値と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントに関連付けられたホッピング周波数と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントによってサポートされた周波数のリストと、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントをオンにすることに関連付けられた緊急性のインジケーションと、
    Ａ−ＧＮＳＳを求める要求と、
    ソースセルに関連付けられた情報と、
    前記第１のＲＡＴコンポーネントまたは前記第２のＲＡＴコンポーネントのブザーサイズに関連付けられた情報と
    のうちの少なくとも１つを備えることを特徴とする請求項１５に記載のＷＴＲＵ。
17. 前記通知を、
    ＲＲＣ接続確立プロシージャを介して、ＲＲＣメッセージ内の新しいフィールドを介して、
    ＲＲＣ接続要求メッセージを介して、ＲＲＣ接続セットアップ完了メッセージを介して、
    ルーティングエリア更新メッセージを介して、
    ＭＡＣ制御要素を介して
    のうちの少なくとも１つによって送信することができることを特徴とする請求項１３に記載のＷＴＲＵ。
18. 前記第１のＲＡＴコンポーネントは、第１の無線技術をサポートし、前記第２のＲＡＴコンポーネントは、第２の無線技術をサポートし、前記第１の無線技術および前記第２の無線技術は、異なることを特徴とする請求項１０に記載のＷＴＲＵ。
19. 無線デバイス内の無線アクセス技術（ＲＡＴ）コンポーネント間の干渉を軽減するための方法であって、
    前記無線デバイス内の第１のＲＡＴコンポーネントと第２のＲＡＴコンポーネントの間の干渉状況を検出するステップと、
    前記無線デバイス内に格納されたアクションを実行するステップと
    を備え、
    前記アクションは、前記検出された干渉状況を軽減するように構成されることを特徴とする方法。
20. 前記干渉状況の通知をネットワークに提供するために、前記ネットワークとの通信リンクが確立されるかどうかを判定するステップと、前記干渉状況の前記通知を提供するために、前記ネットワークとの前記通信リンクが確立されないとき、前記無線デバイス内に格納された前記アクションを実行するステップと
    をさらに備えることを特徴とする請求項１９に記載の方法。
21. 前記干渉状況は、
    先行的トリガと、
    反応的トリガと、
    ハンドオーバが開始されることと、
    動作のモードの変更と、
    使用シナリオ変更における変更と、
    サービスシナリオ変更における変更と、
    タイマの満了と、
    所定の負荷の発生と、
    バッファのサイズと
    のうちの少なくとも１つを備える１つまたは複数のトリガに基づいて検出されることを特徴とする請求項１９に記載の方法。
22. 前記アクションは、無線リンク障害（ＲＬＦ）プロシージャおよびハンドオーバのうちの少なくとも１つを備えることを特徴とする請求項１９に記載の方法。
23. 前記第１のＲＡＴコンポーネントは、第１の無線技術をサポートし、前記第２のＲＡＴコンポーネントは、第２の無線技術をサポートし、前記第１の無線技術および前記第２の無線技術は、異なることを特徴とする請求項１９に記載のＷＴＲＵ。

Images