(57)【要約】  下りリンク・サブフレームを変換するように構成されたｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）が開示される。ｅＮＢは、プロセッサ、およびプロセッサと電子通信状態にあるメモリに記憶された実行可能な命令を含む。ｅＮＢは、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定する。さらに、ｅＮＢは、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定した場合、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信する。
2014522135.tif 000002
【特許請求の範囲】
【請求項１】
下りリンク・サブフレームを変換するために構成されたｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）であって、前記ｅＮＢは、
プロセッサ；
前記プロセッサと電子通信状態にあるメモリ；
前記メモリに記憶された命令であって、前記命令は、
対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定する；および
前記対象下りリンク・サブフレームを前記スペシャル・サブフレーム・タイプ２に変換すると判定した場合、前記対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信する
ために実行可能である、命令、
を含むｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）。
【請求項２】
前記対象下りリンク・サブフレームを前記スペシャル・サブフレーム・タイプ２に変換すると判定した場合、前記命令は、
上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在するかどうかを判定する；および
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記対象下りリンク・サブフレームを、物理下りリンク制御チャネル（ＰＤＣＣＨ）を持つ前記スペシャル・サブフレーム・タイプ２に変換する
ためにさらに実行可能である、請求項１に記載のｅＮＢ。
【請求項３】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在しなければ、前記命令は、
前記対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する；
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続けば、前記対象下りリンク・サブフレームを、ガード期間（ＧＰ）を持たず、前記物理下りリンク制御チャネル（ＰＤＣＣＨ）を持たない前記スペシャル・サブフレーム・タイプ２に変換する；および
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続かなければ、前記対象下りリンク・サブフレームを、前記ＧＰを持ち、前記ＰＤＣＣＨを持たない前記スペシャル・サブフレーム・タイプ２に変換する
ためにさらに実行可能である、請求項２に記述のｅＮＢ。
【請求項４】
前記対象下りリンク・サブフレームを前記スペシャル・サブフレーム・タイプ２に変換すべきかどうかの判定は、トラフィック負荷に基づく、請求項１に記述のｅＮＢ。
【請求項５】
前記ＰＨＹレイヤ通知は、前記対象下りリンク・サブフレームの４サブフレーム前にあるサブフレームで送信され、前記命令は、前記対象下りリンク・サブフレームの６サブフレーム後にあるサブフレームで肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）データを送信するためにさらに実行可能である、請求項１に記述のｅＮＢ。
【請求項６】
信号を受信するために構成された端末装置（ＵＥ）であって、前記ＵＥは、
プロセッサ；
前記プロセッサと電子通信状態にあるメモリ；
前記メモリに記憶された命令であって、前記命令は、
対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を受信する；および
前記対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換するために実行可能である、命令、
を含む、端末装置（ＵＥ）。
【請求項７】
前記命令は、
上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在するかどうかを判定する；および
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記対象下りリンク・サブフレームを、物理下りリンク制御チャネル（ＰＤＣＣＨ）を持つ前記スペシャル・サブフレーム・タイプ２に変換する
ためにさらに実行可能である、請求項６に記述のＵＥ。
【請求項８】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在しなければ、前記命令は、
前記対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する；
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続けば、前記対象下りリンク・サブフレームを、ガード期間（ＧＰ）を持たず、前記ＰＤＣＣＨを持たない前記スペシャル・サブフレーム・タイプ２に変換する；および
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続かなければ、前記対象下りリンク・サブフレームを、前記ＧＰを持ち、前記ＰＤＣＣＨを持たない前記スペシャル・サブフレーム・タイプ２に変換する
ためにさらに実行可能である、請求項７に記述のＵＥ。
【請求項９】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記命令は、
ＲＢの数が１０以下であるかどうかを判定する；
ＲＢの前記数が１０以下でなければ、前記ＰＤＣＣＨのために１つの直交周波数分割多重（ＯＦＤＭ）シンボルを予約する；および
リソースブロック（ＲＢ）の前記数が１０以下であれば、前記ＰＤＣＣＨのために２つのＯＦＤＭシンボルを予約する
ためにさらに実行可能である、請求項７に記述のＵＥ。
【請求項１０】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記命令は、
最小ＰＤＣＣＨサイズを仮定して、データ符号化および多重化を行う；
物理制御フォーマット・インジケータ・チャネル（ＰＣＦＩＣＨ）が、前記最小ＰＤＣＣＨサイズに等しいサイズを指示するかどうかを判定する；
前記ＰＣＦＩＣＨが前記ＰＤＣＣＨサイズに等しくないサイズを指示すれば、前記スペシャル・サブフレーム・タイプ２からのデータをパンクチャする；および
前記ＰＣＦＩＣＨが前記ＰＤＣＣＨサイズに等しいサイズを指示すれば、前記符号化および多重化されたデータを変更なしに送信する
ためにさらに実行可能である、請求項７に記述のＵＥ。
【請求項１１】
前記ＰＨＹレイヤ通知は、前記対象下りリンク・サブフレームの４サブフレーム前にあるサブフレームで受信され、前記命令は、前記対象下りリンク・サブフレームの６サブフレーム後にあるサブフレームで肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）データを受信するためにさらに実行可能である、請求項６に記述のＵＥ。
【請求項１２】
下りリンク・サブフレームを変換するための方法であって、前記方法は、
対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定するステップ；および
前記対象下りリンク・サブフレームを前記スペシャル・サブフレーム・タイプ２に変換すると判定した場合、前記対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信するステップ、
を含む、方法。
【請求項１３】
前記対象下りリンク・サブフレームを前記スペシャル・サブフレーム・タイプ２に変換すると判定した場合、前記方法は、
上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在するかどうかを判定するステップ；および
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記対象下りリンク・サブフレームを、物理下りリンク制御チャネル（ＰＤＣＣＨ）を持つ前記スペシャル・サブフレーム・タイプ２に変換するステップ、
をさらに含む、請求項１２に記述の方法。
【請求項１４】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在しなければ、前記方法は、
前記対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定するステップ；
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続けば、前記対象下りリンク・サブフレームを、ガード期間（ＧＰ）を持たず、前記物理下りリンク制御チャネル（ＰＤＣＣＨ）を持たない前記スペシャル・サブフレーム・タイプ２に変換するステップ；および
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続かなければ、前記対象下りリンク・サブフレームを、前記ＧＰを持ち、前記ＰＤＣＣＨを持たない前記スペシャル・サブフレーム・タイプ２に変換するステップ、
をさらに含む、請求項１３に記述の方法。
【請求項１５】
前記対象下りリンク・サブフレームを前記スペシャル・サブフレーム・タイプ２に変換すべきかどうかの判定は、トラフィック負荷に基づく、請求項１２に記述の方法。
【請求項１６】
前記ＰＨＹレイヤ通知は、前記対象下りリンク・サブフレームの４サブフレーム前にあるサブフレームで送信され、前記方法は、肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）データを、前記対象下りリンク・サブフレームの６サブフレーム後にあるサブフレームで送信するステップをさらに含む、請求項１２に記述の方法。
【請求項１７】
信号を受信するための方法であって、
対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を受信するステップ；および
前記対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換するステップ、
を含む、方法。
【請求項１８】
上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在するかどうかを判定するステップ；および
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記対象下りリンク・サブフレームを、物理下りリンク制御チャネル（ＰＤＣＣＨ）を持つ前記スペシャル・サブフレーム・タイプ２に変換するステップ、
をさらに含む、請求項１７に記述の方法。
【請求項１９】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在しなければ、前記方法は、
前記対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定するステップ；
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続けば、前記対象下りリンク・サブフレームを、ガード期間（ＧＰ）を持たず、前記ＰＤＣＣＨを持たない前記スペシャル・サブフレーム・タイプ２に変換するステップ；および
前記対象下りリンク・サブフレームが前記上りリンク・サブフレームのすぐ後に続かなければ、前記対象下りリンク・サブフレームを、前記ＧＰを持ち、前記ＰＤＣＣＨを持たない前記スペシャル・サブフレーム・タイプ２に変換するステップ、
をさらに含む、請求項１８に記述の方法。
【請求項２０】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記方法は、
リソースブロック（ＲＢ）の数が１０以下であるかどうかを判定するステップ；
ＲＢの前記数が１０以下でなければ、前記ＰＤＣＣＨのために１つの直交周波数分割多重（ＯＦＤＭ）シンボルを予約するステップ；および
ＲＢの前記数が１０以下であれば、前記ＰＤＣＣＨのために２つのＯＦＤＭシンボルを予約するステップ、
をさらに含む、請求項１８に記述の方法。
【請求項２１】
前記上りリンク−下りリンク対応付けが前記対象下りリンク・サブフレームに対して存在すれば、前記方法は、
最小ＰＤＣＣＨサイズを仮定して、データ符号化および多重化を行うステップ；
物理制御フォーマット・インジケータ・チャネル（ＰＣＦＩＣＨ）が前記最小ＰＤＣＣＨサイズに等しいサイズを指示するかどうかを判定するステップ；
前記ＰＣＦＩＣＨが前記最小ＰＤＣＣＨサイズに等しくないサイズを指示すれば、前記スペシャル・サブフレーム・タイプ２からのデータをパンクチャするステップ；および
前記ＰＣＦＩＣＨが前記最小ＰＤＣＣＨサイズに等しいサイズを指示すれば、前記符号化および多重化されたデータを変更なしに送信するステップ、
をさらに含む、請求項１８に記述の方法。
【請求項２２】
前記ＰＨＹレイヤ通知は、前記対象下りリンク・サブフレームの４サブフレーム前にあるサブフレームで受信され、前記方法は、前記対象下りリンク・サブフレームの６サブフレーム後にあるサブフレームで肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）データを受信するステップをさらに含む、請求項１７に記述の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に通信システムに関する。より具体的には、本開示は、下りリンク・サブフレームを変換するためのデバイスに関する。
【背景技術】
【０００２】
ワイヤレス通信デバイスは、消費者ニーズを満たし、可搬性と便利さとを改善するために、より小さく、より強力になった。消費者は、ワイヤレス通信デバイスに依存するようになり、高信頼性のサービス、受信可能エリアの拡大、および機能性の増加を期待するようになった。ワイヤレス通信システムは、多くのワイヤレス通信デバイスに通信を提供し、デバイスのそれぞれが基地局によるサービスを享受する。基地局は、ワイヤレス通信デバイスと通信する固定局である。
【０００３】
ワイヤレス通信デバイスが進歩するにつれて、通信容量、速度および／または効率の向上が求められてきた。しかしながら、通信容量、速度および／または効率の向上は、いくつかの問題を提起することがある。
【０００４】
例えば、ワイヤレス通信デバイスは、通信構造を用いて１つ以上のデバイスと通信する。しかしながら、用いられる通信構造は、限られたフレキシビリティおよび／または効率を提供するにすぎない。この議論によって説明されるように、フレキシビリティおよび／または効率を向上させるシステムおよび方法が有益である。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明に従って、下りリンク・サブフレームを変換するために構成されたｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）が提供される。ｅＮＢは、プロセッサ、プロセッサと電子通信状態にあるメモリ、メモリに記憶された命令を含み、この命令は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換するべきかどうかを判定して、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定した場合、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信するために実行可能である。
【０００６】
本発明に従って、信号を受信するために構成された端末装置（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）が提供される。ＵＥは、プロセッサ、プロセッサと電子通信状態にあるメモリ、メモリに記憶された命令を含み、この命令は、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ：Ｐｈｙｓｉｃａｌ）レイヤ通知を受信して、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換するために実行可能である。
【０００７】
本発明に従って、下りリンク・サブフレームを変換するための方法が提供される。この方法は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定するステップと、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定した場合、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信するステップとを含む。
【０００８】
本発明に従って、信号を受信するための方法が提供される。本方法は、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を受信するステップと、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換するステップとを含む。
【図面の簡単な説明】
【０００９】
【図１】下りリンク・サブフレームを変換するためのシステムおよび方法が実装される、ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）および１つ以上の端末装置（ＵＥ）の一構成を示すブロック図である。
【図２】ｅＮＢ上で下りリンク・サブフレームを変換するための方法の一構成を示すフロー図である。
【図３】ＵＥ上で下りリンク・サブフレームを変換する信号を受信する方法の一構成を示すフロー図である。
【図４】物理下りリンク制御チャネル（ＰＤＣＣＨ：ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）の長さを決定する方法の一構成を示すフロー図である。
【図５】物理下りリンク制御チャネル（ＰＤＣＣＨ）の長さを決定する方法の別の構成を示すフロー図である。
【図６】本明細書に開示されるシステムおよび方法に従って用いられるとよい無線フレームの一例を示す図である。
【図７】上りリンク−下りリンク対応付けの例を示す図である。
【図８】スペシャル・サブフレーム・タイプ２（Ｓ２）の構造を示す図である。
【図９】本明細書に開示されるシステムおよび方法による下りリンク・サブフレーム変換の一例を示す図である。
【図１０】本明細書に開示されるシステムおよび方法による下りリンク・サブフレーム変換の別の例を示す図である。
【図１１】端末装置（ＵＥ）に利用される様々なコンポーネントを示す。
【図１２】ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）に利用される様々なコンポーネントを示す。
【発明を実施するための形態】
【００１０】
下りリンク・サブフレームを変換するように構成されたｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）が開示される。ｅＮＢは、プロセッサ、およびプロセッサと電子通信状態にあるメモリに記憶された実行可能な命令を含む。ｅＮＢは、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定する。ｅＮＢは、また、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定した場合、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信する。対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかの判定は、トラフィック負荷に基づくとよい。
【００１１】
対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定した場合、ｅＮＢはさらに、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定する。ｅＮＢは、また、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、対象下りリンク・サブフレームを、物理下りリンク制御チャネル（ＰＤＣＣＨ：ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）を持つスペシャル・サブフレーム・タイプ２に変換する。
【００１２】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、ｅＮＢは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する。ｅＮＢは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、対象下りリンク・サブフレームを、ガード期間（ＧＰ：ｇｕａｒｄ  ｐｅｒｉｏｄ）を持たず、物理下りリンク制御チャネル（ＰＤＣＣＨ）を持たないスペシャル・サブフレーム・タイプ２に変換する。さらに、ｅＮＢは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、対象下りリンク・サブフレームを、ＧＰを持ち、ＰＤＣＣＨを持たないスペシャル・サブフレーム・タイプ２に変換する。
【００１３】
ＰＨＹレイヤ通知は、対象下りリンク・サブフレームの４サブフレーム前にあるサブフレームで送信される。ｅＮＢは、肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ：Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  ａｎｄ  Ｎｅｇａｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）データを、対象下りリンク・サブフレームの６サブフレーム後にあるサブフレームで送信することもできる。
【００１４】
信号を受信するために構成された端末装置（ＵＥ）も開示される。ＵＥは、プロセッサ、およびプロセッサと電子通信状態にあるメモリに記憶された実行可能な命令を含む。ＵＥは、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を受信する。ＵＥは、また、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換する。
【００１５】
ＵＥは、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定することもできる。ＵＥは、さらに、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、対象下りリンク・サブフレームを、物理下りリンク制御チャネル（ＰＤＣＣＨ）を持つスペシャル・サブフレーム・タイプ２に変換する。
【００１６】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、ＵＥは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する。ＵＥは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、対象下りリンク・サブフレームを、ガード期間（ＧＰ）を持たず、ＰＤＣＣＨを持たないスペシャル・サブフレーム・タイプ２に変換する。ＵＥは、また、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、対象下りリンク・サブフレームを、ＧＰを持ち、ＰＤＣＣＨを持たないスペシャル・サブフレーム・タイプ２に変換する。
【００１７】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、ＵＥは、リソースブロック（ＲＢ：ｒｅｓｏｕｒｃｅ  ｂｌｏｃｋ）の数が１０以下であるかどうかを判定する。ＵＥは、また、ＲＢの数が１０以下でなければ、ＰＤＣＣＨのために１つの直交周波数分割多重（ＯＦＤＭ：ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）シンボルを予約する。ＵＥは、さらに、ＲＢの数が１０以下であれば、ＰＤＣＣＨのために２つのＯＦＤＭシンボルを予約する。
【００１８】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、ＵＥは、最小ＰＤＣＣＨサイズを仮定して、データ符号化および多重化を行い、物理制御フォーマット・インジケータ・チャネル（ＰＣＦＩＣＨ：ｐｈｙｓｉｃａｌ  ｃｏｎｔｒｏｌ  ｆｏｒｍａｔ  ｉｎｄｉｃａｔｏｒ  ｃｈａｎｎｅｌ）が、最小ＰＤＣＣＨサイズに等しいサイズを指示するかどうかを判定することもできる。ＵＥは、ＰＣＦＩＣＨが最小ＰＤＣＣＨのサイズに等しくないサイズを指示すれば、スペシャル・サブフレーム・タイプ２からのデータをパンクチャする。ＵＥは、また、ＰＣＦＩＣＨが最小ＰＤＣＣＨサイズに等しいサイズを指示すれば、符号化および多重化されたデータを変更なしに送信する。
【００１９】
ＰＨＹレイヤ通知は、対象下りリンク・サブフレームの４サブフレーム前にあるサブフレームで受信される。ＵＥは、肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）データを、対象下りリンク・サブフレームの６サブフレーム後にあるサブフレームで受信することもできる。
【００２０】
下りリンク・サブフレームを変換するための方法も開示される。本方法は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定することを含む。本方法は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定した場合、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信することも含む。
【００２１】
信号を受信するための方法も開示される。本方法は、対象下りリンク・サブフレームに関連するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を受信することを含む。本方法は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換することも含む。
【００２２】
「３ＧＰＰ」とも呼ばれる、第３世代パートナーシップ・プロジェクト（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）は、第３および第４世代ワイヤレス通信システムに関する世界的に適用可能な技術仕様および技術レポートを規定することを目指した連携合意である。３ＧＰＰは、次世代モバイルネットワーク、システムおよびデバイスに関する仕様を規定する。
【００２３】
３ＧＰＰロング・ターム・エボリューション（ＬＴＥ：Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）は、将来の要求に対処するためのユニバーサル・モバイル通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）モバイルフォンまたはデバイスの規格を改善するプロジェクトに与えられた名称である。一様態において、ＵＭＴＳは、進化型ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ：Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）および進化型ユニバーサル地上無線アクセス・ネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）に関するサポートおよび仕様を提供するために修正された。
【００２４】
本明細書に開示されるシステムおよび方法の少なくともいくつかの様態は、３ＧＰＰロング・ターム・エボリューション（ＬＴＥ）、ＬＴＥアドバンスト（ＬＴＥ−Ａ：ＬＴＥ−Ａｄｖａｎｃｅｄ）および他の規格（例えば、３ＧＰＰリリース８、９、１０および／または１１）に関連して記述される。しかしながら、本開示の範囲は、この点で限定されるべきではない。本明細書に開示されるシステムおよび方法の少なくともいくつかの様態は、他のタイプのワイヤレス通信システムにおいて利用されてもよい。
【００２５】
ワイヤレス通信デバイスは、音声および／またはデータを基地局へ通信するために用いられ、次には基地局がデバイスのネットワーク（例えば、公衆交換電話網（ＰＳＴＮ：ｐｕｂｌｉｃ  ｓｗｉｔｃｈｅｄ  ｔｅｌｅｐｈｏｎｅ  ｎｅｔｗｏｒｋ）、インターネットなど）と通信する、電子デバイスである。本明細書においてシステムおよび方法を記述するとき、ワイヤレス通信デバイスは、代わりに移動局、端末装置（ＵＥ）、アクセス端末、加入者局、移動端末、遠隔局、ユーザ端末、端末、加入者ユニット、モバイルデバイスなどと呼ばれることもある。ワイヤレス通信デバイスの例は、セルラーフォン、スマートフォン、パーソナル・ディジタル・アシスタント（ＰＤＡ：ｐｅｒｓｏｎａｌ  ｄｉｇｉｔａｌ  ａｓｓｉｓｔａｎｔ）、ラップトップコンピュータ、ネットブック、電子書籍リーダ、ワイヤレス・モデムなどを含む。３ＧＰＰ仕様書では、ワイヤレス通信デバイスは、典型的に端末装置（ＵＥ）と呼ばれる。しかしながら、本開示の範囲は、３ＧＰＰ規格に限定されるべきではないので、より一般的な用語「ワイヤレス通信デバイス」を意味するために、本明細書では用語「ＵＥ」および「ワイヤレス通信デバイス」が同義で用いられる。
【００２６】
３ＧＰＰ仕様書では、基地局は、典型的にＮｏｄｅ  Ｂ、ｅｖｏｌｖｅｄまたはｅｎｈａｎｃｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）、ｈｏｍｅ  ｅｎｈａｎｃｅｄまたはｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ＨｅＮＢ）、あるいはいくつか他の同様の用語法で呼ばれる。本開示の範囲は、３ＧＰＰ規格に限定されるべきではないので、より一般的な用語「基地局」を意味するために、本明細書では、用語「基地局」、「Ｎｏｄｅ  Ｂ」、「ｅＮＢ」、および「ＨｅＮＢ」が同義で用いられる。そのうえ、用語「基地局」は、アクセスポイントを示すために用いられてもよい。アクセスポイントは、ワイヤレス通信デバイスのためにネットワーク（例えば、ローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットなど）へのアクセスを提供する電子デバイスである。用語「通信デバイス」は、ワイヤレス通信デバイスおよび／または基地局の両方を示すために用いられる。
【００２７】
留意すべきは、本明細書において、「セル」は、インターナショナル・モバイル・テレコミュニケーションズ−アドバンスト（ＩＭＴ−Ａｄｖａｎｃｅｄ：Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ−Ａｄｖａｎｃｅｄ）に用いるために、正規化または規制団体によって仕様が定められた任意の通信チャネルであり、Ｎｏｄｅ  Ｂ（例えば、ｅＮｏｄｅＢ）とＵＥとの間の通信に用いることが認可された帯域として、そのすべてまたはそのサブセットが、３ＧＰＰによって採用されている。「構成されたセル」は、ＵＥがそれを関知して、情報を送信または受信することがＮｏｄｅ  Ｂ（例えば、ｅＮＢ）によって許可されたセルである。「構成されたセル（単数または複数）」は、サービングセル（単数または複数）であってもよい。ＵＥは、すべての構成されたセル上でシステム情報を受信し、必要とされる測定を行う。「アクティブ化されたセル」は、ＵＥが送信および受信を行う構成されたセルである。すなわち、アクティブ化されたセルは、ＵＥが物理下りリンク制御チャネル（ＰＤＣＣＨ）をモニターする対象のセルであり、下りリンク送信の場合、ＵＥが物理下りリンク共有チャネル（ＰＤＳＣＨ：ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）を復号する対象のセルである。「非アクティブ化されたセル」は、ＵＥが送信ＰＤＣＣＨをモニターしていない構成されたセルである。留意すべきは、様々な次元の観点から「セル」が記述されることである。例えば、「セル」は、時間、空間（例えば、幾何形状）および周波数特性を有する。
【００２８】
本明細書に開示されるシステムおよび方法は、上りリンクおよび下りリンク割当てを動的に変更するために用いられる。ＬＴＥ周波数分割複信（ＦＤＤ：ｆｒｅｑｕｅｎｃｙ−ｄｉｖｉｓｉｏｎ  ｄｕｐｌｅｘｉｎｇ）では、上りリンクおよび下りリンク信号に異なる周波数帯域が用いられる。この場合、ネットワークにおける非対称なトラフィック負荷は、キャリアアグリゲーション（ＣＡ：ｃａｒｒｉｅｒ  ａｇｇｒｅｇａｔｉｏｎ）によって管理される。例えば、トラフィック負荷がより高い方向（例えば、上りリンクまた下りリンク）に対して、より多くの周波数帯域が割当てられる。
【００２９】
ＬＴＥ時分割複信（ＴＤＤ：ｔｉｍｅ−ｄｉｖｉｓｉｏｎ  ｄｕｐｌｅｘｉｎｇ）では、上りリンクおよび下りリンク信号の両方に同じ周波数帯域が用いられる。様々な下りリンクおよび上りリンク・トラフィック比を実現するために、３ＧＰＰ仕様書（例えば、３ＧＰＰ  ＴＳ  ３６．２１１）では７つの上りリンクおよび下りリンク（ＵＬ−ＤＬ）構成が規定されている。これらの割当ては、下りリンク信号に４０％から９０％の間のサブフレームを割当てることができる。
【００３０】
現行の仕様書（例えば、ＬＴＥリリース８、９および１０）に従って、ＵＬ−ＤＬ構成を変更するためには、システム情報変更手順が用いられる。この手順は、長い遅延を有し、しかもコールド・システム・リスタートを必要とする（例えば、旧構成の上りリンク−下りリンク対応付けを切り離して新しい対応付けを設定するために、ある期間にわたって、システムにおけるすべてのＵＥが送信および受信できない）。留意すべきは、サブフレーム対応付けは、「上りリンク−下りリンク対応付け」と呼ばれてもよく、上りリンクから下りリンク・サブフレームへの対応付け、および／または下りリンクから上りリンク・サブフレームへの対応付けを含むことである。対応付けの例は、下りリンク・サブフレーム物理下りリンク制御チャネル（ＰＤＣＣＨ）の、上りリンク・サブフレームにおける上りリンク電力制御への対応付け、下りリンク・サブフレーム物理下りリンク制御チャネル（ＰＤＣＣＨ）の、上りリンク・サブフレームにおける物理上りリンク共有チャネル（ＰＵＳＣＨ：ｐｈｙｓｉｃａｌ  ｕｐｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）割当てへの対応付け、下りリンク・サブフレーム（単数または複数）での物理下りリンク共有チャネル（ＰＤＳＣＨ）送信に対する、上りリンク・サブフレーム（単数または複数）上の肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）フィードバックの対応付け、上りリンク・サブフレーム（単数または複数）での物理上りリンク共有チャネル（ＰＵＳＣＨ）送信（単数または複数）に対する、物理ハイブリッド自動再送要求（ＨＡＲＱ）インジケータ・チャネル（ＰＨＩＣＨ：ｐｈｙｓｉｃａｌ  ｈｙｂｒｉｄ  ａｕｔｏｍａｔｉｃ  ｒｅｐｅａｔ  ｒｅｑｕｅｓｔ  （ＨＡＲＱ）  ｉｎｄｉｃａｔｏｒ  ｃｈａｎｎｅｌ）または物理下りリンク制御チャネル（ＰＤＣＣＨ）上の肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）フィードバックの対応付けを含む。
【００３１】
システム情報変更手順を用いたＵＬ−ＤＬ構成の変更は、システムにとって極めて高コストである。そのうえ、近隣セルも構成を変更する必要があるとき、波及効果によってＵＬ−ＤＬ構成を変更することがさらに複雑になる。加えて、近隣セルにおける異なるＵＬ−ＤＬ構成によって干渉問題が生じることもある。さらに、現在の準静的割当てが瞬間的なトラフィック状況に合致することも、しないこともある。
【００３２】
現行の仕様書において、標準的スペシャル・サブフレームは、短縮された、または最小限（例えば、１つかまたは２つのシンボル）の時間を上りリンク信号に割当てる、下りリンクから上りリンクへの切り替えのために用いられる。チャネル・リソースの大部分は、下りリンク送信に割当てられる。上りリンク・サブフレームのタイミングが下りリンク・サブフレームのタイミングより早いので、このスペシャル・サブフレームは、下りリンクから上りリンクへの移行部にギャップまたはガード期間（ＧＰ）を用いることによって、下りリンクと上りリンクとの送信の重なりを回避するように設計されている。
【００３３】
３ＧＰＰ会合において、下りリンクと上りリンクとの干渉管理およびトラフィック適応に関するＬＴＥ  ＴＤＤのさらなる強化を検討するために、新しい検討項目が承認された。この検討項目の１つの目的は、孤立セルと複数セルとの両方のシナリオに対して、トラフィック状態に依存した上りリンク−下りリンク再構成の利点を評価することである。本明細書に開示されるシステムおよび方法は、上りリンク−下りリンク再構成に対処するものである。
【００３４】
現行のＬＴＥ  ＴＤＤシステムにおいて、上りリンクおよび下りリンク割当ては、７つの規定された構成から選ばれ、システム全体が同期される。現時点で、セルにおける上りリンク−下りリンク割当て再構成は、上りリンク−下りリンク対応付けを調整するためにすべての送信を停止しなければならないので、極めて高コストである。１つのセルにおける変更は、近接セル（およびそれらの近接セルなど）における上りリンク−下りリンク構成の同期を一致させるために近接セル（およびそれらの近接セルなど）における変化の連鎖を生じるか、あるいは伴うことがある。そのうえ、現行の上りリンク−下りリンク割当て再構成は、システム情報変更を必要とし、延いてはこの変更が長い遅延を有し、トラフィック負荷における瞬間的または短期的な変化に適応することができない。
【００３５】
動的な上りリンクおよび下りリンク割当てをサポートし、一方では（例えば、システム情報変更を用いた）上りリンク−下りリンク割当て再構成を短縮するために、本明細書に開示されるシステムおよび方法は、物理レイヤ（例えば、ＰＨＹレイヤ）通知を用いて、トラフィック適応により上りリンクおよび下りリンク割当てを変更することを記述する。上りリンクから下りリンク、および下りリンクから上りリンクへの変換の影響が本明細書において検討される。下りリンクから上りリンクへの動的な変換は、物理レイヤの既存の上りリンク−下りリンク対応付けを拡張することによって実現される。
【００３６】
本明細書に開示されるシステムおよび方法は、新しいスペシャル・サブフレームを定義する。この新しいスペシャル・サブフレームは、本明細書では「スペシャル・サブフレーム・タイプ２」と呼ばれる。スペシャル・サブフレーム・タイプ２は、現構成の下りリンク・サブフレームでの物理上りリンク共有チャネル（ＰＵＳＣＨ）の送信をサポートする。スペシャル・サブフレーム・タイプ２は、物理下りリンク制御チャネル（ＰＤＣＣＨ）を必要に応じて維持する一方で、大部分のチャネル・リソースをＰＵＳＣＨ送信に割当てる。本明細書に開示されるシステムおよび方法は、スペシャル・サブフレーム・タイプ２のための詳細な構造および構成手順を提供する。そのうえ、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変更する（例えば、変換または再構成する）ための手順および通知が提示される。一構成において、本明細書に開示されるシステムおよび方法は、すべての既存の上りリンク−下りリンク対応付けを維持し、レガシーＵＥ（例えば、以前の仕様書に従って機能するＵＥ）に対して透過的である。従って、場合によっては、（システム情報変更による）いかなる上りリンク−下りリンク割当て再構成手順も必要としない。
【００３７】
本明細書に開示されるシステムおよび方法のいくつか独自な様態は、既存の上りリンク下りリンク対応付けを変更することなく、上りリンクおよび下りリンク割当てを動的に変更するために、物理レイヤ通知を用いること、および過渡的かつ一時的なサブフレーム変換のための新しいスペシャル・サブフレーム・タイプ２を規定することを含む。そのうえ、これらは、スペシャル・サブフレーム・タイプ２の構造、構成、および構成を決定するための手順を規定することを含む。加えて、これらは、スペシャル・サブフレーム・タイプ２に対する制御通知対応付けのための手順、およびより大きな上りリンク・トラフィックを受け入れるために下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に動的に変換または再構成するための手順を規定することを含む。
【００３８】
明確さのために、本明細書に開示されるシステムおよび方法に従って用いられるフレーム構造の一例が、３ＧＰＰ  ＴＳ  ３６．２１１から以下のように示される。このフレーム構造は、時分割複信（ＴＤＤ）手法に適用可能である。各フレームは
Ｔｆ＝３０７２００・Ｔｓ＝１０
ミリ秒（ｍｓ）の長さを有し、ここで
Ｔｆ
は無線フレーム持続時間であり、
Ｔｓ
は
【００３９】
【数１】
2014522135.tif 000003
【００４０】
秒に等しい時間単位である。フレームは、
１５３６００・Ｔｓ＝５
ｍｓの長さをそれぞれが有する２つの半フレームを含む。各半フレームは、
３０７２０・Ｔｓ＝１
ｍｓの長さをそれぞれが有する５つのサブフレームを含む。いくつかのＵＬ−ＤＬフレーム構成は、以下の表（１）に示される。
【００４１】
【表１】
2014522135.tif 000004
【００４２】
表（１）では、無線フレームにおける各サブフレームに関連して、「Ｄ」は、サブフレームが下りリンク送信のために予約されていることを示し、「Ｕ」は、サブフレームが上りリンク送信のために予約されていることを示し、「Ｓ」は、３つのフィールド：下りリンク・パイロット時間スロット（ＤｗＰＴＳ：ｄｏｗｎｌｉｎｋ  ｐｉｌｏｔ  ｔｉｍｅ  ｓｌｏｔ）、ガード期間（ＧＰ）および上りリンク・パイロット時間スロット（ＵｐＰＴＳ：ｕｐｌｉｎｋ  ｐｉｌｏｔ  ｔｉｍｅ  ｓｌｏｔ）を持つスペシャル・サブフレームを示す。ＤｗＰＴＳおよびＵｐＰＴＳの長さは、ＤｗＰＴＳ、ＧＰおよびＵｐＰＴＳの全長が
３０７２０・Ｔｓ＝１
ｍｓに等しいことを前提として、３ＧＰＰ  ＴＳ  ３６．２１１の表４．２−１に示される。各サブフレームｉは、各サブフレームにおける長さが
Ｔｓｌｏｔ＝１５３６０・Ｔｓ＝０．５
ｍｓの２つのスロット
２ｉ
および
２ｉ＋１
として定義される。
【００４３】
下りリンクから上りリンクへの切り替えポイント周期が５ｍｓおよび１０ｍｓの両方のＵＬ−ＤＬ構成がサポートされる。下りリンクから上りリンクへの切り替えポイント周期が５ｍｓの場合、スペシャル・サブフレームは、両方の半フレームに存在する。下りリンクから上りリンクへの切り替えポイント周期が１０ｍｓの場合、スペシャル・サブフレームは、第１の半フレームだけに存在する。サブフレーム０および５ならびにＤｗＰＴＳは、下りリンク送信のために予約される。ＵｐＰＴＳおよびスペシャル・サブフレームのすぐ後に続くサブフレームは、上りリンク送信のために予約される。複数のセルがアグリゲートされた場合、ＵＥは、すべてのセルにわたって同じＵＬ−ＤＬ構成を仮定し、異なったセルにおけるスペシャル・サブフレームのガード期間が少なくとも
１４５６・Ｔｓ
の重なりを有すると仮定する。
【００４４】
ＵＬ−ＤＬ構成は、サブフレーム割当ておよびｓｐｅｃｉａｌＳｕｂｆｒａｍｅＰａｔｔｅｒｎｓを含む情報要素（ＩＥ：ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ）ＴＤＤ−Ｃｏｎｆｉｇによって定義されるＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋＴｙｐｅ１（ＳＩＢ１）の一部であってもよい。ＳＩＢ１は、論理チャネルとしてのブロードキャスト制御チャネル上で送信される。ＵＬ−ＤＬ構成を変更するために、システム情報変更手順が実行されることがある。
【００４５】
いくつかのＴＤＤ構成および再構成の課題が以下に記述される。ＴＤＤ構成は、対になった周波数帯域を必要としない。従って、ＴＤＤ構成の１つの利点は、帯域幅割当てのフレキシビリティにある。ＴＤＤ構成において、フレームは、１０個のサブフレームを有する。下りリンクから上りリンクへの切り替えポイント周期が５ｍｓおよび１０ｍｓの両方のＵＬ−ＤＬ構成がサポートされる。３ＧＰＰ規格では、７つのＵＬ−ＤＬ構成が規定されている。上りリンクおよび下りリンク送信の間の干渉を回避するために、システム全体にわたる同期が必要である。それゆえに、すべてのｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）およびすべてのＵＥは、同じＵＬ−ＤＬ構成およびタイミングに従う。
【００４６】
現行の仕様書（例えば、ＬＴＥリリース８、９および１０）では、ＵＬ−ＤＬ構成を変更するために、システム情報変更手順が用いられる。この処理は、複数のブロードキャスト・チャネル間隔を必要とし、延いては長い遅延を有し、瞬間的なトラフィック負荷の変化に適応することができない。上りリンクおよび下りリンク割当ての再構成は、極めて高コストである。異なる上りリンク−下りリンク対応付けゆえに、旧構成の上りリンク−下りリンク対応付けを切り離して新しい対応付けを設定するためには、すべての送信機が送信をすっかり停止しなければならない。該対応付けの例は、上りリンク電力制御、ＰＵＳＣＨ対応付け、ＡＣＫ／ＮＡＣＫフィードバック、ＰＨＩＣＨ対応付けなどを含む。これは、システム能力の莫大な損失とユーザ・トラフィックの中断とをもたらす。そのうえ、１つのセルにおける変更は、近接セルにそれらのＵＬ−ＤＬ構成の変更を強いることがある。かくして、「波及」効果が発生しかねない。
【００４７】
ＦＤＤ構成では、上りリンク−下りリンク対応付けが簡単である。例えば、通常のＨＡＲＱ動作を用いたＦＤＤ構成において、ＵＥを対象とするサブフレームｎでのＰＵＳＣＨ電力制御およびＰＵＳＣＨ送信は、サブフレームｎ−４における下りリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｉｎｆｏｒｍａｔｉｏｎ）フォーマット０を持つＰＤＣＣＨによって、あるいはサブフレームｎ−４におけるＰＨＩＣＨによってスケジューリングされる。サブフレームｎでのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫフィードバックは、サブフレームｎ＋４におけるＰＨＩＣＨまたはＰＤＣＣＨ上で指示される。サブフレームｋでの物理下りリンク共有チャネル（ＰＤＳＣＨ）送信のＡＣＫ／ＮＡＣＫフィードバックは、サブフレームｋ＋４における物理上りリンク制御チャネル（ＰＵＣＣＨ）または物理上りリンク共有チャネル（ＰＵＳＣＨ）上でＵＥによってレポートされる。
【００４８】
あるＬＴＥ  ＴＤＤ構成では、サブフレームが、時間領域で上りリンクと下りリンクとに割当てられる。ＵＬ−ＤＬ構成ゆえに、４つに固定されたサブフレーム対応付けは、保証されない。例えば、ＵＬ−ＤＬ構成０では、サブフレーム２および３に関して、ＰＤＣＣＨは、それぞれ６および７サブフレーム後の上りリンク・サブフレームでのＰＵＳＣＨ送信をスケジューリングする。従って、上りリンク−下りリンク対応付けが非常に複雑になりかねず、様々なＵＬ−ＤＬ構成に対して様々な対応付け構成が適応されることがある。
【００４９】
対応付けの例は、下りリンク・サブフレーム物理下りリンク制御チャネル（ＰＤＣＣＨ）の、上りリンク・サブフレームにおける上りリンク電力制御への対応付け、下りリンク・サブフレーム物理下りリンク制御チャネル（ＰＤＣＣＨ）の、上りリンク・サブフレームにおける物理上りリンク共有チャネル（ＰＵＳＣＨ）割当てへの対応付け、下りリンク・サブフレーム（単数または複数）での物理下りリンク共有チャネル（ＰＤＳＣＨ）送信に対する、上りリンク・サブフレーム（単数または複数）上の肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）フィードバックの対応付け、上りリンク・サブフレーム（単数または複数）での物理上りリンク共有チャネル（ＰＵＳＣＨ）送信（単数または複数）に対する、物理ハイブリッド自動再送要求（ＨＡＲＱ）インジケータ・チャネル（ＰＨＩＣＨ）または物理下りリンク制御チャネル（ＰＤＣＣＨ）上の肯定応答および否定応答（ＡＣＫ／ＮＡＣＫ）フィードバックの対応付けなどを含む。例として、対応付けは、下りリンク・サブフレームが上りリンク・サブフレームにいかに対応するか、および／または、上りリンク・サブフレームが下りリンク・サブフレームにいかに対応するかを特定する。対応付けの一例は、下りリンク・サブフレームが、この下りリンク・サブフレームのいくつかのサブフレーム後に続く上りリンク・サブフレームのために通信をスケジューリングするように特定する。対応付けの別の例は、上りリンク・サブフレームのいくつかのサブフレーム後に続く下りリンク・サブフレームが、この上りリンク・サブフレームに対応するＡＣＫ／ＮＡＣＫフィードバックを含むように特定する。
【００５０】
いくつかの構成において、本明細書に開示されるシステムおよび方法は、現在および／または過去の３ＧＰＰ仕様書によるＴＤＤ上りリンク−下りリンク対応付けを用いる。本明細書におけるシステムおよび方法に従って用いられる上りリンク−下りリンク対応付けのいくつかの例は、３ＧＰＰ  ＴＳ  ３６．２１３の５．１．１．１、７．３、８、８．２、８．３、９．１．２および１０節、ならびに３ＧＰＰ  ＴＳ  ３６．２１１の６．９節に見出される。
【００５１】
システム情報変更手順を用いた従来の上りリンク−下りリンク割当て再構成では、新しい対応付けが生じる前に、先ず古い対応付けが壊されなければならない。結果として、移行期間中はすべての送信が終了されなければならない。これは、チャネル・リソースの甚大な浪費と、サービスの低下および途絶とをもたらす。高いトラフィック負荷変動とともに、システム情報変更手順を用いた頻繁な上りリンク−下りリンク割当て再構成の使用は、重大なネットワーク問題をもたらすであろう。
【００５２】
一例において、ＴＤＤ構成に関する上りリンク−下りリンク対応付けは、単一のサブフレームだけが異なるときでさえ、大きく異なる可能性がある。例として、５ミリ秒（ｍｓ）間隔において１つだけのサブフレームが上りリンクと下りリンクとの間で変換されたＵＬ−ＤＬ構成１と構成２との間の違いは、小さく思われるであろう。しかしながら、これら２つの構成では、いずれの上りリンク−下りリンク対応付けも同じではない。
【００５３】
本明細書に開示されるシステムおよび方法の構成の一例は、以下の通りである。１０個のサブフレーム期間によって、ＴＤＤ  ＵＬ−ＤＬ構成が
ＮＵ
個の上りリンク・サブフレームと、スペシャル・サブフレームを含む
（１０−ＮＵ）
個の下りリンク・サブフレームとを有すると仮定する。ネットワーク・リソースまたは能力が１に正規化され、アグリゲートされた上りリンクおよびアグリゲートされた下りリンク・トラフィック負荷がそれぞれ
λＵ
および
λＤであると仮定する。ここで、
λＵ
および
λＤ
は、チャネル使用のパーセンテージとして正規化された（必要な制御通知を含む）上りリンクおよび下りリンク・トラフィック負荷である。
【００５４】
オペレータは、いくつか所望の負荷比「目標」を持つネットワークを、その収益モデルに対するオペレータの選好に基づいて構成する。実際のシステムのトラフィック特性は、２つの様態を含む。第１の様態は、全トラフィック負荷対能力比であり、式
λ＝（λＵ＋λＤ）
で表される。第２の様態は、上りリンク対下りリンク・トラフィック比であり、次式で表される。
【００５５】
【数２】
2014522135.tif 000005
【００５６】
上りリンク対下りリンク・トラフィック比は、オペレータの目標または所望の負荷比と一致することもしないこともある。
【００５７】
ネットワーク・アグリゲートされたトラフィック負荷対能力比が低いとき、ＵＬ−ＤＬ構成は、上りリンク・トラフィックおよび下りリンク・トラフィック負荷が、割当てられた上りリンク・サブフレームおよび下りリンク・サブフレームによって、次式でそれぞれ示されるようにサポート可能な場合、受け入れ可能である。
【００５８】
【数３】
2014522135.tif 000006
【００５９】
全トラフィック負荷対能力比が、
λ≧１
の場合、システムは、過負荷であるか、または飽和している。ｅＮＢにおけるスケジューラは、優先度と、過負荷になったトラフィック負荷から送信すべきパケットとを決定する責任がある。ネットワーク・アグリゲートされたトラフィック負荷対能力比が高いか、またはシステムが過負荷であるとき、正しい割当ての上りリンク対下りリンク・トラフィック比を持つＵＬ−ＤＬ構成が好ましい。
【００６０】
ＬＴＥ  ＴＤＤ上りリンク−下りリンク構成は、アグリゲートされたネットワーク・トラフィック・フローに対して設計される。各アプリケーションおよび／または各ＵＥのトラフィック特性は、著しく異なることがある。統計的に、ネットワーク・トラフィック負荷（例えば、セルにおけるすべてのＵＥのアグリゲートされたトラフィック負荷）は、個々のＵＥのトラフィック特性と比較して、相対的に安定しており、よりゆっくりと変化する筈である。しかしながら、アグリゲートされたトラフィック負荷は、平均値の周りで大きく変動することがある。一日の異なった時間における平均トラフィック負荷が、著しく変化することもある。いくつかのＵＥがビデオ・ストリーミングおよび大きなファイルのダウンロードのような広帯域のアプリケーションを用いたとき、上りリンクおよび下りリンク比が著しく変わることがある。
【００６１】
再構成は、下記の条件のいずれかを満足しない場合に必要とされる。
【００６２】
【数４】
2014522135.tif 000007
【００６３】
再構成は、現行のＵＬ−ＤＬ構成が上りリンク対下りリンク・トラフィック比に整合しない場合、特に、ネットワーク・アグリゲートされたトラフィック負荷対能力比が高いか、またはシステムが過負荷のときにも必要とされる。現在は、システム情報手順の変更が用いられている。この処理は、無線リソース管理（ＲＲＣ：ｒａｄｉｏ  ｒｅｓｏｕｒｃｅ  ｃｏｎｔｒｏｌ）レイヤ手順である。これは、長時間を要し、瞬間的なトラフィック負荷の変化に対して調整できない。瞬間的なトラフィック負荷の変化が一時的なこともある。ネットワーク構成が変更されるまでに、トラフィック負荷がすでに、再び正常状態に変化していることもある。かくして、また別の再構成が必要とされる。さらに悪いことに、ＴＤＤシステムは、下りリンクおよび上りリンク送信の間の干渉を回避するために、同じＵＬ−ＤＬ構成を有するように設計されているので、１つのセルにおけるＵＬ−ＤＬ構成の変更は、近接セルにおけるＵＬ−ＤＬ構成の変更のきっかけとなる。それゆえに、（システム情報の変更を用いた）ＵＬ−ＤＬ構成の変更は、ＲＲＣレベルで極めて高コストであり、いくつかの場合、これを回避することが有益である。
【００６４】
物理（ＰＨＹ）レイヤの上りリンク−下りリンク再構成に関するいくつかの考察が、以下に詳述される。リアルタイムのトラフィック負荷変動を考慮すると、よりフレキシブルな時間領域の上りリンク−下りリンク再構成が、トラフィック変動特性に追随することができる。かくして、システム情報変更手順の他に、ＰＨＹレイヤの再構成がサポートされる。ＰＨＹレイヤ手順は、大部分の一時的なトラフィック負荷変動を扱う。システム情報変更手順は、トラフィック変化が極めて著しく、ＰＨＹレイヤ手順が変化を扱えないときにだけ用いられる。
【００６５】
ｅＮＢは、チャネル・リソースおよびＵＥの振舞いを完全に制御する。様々な制御情報を運ぶために、いくつかの下りリンク制御情報（ＤＣＩ）フォーマットが規定されている。例えば、ＤＣＩフォーマット０は、物理上りリンク共有チャネル（ＰＵＳＣＨ）のスケジューリングに用いられる。ＤＣＩフォーマット１は、物理下りリンク共有チャネル（ＰＤＳＣＨ）符号語のスケジューリングに用いられる。そのうえ、ＤＣＩフォーマット３は、物理上りリンク制御チャネル（ＰＵＣＣＨ）および物理上りリンク共有チャネル（ＰＵＳＣＨ）に対する、２ビットの電力調整を含んだ送信電力制御（ＴＰＣ：ｔｒａｎｓｍｉｔ  ｐｏｗｅｒ  ｃｏｎｔｒｏｌ）コマンドの送信に用いられる。
【００６６】
下りリンク・サブフレームにおいて、ＵＥは、物理下りリンク制御チャネル（ＰＤＣＣＨ）をモニターし、ＰＤＣＣＨを復号しようと試みる筈である。本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレームｎに位置するＰＤＣＣＨにより、ＰＨＹレイヤ手順を用いて、既存の上りリンクおよび下りリンク割当てを動的に修正し、新しい上りリンク・サブフレームに動的に切り替えられる（例えば、変換または再構成される）下りリンク・サブフレームｎ＋ｋに、ＰＵＳＣＨ送信を割当てることが可能である。そのうえ、サブフレームｎ＋ｋに位置するＰＤＣＣＨを用いて、同じサブフレームｎ＋ｋにおける物理下りリンク共有チャネル（ＰＤＳＣＨ）割当てを短縮または削除することが可能である。現行の仕様書に従って、下りリンク・サブフレームｎに位置するＰＤＣＣＨは、サブフレームｎ＋ｋでのＰＵＳＣＨ送信に対応付けられていない。それゆえに、サブフレームｎにおけるＰＤＣＣＨ検出は、下りリンク・サブフレームｎ＋ｋを上りリンク・サブフレーム（例えば、スペシャル・サブフレーム・タイプ２）に切り替える（例えば、変換または再構成する）ように、ＵＥに暗黙的に指令するために用いることができる。
【００６７】
下りリンク・サブフレームにおけるＰＤＣＣＨおよびＰＨＩＣＨが、ＰＵＳＣＨスケジューリングおよびＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫフィードバックと対応付けられていることがある。この場合、下りリンク制御シンボルが消されることはない（例えば、下りリンク・サブフレームが、上りリンク・サブフレームに完全に変換または再構成されることはできない）。例えば、下りリンク・サブフレームが上りリンク・サブフレームに完全に変換されるとすれば、このＰＵＳＣＨスケジューリングに依存する上りリンク・サブフレーム、および所定の下りリンク・サブフレームにおけるＰＨＩＣＨフィードバックを必要とする上りリンク・サブフレームは、空にされる必要があろう。これは、トラフィック負荷に合せるために上りリンク・サブフレームの数を増やすという目的に矛盾する。
【００６８】
他方、下りリンク・サブフレームにいかなる上りリンク対応付けもない場合（例えば、所定の下りリンク・サブフレームではいかなるＰＵＳＣＨ電力制御、ＰＵＳＣＨスケジューリング、およびいかなるＰＨＩＣＨフィードバックも許可されていないとき）、それが上りリンク・サブフレームの直後に続くのであれば、所定の下りリンク・サブフレームは、上りリンク・サブフレームに完全に変換される。しかしながら、所定のサブフレームが別の下りリンク・サブフレームの後に続くのであれば、上りリンク送信のための時間前進を調整するガード期間が必要とされる。
【００６９】
下りリンクから上りリンクへのサブフレーム変換は、ＰＨＹレイヤ通知によって制御される。すべてのレガシーＵＥ（例えば、３ＧＰＰリリース８、９および／または１０に準拠するＵＥ）は、サブフレームを依然として下りリンク・サブフレームとして指定し、ＰＤＣＣＨを探してそれをモニターする。ＰＤＣＣＨが存在しない場合、レガシーＵＥは、所定のサブフレームでの不連続送信（ＤＴＸ：ｄｉｓｃｏｎｔｉｎｕｏｕｓ  ｔｒａｎｓｍｉｓｓｉｏｎ）を仮定する。動的なサブフレーム変換をサポートする他のＵＥは、ＰＨＹレイヤ通知に従って、所定のサブフレームを上りリンク・サブフレームとして用いることができる。
【００７０】
動的な上りリンクおよび下りリンク（再）構成（例えば、変換）が適用されるとき、（例えば、以前の３ＧＰＰリリースによる）すべての既存の上りリンク−下りリンク対応付けを維持することが望ましい。本明細書に開示されるシステムおよび方法は、一時的および／または部分的な下りリンクから上りリンクへの変換のために、現行の仕様書のスペシャル・サブフレームを拡張する。本明細書に開示されるスペシャル・サブフレーム拡張版または新しいスペシャル・サブフレームは、「スペシャル・サブフレーム・タイプ２」または「Ｓ２」と呼ばれる。加えて、または代わりに、新しいスペシャル・サブフレームまたはスペシャル・サブフレーム・タイプ２は、ハイブリッド・サブフレーム、フレキシブル・サブフレーム、拡張可能なスペシャル・サブフレームなどと呼ばれてもよい。
【００７１】
ＬＴＥ−ＴＤＤにおける上りリンク・サブフレームでは、スケジューリングされたＰＵＣＣＨおよび／またはＰＵＳＣＨ送信を有するＵＥだけがチャネル上で送信を行うことができる。他のＵＥは、チャネルを感知しない。それゆえに、いくつかの理由で、ＰＨＹレイヤにおける上りリンク・サブフレームから下りリンク・サブフレームへの動的な変更は、既存のＰＨＹレイヤ通知では可能でない。
【００７２】
第１に、ＰＤＣＣＨは、同じサブフレームでのＰＤＳＣＨ送信をスケジューリングする。しかしながら、ＵＥは、下りリンク・サブフレームに切り替えられる（例えば、変換される）であろう上りリンク・サブフレームでは、ＰＤＳＣＨをスケジューリングするためにＰＤＣＣＨをモニターすることはない。
【００７３】
第２に、ｅＮＢは、下りリンク・サブフレームに切り替えられる（例えば、変換される）であろう上りリンク・サブフレームでのＰＵＳＣＨ送信の割当ても回避することが可能であろう。しかしながら、この上りリンク・サブフレームでのＰＵＣＣＨによるＡＣＫ／ＮＡＣＫフィードバックまたはＰＵＳＣＨ送信を防止するために、ｅＮＢは、ＡＣＫ／ＮＡＣＫフィードバックと対応付けられたサブフレームにおけるＰＤＳＣＨ割当ても回避することがある。例えば、この下りリンク対応付けの一組のサブフレームでは、すべてのＵＥに対していかなるＰＤＳＣＨ送信も発生することはない。これは、上りリンク・サブフレームを下りリンク・サブフレームに変換するという目的に矛盾する。例として、より多くの下りリンク・サブフレームが必要とされるにも係わらず、ＡＣＫ／ＮＡＣＫ対応付けの問題ゆえに、より多くの下りリンク・サブフレームを空にしなければならない。
【００７４】
スペシャル・サブフレーム・タイプ２の構造に関するさらなる詳細は、以下の通りである。（スペシャル・サブフレーム・タイプ２と混同すべきではない）標準的スペシャル・サブフレームは、下りリンクから上りリンクへの切り替えに用いられる。標準的スペシャル・サブフレームでは、チャネル・リソースの大部分が下りリンク送信に割当てられるのに対して、上りリンクには短時間（例えば、１つかまたは２つのシンボル）が割当てられる。スペシャル・サブフレーム・タイプ２（Ｓ２）は、すべての必要な下りリンク通知（例えば、ＰＵＳＣＨスケジューリングおよびＰＨＩＣＨフィードバックに関する制御情報）を維持する一方で、より多くのリソースを上りリンク送信に提供することを目指す。ＰＤＣＣＨ送信だけを維持し、リソースの残りをＰＵＳＣＨ送信に割当てることによって、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換される。
【００７５】
ＰＤＣＣＨ  ＤＣＩフォーマット０を用いたＰＵＳＣＨスケジューリングでは、ＰＵＳＣＨ割当ては、スタートＲＢのインデックスとＲＢの数とによって表される連続的なリソースブロック（ＲＢ）からなるブロックである。スペシャル・サブフレーム・タイプ２のためのＰＵＳＣＨ割当てにおいて、各サブキャリアに使用可能なリソース要素（ＲＥ：ｒｅｓｏｕｒｃｅ  ｅｌｅｍｅｎｔ）は、上りリンク・パイロット時間スロット（ＵｐＰＴＳ）領域におけるシンボルの数と同じにするとよい。例えば、割当てられるＲＥの数は、割当てられるＲＢの数×各ＲＢにおける１２サブキャリア×各サブキャリアにおける使用可能なシンボルの数である。スペシャル・サブフレーム・タイプ２の構造に関するさらなる詳細は、以下の通りである。
【００７６】
標準的スペシャル・サブフレームと同様に、スペシャル・サブフレーム・タイプ２は、３つのフィールドを有する。標準的スペシャル・サブフレームでは、３つのフィールドは、下りリンク・パイロット時間スロット（ＤｗＰＴＳ）、ガード期間（ＧＰ）および上りリンク・パイロット時間スロット（ＵｐＰＴＳ）である。便宜上、スペシャル・サブフレーム・タイプ２における３つのフィールドも、ＤｗＰＴＳ、ＧＰおよびＵｐＰＴＳと呼ばれる。スペシャル・サブフレーム・タイプ２における３つのフィールドは、標準的スペシャル・サブフレームにおけるのと同じ名前を用いて呼ばれるが、留意すべきは、スペシャル・サブフレーム・タイプ２における３つのフィールドの特性が、標準的スペシャル・サブフレームにおける同名のフィールドの特性と異なっても、同様でも、および／または同じでもよいことである。例として、スペシャル・サブフレーム・タイプ２では、標準的スペシャル・サブフレームにおけるのと比べて、より多くのデータがＵｐＰＴＳで運ばれる。
【００７７】
スペシャル・サブフレーム・タイプ２（Ｓ２）は、必要な下りリンク通知を維持する一方で、増加したリソースを上りリンク送信に提供することを目指す。例えば、スペシャル・サブフレーム・タイプ２は、必要に応じてＰＤＣＣＨ領域を維持するが、いかなるＰＤＳＣＨ割当ても有さない。スペシャル・サブフレーム・タイプ２におけるリソースの大部分は、ＰＵＳＣＨ送信に割当てられる。すべての上りリンク制御フィードバックは、既存の上りリンク・サブフレームと対応付けられるので、スペシャル・サブフレーム・タイプ２では、いかなるＰＵＣＣＨ割当ておよびＰＵＣＣＨ送信も許可されることはない。
【００７８】
スペシャル・サブフレーム・タイプ２では、ＤｗＰＴＳは、必要な下りリンク制御通知（例えば、ＰＤＣＣＨおよびＰＨＩＣＨ）だけを提供するように制限される。ＰＤＣＣＨは、上りリンク・サブフレームでのＰＵＳＣＨ送信をスケジューリングするために用いられる。しかしながら、スペシャル・サブフレーム・タイプ２におけるＰＤＣＣＨは、ＰＤＳＣＨ送信をスケジューリングすることがないので、スペシャル・サブフレーム・タイプ２におけるＤｗＰＴＳのサイズは、通常の下りリンク・サブフレームにおけるＤｗＰＴＳより小さくてもよい。例えば、スペシャル・サブフレーム・タイプ２におけるリソースブロックの数が１０より多いとき、ＰＤＣＣＨに用いられる直交周波数分割多重（ＯＦＤＭ）シンボルの数は、１つかまたは２つに制限されるべきである。そのうえ、ＰＤＣＣＨに用いられるＯＦＤＭシンボルの数は、スペシャル・サブフレーム・タイプ２におけるリソースブロックの数が１０以下であるとき、２つにすべきである。
【００７９】
ガード期間（ＧＰ）は、ＵＥが、上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス（ＣＰ：ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）構成を有する場合、スペシャル・サブフレーム・タイプ２におけるＧＰは、１つのＯＦＤＭシンボルの長さを有する。上りリンクおよび下りリンクが異なったサイクリックプレフィックス（ＣＰ）構成を有する場合、ＧＰは、１つより少ないか、または１つより多いＯＦＤＭシンボルとする。しかしながら、切り替えタイミングを確保するために、もし存在するならば、スペシャル・サブフレーム・タイプ２におけるＧＰは、少なくとも
１４５６・Ｔｓ
の長さを有するとよい。
【００８０】
現行のＵＬ−ＤＬ構成において、下りリンク・サブフレームが、ＰＵＳＣＨスケジューリング、電力制御および、任意の上りリンク送信へのＰＨＩＣＨフィードバックとの対応付けを有さない場合、下りリンク・サブフレームは、いかなる予約されたＰＤＣＣＨ領域も持たない（例えば、ＤｗＰＴＳ長が０の）スペシャル・サブフレーム・タイプ２に変換される。下りリンク・サブフレームが、上りリンク・サブフレームのすぐに後に（あるいは、おそらくいくつかの構成において、スペシャル・サブフレーム・タイプ２の後に）ある場合、下りリンク・サブフレームは、いかなるＧＰも持たない上りリンク・サブフレームに完全に変換される。変換されるべき下りリンク・サブフレームが、下りリンク・サブフレームの後にある場合、例えば、第１のＯＦＤＭ符号長がＧＰとして予約され、一方では、すべての他のＯＦＤＭシンボルが上りリンク送信に割当てられる。
【００８１】
スペシャル・サブフレーム・タイプ２の一構成において、ＤｗＰＴＳフィールドの長さおよびＵｐＰＴＳフィールドの長さは、ＤｗＰＴＳ、ＧＰおよびＵｐＰＴＳの全長が
３０７２０・Ｔｓ＝１
ｍｓに等しいことを前提として、表（２）に示される。スペシャル・サブフレーム・タイプ２の構造に関するさらなる詳細は、以下の通りである。
【００８２】
【表２】
2014522135.tif 000008
【００８３】
以下の表（３）は、同じ構成をＯＦＤＭシンボルの数の観点から提供するものである。ＰＤＣＣＨに１つのＯＦＤＭシンボルが用いられる場合、上りリンク送信のために通常のサイクリックプレフィックス（ＣＰ）が構成されるのであれば、ＵｐＰＴＳは、１２個のＯＦＤＭシンボルを有し、上りリンク送信のために拡張されたＣＰが構成されるのであれば、１０個のＯＦＤＭシンボルを有する。ＰＤＣＣＨに２つのＯＦＤＭシンボルが用いられる場合、上りリンク送信のために通常のＣＰが構成されるのであれば、ＵｐＰＴＳは、１１個のＯＦＤＭシンボルを有し、上りリンク送信のために拡張されたＣＰが構成されるのであれば、９個のＯＦＤＭシンボルを有する。いかなる予約されたＰＤＣＣＨ領域も持たない（例えば、ＤｗＰＴＳ長が０の）スペシャル・サブフレーム・タイプ２に関して、変換されるべき下りリンク・サブフレームが上りリンク・サブフレームの直後にある場合、すべてのシンボルが上りリンク割当てに用いられる。しかしながら、変換されるべき下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、第１のＯＦＤＭシンボル長がＧＰとして予約され、一方では、すべての他のＯＦＤＭシンボルが上りリンク送信に割当てられる。
【００８４】
【表３】
2014522135.tif 000009
【００８５】
スペシャル・サブフレーム・タイプ２の変換ルールおよびＰＨＹレイヤ通知に関する詳細は、以下の通りである。ＰＵＳＣＨ送信は、ＵＥを対象とするサブフレームｎにおける上りリンクＤＣＩフォーマットを持つＰＤＣＣＨによって、および／またはサブフレームｎでのＰＨＩＣＨ送信によってスケジューリングされる。対応するＰＵＳＣＨ送信は、ＰＤＣＣＨおよびＰＨＩＣＨ情報に従って、サブフレームｎ＋ｋで調整され、ここでＦＤＤに関して、ｋ＝４であり、ＴＤＤに関して、ｋは、（３ＧＰＰ  ＴＳ  ３６．２１３における表８−２から）以下の表（４）に示される。なお、「ＵＬ」は上りリンクを示し、「ＤＬ」は下りリンクを示す。
【００８６】
【表４】
2014522135.tif 000010
【００８７】
現行の３ＧＰＰ仕様書に従うと、ＴＤＤでは、いかなるＰＵＳＣＨ送信も下りリンク・サブフレームにおいてスケジューリングされるべきではない。上りリンク・サブフレームにおけるＰＵＳＣＨ割当ては、下りリンク・サブフレームへの１対１の対応付けマッピングを有する。例えば、ＴＤＤ  ＵＬ／ＤＬ構成１〜６および通常のＨＡＲＱ動作に関して、ＵＥは、ＵＥを対象とするサブフレームｎにおける、上りリンクＤＣＩフォーマット０を持つＰＤＣＣＨの検出、および／またはＰＨＩＣＨ送信の際に、サブフレームｎ＋ｋでの対応するＰＵＳＣＨ送信を、ＰＤＣＣＨおよびＰＨＩＣＨ情報に従って調整する。ｋは、表（４）に示されている。現行の仕様書に従うと、ＰＵＳＣＨ割当てのためのＤＣＩフォーマット０を運ぶことができない、あるいはＰＨＩＣＨフィードバックを有することができない、いくつかの下りリンク・サブフレームがある。
【００８８】
本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換される。これは、例えば、１つ以上のＤＣＩフォーマット０  ＰＵＳＣＨ送信が、（現行の３ＧＰＰリリース８、９および１０の仕様書では、ＰＵＳＣＨ割当てのためのＤＣＩフォーマット０を有することが許可されていない）下りリンク・サブフレームに割当てられたとき、あるいは以前に割当てられたスペシャル・サブフレーム・タイプ２に対するＰＨＩＣＨフィードバックが必要とされるときに発生する。
【００８９】
スペシャル・サブフレーム・タイプ２に関する対応付けは、以下のように規定される。サブフレームｎ−４におけるＤＣＩフォーマット０を持つＰＤＣＣＨは、下りリンク・サブフレームｎをスペシャル・サブフレーム・タイプ２に変換する。サブフレーム番号ｎを持つスペシャル・サブフレーム・タイプ２に対するＡＣＫ／ＮＡＣＫフィードバックは、サブフレームｎ＋６でレポートされる。一構成において、変換されたサブフレームｎでのＰＵＳＣＨ送信に対するＡＣＫ／ＮＡＣＫは、サブフレームｎ＋６におけるＰＨＩＣＨ上で運ばれる。加えて、サブフレームｎ＋６におけるＰＤＣＣＨがＰＨＩＣＨをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームｎ＋１０での新しいデータ送信または再送信をスケジューリングすることもできる。
【００９０】
別の構成では、変換されたサブフレームｎでのＰＵＳＣＨ送信に対するいかなるＰＨＩＣＨフィードバックもなく、ＵＥは、ＰＨＩＣＨ値をＡＣＫと見做す。そのうえ、サブフレームｎ＋６におけるＰＤＣＣＨがＡＣＫをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームｎ＋１０での新しいデータ送信または再送信をスケジューリングすることもできる。サブフレームｎ＋１０での再送信のスケジューリングは、サブフレームｎでのＰＵＳＣＨ送信に対するＮＡＣＫを示す。ＵＥがＰＤＣＣＨを何も検出しない場合、ＵＥは、サブフレームｎ＋１０でＰＵＳＣＨを送信することはない。ＴＤＤは、５ｍｓおよび１０ｍｓの両方の構成に共通の１０個の間隔を有し、ｎ＋６＝（ｎ−４）＋１０なので、ＰＨＩＣＨおよびＤＣＩフォーマット０を持つＰＤＣＣＨ割当ては、常に同じ下りリンク・サブフレーム・インデックス番号を有する。
【００９１】
言い換えれば、サブフレーム番号ｎを持つスペシャル・サブフレーム・タイプ２のＰＵＳＣＨは、スペシャル・サブフレーム・タイプ２の４サブフレーム前にある下りリンク・サブフレーム（例えば、サブフレーム番号ｎ−４を持つ下りリンク・サブフレーム）のＰＤＣＣＨまたはＰＨＩＣＨフィードバックでスケジューリングされる。サブフレーム番号ｋを持つスペシャル・サブフレーム・タイプ２でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫフィードバックは、サブフレーム番号ｎ＋６を持つ下りリンク・サブフレームにおけるＰＨＩＣＨ上で、または明示的なＰＤＣＣＨスケジューリングによってレポートされる。スペシャル・サブフレーム・タイプ２の対応付けに関するさらなる詳細は、以下の通りである。
【００９２】
一例において、（上掲の表（１）に示されるような）現行の上りリンクおよび下りリンク（ＵＬ−ＤＬ）構成５では、１つだけの上りリンク・サブフレームがサブフレーム番号ｉ＝２に存在する。そのうえ、ＰＵＳＣＨ割当ては、前のフレームのサブフレーム番号ｉ＝８におけるＰＤＣＣＨ  ＤＣＩフォーマット０またはＰＨＩＣＨフィードバックによって通知される。現行の３ＧＰＰ仕様書に従って、この構成では、すべての他の下りリンク・サブフレームは、ＰＤＣＣＨ  ＤＣＩフォーマット０またはＰＨＩＣＨフィードバックを運ぶことがない。
【００９３】
しかしながら、本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレーム番号ｉ＝３でのＰＵＳＣＨ送信をスケジューリングするために、ＰＤＣＣＨ  ＤＣＩフォーマット０がサブフレーム番号ｉ＝９に割当てられた場合、次のフレームのサブフレーム番号ｉ＝３を持つ対象下りリンク・サブフレームが、スペシャル・サブフレーム・タイプ２に変換される。ＰＵＳＣＨ送信は、割当てられたＰＵＳＣＨリソース上で運ばれる。ＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、次に、サブフレーム番号ｉ＝９上でレポートされる。
【００９４】
下りリンク・サブフレームからスペシャル・サブフレーム・タイプ２への変換は、一時的かつ動的であってもよい。いくつかの構成において、下りリンク・サブフレームは、上記の条件下においてのみ、スペシャル・サブフレーム・タイプ２に変換される。その他の場合は、下りリンク・サブフレームは、通常の下りリンク・サブフレームとして機能する。かくして、変換および遷移は、自律的に生じ、いかなる追加の通知も必要ではない。
【００９５】
スペシャル・サブフレームを予期しないレガシーＵＥは、これを通常の下りリンク・サブフレームとして扱う。スペシャル・サブフレーム・タイプ２にＰＤＣＣＨが存在するとき、レガシーＵＥにとって何も変化はない。スペシャル・サブフレーム・タイプ２にＰＤＣＣＨが存在しないとき、レガシーＵＥは、ＰＤＣＣＨを首尾よく検出できないので、このサブフレームに関してＤＴＸをレポートする。リリース１１以降のＵＥは、本明細書に開示されるシステムおよび方法に従って、必要とされる上りリンク−下りリンク対応付け、およびスペシャル・サブフレーム・タイプ２でのデータ送信を行う。
【００９６】
スペシャル・サブフレーム・タイプ２構造およびＰＵＳＣＨリソース割当ての決定に関するさらなる詳細は、以下の通りである。スペシャル・サブフレーム・タイプ２では、ＰＵＳＣＨ割当てに利用可能なリソース要素（ＲＥ）が、ＵｐＰＴＳ領域またはフィールドにおけるＯＦＤＭシンボルの数によって決定される。従って、スペシャル・サブフレーム・タイプ２上でのＰＵＳＣＨスケジューリングの前に、スペシャル・サブフレーム・タイプ２の構成が、ｅＮＢおよび１つ以上のＵＥに知られているとよい。ＵＥは、所定のＰＵＳＣＨリソース上でデータ符号化および多重化を行うために、この構成を必要とする。そのうえ、ｅＮＢは、ＰＵＳＣＨデータを受信して復号するために、同じ情報を必要とする。
【００９７】
下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換される場合、構成の決定に関する手順の一例は、以下の通りである。スペシャル・サブフレーム・タイプ２に変換されるべき下りリンク・サブフレーム（例えば、「対象下りリンク・サブフレーム」）は、上記のようなＰＨＹレイヤ通知およびルールによって決定される。対象下りリンク・サブフレームに関して、この手順は、下りリンク・サブフレーム変換のためのスペシャル・サブフレーム・タイプ２構造をいかに決定するかを説明する。
【００９８】
現行のＵＬ−ＤＬ構成において、対象下りリンク・サブフレームが、ＰＵＳＣＨスケジューリング、電力制御、および任意の上りリンク送信へのＰＨＩＣＨフィードバックとの対応付けを有さない場合、対象下りリンク・サブフレームは、いかなる予約されたＰＤＣＣＨ領域も持たない（例えば、ＤｗＰＴＳ長が０の）スペシャル・サブフレーム・タイプ２に変換される。対象下りリンク・サブフレームが上りリンク・サブフレーム（あるいは、おそらくいくつかの構成において、スペシャル・サブフレーム・タイプ２）の直後にある場合、対象下りリンク・サブフレームは、いかなるガード期間（ＧＰ）も持たない上りリンク・サブフレームに完全に変換される。しかしながら、対象下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、第１のＯＦＤＭシンボル長がＧＰとして予約され、一方では、すべての他のＯＦＤＭシンボルが上りリンク送信に割当てられる。
【００９９】
標準的なＵＬ−ＤＬ構成において、対象下りリンク・サブフレームが、ＰＵＳＣＨスケジューリング、電力制御、および任意の上りリンク送信へのＰＨＩＣＨフィードバックとの対応付けを有する場合、対象下りリンク・サブフレームは、予約されたＰＤＣＣＨ領域またはフィールドを持つスペシャル・サブフレーム・タイプ２に変換される。この場合、ＰＤＣＣＨ領域の長さがさらに決定される。
【０１００】
ＬＴＥネットワークにおいて、物理制御フォーマット・インジケータ・チャネル（ＰＣＦＩＣＨ）は、サブフレームでのＰＤＣＣＨの送信に用いられるＯＦＤＭシンボルの数についての情報を運ぶ。ＰＣＦＩＣＨは、ＰＤＣＣＨのためのＯＦＤＭシンボルの数がゼロより大きいときに送信される。
【０１０１】
予約されたＰＤＣＣＨ領域またはフィールドを持つスペシャル・サブフレーム・タイプ２のＰＤＣＣＨ長を決定するために、いくつか代わりの手法が用いられてもよい。第１の代替手段では、スペシャル・サブフレーム・タイプ２は、ＰＤＣＣＨ領域またはフィールドの長さが固定された構成を用いる。一構成において、リソースブロック（ＲＢ）の数が１０より多い場合、ＰＤＣＣＨのために１つのＯＦＤＭシンボルが予約され、ＲＢの数が１０以下である場合、２つのＯＦＤＭシンボルが予約される。別の構成では、ＰＤＣＣＨのために常に２つのＯＦＤＭシンボルが予約されてもよい。固定された構成は、ｅＮＢに明示的な通知を用いて（例えば、システム情報におけるようなＲＲＣ通知で）伝達される。
【０１０２】
ＰＤＣＣＨ長が固定された構成を持つ一構成では、ＰＣＦＩＣＨは、スペシャル・サブフレーム・タイプ２に必要とされることはない。別の構成では、ＰＣＦＩＣＨは、スペシャル・サブフレーム・タイプ２に含まれ、ＰＤＣＣＨのために予約されたＯＦＤＭシンボルの数に対する所定の構成に従う。ＰＣＦＩＣＨで通知され、ＰＤＣＣＨに用いられるＯＦＤＭシンボルの数は、スペシャル・サブフレーム・タイプ２においてＰＤＣＣＨのために予約されたＯＦＤＭシンボルの数以下とされる。例えば、スペシャル・サブフレーム・タイプ２においてＰＤＣＣＨのために予約されたＯＦＤＭシンボルの数が２つであれば、ＰＣＦＩＣＨは、ＰＤＣＣＨ上のペイロードに依存して、ＰＤＣＣＨに用いられるシンボルの数を１つかまたは２つに構成するとよい。スペシャル・サブフレーム・タイプ２の構成が一旦設定されると、ｅＮＢおよび１つ以上のＵＥは、この構成に従って、然るべくＰＵＳＣＨスケジューリングおよびＰＵＳＣＨ送信を行う。
【０１０３】
第２の代替手段では、ＰＤＣＣＨ長は、ＰＣＦＩＣＨによって決定される。しかしながら、スペシャル・サブフレーム・タイプ２では、ＰＣＦＩＣＨ情報（例えば、ＰＤＣＣＨ領域の長さ）が初めにＵＥに知られていないので、ＵＥは、最小ＰＤＣＣＨサイズを持つデフォルト設定を用いてデータを処理しなければならない。それゆえに、ＵＥは、スペシャル・サブフレーム・タイプ２における最小ＰＤＣＣＨサイズ（例えば、ＲＢの数が１０より多い場合、ＰＤＣＣＨに１つのＯＦＤＭシンボル、ＲＢの数が１０以下である場合、２つのＯＦＤＭシンボル）を仮定して、データ符号化および多重化を行う。
【０１０４】
スペシャル・サブフレーム・タイプ２におけるＰＣＦＩＣＨの検出の際に、スペシャル・サブフレーム・タイプ２にＰＵＳＣＨスケジューリングを持つＵＥは、ＰＣＦＩＣＨからＰＤＣＣＨのためのＯＦＤＭシンボルの数を取得する。ＰＣＦＩＣＨがデフォルト最小ＰＤＣＣＨサイズにおけるのと同じＯＦＤＭシンボルの数を指示する場合、符号化および多重化されたデータは、変更なしに送信される。しかしながら、ＰＣＦＩＣＨによって与えられるＰＤＣＣＨ領域がデフォルト値より大きい場合、上りリンク送信は、ＰＣＦＩＣＨからのＯＦＤＭシンボルの数によって決定されるスペシャル・サブフレーム・タイプ２構造を用いる。例えば、選択されたスペシャル・サブフレーム・タイプ２構造によって取って代わられたＯＦＤＭシンボル中の符号化および多重化されたデータは、パンクチャして除かれる。かくして、所定のＯＦＤＭシンボルではいかなるＰＵＳＣＨ送信も発生することはない。
【０１０５】
一例において、通常のＣＰを上りリンクおよび下りリンクの両方に仮定する。スペシャル・サブフレーム・タイプ２にＰＵＳＣＨ割当てを持つＵＥは、ＰＤＣＣＨのための１つのＯＦＤＭシンボルと、それに続く１ＯＦＤＭシンボル長のＧＰとのデフォルト設定を仮定する。従って、データ符号化および多重化は、サブフレームにおけるサブキャリア当り１２個のシンボルを用いて行われる。ＵＥは、次に、スペシャル・サブフレーム・タイプ２におけるＰＣＦＩＣＨを検出する。ＰＣＦＩＣＨがＰＤＣＣＨのための１つのＯＦＤＭシンボルを指示する場合、ＰＵＳＣＨは、すべての符号化および多重化されたデータを用いて送信される。しかしながら、ＰＣＦＩＣＨがＰＤＣＣＨのための２つのＯＦＤＭシンボルを指示する場合、スペシャル・サブフレーム・タイプ２構造は、ＤｗＰＴＳのための２つのＯＦＤＭシンボル、ＧＰのための１つのＯＦＤＭシンボル、およびＰＵＳＣＨ送信のための１０個のＯＦＤＭシンボルを有するべきである。ＵＥは、そのときには第４のＯＦＤＭシンボル上のすべての符号化および多重化されたデータをパンクチャして除き、スペシャル・サブフレーム・タイプ２のサブキャリアにおける１０個のＯＦＤＭシンボルでのＰＵＳＣＨ送信をもたらす。
【０１０６】
ＰＨＹレイヤを動的に下りリンクから上りリンクに変換するためのスペシャル・サブフレーム・タイプ２の使用に関するさらなる詳細は、以下の通りである。上記のように、ＰＨＹレイヤでの上りリンク・サブフレームから下りリンク・サブフレームへの動的な変更は、既存のＰＨＹレイヤ通知では可能でない。従って、この場合、システム情報変更手順を用いることもできる。しかしながら、下りリンク・サブフレームから上りリンク・サブフレームへの変換は、上記のようにスペシャル・サブフレーム・タイプ２を用いて、ＰＨＹレイヤ手順によって動的に行われるとよい。
【０１０７】
スペシャル・サブフレーム・タイプ２を用いた下りリンクから上りリンクへの変換のいくつかの利益は、以下の通りである。本明細書に開示されるシステムおよび方法に従って、下りリンクから上りリンクへの変換は、現行のＰＨＹレイヤの上りリンク−下りリンク対応付けを拡張する。例えば、サブフレーム番号ｎを持つスペシャル・サブフレーム・タイプ２のＰＵＳＣＨ割当ては、サブフレーム番号ｎ−４を持つ下りリンク・サブフレームにおけるＰＤＣＣＨまたはＰＨＩＣＨフィードバックによってスケジューリングされる。そのうえ、サブフレーム番号ｎを持つスペシャル・サブフレームでのＰＵＳＣＨ送信のＰＨＩＣＨフィードバックは、サブフレーム番号ｎ＋６を持つ下りリンク・サブフレーム中とされる。
【０１０８】
そのうえ、本明細書に開示されるシステムおよび方法は、いずれの既存の上りリンク−上りリンク対応付けも壊さない（例えば、スペシャル・サブフレーム・タイプ２において、ＰＵＣＣＨは、何も必要ないか、あるいは許可されない）。また、サブフレーム変換は、動的、自律的かつフレキシブルである。加えて、対応付けルールを満たすことができる場合、任意の下りリンク・サブフレームがスペシャル・サブフレームに変換される。このように、１つ以上の下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２のサブフレームに変換される。
【０１０９】
提案される下りリンクから上りリンクへの変換は、システムにとって低コストである。現行の上りリンク割当てが上りリンク・トラフィックを扱えない場合、必要に応じて、または所望通りに、下りリンク・サブフレームは、ＰＨＹレイヤ手順を用いてスペシャル・サブフレーム・タイプ２のサブフレームに動的に変換される。かくして、提案される手法は、システム情報変更手順を用いてＵＬ−ＤＬ構成を変更することなく、増加した上りリンク送信の大部分のトラフィック変動を扱うことができる。
【０１１０】
一例において、ネットワークＵＬ−ＤＬ構成は、初期化され、より多くの下りリンク・サブフレームによって構成される（例えば、ＵＬ−ＤＬ構成は、ピーク下りリンク・トラフィック負荷に基づくか、あるいは下りリンク送信側にバイアスを持つ上りリンク対下りリンク・トラフィック比に基づいてもよい）。通常の状況下では、ネットワークにおける下りリンク・トラフィックは、上りリンクより高いであろう。１つ以上のＵＥがデータ量の多いアプリケーションを開始した場合、あるいはピコセルへのトラフィック負荷分散のシナリオにおいては、トラフィック負荷が不均衡になることがある。
【０１１１】
下りリンクから上りリンクへの動的な変換のためにＰＨＹレイヤ通知を行うとき、いくつかのガイドラインが適用される。第一に、サブフレーム０およびサブフレーム５は、現行のＵＬ−ＤＬ構成におけるように、専ら下りリンク・サブフレームとされ、スペシャル・サブフレーム・タイプ２に変換されることはない。そのうえ、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されるとき、上りリンク・サブフレームもしくは別のスペシャル・サブフレーム・タイプ２の直後にあるサブフレームは、（変換のための）第１の、および／または優先されるサブフレームと見做される。
【０１１２】
次に、図面を参照して様々な構成が記述される。なお、図面において、同様の参照番号は、機能的に同様の要素を示す。本明細書において図面に一般的に記述され、説明されるようなシステムおよび方法は、多種多様に異なった構成に配置され、設計されてもよい。従って、図面に表現されるようないくつかの構成の以下のさらに詳細な記述は、請求される範囲を限定する意図はなく、システムおよび方法を単に代表するに過ぎない。
【０１１３】
図１は、下りリンク・サブフレームを変換するためのシステムおよび方法が実装されるｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）１６０および１つ以上の端末装置（ＵＥ）１０２の一構成を示すブロック図である。１つ以上のＵＥ１０２は、１本以上のアンテナ１２２ａ〜ｎを用いてｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）１６０と通信する。例えば、ＵＥ１０２は、１つ以上のアンテナ１２２ａ〜ｎを用いてｅＮＢ１６０へ電磁信号を送信し、ｅＮＢ１６０から電磁信号を受信する。ｅＮＢ１６０は、１つ以上のアンテナ１８０ａ〜ｎを用いてＵＥ１０２と通信する。留意すべきは、いくつかの構成において、ｅＮＢ１６０がＮｏｄｅ  Ｂ、ｈｏｍｅ  ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ＨｅＮＢ）または他の種類の基地局であってもよいことである。
【０１１４】
ＵＥ１０２およびｅＮＢ１６０は、相互に通信するために１つ以上のチャネル１１９、１２１を用いる。例えば、ＵＥ１０２は、１つ以上の上りリンク・チャネル１２１を用いてｅＮＢ１６０へ情報またはデータを送信する。上りリンク・チャネル１２１の例は、物理上りリンク制御チャネル（ＰＵＣＣＨ）および物理上りリンク共有チャネル（ＰＵＳＣＨ）などを含む。ｅＮＢ１６０も、例として、１つ以上の下りリンク・チャネル１１９を用いて１つ以上のＵＥ１０２へ情報またはデータを送信する。下りリンク・チャネル１１９の例は、物理下りリンク制御チャネル（ＰＤＣＣＨ）、物理下りリンク共有チャネル（ＰＤＳＣＨ）などを含む。他の種類のチャネルを用いてもよい。
【０１１５】
１つ以上のＵＥ１０２のそれぞれは、１つ以上のトランシーバ１１８、１つ以上の復調器１１４、１つ以上のデコーダ１０８、１つ以上のエンコーダ１５０、１つ以上の変調器１５４およびＵＥ操作部１２４を含む。例えば、ＵＥ１０２では１つ以上の受信および／または送信経路が用いられる。便宜上、単一のトランシーバ１１８、デコーダ１０８、復調器１１４、エンコーダ１５０および変調器１５４だけが示されるが、構成に依存して、複数の並列要素（例えば、トランシーバ１１８、デコーダ１０８、復調器１１４、エンコーダ１５０および変調器１５４）が用いられる。
【０１１６】
トランシーバ１１８は、１つ以上の受信機１２０および１つ以上の送信機１５８を含む。１つ以上の受信機１２０は、１つ以上のアンテナ１２２ａ〜ｎを用いてｅＮＢ１６０から信号を受信する。例えば、受信機１２０は、１つ以上の受信信号１１６を生成するために、信号を受信してダウンコンバートする。１つ以上の受信信号１１６は、復調器１１４に供給される。１つ以上の送信機１５８は、１つ以上のアンテナ１２２ａ〜ｎを用いてｅＮＢ１６０へ信号を送信する。例えば、１つ以上の送信機１５８は、１つ以上の変調信号１５６をアップコンバートして送信する。
【０１１７】
復調器１１４は、１つ以上の復調信号１１２を生成するために、１つ以上の受信信号１１６を復調する。１つ以上の復調信号１１２は、デコーダ１０８に供給される。ＵＥ１０２は、信号を復号するためにデコーダ１０８を用いる。デコーダ１０８は、１つ以上の復号信号１０６、１１０を生成する。例えば、第１のＵＥ復号信号１０６は、受信されたペイロード・データ１０４を備える。第２のＵＥ復号信号１１０は、オーバーヘッド・データおよび／または制御データを備える。例えば、第２のＵＥ復号信号１１０は、１つ以上の操作を行うためにＵＥ操作部１２４によって用いられるデータを供給する。
【０１１８】
本明細書では、用語「部」は、特定の要素またはコンポーネントが、ハードウェア、ソフトウェアあるいはハードウェアとソフトウェアとの組み合わせで実装されることを意味する。しかしながら、留意すべきは、本明細書に「部」として示される任意の要素が、代わりにハードウェアで実装されてもよいことである。例えば、ＵＥ操作部１２４は、ハードウェア、ソフトウェアまたは両方の組み合わせで実装されてもよい。
【０１１９】
一般に、ＵＥ操作部１２４は、ＵＥ１０２がｅＮＢ１６０と通信することを可能にする。ＵＥ操作部１２４は、ＵＥ下りリンク・サブフレーム変換部１３２を含む。ＵＥ下りリンク・サブフレーム変換部１３２は、スペシャル・サブフレーム・タイプ２構造１３４を含む。
【０１２０】
ＵＥ下りリンク・サブフレーム変換部１３２は、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換する。留意すべきは、１つ以上の下りリンク・サブフレームが変換されることである。例えば、表（１）に下りリンク・サブフレームとして示される１つ以上のサブフレームが、スペシャル・サブフレーム・タイプ２のサブフレームに変換される。例として、図１に示されるように、１つ以上のＵＥ１０２およびｅＮＢ１６０が、無線フレームにおけるいくつかのサブフレームが下りリンク・サブフレームとして指定された特定の構成に従って動作している。しかしながら、本明細書に開示されるシステムおよび方法を用いて、ＵＥ１０２は、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換することができる。
【０１２１】
上記のように、スペシャル・サブフレーム・タイプ２は、ｅＮＢ１６０が、より多くの通信リソースを上りリンク送信に動的かつ一時的に割当てることを可能にする。これは、（例えば、必要または有益なときに）１つ以上のＵＥ１０２が、より多くの上りリンク・データをｅＮＢ１６０へ送信することを可能にする。
【０１２２】
ＵＥ下りリンク・サブフレーム変換部１３２は、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換するために、スペシャル・サブフレーム・タイプ２構造１３４を用いる。例えば、スペシャル・サブフレーム・タイプ２構造１３４は、いくつかの状況において、スペシャル・サブフレーム・タイプ２の構造を規定する。例として、スペシャル・サブフレーム・タイプ２の構造は、対応付けが対象下りリンク・サブフレーム（例えば、変換されるべき下りリンク・サブフレーム）に対応するかどうかに依存して、
対象下りリンク・サブフレームのすぐ前が上りリンク・サブフレームであるか下りリンク・サブフレームであるかに依存して、および／または、スペシャル・サブフレーム・タイプ２に含まれてよい（あるいは含まれない）ＰＤＣＣＨの長さに依存して、変化する。
【０１２３】
ＵＥ操作部１２４は、１つ以上の受信機１２０に情報１８４を提供する。例えば、ＵＥ操作部１２４は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づいて、送信をいつ受信すべきか、あるいはいつすべきでないかを受信機（単数または複数）１２０に通知する。
【０１２４】
ＵＥ操作部１２４は、復調器１１４に情報１３８を提供する。例えば、ＵＥ操作部１２４は、ｅＮＢ１６０からの送信に予想される変調パターンを復調器１１４に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。
【０１２５】
ＵＥ操作部１２４は、デコーダ１０８に情報１３６を提供する。例えば、ＵＥ操作部１２４は、ｅＮＢ１６０からの送信に予想される符号化法をデコーダ１０８に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。
【０１２６】
ＵＥ操作部１２４は、エンコーダ１５０に情報１４２を提供する。情報１４２は、符号化されるべきデータおよび／または符号化に関する命令を含む。例えば、ＵＥ操作部１２４は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づいて、送信データ１４６および／または制御情報１４２を符号化するようにエンコーダ１５０に命令する。例として、ＵＥ操作部１２４は、いくつかの構成において、符号化および多重化のために最小ＰＤＣＣＨ長を仮定するようにエンコーダ１５０に通知する。
【０１２７】
エンコーダ１５０は、送信データ１４６および／またはＵＥ操作部１２４によって供給された他の情報１４２を符号化する。例えば、データ１４６および／または他の情報１４２の符号化は、誤り検出および／または訂正符号化、送信のための空間、時間および／または周波数リソースへのデータのマッピング、多重化などを伴う。エンコーダ１５０は、変調器１５４に符号化データ１５２を供給する。
【０１２８】
ＵＥ操作部１２４は、変調器１５４に情報１４４を供給する。例えば、ＵＥ操作部１２４は、ｅＮＢ１６０への送信に用いられるべき変調型（例えば、コンステレーション・マッピング）を変調器１５４に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。変調器１５４は、１つ以上の送信機１５８に１つ以上の変調信号１５６を供給するために、符号化データ１５２を変調する。
【０１２９】
ＵＥ操作部１２４は、１つ以上の送信機１５８に情報１４０を提供する。この情報１４０は、１つ以上の送信機１５８に対する命令を含む。例えば、ＵＥ操作部１２４は、ｅＮＢ１６０へ信号をいつ送信すべきかを１つ以上の送信機１５８に命令する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。例として、１つ以上の送信機１５８は、スペシャル・サブフレーム・タイプ２に変換された下りリンク・サブフレームの間に送信する。１つ以上の送信機１５８は、１つ以上のｅＮＢ１６０へ変調信号（単数または複数）１５６をアップコンバートして送信する。
【０１３０】
ｅＮＢ１６０は、１つ以上のトランシーバ１７６、１つ以上の復調器１７２、１つ以上のデコーダ１６６、１つ以上のエンコーダ１０９、１つ以上の変調器１１３およびｅＮＢ操作部１８２を含む。例えば、ｅＮＢ１６０では１つ以上の受信および／または送信経路を用いる。便宜上、単一のトランシーバ１７６、デコーダ１６６、復調器１７２、エンコーダ１０９および変調器１１３だけが示されるが、構成に依存して、複数の並列要素（例えば、トランシーバ１７６、デコーダ１６６、復調器１７２、エンコーダ１０９および変調器１１３）が用いられる。
【０１３１】
トランシーバ１７６は、１つ以上の受信機１７８および１つ以上の送信機１１７を含む。１つ以上の受信機１７８は、１つ以上のアンテナ１８０ａ〜ｎを用いてＵＥ１０２から信号を受信する。例えば、受信機１７８は、１つ以上の受信信号１７４を生成するために、信号を受信してダウンコンバートする。１つ以上の受信信号１７４は、復調器１７２に供給される。１つ以上の送信機１１７は、１つ以上のアンテナ１８０ａ〜ｎを用いてＵＥ１０２へ信号を送信する。例えば、１つ以上の送信機１１７は、１つ以上の変調信号１１５をアップコンバートして送信する。
【０１３２】
復調器１７２は、１つ以上の復調信号１７０を生成するために、１つ以上の受信信号１７４を復調する。１つ以上の復調信号１７０は、デコーダ１６６に供給される。ｅＮＢ１６０は、信号を復号するためにデコーダ１６６を用いる。デコーダ１６６は、１つ以上の復号信号１６４、１６８を生成する。例えば、第１のｅＮＢ復号信号１６４は、受信されたペイロード・データ１６２を備える。第２のｅＮＢ復号信号１６８は、オーバーヘッド・データおよび／または制御データを備える。例えば、第２のｅＮＢ復号信号１６８は、１つ以上の操作を行うために、ｅＮＢ操作部１８２によって用いられるデータを提供する。
【０１３３】
ｅＮＢ操作部１８２は、ネットワーク・トラフィック・モニター部１２６およびｅＮＢ下りリンク・サブフレーム変換部１２８を含む。ネットワーク・トラフィック・モニター部１２６は、ｅＮＢ１６０と１つ以上のＵＥ１０２との間に発生する上りリンクおよび下りリンク・トラフィック（例えば、通信）の量をモニターする。例えば、ネットワーク・トラフィック・モニター部１２６は、現行の上りリンクおよび／または下りリンク割当てが現トラフィック負荷に対して十分であるかどうかを判定する。
【０１３４】
ｅＮＢ下りリンク・サブフレーム変換部１２８は、１つ以上の下りリンク・サブフレームが１つ以上のスペシャル・サブフレーム・タイプ２のサブフレームに変換されるかどうかを制御する。例えば、ｅＮＢ下りリンク・サブフレーム変換部１２８は、現行の上りリンク・トラフィック割当てが現上りリンク・トラフィック負荷を扱うには不十分であることをネットワーク・トラフィック・モニター部１２６が示した場合、下りリンク・サブフレームを上りリンク・サブフレームに変換するように１つ以上のＵＥ１０２に通知するために用いられる、物理（ＰＨＹ）レイヤ通知を発生させる。
【０１３５】
ｅＮＢ下りリンク・サブフレーム変換部１２８は、スペシャル・サブフレーム・タイプ２構造１３０を含む。スペシャル・サブフレーム・タイプ２構造１３０は、いくつかの状況において、スペシャル・サブフレーム・タイプ２の構造を規定する。例として、スペシャル・サブフレーム・タイプ２の構造は、対応付けが対象下りリンク・サブフレーム（例えば、変換されるべき下りリンク・サブフレーム）に対応するかどうかに依存して、上りリンクまたは下りリンク・サブフレームが対象下りリンク・サブフレームの前に来るかどうかに依存して、および／または、スペシャル・サブフレーム・タイプ２に含まれるとよい（あるいは含まれなくてよい）ＰＤＣＣＨの長さに依存して、変化する。
【０１３６】
ｅＮＢ操作部１８２は、１つ以上の受信機１７８に情報１９０を提供する。例えば、ｅＮＢ操作部１８２は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づいて、送信をいつ受信すべきか、あるいはいつすべきでないかを受信機（単数または複数）１７８に通知する。
【０１３７】
ｅＮＢ操作部１８２は、復調器１７２に情報１８８を提供する。例えば、ｅＮＢ操作部１８２は、ＵＥ（単数または複数）１０２からの送信に予想される変調パターンを復調器１７２に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。
【０１３８】
ｅＮＢ操作部１８２は、デコーダ１６６に情報１８６を提供する。例えば、ｅＮＢ操作部１８２は、ＵＥ（単数または複数）１０２からの送信に予想される符号化法をデコーダ１６６に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。
【０１３９】
ｅＮＢ操作部１８２は、エンコーダ１０９に情報１０１を提供する。情報１０１は、符号化されるべきデータおよび／または符号化のための命令を含む。例えば、ｅＮＢ操作部１８２は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づいて、送信データ１０５および／または制御情報１０１を符号化するようにエンコーダ１０９に命令する。加えて、または代わりに、情報１０１は、スケジューリング情報、ＨＡＲＱデータ、チャネル割当ておよび／または他の制御情報を指示するＰＨＹレイヤ通知（例えば、ＰＤＣＣＨ、ＰＨＩＣＨなど）のような符号化されるべきデータを含む。
【０１４０】
エンコーダ１０９は、送信データ１０５、および／またはｅＮＢ操作部１８２によって提供される他の情報１０１を符号化する。例えば、データ１０５および／または他の情報１０１の符号化は、誤り検出および／または訂正符号化、送信のための空間、時間および／または周波数リソースへのデータのマッピング、多重化などを伴う。エンコーダ１０９は、変調器１１３に符号化データ１１１を供給する。送信データ１０５は、ＵＥ１０２へ伝えられるべきネットワーク・データを含む。
【０１４１】
ｅＮＢ操作部１８２は、変調器１１３に情報１０３を提供する。この情報１０３は、変調器１１３に対する命令を含む。例えば、ｅＮＢ操作部１８２は、ＵＥ（単数または複数）１０２への送信に用いられるべき変調型（例えば、コンステレーション・マッピング）を変調器１１３に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。変調器１１３は、１つ以上の送信機１１７に１つ以上の変調信号１１５を供給するためにデータ１１１を変調する。
【０１４２】
ｅＮＢ操作部１８２は、１つ以上の送信機１１７に情報１９２を提供する。この情報１９２は、１つ以上の送信機１１７に対する命令を含む。例えば、ｅＮＢ操作部１８２は、ＵＥ（単数または複数）１０２へ信号をいつ送信すべきか（あるいはいつすべきでないか）を１つ以上の送信機１１７に命令する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２に変換されているかどうかに基づく。例として、１つ以上の送信機１１７は、スペシャル・サブフレーム・タイプ２に変換された下りリンク・サブフレームの部分またはすべての間、送信することはない。１つ以上の送信機１１７は、１つ以上のＵＥ１０２へ変調信号（単数または複数）１１５をアップコンバートして送信する。
【０１４３】
留意すべきは、下りリンク・サブフレームは、ｅＮＢ１６０から１つ以上のＵＥ１０２へ送信され、上りリンク・サブフレームは、１つ以上のＵＥ１０２からｅＮＢ１６０へ送信されることである。そのうえ、標準的スペシャル・サブフレームでは、ｅＮＢ１６０も、１つ以上のＵＥ１０２もデータを送信する。スペシャル・サブフレーム・タイプ２では、１つ以上のＵＥ１０２は、データを送信する。しかしながら、スペシャル・サブフレーム・タイプ２では、ｅＮＢ１６０は、データを送信してもよく、しなくてもよい。
【０１４４】
図２は、ｅＮＢ１６０上で下りリンク・サブフレームを変換するための方法２００の一構成を示すフロー図である。ｅＮＢ１６０は、スペシャル・サブフレーム・タイプ２変換のための通知用サブフレームおよび１つ以上の対象下りリンク・サブフレームを決定する（ステップ２０１）。通知用サブフレームは、下りリンク・サブフレーム、標準的スペシャル・サブフレームまたはスペシャル・サブフレーム・タイプ２であってもよい。通知用サブフレームおよび対象下りリンク・サブフレームの対は、然るべき分離間隔（例えば、４つのサブフレーム）を有するべきである。そのうえ、通知用下りリンク・サブフレームは、ＰＨＩＣＨあるいはＰＤＣＣＨ上でのＰＵＳＣＨスケジューリング、および／またはＰＵＳＣＨ送信に対するＡＣＫ／ＮＡＣＫフィードバックに関する対応付けを有さなくてもよい。対象下りリンク・サブフレームは、一構成におけるスペシャル・サブフレーム・タイプ２の数に基づいて所定の順序によって決定される。
【０１４５】
ｅＮＢ１６０は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定する（ステップ２０２）。例えば、ｅＮＢ１６０は、現行のトラフィック割当ておよび現トラフィック負荷に基づいて、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定する（ステップ２０２）。
【０１４６】
一構成において、１０個のサブフレームの期間を仮定し、
ＮＵ
個の上りリンク・サブフレーム、およびスペシャル・サブフレームを含む（１０−
ＮＵ
）個の下りリンク・サブフレームからなるＴＤＤ  ＵＬ−ＤＬ構成を仮定する。ネットワーク・リソースまたは能力が１に正規化され、アグリゲートされた上りリンクおよびアグリゲートされた下りリンク・トラフィック負荷が、それぞれ
λＵ
および
λＤであると仮定する。ここで、
λＵ
および
λＤ
は、チャネル使用のパーセンテージとして正規化された（必要な制御シグナリングを含む）上りリンクおよび下りリンク・トラフィック負荷である。
【０１４７】
オペレータは、いくつか所望の負荷比「目標」を持つネットワーク（例えば、ｅＮＢ１６０）を、その収益モデルに対するオペレータの選好に基づいて構成する。実際のトラフィック特性は、２つの様態を含む。第１の様態は、全トラフィック負荷対能力比であり、次式で示される。
λ＝（λＵ＋λＤ）
第２の様態は、上りリンク対下りリンク・トラフィック比であり、次式で示される。
【０１４８】
【数５】
2014522135.tif 000011
【０１４９】
上りリンク対下りリンク・トラフィック比は、オペレータの目標または所望の負荷比に一致しても、しなくてもよい。
【０１５０】
ネットワーク・アグリゲートされたトラフィック負荷対能力比が低いとき、上りリンク・トラフィックおよび下りリンク・トラフィック負荷が、次式
【０１５１】
【数６】
2014522135.tif 000012
【０１５２】
でそれぞれ示されるように、割当てられた上りリンク・サブフレームおよび下りリンク・サブフレームによってサポートされる場合、ＵＬ−ＤＬ構成は、受け入れ可能である。
【０１５３】
いくつかの構成において、現上りリンク・トラフィック負荷が、割当てられた上りリンク・サブフレームによって受け入れられるのに比べて、より大きい（例えば、次式が満足されない）場合、
【０１５４】
【数７】
2014522135.tif 000013
【０１５５】
および／または、現下りリンク・トラフィック負荷が、割当てられた下りリンク・サブフレームを満たしていない場合、ｅＮＢ１６０は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定する（ステップ２０２）。
【０１５６】
加えて、または代わりに、現上りリンク対下りリンク・トラフィック比
【０１５７】
【数８】
2014522135.tif 000014
【０１５８】
が、目標上りリンク対下りリンク・トラフィック比と比較して、ある量大きい場合、ｅＮＢ１６０は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定する（ステップ２０２）。対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきかどうかを判定する（ステップ２０２）ために、他の手法が、さらに、あるいは代わりに用いられてもよい。
【０１５９】
ｅＮＢ１６０が対象下りリンク・サブフレームを変換しないと判定した（ステップ２０２）場合、ｅＮＢ１６０は、対象下りリンク・サブフレームを変換することはなく、スペシャル・サブフレーム・タイプ２変換のための通知サブフレームおよび対象下りリンク・サブフレームを決定する（ステップ２０１）ために戻る。
【０１６０】
ｅＮＢ１６０が対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すると判定した（ステップ２０２）場合、ｅＮＢ１６０は、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を送信する（ステップ２０４）。例えば、ｅＮＢ１６０は、特定のＵＥに対して、ＤＣＩフォーマット０を持つＰＤＣＣＨを発生させて送信（ステップ２０４）してもよく、あるいはＰＨＩＣＨを発生させて送信（ステップ２０４）してもよい。ＤＣＩフォーマット０を持つＰＤＣＣＨの送信２０４は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきであることを暗黙的に示す。
【０１６１】
ｅＮＢ１６０は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定する（ステップ２０６）。例えば、ｅＮＢ１６０は、対象下りリンク・サブフレームが、（例えば、電力制御、スケジューリングなどに関して）予想される上りリンク・サブフレームと対応付けられているかどうかを判定する。例として、ｅＮＢ１６０は、上りリンク電力制御対応付け、ＰＵＳＣＨ対応付け、ＰＵＳＣＨ送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け、ＰＨＩＣＨ対応付け、もしくはいくつか他の対応付けが、対象下りリンク・サブフレームに対応するかどうかを判定する（ステップ２０６）。
【０１６２】
ｅＮＢ１６０が、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに関して存在すると判定した（ステップ２０６）場合、ｅＮＢ１６０は、対象下りリンク・サブフレームを、ＰＤＣＣＨを持つスペシャル・サブフレーム・タイプ２に変換する（ステップ２０８）。例えば、ｅＮＢ１６０は、ＰＤＣＣＨのためにスペシャル・サブフレーム・タイプ２の一部分を予約する。ｅＮＢ１６０は、スペシャル・サブフレーム・タイプ２において、データをＤｗＰＴＳ領域で送信する。
【０１６３】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、ｅＮＢ１６０は、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する（ステップ２１０）。いくつかの構成において、この判定２１０は、標準的上りリンク・サブフレームに基づくとよい。すべてのＵＬ−ＤＬ構成において、標準的スペシャル・サブフレームは、上りリンク・サブフレームが後に続く。それゆえに、スペシャル・サブフレーム・タイプ２は、上りリンク・サブフレームまたは下りリンク・サブフレームの後ろにのみある。
【０１６４】
いくつかの構成において、スペシャル・サブフレーム・タイプ２のサブフレームは、この判定２１０に関して、上りリンク・サブフレームと見做されることも、あるいは見做されないこともある。例えば、スペシャル・サブフレーム・タイプ２（Ｓ２）が別のＳ２の直後にある場合、前のＳ２は、上りリンクとして扱われる。しかしながら、いくつかの場合、ｅＮＢ１６０は、第２のＳ２のみでＵＥ１０２をスケジューリングする。かかる場合、前のＳ２は、ＵＥ１０２には知られない。これは、問題を生じかねない。しかしながら、この問題は、前のサブフレームもＳ２であるときにのみ第２のＳ２が許可されるように、Ｓ２の位置が明確に規定されていれば、解決することができる。
【０１６５】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、ｅＮＢ１６０は、対象下りリンク・サブフレームを、ガード期間（ＧＰ）を持たず、ＰＤＣＣＨを持たないスペシャル・サブフレーム・タイプ２に変換する（ステップ２１２）。この場合、対象下りリンク・サブフレームは、上りリンク・サブフレームに完全に変換されるとよい。ｅＮＢ１６０は、スペシャル・サブフレーム・タイプ２でデータを受信することができる。
【０１６６】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、ｅＮＢ１６０は、対象下りリンク・サブフレームを、ＧＰを持ち、ＰＤＣＣＨを持たないスペシャル・サブフレーム・タイプ２に変換する（ステップ２１４）。例えば、ｅＮＢ１６０は、ＧＰのためにスペシャル・サブフレーム・タイプ２の一部分を予約する。ＧＰは、ＵＥ１０２が上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス（ＣＰ）構成を有する場合、スペシャル・サブフレーム・タイプ２におけるＧＰは、１つのＯＦＤＭシンボルの長さを有する。上りリンクおよび下りリンクが異なったサイクリックプレフィックス（ＣＰ）構成を有する場合、ＧＰは、１つより少ないか、または１つより多いＯＦＤＭシンボルとする。しかしながら、切り替えタイミングを確保するために、スペシャル・サブフレーム・タイプ２のＧＰは、少なくとも
１４５６・Ｔｓ
の長さを有するとよい。
【０１６７】
図３は、ＵＥ１０２上で下りリンク・サブフレームを変換するための信号を受信する方法３００の一構成を示すフロー図である。ＵＥ１０２は、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理（ＰＨＹ）レイヤ通知を受信する（ステップ３０２）。例えば、ＵＥ１０２は、ＤＣＩフォーマット０を持つＰＤＣＣＨを受信（ステップ３０２）してもよく、あるいはＰＨＩＣＨを受信（ステップ３０２）してもよい。ＤＣＩフォーマット０を持つＰＤＣＣＨの受信３０２は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ２に変換すべきであることを暗黙的に示す。
【０１６８】
ＵＥ１０２は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定する（ステップ３０４）。例えば、ＵＥ１０２は、対象下りリンク・サブフレームが、（例えば、電力制御、スケジューリングなどに関して）予想される上りリンク・サブフレームと対応付けられているかどうかを判定する。例として、ＵＥ１０２は、上りリンク電力制御対応付け、ＰＵＳＣＨ対応付け、ＰＵＳＣＨ送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け、ＰＨＩＣＨ対応付け、もしくはいくつかの他の対応付けが、対象下りリンク・サブフレームに対応するかどうかを判定する（ステップ３０４）。
【０１６９】
ＵＥ１０２が上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在すると判定した（ステップ３０４）場合、ＵＥ１０２は、対象下りリンク・サブフレームを、ＰＤＣＣＨを持つスペシャル・サブフレーム・タイプ２に変換する（ステップ３０６）。例えば、ＵＥ１０２は、ＰＤＣＣＨのためにスペシャル・サブフレーム・タイプ２の一部分を予約する。ＵＥは、スペシャル・サブフレーム・タイプ２でデータを送信し、データを受信する。この場合、ＰＤＣＣＨの長さを決定する必要がある。ＰＤＣＣＨの長さを決定するための手法が、以下にさらに詳細に記述される。
【０１７０】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、ＵＥ１０２は、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する（ステップ３０８）。いくつかの構成において、この判定３０８は、標準的上りリンク・サブフレームに基づくとよい。いくつかの構成において、サブフレーム・タイプ２のサブフレームは、この判定３０８に関して、上りリンク・サブフレームと見做されることも、あるいは見做されないこともある。
【０１７１】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、ＵＥ１０２は、対象下りリンク・サブフレームを、ガード期間（ＧＰ）を持たず、ＰＤＣＣＨを持たないスペシャル・サブフレーム・タイプ２に変換する（ステップ３１０）。この場合、対象下りリンク・サブフレームは、上りリンク・サブフレームに完全に変換される。ＵＥ１０２は、スペシャル・サブフレーム・タイプ２でデータを送信する。
【０１７２】
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、ＵＥ１０２は、対象下りリンク・サブフレームを、ＧＰを持ち、ＰＤＣＣＨを持たないスペシャル・サブフレーム・タイプ２に変換する（ステップ３１２）。例えば、ＵＥ１０２は、ＧＰのためにスペシャル・サブフレーム・タイプ２の一部分を予約する。ＧＰは、ＵＥ１０２が上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス（ＣＰ）構成を有する場合、スペシャル・サブフレーム・タイプ２におけるＧＰは、１つのＯＦＤＭシンボルの長さを有する。上りリンクおよび下りリンクが異なったサイクリックプレフィックス（ＣＰ）構成を有する場合、ＧＰは、１つより少ないか、または１つより多いＯＦＤＭシンボルとする。しかしながら、切り替えタイミングを確保するために、スペシャル・サブフレーム・タイプ２のＧＰは、少なくとも
１４５６・Ｔｓ
の長さを有するとよい。
【０１７３】
図４は、物理下りリンク制御チャネル（ＰＤＣＣＨ）の長さを決定する方法４００の一構成を示すフロー図である。例えば、図４は、ＵＥ１０２が対象下りリンク・サブフレームをＰＤＣＣＨを持つスペシャル・サブフレーム・タイプ２に変換３０６しているときに用いられる一手法を示す。
【０１７４】
ＵＥ１０２は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在すると判定する（ステップ４０２）ことがある。ＵＥ１０２は、そのときには対象下りリンク・サブフレームのためのリソースブロック（ＲＢ）の数が１０以下であるかどうかを判定する（ステップ４０４）。
【０１７５】
対象下りリンク・サブフレームのためのリソースブロックの数が１０以下でない（例えば、数が１０より大きい）場合、ＵＥ１０２は、ＰＤＣＣＨのために１つのＯＦＤＭシンボルを予約する（ステップ４０６）。対象下りリンク・サブフレームのためのリソースブロックの数が１０以下である場合、ＵＥ１０２は、ＰＤＣＣＨのために２つのＯＦＤＭシンボルを予約する（ステップ４０８）。この手法は、対象下りリンク・サブフレームのためのリソースブロックの数に基づいて固定数のシンボルが用いられる「固定」手法と見做すことができる。いくつかの構成において、ＵＥ１０２は、この手法を用いるべきであることを示すｅＮＢ１６０からの信号を受信する。
【０１７６】
図５は、物理下りリンク制御チャネル（ＰＤＣＣＨ）の長さを決定する方法５００の別の構成を示すフロー図である。例えば、図５は、ＵＥ１０２が対象下りリンク・サブフレームをＰＤＣＣＨを持つスペシャル・サブフレーム・タイプ２に変換する（ステップ３０６）ときに用いられる別の手法を示す。
【０１７７】
ＵＥ１０２は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在すると判定する（ステップ５０２）ことがある。図５に示される手法では、ＰＤＣＣＨ長は、ＰＣＦＩＣＨに基づいて決定される。しかしながら、スペシャル・サブフレーム・タイプ２では、ＰＣＦＩＣＨ情報（例えば、ＰＤＣＣＨ領域の長さ）が初めにＵＥに知られていないこともあるので、ＵＥ１０２は、最小ＰＤＣＣＨサイズを持つデフォルト設定を用いてデータを処理しなければならない。それゆえに、ＵＥ１０２は、スペシャル・サブフレーム・タイプ２における最小ＰＤＣＣＨサイズを仮定して、データ符号化および多重化を行う（ステップ５０４）。例えば、ＵＥ１０２は、対象下りリンク・サブフレームのためのＲＢの数が１０より大きい場合、ＰＤＣＣＨのために１つのＯＦＤＭシンボルを、対象下りリンク・サブフレームのためのＲＢの数が１０以下である場合、２つのＯＦＤＭシンボルを仮定する。
【０１７８】
スペシャル・サブフレーム・タイプ２におけるＰＣＦＩＣＨの検出の際に、スペシャル・サブフレーム・タイプ２にＰＵＳＣＨスケジューリングを持つＵＥは、ＰＣＦＩＣＨからＰＤＣＣＨのためのＯＦＤＭシンボルの数を取得する。ＵＥ１０２は、ＰＣＦＩＣＨが最小（仮定された）ＰＤＣＣＨサイズに等しいサイズを指示するかどうかを判定する（ステップ５０６）。ＰＣＦＩＣＨが、仮定された最小ＰＤＣＣＨサイズにおけるのと同じＯＦＤＭシンボルの数を指示する場合、ＵＥ１０２は、符号化および多重化されたデータをいずれの変更もなしに送信する（ステップ５１０）。
【０１７９】
しかしながら、ＰＣＦＩＣＨによって与えられるＰＤＣＣＨ領域がデフォルト値より大きい場合、上りリンク送信は、ＰＣＦＩＣＨからのＯＦＤＭシンボルの数によって決定されるスペシャル・サブフレーム・タイプ２構造を用いる。例えば、ＰＣＦＩＣＨが最小（仮定された）ＰＤＣＣＨサイズより大きいサイズを指示する場合、ＵＥ１０２は、スペシャル・サブフレーム・タイプ２からのデータをパンクチャする（ステップ５０８）。例として、選択されたスペシャル・サブフレーム・タイプ２構造によって取って代わられたＯＦＤＭシンボル中の符号化および多重化されたデータは、パンクチャして除かれる。かくして、所定のＯＦＤＭシンボルではいかなるＰＵＳＣＨ送信も発生することはない。
【０１８０】
図６は、本明細書に開示されるシステムおよび方法に従って用いられる無線フレーム６９４の一例を示す図である。この無線フレーム６９４構造は、時分割複信（ＴＤＤ）手法に適用可能である。各無線フレーム６９４は、
Ｔｆ＝３０７２００・Ｔｓ＝１０
ミリ秒（ｍｓ）の長さを有し、ここで
Ｔｆ
は無線フレーム６９４持続時間であり、
Ｔｓ
は
【０１８１】
【数９】
2014522135.tif 000015
【０１８２】
秒に等しい時間単位である。無線フレーム６９４は、それぞれが
１５３６００・Ｔｓ＝５
ｍｓの長さを有する２つの半フレーム６９６を含む。各半フレーム６９６は、それぞれが
３０７２０・Ｔｓ＝１
ｍｓの長さを有する５つのサブフレーム６２３ａ〜ｅ、６２３ｆ〜ｊを含む。
【０１８３】
本明細書に開示されるシステムおよび方法に従って、用いられるサブフレーム６２３のいくつかのタイプは、下りリンク・サブフレーム、上りリンク・サブフレーム、標準的スペシャル・サブフレーム６３１およびスペシャル・サブフレーム・タイプ２を含む。図６に示される例では、２つの標準的スペシャル・サブフレーム６３１ａ〜ｂが無線フレーム６９４に含まれる。
【０１８４】
第１の標準的スペシャル・サブフレーム６３１ａは、下りリンク・パイロット時間スロット（ＤｗＰＴＳ）６２５ａ、ガード期間（ＧＰ）６２７ａおよび上りリンク・パイロット時間スロット（ＵｐＰＴＳ）６２９ａを含む。この例では、第１の標準的スペシャル・サブフレーム６３１ａは、サブフレームｏｎｅ  ６２３ｂに含まれる。第２の標準的スペシャル・サブフレーム６３１ｂは、下りリンク・パイロット時間スロット（ＤｗＰＴＳ）６２５ｂ、ガード期間（ＧＰ）６２７ｂおよび上りリンク・パイロット時間スロット（ＵｐＰＴＳ）６２９ｂを含む。この例では、第２の標準的スペシャル・サブフレーム６３１ｂは、サブフレームｓｉｘ  ６２３ｇに含まれる。ＤｗＰＴＳ６２５ａ〜ｂおよびＵｐＰＴＳ６２９ａ〜ｂの長さは、ＤｗＰＴＳ６２５、ＧＰ６２７およびＵｐＰＴＳ６２９の各組の全長が
３０７２０・Ｔｓ＝１
ｍｓであることを前提として、３ＧＰＰ  ＴＳ  ３６．２１１の表４．２−１に示される。
【０１８５】
各サブフレームｉ  ６２３ａ〜ｊ（この例では、ｉはサブフレームｚｅｒｏ  ６２３ａ（例えば０）からサブフレームｎｉｎｅ  ６２３ｊ（例えば９）に及ぶサブフレームを示す）は、各サブフレーム６２３における長さが
Ｔｓｌｏｔ＝１５３６０・Ｔｓ＝０．５
ｍｓの２つのスロット
２ｉ
および
２ｉ＋１
として定義される。例えば、サブフレームｚｅｒｏ（例えば０）６２３ａは、第１のスロット６９８を含めて、２つのスロットを含む。
【０１８６】
本明細書に開示されるシステムおよび方法に従って、下りリンクから上りリンクへの切り替えポイント周期が５ｍｓおよび１０ｍｓの両方のＵＬ−ＤＬ構成が用いられる。図６は、５ｍｓの切り替えポイント周期を持つ無線フレーム６９４の一例を示す。下りリンクから上りリンクへの切り替えポイント周期が５ｍｓの場合、各半フレーム６９６が標準的スペシャル・サブフレーム６３１ａ〜ｂを含む。下りリンクから上りリンクへの切り替えポイント周期が１０ｍｓの場合、スペシャル・サブフレームは、第１の半フレーム６９６だけに存在する。
【０１８７】
サブフレームｚｅｒｏ（例えば、０）６２３ａおよびサブフレームｆｉｖｅ（例えば、５）６２３ｅならびにＤｗＰＴＳ６２５ａ〜ｂは、下りリンク送信のために予約される。ＵｐＰＴＳ６２９ａ〜ｂ、および標準的スペシャル・サブフレーム（単数または複数）６３１ａ〜ｂのすぐ後に続くサブフレーム（単数または複数）（例えば、サブフレームｔｗｏ  ６２３ｃおよびサブフレームｓｅｖｅｎ  ６２３ｈ）は、上りリンク送信のために予約される。複数のセルがアグリゲートされた場合、ＵＥ１０２は、すべてのセルにわたって同じＵＬ−ＤＬ構成を仮定し、かつ異なったセルにおけるスペシャル・サブフレーム（単数または複数）のガード期間（ＧＰ）が、少なくとも
１４５０・Ｔｓ
の重なりを有すると仮定する。
【０１８８】
図６に示されるサブフレーム６２３の１つ以上が、用いられるＵＬ−ＤＬ構成に依存して、上りリンク・サブフレームに変換されてもよい。例えば、上掲の表（１）に示されるようなＵＬ−ＤＬ構成５を仮定すると、サブフレームｔｈｒｅｅ（例えば、３）６２３ｄは、下りリンク・サブフレーム６３３として構成されているとき、スペシャル・サブフレーム・タイプ２に変換されてもよい。
【０１８９】
図７は、上りリンク−下りリンク対応付けの例を示す図である。ＴＤＤ  ＵＬ−ＤＬ構成Ａ  ７３５ａにおけるサブフレーム７２３ａの第１の例（例えば、上掲の表（１）に示されるようなＵＬ−ＤＬ構成１）は、下りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け７３７ａ〜ｄ、ＰＵＳＣＨ送信に対する下りリンク・スケジューリング対応付け７３９ａ〜ｂ、および上りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け７４１ａ〜ｂを示す。この例に関連するサブフレーム番号７４９ａが示される。
【０１９０】
この例では、第１の無線フレーム７９４ａにおける下りリンク・サブフレーム０および標準的スペシャル・サブフレーム１での下りリンク送信のＡＣＫ／ＮＡＣＫは、第１の無線フレーム７９４ａにおける上りリンク・サブフレーム７でレポートされ、対応付け７３７ａとして示される。第１の無線フレーム７９４ａにおける下りリンク・サブフレーム４での下りリンク送信のＡＣＫ／ＮＡＣＫは、第１の無線フレーム７９４ａにおける上りリンク・サブフレーム８でレポートされ、対応付け７３７ｂとして示される。同様に、第１の無線フレーム７９４ａにおける下りリンク・サブフレーム５および標準的スペシャル・サブフレーム６での下りリンク送信のＡＣＫ／ＮＡＣＫは、第２の無線フレーム７９４ｂにおける上りリンク・サブフレーム２でレポートされ、対応付け７３７ｃとして示される。第１の無線フレーム７９４ａにおける下りリンク・サブフレーム９での下りリンク送信のＡＣＫ／ＮＡＣＫは、第２の無線フレーム７９４ｂにおける上りリンク・サブフレーム３でレポートされ、対応付け７３７ｄとして示される。
【０１９１】
例を続けると、第１の無線フレーム７９４ａにおける標準的スペシャル・サブフレーム１は、第１の無線フレーム７９４ａにおける上りリンク・サブフレーム７でのＰＵＳＣＨ送信をスケジューリングし、対応付け７３９ａとして示される。第１の無線フレーム７９４ａにおける下りリンク・サブフレーム４は、第１の無線フレーム７９４ａにおける上りリンク・サブフレーム８でのＰＵＳＣＨ送信をスケジューリングし、対応付け７３９ｂとして示される。同様に、第１の無線フレーム７９４ａにおける標準的スペシャル・サブフレーム６は、第２の無線フレーム７９４ｂにおける上りリンク・サブフレーム２でのＰＵＳＣＨ送信をスケジューリングする（図７に示されない）。
【０１９２】
例を続けると、第１の無線フレーム７９４ａにおける下りリンク・サブフレーム９は、第２の無線フレーム７９４ｂにおける上りリンク・サブフレーム３でのＰＵＳＣＨ送信をスケジューリングする（図７に示されない）。第１の無線フレーム７９４ａにおける上りリンク・サブフレーム７でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、第２の無線フレーム７９４ｂにおける標準的スペシャル・サブフレーム１でレポートされ、対応付け７４１ａとして示される。第１の無線フレーム７９４ａにおける上りリンク・サブフレーム８でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、第２の無線フレーム７９４ｂにおける下りリンク・サブフレーム４でレポートされ、対応付け７４１ｂとして示される。同様に、第１の無線フレーム７９４ａにおける上りリンク・サブフレーム２でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、第１の無線フレーム７９４ａにおける標準的スペシャル・サブフレーム６でレポートされる（図７に示されない）。第１の無線フレーム７９４ａにおける上りリンク・サブフレーム３でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、第１の無線フレーム７９４ａにおける下りリンク・サブフレーム９でレポートされる（図７に示されない）。
【０１９３】
ＴＤＤ  ＵＬ−ＤＬ構成Ｂ  ７３５ｂにおけるサブフレーム７２３ｂの第２の例（例えば、上掲の表（１）に示されるようなＵＬ−ＤＬ構成２）は、下りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け７３７ｅ〜ｆ、ＰＵＳＣＨ送信に対する下りリンク・スケジュール対応付け７３９ｃ〜ｄ、および上りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け７４１ｃ〜ｄを示す。この例に関連するサブフレーム番号７４９ｂが示される。
【０１９４】
この例では、第３の無線フレーム７９４ｃにおける下りリンク・サブフレーム４、５、６および８での下りリンク送信のＡＣＫ／ＮＡＣＫは、第４の無線フレーム７９４ｄにおける上りリンク・サブフレーム２でレポートされ、対応付け７３７ｅとして示される。同様に、第３の無線フレーム７９４ｃの下りリンク・サブフレーム９、および第４の無線フレーム７９４ｄにおける下りリンク・サブフレーム０、１および３での下りリンク送信のＡＣＫ／ＮＡＣＫは、第４の無線フレーム７９４ｄにおける上りリンク・サブフレーム７でレポートされ、対応付け７３７ｆとして示される。
【０１９５】
例を続けると、第３の無線フレーム７９４ｃにおける下りリンク・サブフレーム３は、第３の無線フレーム７９４ｃにおける上りリンク・サブフレーム７でのＰＵＳＣＨ送信をスケジューリングし、対応付け７３９ｃとして示される。同様に、第３の無線フレーム７９４ｃにおける下りリンク・サブフレーム８は、第４の無線フレーム７９４ｄにおける上りリンク・サブフレーム２でのＰＵＳＣＨ送信をスケジューリングし、対応付け７３９ｄとして示される。
【０１９６】
例を続けると、第３の無線フレーム７９４ｃにおける上りリンク・サブフレーム７でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、第４の無線フレーム７９４ｄにおける下りリンク・サブフレーム３でレポートされ、対応付け７４１ｃとして示される。同様に、第４の無線フレーム７９４ｄにおける上りリンク・サブフレーム２でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、第４の無線フレーム７９４ｄにおける下りリンク・サブフレーム８でレポートされ、対応付け７４１ｄとして示される。
【０１９７】
第１の例と第２の例とを比較したときに、気付きうるのは、たとえ２つの例の間で１つのサブフレーム７２３だけが異なるに過ぎないとしても、対応付け７３７、７３９、７４１のいずれも同じでないことである。留意すべきは、図７において「Ｄ」が下りリンク・サブフレーム７４３を示し、「Ｕ」が上りリンク・サブフレーム７４５を示し、「Ｓ」が標準的スペシャル・サブフレーム７４７を示すことである。
【０１９８】
図８は、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１の構造を示す図である。（スペシャル・サブフレーム・タイプ２（Ｓ２）８５１と混同すべきではない）標準的スペシャル・サブフレームは、下りリンクから上りリンクへの切り替えに用いられる。標準的スペシャル・サブフレームでは、チャネル・リソースの大部分が下りリンク送信に割当てられるのに対して、上りリンクには短時間（例えば、１つかまたは２つのシンボル）が割当てられる。しかしながら、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１は、すべての必要な下りリンク通知（例えば、ＰＵＳＣＨスケジューリングおよびＰＨＩＣＨフィードバックに関する制御情報）を維持する一方で、より多くのリソースを上りリンク送信に提供することができる。（もしあれば）ＰＤＣＣＨ送信だけを維持し、リソースの残りを（例えば、可能なガード期間８５５とともに）ＰＵＳＣＨ送信に割当てることによって、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２（Ｓ２）８５１に変換される。
【０１９９】
ＰＤＣＣＨ  ＤＣＩフォーマット０を用いたＰＵＳＣＨスケジューリングでは、ＰＵＳＣＨ割当ては、スタートＲＢのインデックスとＲＢの数とによって表される連続的なリソースブロック（ＲＢ）からなるブロックである。スペシャル・サブフレーム・タイプ２（Ｓ２）８５１のためのＰＵＳＣＨ割当てにおいて、各サブキャリアに使用可能なリソース要素（ＲＥ）は、上りリンク・パイロット時間スロット（ＵｐＰＴＳ）８５７領域におけるシンボルの数と同じにするとよい。
【０２００】
標準的スペシャル・サブフレームと同様に、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１は、３つのフィールド８５３、８５５、８５７を有する。標準的スペシャル・サブフレームでは、３つのフィールドは、下りリンク・パイロット時間スロット（ＤｗＰＴＳ）、ガード期間（ＧＰ）および上りリンク・パイロット時間スロット（ＵｐＰＴＳ）である。便宜上、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１における３つのフィールドも、ＤｗＰＴＳ８５３、ＧＰ８５５およびＵｐＰＴＳ８５７）と呼ばれる。スペシャル・サブフレーム・タイプ２（Ｓ２）８５１における３つのフィールドは、標準的スペシャル・サブフレームにおけるのと同じ名前を用いて呼ばれるが、留意すべきは、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１における３つのフィールドの特性が、標準的スペシャル・サブフレームにおける同じ名前のフィールドの特性と異なっても、同様でも、および／または同じでもよいことである。
【０２０１】
留意すべきは、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１が下りリンク・サブフレームを置き換えることができる（一方、標準的スペシャル・サブフレームはできない）という点で、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１が標準的スペシャル・サブフレームと異なることである。スペシャル・サブフレーム・タイプ２（Ｓ２）８５１は、標準的スペシャル・サブフレームがそのＵｐＰＴＳで運ぶのに比べて、より多くのデータをＵｐＰＴＳ８５７で運ぶことができる。
【０２０２】
スペシャル・サブフレーム・タイプ２（Ｓ２）８５１は、必要な下りリンク・シグナリングを維持する一方で、増加したリソースを上りリンク送信に提供する。例えば、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１は、必要に応じてＰＤＣＣＨ領域を維持するが、いかなるＰＤＳＣＨ割当ても有さない。スペシャル・サブフレーム・タイプ２（Ｓ２）８５１におけるリソースの大部分は、ＰＵＳＣＨ送信に割当てられる。すべての上りリンク制御フィードバックは、既存の上りリンク・サブフレームと対応付けられるので、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１ではいかなるＰＵＣＣＨ割当ておよびＰＵＣＣＨ送信も許可されることはない。
【０２０３】
スペシャル・サブフレーム・タイプ２（Ｓ２）８５１では、ＤｗＰＴＳ８５３は、必要な下りリンク制御通知（例えば、ＰＤＣＣＨおよびＰＨＩＣＨ）だけを提供するように制限される。ＰＤＣＣＨは、上りリンク・サブフレームでのＰＵＳＣＨ送信をスケジューリングするために用いられる。しかしながら、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１におけるＰＤＣＣＨは、ＰＤＳＣＨ送信をスケジューリングすることはないので、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１におけるＤｗＰＴＳ８５３のサイズは、通常の下りリンク・サブフレームにおけるＤｗＰＴＳより小さくてもよい。例えば、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１におけるリソースブロックの数が１０より大きいとき、ＰＤＣＣＨに用いられる直交周波数分割多重（ＯＦＤＭ）シンボルの数は、１つかまたは２つに制限される。そのうえ、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１におけるリソースブロックの数が１０以下であるとき、ＰＤＣＣＨに用いられるＯＦＤＭシンボルの数は、２つにするとよい。
【０２０４】
ガード期間（ＧＰ）８５５は、ＵＥ１０２が上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス（ＣＰ）構成を有する場合、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１におけるＧＰ８５５は、１つのＯＦＤＭシンボルの長さを有するべきである。上りリンクおよび下りリンクが異なったサイクリックプレフィックス（ＣＰ）構成を有する場合、ＧＰは、１つより少ないか、または１つより多いＯＦＤＭシンボルにするとよい。しかしながら、切り替えタイミングを確実にするために、スペシャル・サブフレーム・タイプ２（Ｓ２）８５１の（もし存在するならば）ＧＰ８５５は、（もし用いられるならば）少なくとも
１４５６・Ｔｓ
の長さを有するべきである。
【０２０５】
現行のＵＬ−ＤＬ構成において、下りリンク・サブフレームがＰＵＳＣＨスケジューリング、電力制御および任意の上りリンク送信へのＰＨＩＣＨフィードバックとの関連付けを有さない場合、下りリンク・サブフレームは、いかなる予約されたＰＤＣＣＨ領域も持たない（例えば、ＤｗＰＴＳ８５３長が０の）スペシャル・サブフレーム・タイプ２（Ｓ２）８５１に変換される。現行のＵＬ−ＤＬ構成において、下りリンク・サブフレームがＰＵＳＣＨスケジューリング、電力制御および任意の上りリンク送信へのＰＨＩＣＨフィードバックとの関連付けを有さず、下りリンク・サブフレームが上りリンク・サブフレームのすぐに後（あるいは、おそらくいくつかの構成においてスペシャル・サブフレーム・タイプ２（Ｓ２）８５１の後）にある場合、下りリンク・サブフレームは、いかなるＧＰ８５５も持たない上りリンク・サブフレームに完全に変換される。現行のＵＬ−ＤＬ構成において、下りリンク・サブフレームがＰＵＳＣＨスケジューリング、電力制御および任意の上りリンク送信へのＰＨＩＣＨフィードバックとの関連付けを有さず、変換されるべき下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、例えば、第１のＯＦＤＭシンボル長がＧＰ８５５として予約され、一方では、すべての他のＯＦＤＭシンボルが上りリンク送信に割当てられる。
【０２０６】
スペシャル・サブフレーム・タイプ２（Ｓ２）８５１の一構成において、ＤｗＰＴＳ８５３の長さおよびＵｐＰＴＳ８５７の長さは、ＤｗＰＴＳ８５３、ＧＰ８５５およびＵｐＰＴＳ８５７の全長が
３０７２０・Ｔｓ＝１
ｍｓに等しいことを前提として、表（５）に示される。スペシャル・サブフレーム・タイプ２（Ｓ２）８５１の構造に関するさらなる詳細は、以下の通りである。
【０２０７】
【表５】
2014522135.tif 000016
【０２０８】
以下の表（６）は、同じ構成をＯＦＤＭシンボルの数の観点から提供するものである。ＰＤＣＣＨのために１つのＯＦＤＭシンボルが用いられる場合、ＵｐＰＴＳ８５７は、上りリンク送信のために通常のサイクリックプレフィックス（ＣＰ）が構成されるのであれば１２個のＯＦＤＭシンボルを、あるいは上りリンク送信のために拡張されたＣＰが構成されるのであれば１０個のＯＦＤＭシンボルを有する。ＰＤＣＣＨのために２つのＯＦＤＭシンボルが用いられる場合、ＵｐＰＴＳ８５７は、上りリンク送信のために通常のＣＰが構成されるのであれば、１１個のＯＦＤＭシンボル、あるいは上りリンク送信のために拡張されたＣＰが構成されるのであれば、９個のＯＦＤＭシンボルを有する。いかなる予約されたＰＤＣＣＨ領域も持たない（例えば、ＤｗＰＴＳ８５３長が０の）スペシャル・サブフレーム・タイプ２（Ｓ２）８５１に関して、対象下りリンク・サブフレーム（例えば、変換されるべき下りリンク・サブフレーム）が上りリンク・サブフレームの直後にある場合、すべてのシンボルが上りリンク割当てに用いられる。しかしながら、対象下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、第１のＯＦＤＭシンボル長がＧＰ８５５として予約され、一方では、すべての他のＯＦＤＭシンボルが上りリンク送信に割当てられる。
【０２０９】
【表６】
2014522135.tif 000017
【０２１０】
図９は、本明細書に開示されるシステムおよび方法による下りリンク・サブフレーム変換の一例を示す図である。より具体的には、図９は、いくつかのサブフレーム９２３を示し、同図中、（以前は下りリンク・サブフレームであった）サブフレームｎがスペシャル・サブフレーム・タイプ２（Ｓ２）９６３に変換される。加えて、図９は、スペシャル・サブフレーム・タイプ２（Ｓ２）変換ルールおよびＰＨＹレイヤ通知を示す。
【０２１１】
本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ２（Ｓ２）９６３に変換される。これは、例えば、１つ以上のＤＣＩフォーマット０  ＰＵＳＣＨ送信が、（現行の３ＧＰＰリリース８、９および１０の仕様書では、ＰＵＳＣＨ割当てのためのＤＣＩフォーマット０を有することが許可されていない）下りリンク・サブフレームに割当てられたとき、あるいは以前に割当てられたスペシャル・サブフレーム・タイプ２に対するＰＨＩＣＨフィードバックが必要とされるときに発生する。
【０２１２】
スペシャル・サブフレーム・タイプ２（Ｓ２）９５１に対する対応付けは、以下のように規定される。所定のＵＬ−ＤＬ構成に関して、下りリンク・サブフレームｎ−４は、ＰＵＳＣＨスケジューリング、および上りリンク送信に対するＰＨＩＣＨまたはＰＤＣＣＨフィードバックとの対応付けを有さなくてもよい。下りリンク・サブフレームｎ−４（例えば、ＤＣＩフォーマット０を持つＰＤＣＣＨを含んだ下りリンク・サブフレーム９４３ａ）は、（例えば、以前は下りリンク・サブフレームであった）下りリンク・サブフレームｎ９６３をスペシャル・サブフレーム・タイプ２（Ｓ２）９５１に変換する。例として、対応付けＡ９５９は、サブフレームｎ−４（例えば、下りリンク・サブフレーム９４３ａ）におけるＰＵＳＣＨのスケジューリングが、サブフレームｎをスペシャル・サブフレーム・タイプ２（Ｓ２）９５１に変換することを特定する。サブフレームｎ−４における制御情報に従って、サブフレームｎがスペシャル・サブフレーム・タイプ２（Ｓ２）９５１に変換される。ＰＵＳＣＨ割当てを持つ１つ以上のＵＥ１０２は、サブフレームｎで送信を行うことができる。
【０２１３】
サブフレーム番号ｎを持つスペシャル・サブフレーム・タイプ２に対するＡＣＫ／ＮＡＣＫフィードバックは、サブフレームｎ＋６（例えば、下りリンク・サブフレーム９４３ｂ）でレポートされる。例として、対応付けＢ９６１は、スペシャル・サブフレーム・タイプ２（Ｓ２）９５１に対するＡＣＫ／ＮＡＣＫがサブフレームｎ＋６でレポートされることを特定する。留意すべきは、この対応付け９５９、９６１が無線フレーム境界を越えて適用されてもよいことである。
【０２１４】
一構成において、変換されたサブフレームｎでのＰＵＳＣＨ送信に対するＡＣＫ／ＮＡＣＫは、下りリンク・サブフレームｎ＋６におけるＰＨＩＣＨ上で運ばれる。随意的に、サブフレームｎ＋６におけるＰＤＣＣＨがＰＨＩＣＨをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームｎ＋１０での新しいデータの送信または再送信をスケジューリングすることもできる。
【０２１５】
別の構成では、変換されたサブフレームｎにＰＵＳＣＨ送信に対するいかなるＰＨＩＣＨもないことがあり、ＵＥ１０２は、ＰＨＩＣＨ値をＡＣＫと見做す。そのうえ、サブフレームｎ＋６におけるＰＤＣＣＨがＡＣＫをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームｎ＋１０での新しいデータ送信または再送信をスケジューリングすることもできる。再送信のスケジューリングは、以前のＰＵＳＣＨ送信に対するＮＡＣＫを示す。ＵＥ１０２がＰＤＣＣＨを何も検出しない場合、ＵＥ１０２は、サブフレームｎ＋１０でＰＵＳＣＨを送信することはない。ＴＤＤは、５ｍｓおよび１０ｍｓの両方の構成に共通の１０個の間隔を有し、ｎ＋６＝（ｎ−４）＋１０なので、ＰＨＩＣＨおよびＤＣＩフォーマット０を持つＰＤＣＣＨ割当ては、常に同じ下りリンク・サブフレーム・インデックス番号を有する。
【０２１６】
言い換えれば、サブフレーム番号ｎを持つスペシャル・サブフレーム・タイプ２（Ｓ２）９５１のＰＵＳＣＨは、スペシャル・サブフレーム・タイプ２（Ｓ２）９５１の４サブフレーム前にある下りリンク・サブフレーム（例えば、標準的な構成においてＰＵＳＣＨスケジューリング、およびＰＵＳＣＨ送信に対するＡＣＫ／ＮＡＣＫフィードバックに関するいかなる既存の対応付けもない、サブフレーム番号ｎ−４を持つ下りリンク・サブフレーム９４３ａ）のＰＤＣＣＨまたはＰＨＩＣＨフィードバックでスケジューリングされる。サブフレーム番号ｎを持つスペシャル・サブフレーム・タイプ２（Ｓ２）９５１でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫフィードバックは、サブフレーム番号ｎ＋６を持つ下りリンク・サブフレーム９４３ｂにおいてＰＨＩＣＨ上で、あるいは明示的なＰＤＣＣＨスケジューリングによってレポートされる。
【０２１７】
いくつかの構成において、ｎは、サブフレーム番号またはインデックスｉの周期的な組における現サブフレームを示す。サブフレーム番号またはインデックスｉは、０から９に及び、各周期が無線フレームに対応する。従って、数ｋがｎに加えられるか、またはｎから引かれて、ｉの周期の範囲（例えば、０≦ｉ≦９）を越えた場合、結果は、異なった無線フレームにおけるサブフレームを特定する。例として、ｎ＋ｋ＝ｉは、ｎ＝９およびｋ＝４の場合、現無線フレームの次の無線フレームにおけるサブフレームｉ＝３を特定する。言い換えれば、インデックスは、モジュラー関数ｍｏｄ（ｎ＋ｋ）＝ｉによって表すことができて、（ｎ＋ｋ）＝ｉであれば、これらは同じ無線フレーム中にある。（ｎ＋ｋ）≧１０であれば、ｉ＝ｍｏｄ（ｎ＋ｋ）＝ｎ＋ｋ−１０であり、サブフレーム・インデックスｉは、現無線フレームの次の無線フレーム中にある。
【０２１８】
図９に示される例に従って、ｅＮＢ１６０は、スペシャル・サブフレーム・タイプ２（Ｓ２）９５１に変換された対象下りリンク・サブフレームの４サブフレーム前にある、下りリンク・サブフレーム９４３ａでＰＨＹレイヤ通知を送信し、ＵＥ（単数または複数）１０２はこれを受信する。１つ以上のＵＥ１０２および随意的にｅＮＢ１６０は、スペシャル・サブフレーム・タイプ２（Ｓ２）９５１でデータを送信（および／または受信）する。ｅＮＢ１６０は、スペシャル・サブフレーム・タイプ２（Ｓ２）９５１に変換された対象下りリンク・サブフレームの６サブフレーム後にある、下りリンク・サブフレーム９４３ｂでＡＣＫ／ＮＡＣＫデータを送信し、ＵＥ（単数または複数）１０２は、これを受信する。ＡＣＫ／ＮＡＣＫデータは、スペシャル・サブフレーム・タイプ２（Ｓ２）９５１でＵＥ（単数または複数）１０２からｅＮＢ１６０へ送信されたデータに対応する。
【０２１９】
図１０は、本明細書に開示されるシステムおよび方法による下りリンク・サブフレーム変換の別の例を示す図である。留意すべきは、図１０において「Ｄ」が下りリンク・サブフレーム１０４３を示し、「Ｕ」が上りリンク・サブフレーム１０４５を示し、「Ｓ」が標準的スペシャル・サブフレーム１０４７を示し、「Ｓ２」がスペシャル・サブフレーム・タイプ２（Ｓ２）１０５１を示すことである。
【０２２０】
この例において、（上掲の表（１）に示されるような）上りリンクおよび下りリンク（ＵＬ−ＤＬ）構成５は、サブフレームの第１の組１０２３ａでは、下りリンク・サブフレーム変換なしに用いられ、サブフレームの第２の組１０２３ｂでは、下りリンク・サブフレーム変換して用いられる。構成５では、サブフレームの第１および第２の組１０２３ａ〜ｂに対応するサブフレーム番号１０４９ａ〜ｂに従って、それぞれのサブフレーム番号ｉ＝２に１つだけ上りリンク・サブフレーム１０４５が存在する。
【０２２１】
サブフレームの両方の組１０２３ａ〜ｂにおいて、ＰＵＳＣＨ割当ては、現フレーム１０９４ａ〜ｂの前のフレームのサブフレーム番号ｉ＝８におけるＰＤＣＣＨ  ＤＣＩフォーマット０またはＰＨＩＣＨフィードバックによって通知される。例えば、ＰＵＳＣＨ送信に対する下りリンク・スケジューリング対応付け１０３９ａ〜ｂが、サブフレームの両方の組１０２３ａに示される。現行の３ＧＰＰ仕様書（例えば、リリース８、９および１０）によれば、構成５では、すべての他の下りリンク・サブフレームは、ＰＤＣＣＨ  ＤＣＩフォーマット０またはＰＨＩＣＨフィードバックを運ぶことができない。
【０２２２】
しかしながら、本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレーム１０４３番号ｉ＝３でのＰＵＳＣＨ送信をスケジューリングする（あるいはＰＨＩＣＨ上でＰＵＳＣＨ送信を肯定する）ためにＰＤＣＣＨ  ＤＣＩフォーマット０が前のフレームのサブフレーム番号ｉ＝９に割当てられている場合、現フレーム１０９４ｂの下りリンク・サブフレーム１０４３番号ｉ＝３は、スペシャル・サブフレーム・タイプ２（Ｓ２）１０５１に変換される。このように、ＰＵＳＣＨ送信に対する下りリンク・スケジューリング対応付け１０３９ｃが用いられる。割当てられたＰＵＳＣＨリソース上でＰＵＳＣＨ送信を運ぶことができる。
【０２２３】
図１０に示されるように、サブフレームの両方の組１０２３ａ〜ｂにおいて、上りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け１０４１ａ〜ｂは、対応するＡＣＫ／ＮＡＣＫ情報が下りリンク・サブフレーム１０４３番号ｉ＝８で通信されることを特定するために、上りリンク・サブフレーム番号ｉ＝２に対して用いられる。サブフレームの第２の組１０２３ｂでは、スペシャル・サブフレーム・タイプ２（Ｓ２）１０５１でのＰＵＳＣＨ送信のＡＣＫ／ＮＡＣＫは、上りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック１０４１ｃに従って、サブフレーム番号ｉ＝９上でレポートされる。
【０２２４】
下りリンク・サブフレーム１０４３からスペシャル・サブフレーム・タイプ２（Ｓ２）１０５１への変換は、一時的かつ動的であってもよい。いくつかの構成において、下りリンク・サブフレーム１０４３は、上記の条件下においてのみ、スペシャル・サブフレーム・タイプ２（Ｓ２）１０５１に変換される。その他の場合は、通常の下りリンク・サブフレーム１０４３として機能する。このように、変換および遷移は、自律的に生じ、いかなる追加の通知も必要ではない。
【０２２５】
スペシャル・サブフレームを予期しないレガシーＵＥは、スペシャル・サブフレーム・タイプ２（Ｓ２）１０５１を通常の下りリンク・サブフレーム１０４３として扱う。スペシャル・サブフレーム・タイプ２（Ｓ２）１０５１にＰＤＣＣＨが存在するとき、レガシーＵＥにとって何も変化はない。スペシャル・サブフレーム・タイプ２（Ｓ２）１０５１にＰＤＣＣＨが存在しないとき、レガシーＵＥは、ＰＤＣＣＨを首尾よく検出できないので、このサブフレームに関してＤＴＸをレポートする。リリース１１以降のＵＥ１０２は、本明細書に開示されるシステムおよび方法に従って、必要とされる上りリンク−下りリンク対応付け、およびスペシャル・サブフレーム・タイプ２（Ｓ２）１０５１でのデータ送信を行う。
【０２２６】
本明細書に開示されるシステムおよび方法は、既存の（例えば、３ＧＰＰリリース８、９および１０による）対応付け１０３７、１０３９、１０４１を維持する一方で、下りリンク・サブフレーム１０４３のスペシャル・サブフレーム・タイプ２（Ｓ２）１０５１への変換を提供する。例えば、スペシャル・サブフレーム・タイプ２（Ｓ２）１０５１）を持つ第２のサブフレームの組１０２３ｂにおける、下りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け１０３７ｂは、第１のサブフレームの組１０２３ａにおける、下りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け１０３７ａと同じである。同様に、ＰＵＳＣＨ送信に対する既存の下りリンク・スケジューリング対応付け１０３９ａ、１０３９ｂ、および上りリンク送信に対するＡＣＫ／ＮＡＣＫフィードバック対応付け１０４１ａ、１０４１ｂは、維持される。
【０２２７】
図１１は、端末装置（ＵＥ）１１０２に利用される様々なコンポーネントを示す。ＵＥ１１０２は、上記のＵＥ１０２として利用されてもよい。ＵＥ１１０２は、ＵＥ１１０２の動作を制御するプロセッサ１１６９を含む。プロセッサ１１６９は、ＣＰＵと呼ぶこともできる。メモリ１１７５は、リードオンリーメモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、これら２つの組み合わせ、あるいは情報を記憶する任意のタイプのデバイスを含み、プロセッサ１１６９に命令１１７１ａおよびデータ１１７３ａを与える。メモリ１１７５の一部分は、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ：ｎｏｎ−ｖｏｌａｔｉｌｅ  ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）も含んでもよい。命令１１７１ｂおよびデータ１１７３ｂは、プロセッサ１１６９にも存在する。プロセッサ１１６９に読み込まれた命令１１７１ｂおよび／またはデータ１１７３ｂは、プロセッサ１１６９による実行または処理のために読み込まれた、メモリ１１７５からの命令１１７１ａおよび／またはデータ１１７３ａも含んでもよい。命令１１７１ｂは、本明細書に開示される方法３００、４００、５００の１つ以上を実装するためにプロセッサ１１６９によって実行される。
【０２２８】
ＵＥ１１０２は、データの送信および受信を可能にするために１つ以上の送信機１１５８および１つ以上の受信機１１２０が入った筺体も含む。送信機（単数または複数）１１５８および受信機（単数または複数）１１２０は、１つ以上のトランシーバ１１１８に組み合わされてもよい。１つ以上のアンテナ１１２２ａ〜ｎは、筺体に取り付けられ、トランシーバ１１１８に電気的に結合される。
【０２２９】
ＵＥ１１０２の様々なコンポーネントは、データバスに加えて、電力バス、制御信号バスおよびステータス信号バスを含む、バスシステム１１８１によって一緒に結合される。しかしながら、明確さのために、図１１では様々なバスがバスシステム１１８１として示される。ＵＥ１１０２は、信号処理用デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）１１７７を含むこともできる。ＵＥ１１０２は、ＵＥ１１０２の機能へのユーザ・アクセスを提供する通信インタフェース１１７９を含むこともできる。図１１に示されるＵＥ１１０２は、具体的なコンポーネントのリストではなく、機能ブロック図である。
【０２３０】
図１２は、ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ（ｅＮＢ）１２６０に利用される様々なコンポーネントを示す。ｅＮＢ１２６０は、先述のｅＮＢ１６０として利用されてもよい。ｅＮＢ１２６０は、ＵＥ１１０２に関する上述のコンポーネントと同様のコンポーネントを含むことができ、プロセッサ１２８３、プロセッサ１２８３に命令１２８５ａおよびデータ１２８７ａを与えるメモリ１２８９、プロセッサ１２８３中に存在しても、あるいは読み込まれてもよい命令１２８５ｂおよびデータ１２８７ｂ、（１つの以上のトランシーバ１２７６に組み合わされてもよい）１つ以上の送信機１２１７および１つ以上の受信機１２７８が入った筺体、トランシーバ（単数または複数）１２７６に電気的に結合された１つ以上のアンテナ１２８０ａ〜ｎ、バスシステム１２９５、信号処理用ＤＳＰ  １２９１、通信インタフェース１２９３などを含む。命令１２８５ｂは、本明細書に開示される方法２００を実施するために、プロセッサ１２８３によって実行される。
【０２３１】
用語「コンピュータ可読媒体」は、コンピュータまたはプロセッサによってアクセスされる任意の利用可能な媒体を指す。用語「コンピュータ可読媒体」は、本明細書では、非一時的かつ有形のコンピュータおよび／またはプロセッサ可読媒体を示す。限定ではなく、例として、コンピュータ可読またはプロセッサ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶、磁気ディスク記憶もしくは他の磁気記憶デバイス、あるいは、命令の形態の所望のプログラムコードまたはデータ構造を載せるか、または記憶するために用いられ、コンピュータまたはプロセッサによってアクセスされる任意の他の媒体を備えてもよい。ディスク（ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、本明細書では、コンパクトディスク（ＣＤ：ｃｏｍｐａｃｔ  ｄｉｓｃ）、レーザディスク（ｌａｓｅｒ  ｄｉｓｃ）、光ディスク（ｏｐｔｉｃａｌ  ｄｉｓｃ）、デジタルバーサタイルディスク（ＤＶＤ：ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｃ）、フロッピーディスク（ｆｌｏｐｐｙ  ｄｉｓｋ）およびＢｌｕ−ｒａｙ（登録商標）ディスク（ｄｉｓｃ）を含み、ディスク（ｄｉｓｋ）は、通常、磁気的にデータを再生し、一方でディスク（ｄｉｓｃ）は、レーザを用いて光学的にデータを再生する。
【０２３２】
留意すべきは、本明細書に記述される方法の１つ以上が、ハードウェアで実装されてもよい、および／またはハードウェアを用いて行われてもよいことである。例えば、本明細書に記述される方法の１つ以上は、チップセット、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）、大規模集積回路（ＬＳＩ：ｌａｒｇｅ−ｓｃａｌｅ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）または集積回路などで実装されてもよく、および／またはそれらを用いて実現されてもよい。
【０２３３】
本明細書に開示される方法のそれぞれは、記述される方法を実現するための１つ以上のステップまたは動作を含む。本方法のステップおよび／または動作は、特許請求の範囲から逸脱することなく、相互に交換されても、および／または単一のステップに組み合わされてもよい。言い換えれば、記述される方法の適切な操作のために、ステップまたは動作の特定の順序が、必要とされない限り、特許請求の範囲から逸脱することなく、特定のステップおよび／または動作の順序および／または使用が修正されてもよい。
【０２３４】
当然のことながら、特許請求の範囲は、上記に説明されたまさにその構成およびコンポーネントには限定されない。特許請求の範囲から逸脱することなく、本明細書に記述される配置、操作、ならびにシステム、方法、および装置の詳細に様々な修正、変更および変形がなされてもよい。
【図１】
2014522135.tif 000018
【図２】
2014522135.tif 000019
【図３】
2014522135.tif 000020
【図４】
2014522135.tif 000021
【図５】
2014522135.tif 000022
【図６】
2014522135.tif 000023
【図７】
2014522135.tif 000024
【図８】
2014522135.tif 000025
【図９】
2014522135.tif 000026
【図１０】
2014522135.tif 000027
【図１１】
2014522135.tif 000028
【図１２】
2014522135.tif 000029
【国際調査報告】
2014522135.tif 000030
2014522135.tif 000031