下りリンク・サブフレームを変換するように構成されたevolved Node B(eNB)が開示される。eNBは、プロセッサ、およびプロセッサと電子通信状態にあるメモリに記憶された実行可能な命令を含む。eNBは、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきかどうかを判定する。eNBは、また、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すると判定した場合、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理(PHY)レイヤ通知を送信する。対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきかどうかの判定は、トラフィック負荷に基づくとよい。
対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すると判定した場合、eNBはさらに、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定する。eNBは、また、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、対象下りリンク・サブフレームを、物理下りリンク制御チャネル(PDCCH:physical downlink control channel)を持つスペシャル・サブフレーム・タイプ2に変換する。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、eNBは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する。eNBは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、対象下りリンク・サブフレームを、ガード期間(GP:guard period)を持たず、物理下りリンク制御チャネル(PDCCH)を持たないスペシャル・サブフレーム・タイプ2に変換する。さらに、eNBは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、対象下りリンク・サブフレームを、GPを持ち、PDCCHを持たないスペシャル・サブフレーム・タイプ2に変換する。
PHYレイヤ通知は、対象下りリンク・サブフレームの4サブフレーム前にあるサブフレームで送信される。eNBは、肯定応答および否定応答(ACK/NACK:Acknowledgement and Negative Acknowledgement)データを、対象下りリンク・サブフレームの6サブフレーム後にあるサブフレームで送信することもできる。
信号を受信するために構成された端末装置(UE)も開示される。UEは、プロセッサ、およびプロセッサと電子通信状態にあるメモリに記憶された実行可能な命令を含む。UEは、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理(PHY)レイヤ通知を受信する。UEは、また、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換する。
UEは、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定することもできる。UEは、さらに、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、対象下りリンク・サブフレームを、物理下りリンク制御チャネル(PDCCH)を持つスペシャル・サブフレーム・タイプ2に変換する。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、UEは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する。UEは、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、対象下りリンク・サブフレームを、ガード期間(GP)を持たず、PDCCHを持たないスペシャル・サブフレーム・タイプ2に変換する。UEは、また、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、対象下りリンク・サブフレームを、GPを持ち、PDCCHを持たないスペシャル・サブフレーム・タイプ2に変換する。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、UEは、リソースブロック(RB:resource block)の数が10以下であるかどうかを判定する。UEは、また、RBの数が10以下でなければ、PDCCHのために1つの直交周波数分割多重(OFDM:orthogonal frequency division multiplexing)シンボルを予約する。UEは、さらに、RBの数が10以下であれば、PDCCHのために2つのOFDMシンボルを予約する。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在する場合、UEは、最小PDCCHサイズを仮定して、データ符号化および多重化を行い、物理制御フォーマット・インジケータ・チャネル(PCFICH:physical control format indicator channel)が、最小PDCCHサイズに等しいサイズを指示するかどうかを判定することもできる。UEは、PCFICHが最小PDCCHのサイズに等しくないサイズを指示すれば、スペシャル・サブフレーム・タイプ2からのデータをパンクチャする。UEは、また、PCFICHが最小PDCCHサイズに等しいサイズを指示すれば、符号化および多重化されたデータを変更なしに送信する。
PHYレイヤ通知は、対象下りリンク・サブフレームの4サブフレーム前にあるサブフレームで受信される。UEは、肯定応答および否定応答(ACK/NACK)データを、対象下りリンク・サブフレームの6サブフレーム後にあるサブフレームで受信することもできる。
下りリンク・サブフレームを変換するための方法も開示される。本方法は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきかどうかを判定することを含む。本方法は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すると判定した場合、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理(PHY)レイヤ通知を送信することも含む。
信号を受信するための方法も開示される。本方法は、対象下りリンク・サブフレームに関連するサブフレーム変換を指示する物理(PHY)レイヤ通知を受信することを含む。本方法は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換することも含む。
「3GPP」とも呼ばれる、第3世代パートナーシップ・プロジェクト(3rd Generation Partnership Project)は、第3および第4世代ワイヤレス通信システムに関する世界的に適用可能な技術仕様および技術レポートを規定することを目指した連携合意である。3GPPは、次世代モバイルネットワーク、システムおよびデバイスに関する仕様を規定する。
3GPPロング・ターム・エボリューション(LTE:Long Term Evolution)は、将来の要求に対処するためのユニバーサル・モバイル通信システム(UMTS:Universal Mobile Telecommunications System)モバイルフォンまたはデバイスの規格を改善するプロジェクトに与えられた名称である。一様態において、UMTSは、進化型ユニバーサル地上無線アクセス(E−UTRA:Evolved Universal Terrestrial Radio Access)および進化型ユニバーサル地上無線アクセス・ネットワーク(E−UTRAN:Evolved Universal Terrestrial Radio Access Network)に関するサポートおよび仕様を提供するために修正された。
本明細書に開示されるシステムおよび方法の少なくともいくつかの様態は、3GPPロング・ターム・エボリューション(LTE)、LTEアドバンスト(LTE−A:LTE−Advanced)および他の規格(例えば、3GPPリリース8、9、10および/または11)に関連して記述される。しかしながら、本開示の範囲は、この点で限定されるべきではない。本明細書に開示されるシステムおよび方法の少なくともいくつかの様態は、他のタイプのワイヤレス通信システムにおいて利用されてもよい。
ワイヤレス通信デバイスは、音声および/またはデータを基地局へ通信するために用いられ、次には基地局がデバイスのネットワーク(例えば、公衆交換電話網(PSTN:public switched telephone network)、インターネットなど)と通信する、電子デバイスである。本明細書においてシステムおよび方法を記述するとき、ワイヤレス通信デバイスは、代わりに移動局、端末装置(UE)、アクセス端末、加入者局、移動端末、遠隔局、ユーザ端末、端末、加入者ユニット、モバイルデバイスなどと呼ばれることもある。ワイヤレス通信デバイスの例は、セルラーフォン、スマートフォン、パーソナル・ディジタル・アシスタント(PDA:personal digital assistant)、ラップトップコンピュータ、ネットブック、電子書籍リーダ、ワイヤレス・モデムなどを含む。3GPP仕様書では、ワイヤレス通信デバイスは、典型的に端末装置(UE)と呼ばれる。しかしながら、本開示の範囲は、3GPP規格に限定されるべきではないので、より一般的な用語「ワイヤレス通信デバイス」を意味するために、本明細書では用語「UE」および「ワイヤレス通信デバイス」が同義で用いられる。
3GPP仕様書では、基地局は、典型的にNode B、evolvedまたはenhanced Node B(eNB)、home enhancedまたはevolved Node B(HeNB)、あるいはいくつか他の同様の用語法で呼ばれる。本開示の範囲は、3GPP規格に限定されるべきではないので、より一般的な用語「基地局」を意味するために、本明細書では、用語「基地局」、「Node B」、「eNB」、および「HeNB」が同義で用いられる。そのうえ、用語「基地局」は、アクセスポイントを示すために用いられてもよい。アクセスポイントは、ワイヤレス通信デバイスのためにネットワーク(例えば、ローカルエリアネットワーク(LAN:Local Area Network)、インターネットなど)へのアクセスを提供する電子デバイスである。用語「通信デバイス」は、ワイヤレス通信デバイスおよび/または基地局の両方を示すために用いられる。
留意すべきは、本明細書において、「セル」は、インターナショナル・モバイル・テレコミュニケーションズ−アドバンスト(IMT−Advanced:International Mobile Telecommunications−Advanced)に用いるために、正規化または規制団体によって仕様が定められた任意の通信チャネルであり、Node B(例えば、eNodeB)とUEとの間の通信に用いることが認可された帯域として、そのすべてまたはそのサブセットが、3GPPによって採用されている。「構成されたセル」は、UEがそれを関知して、情報を送信または受信することがNode B(例えば、eNB)によって許可されたセルである。「構成されたセル(単数または複数)」は、サービングセル(単数または複数)であってもよい。UEは、すべての構成されたセル上でシステム情報を受信し、必要とされる測定を行う。「アクティブ化されたセル」は、UEが送信および受信を行う構成されたセルである。すなわち、アクティブ化されたセルは、UEが物理下りリンク制御チャネル(PDCCH)をモニターする対象のセルであり、下りリンク送信の場合、UEが物理下りリンク共有チャネル(PDSCH:physical downlink shared channel)を復号する対象のセルである。「非アクティブ化されたセル」は、UEが送信PDCCHをモニターしていない構成されたセルである。留意すべきは、様々な次元の観点から「セル」が記述されることである。例えば、「セル」は、時間、空間(例えば、幾何形状)および周波数特性を有する。
本明細書に開示されるシステムおよび方法は、上りリンクおよび下りリンク割当てを動的に変更するために用いられる。LTE周波数分割複信(FDD:frequency−division duplexing)では、上りリンクおよび下りリンク信号に異なる周波数帯域が用いられる。この場合、ネットワークにおける非対称なトラフィック負荷は、キャリアアグリゲーション(CA:carrier aggregation)によって管理される。例えば、トラフィック負荷がより高い方向(例えば、上りリンクまた下りリンク)に対して、より多くの周波数帯域が割当てられる。
LTE時分割複信(TDD:time−division duplexing)では、上りリンクおよび下りリンク信号の両方に同じ周波数帯域が用いられる。様々な下りリンクおよび上りリンク・トラフィック比を実現するために、3GPP仕様書(例えば、3GPP TS 36.211)では7つの上りリンクおよび下りリンク(UL−DL)構成が規定されている。これらの割当ては、下りリンク信号に40%から90%の間のサブフレームを割当てることができる。
現行の仕様書(例えば、LTEリリース8、9および10)に従って、UL−DL構成を変更するためには、システム情報変更手順が用いられる。この手順は、長い遅延を有し、しかもコールド・システム・リスタートを必要とする(例えば、旧構成の上りリンク−下りリンク対応付けを切り離して新しい対応付けを設定するために、ある期間にわたって、システムにおけるすべてのUEが送信および受信できない)。留意すべきは、サブフレーム対応付けは、「上りリンク−下りリンク対応付け」と呼ばれてもよく、上りリンクから下りリンク・サブフレームへの対応付け、および/または下りリンクから上りリンク・サブフレームへの対応付けを含むことである。対応付けの例は、下りリンク・サブフレーム物理下りリンク制御チャネル(PDCCH)の、上りリンク・サブフレームにおける上りリンク電力制御への対応付け、下りリンク・サブフレーム物理下りリンク制御チャネル(PDCCH)の、上りリンク・サブフレームにおける物理上りリンク共有チャネル(PUSCH:physical uplink shared channel)割当てへの対応付け、下りリンク・サブフレーム(単数または複数)での物理下りリンク共有チャネル(PDSCH)送信に対する、上りリンク・サブフレーム(単数または複数)上の肯定応答および否定応答(ACK/NACK)フィードバックの対応付け、上りリンク・サブフレーム(単数または複数)での物理上りリンク共有チャネル(PUSCH)送信(単数または複数)に対する、物理ハイブリッド自動再送要求(HARQ)インジケータ・チャネル(PHICH:physical hybrid automatic repeat request (HARQ) indicator channel)または物理下りリンク制御チャネル(PDCCH)上の肯定応答および否定応答(ACK/NACK)フィードバックの対応付けを含む。
システム情報変更手順を用いたUL−DL構成の変更は、システムにとって極めて高コストである。そのうえ、近隣セルも構成を変更する必要があるとき、波及効果によってUL−DL構成を変更することがさらに複雑になる。加えて、近隣セルにおける異なるUL−DL構成によって干渉問題が生じることもある。さらに、現在の準静的割当てが瞬間的なトラフィック状況に合致することも、しないこともある。
現行の仕様書において、標準的スペシャル・サブフレームは、短縮された、または最小限(例えば、1つかまたは2つのシンボル)の時間を上りリンク信号に割当てる、下りリンクから上りリンクへの切り替えのために用いられる。チャネル・リソースの大部分は、下りリンク送信に割当てられる。上りリンク・サブフレームのタイミングが下りリンク・サブフレームのタイミングより早いので、このスペシャル・サブフレームは、下りリンクから上りリンクへの移行部にギャップまたはガード期間(GP)を用いることによって、下りリンクと上りリンクとの送信の重なりを回避するように設計されている。
3GPP会合において、下りリンクと上りリンクとの干渉管理およびトラフィック適応に関するLTE TDDのさらなる強化を検討するために、新しい検討項目が承認された。この検討項目の1つの目的は、孤立セルと複数セルとの両方のシナリオに対して、トラフィック状態に依存した上りリンク−下りリンク再構成の利点を評価することである。本明細書に開示されるシステムおよび方法は、上りリンク−下りリンク再構成に対処するものである。
現行のLTE TDDシステムにおいて、上りリンクおよび下りリンク割当ては、7つの規定された構成から選ばれ、システム全体が同期される。現時点で、セルにおける上りリンク−下りリンク割当て再構成は、上りリンク−下りリンク対応付けを調整するためにすべての送信を停止しなければならないので、極めて高コストである。1つのセルにおける変更は、近接セル(およびそれらの近接セルなど)における上りリンク−下りリンク構成の同期を一致させるために近接セル(およびそれらの近接セルなど)における変化の連鎖を生じるか、あるいは伴うことがある。そのうえ、現行の上りリンク−下りリンク割当て再構成は、システム情報変更を必要とし、延いてはこの変更が長い遅延を有し、トラフィック負荷における瞬間的または短期的な変化に適応することができない。
動的な上りリンクおよび下りリンク割当てをサポートし、一方では(例えば、システム情報変更を用いた)上りリンク−下りリンク割当て再構成を短縮するために、本明細書に開示されるシステムおよび方法は、物理レイヤ(例えば、PHYレイヤ)通知を用いて、トラフィック適応により上りリンクおよび下りリンク割当てを変更することを記述する。上りリンクから下りリンク、および下りリンクから上りリンクへの変換の影響が本明細書において検討される。下りリンクから上りリンクへの動的な変換は、物理レイヤの既存の上りリンク−下りリンク対応付けを拡張することによって実現される。
本明細書に開示されるシステムおよび方法は、新しいスペシャル・サブフレームを定義する。この新しいスペシャル・サブフレームは、本明細書では「スペシャル・サブフレーム・タイプ2」と呼ばれる。スペシャル・サブフレーム・タイプ2は、現構成の下りリンク・サブフレームでの物理上りリンク共有チャネル(PUSCH)の送信をサポートする。スペシャル・サブフレーム・タイプ2は、物理下りリンク制御チャネル(PDCCH)を必要に応じて維持する一方で、大部分のチャネル・リソースをPUSCH送信に割当てる。本明細書に開示されるシステムおよび方法は、スペシャル・サブフレーム・タイプ2のための詳細な構造および構成手順を提供する。そのうえ、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変更する(例えば、変換または再構成する)ための手順および通知が提示される。一構成において、本明細書に開示されるシステムおよび方法は、すべての既存の上りリンク−下りリンク対応付けを維持し、レガシーUE(例えば、以前の仕様書に従って機能するUE)に対して透過的である。従って、場合によっては、(システム情報変更による)いかなる上りリンク−下りリンク割当て再構成手順も必要としない。
本明細書に開示されるシステムおよび方法のいくつか独自な様態は、既存の上りリンク下りリンク対応付けを変更することなく、上りリンクおよび下りリンク割当てを動的に変更するために、物理レイヤ通知を用いること、および過渡的かつ一時的なサブフレーム変換のための新しいスペシャル・サブフレーム・タイプ2を規定することを含む。そのうえ、これらは、スペシャル・サブフレーム・タイプ2の構造、構成、および構成を決定するための手順を規定することを含む。加えて、これらは、スペシャル・サブフレーム・タイプ2に対する制御通知対応付けのための手順、およびより大きな上りリンク・トラフィックを受け入れるために下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に動的に変換または再構成するための手順を規定することを含む。
明確さのために、本明細書に開示されるシステムおよび方法に従って用いられるフレーム構造の一例が、3GPP TS 36.211から以下のように示される。このフレーム構造は、時分割複信(TDD)手法に適用可能である。各フレームは
Tf=307200・Ts=10
ミリ秒(ms)の長さを有し、ここで
Tf
は無線フレーム持続時間であり、
Ts
は
秒に等しい時間単位である。フレームは、
153600・Ts=5
msの長さをそれぞれが有する2つの半フレームを含む。各半フレームは、
30720・Ts=1
msの長さをそれぞれが有する5つのサブフレームを含む。いくつかのUL−DLフレーム構成は、以下の表(1)に示される。
表(1)では、無線フレームにおける各サブフレームに関連して、「D」は、サブフレームが下りリンク送信のために予約されていることを示し、「U」は、サブフレームが上りリンク送信のために予約されていることを示し、「S」は、3つのフィールド:下りリンク・パイロット時間スロット(DwPTS:downlink pilot time slot)、ガード期間(GP)および上りリンク・パイロット時間スロット(UpPTS:uplink pilot time slot)を持つスペシャル・サブフレームを示す。DwPTSおよびUpPTSの長さは、DwPTS、GPおよびUpPTSの全長が
30720・Ts=1
msに等しいことを前提として、3GPP TS 36.211の表4.2−1に示される。各サブフレームiは、各サブフレームにおける長さが
Tslot=15360・Ts=0.5
msの2つのスロット
2i
および
2i+1
として定義される。
下りリンクから上りリンクへの切り替えポイント周期が5msおよび10msの両方のUL−DL構成がサポートされる。下りリンクから上りリンクへの切り替えポイント周期が5msの場合、スペシャル・サブフレームは、両方の半フレームに存在する。下りリンクから上りリンクへの切り替えポイント周期が10msの場合、スペシャル・サブフレームは、第1の半フレームだけに存在する。サブフレーム0および5ならびにDwPTSは、下りリンク送信のために予約される。UpPTSおよびスペシャル・サブフレームのすぐ後に続くサブフレームは、上りリンク送信のために予約される。複数のセルがアグリゲートされた場合、UEは、すべてのセルにわたって同じUL−DL構成を仮定し、異なったセルにおけるスペシャル・サブフレームのガード期間が少なくとも
1456・Ts
の重なりを有すると仮定する。
UL−DL構成は、サブフレーム割当ておよびspecialSubframePatternsを含む情報要素(IE:information element)TDD−Configによって定義されるSystemInformationBlockType1(SIB1)の一部であってもよい。SIB1は、論理チャネルとしてのブロードキャスト制御チャネル上で送信される。UL−DL構成を変更するために、システム情報変更手順が実行されることがある。
いくつかのTDD構成および再構成の課題が以下に記述される。TDD構成は、対になった周波数帯域を必要としない。従って、TDD構成の1つの利点は、帯域幅割当てのフレキシビリティにある。TDD構成において、フレームは、10個のサブフレームを有する。下りリンクから上りリンクへの切り替えポイント周期が5msおよび10msの両方のUL−DL構成がサポートされる。3GPP規格では、7つのUL−DL構成が規定されている。上りリンクおよび下りリンク送信の間の干渉を回避するために、システム全体にわたる同期が必要である。それゆえに、すべてのevolved Node B(eNB)およびすべてのUEは、同じUL−DL構成およびタイミングに従う。
現行の仕様書(例えば、LTEリリース8、9および10)では、UL−DL構成を変更するために、システム情報変更手順が用いられる。この処理は、複数のブロードキャスト・チャネル間隔を必要とし、延いては長い遅延を有し、瞬間的なトラフィック負荷の変化に適応することができない。上りリンクおよび下りリンク割当ての再構成は、極めて高コストである。異なる上りリンク−下りリンク対応付けゆえに、旧構成の上りリンク−下りリンク対応付けを切り離して新しい対応付けを設定するためには、すべての送信機が送信をすっかり停止しなければならない。該対応付けの例は、上りリンク電力制御、PUSCH対応付け、ACK/NACKフィードバック、PHICH対応付けなどを含む。これは、システム能力の莫大な損失とユーザ・トラフィックの中断とをもたらす。そのうえ、1つのセルにおける変更は、近接セルにそれらのUL−DL構成の変更を強いることがある。かくして、「波及」効果が発生しかねない。
FDD構成では、上りリンク−下りリンク対応付けが簡単である。例えば、通常のHARQ動作を用いたFDD構成において、UEを対象とするサブフレームnでのPUSCH電力制御およびPUSCH送信は、サブフレームn−4における下りリンク制御情報(DCI:downlink control information)フォーマット0を持つPDCCHによって、あるいはサブフレームn−4におけるPHICHによってスケジューリングされる。サブフレームnでのPUSCH送信のACK/NACKフィードバックは、サブフレームn+4におけるPHICHまたはPDCCH上で指示される。サブフレームkでの物理下りリンク共有チャネル(PDSCH)送信のACK/NACKフィードバックは、サブフレームk+4における物理上りリンク制御チャネル(PUCCH)または物理上りリンク共有チャネル(PUSCH)上でUEによってレポートされる。
あるLTE TDD構成では、サブフレームが、時間領域で上りリンクと下りリンクとに割当てられる。UL−DL構成ゆえに、4つに固定されたサブフレーム対応付けは、保証されない。例えば、UL−DL構成0では、サブフレーム2および3に関して、PDCCHは、それぞれ6および7サブフレーム後の上りリンク・サブフレームでのPUSCH送信をスケジューリングする。従って、上りリンク−下りリンク対応付けが非常に複雑になりかねず、様々なUL−DL構成に対して様々な対応付け構成が適応されることがある。
対応付けの例は、下りリンク・サブフレーム物理下りリンク制御チャネル(PDCCH)の、上りリンク・サブフレームにおける上りリンク電力制御への対応付け、下りリンク・サブフレーム物理下りリンク制御チャネル(PDCCH)の、上りリンク・サブフレームにおける物理上りリンク共有チャネル(PUSCH)割当てへの対応付け、下りリンク・サブフレーム(単数または複数)での物理下りリンク共有チャネル(PDSCH)送信に対する、上りリンク・サブフレーム(単数または複数)上の肯定応答および否定応答(ACK/NACK)フィードバックの対応付け、上りリンク・サブフレーム(単数または複数)での物理上りリンク共有チャネル(PUSCH)送信(単数または複数)に対する、物理ハイブリッド自動再送要求(HARQ)インジケータ・チャネル(PHICH)または物理下りリンク制御チャネル(PDCCH)上の肯定応答および否定応答(ACK/NACK)フィードバックの対応付けなどを含む。例として、対応付けは、下りリンク・サブフレームが上りリンク・サブフレームにいかに対応するか、および/または、上りリンク・サブフレームが下りリンク・サブフレームにいかに対応するかを特定する。対応付けの一例は、下りリンク・サブフレームが、この下りリンク・サブフレームのいくつかのサブフレーム後に続く上りリンク・サブフレームのために通信をスケジューリングするように特定する。対応付けの別の例は、上りリンク・サブフレームのいくつかのサブフレーム後に続く下りリンク・サブフレームが、この上りリンク・サブフレームに対応するACK/NACKフィードバックを含むように特定する。
いくつかの構成において、本明細書に開示されるシステムおよび方法は、現在および/または過去の3GPP仕様書によるTDD上りリンク−下りリンク対応付けを用いる。本明細書におけるシステムおよび方法に従って用いられる上りリンク−下りリンク対応付けのいくつかの例は、3GPP TS 36.213の5.1.1.1、7.3、8、8.2、8.3、9.1.2および10節、ならびに3GPP TS 36.211の6.9節に見出される。
システム情報変更手順を用いた従来の上りリンク−下りリンク割当て再構成では、新しい対応付けが生じる前に、先ず古い対応付けが壊されなければならない。結果として、移行期間中はすべての送信が終了されなければならない。これは、チャネル・リソースの甚大な浪費と、サービスの低下および途絶とをもたらす。高いトラフィック負荷変動とともに、システム情報変更手順を用いた頻繁な上りリンク−下りリンク割当て再構成の使用は、重大なネットワーク問題をもたらすであろう。
一例において、TDD構成に関する上りリンク−下りリンク対応付けは、単一のサブフレームだけが異なるときでさえ、大きく異なる可能性がある。例として、5ミリ秒(ms)間隔において1つだけのサブフレームが上りリンクと下りリンクとの間で変換されたUL−DL構成1と構成2との間の違いは、小さく思われるであろう。しかしながら、これら2つの構成では、いずれの上りリンク−下りリンク対応付けも同じではない。
本明細書に開示されるシステムおよび方法の構成の一例は、以下の通りである。10個のサブフレーム期間によって、TDD UL−DL構成が
NU
個の上りリンク・サブフレームと、スペシャル・サブフレームを含む
(10−NU)
個の下りリンク・サブフレームとを有すると仮定する。ネットワーク・リソースまたは能力が1に正規化され、アグリゲートされた上りリンクおよびアグリゲートされた下りリンク・トラフィック負荷がそれぞれ
λU
および
λDであると仮定する。ここで、
λU
および
λD
は、チャネル使用のパーセンテージとして正規化された(必要な制御通知を含む)上りリンクおよび下りリンク・トラフィック負荷である。
オペレータは、いくつか所望の負荷比「目標」を持つネットワークを、その収益モデルに対するオペレータの選好に基づいて構成する。実際のシステムのトラフィック特性は、2つの様態を含む。第1の様態は、全トラフィック負荷対能力比であり、式
λ=(λU+λD)
で表される。第2の様態は、上りリンク対下りリンク・トラフィック比であり、次式で表される。
上りリンク対下りリンク・トラフィック比は、オペレータの目標または所望の負荷比と一致することもしないこともある。
ネットワーク・アグリゲートされたトラフィック負荷対能力比が低いとき、UL−DL構成は、上りリンク・トラフィックおよび下りリンク・トラフィック負荷が、割当てられた上りリンク・サブフレームおよび下りリンク・サブフレームによって、次式でそれぞれ示されるようにサポート可能な場合、受け入れ可能である。
全トラフィック負荷対能力比が、
λ≧1
の場合、システムは、過負荷であるか、または飽和している。eNBにおけるスケジューラは、優先度と、過負荷になったトラフィック負荷から送信すべきパケットとを決定する責任がある。ネットワーク・アグリゲートされたトラフィック負荷対能力比が高いか、またはシステムが過負荷であるとき、正しい割当ての上りリンク対下りリンク・トラフィック比を持つUL−DL構成が好ましい。
LTE TDD上りリンク−下りリンク構成は、アグリゲートされたネットワーク・トラフィック・フローに対して設計される。各アプリケーションおよび/または各UEのトラフィック特性は、著しく異なることがある。統計的に、ネットワーク・トラフィック負荷(例えば、セルにおけるすべてのUEのアグリゲートされたトラフィック負荷)は、個々のUEのトラフィック特性と比較して、相対的に安定しており、よりゆっくりと変化する筈である。しかしながら、アグリゲートされたトラフィック負荷は、平均値の周りで大きく変動することがある。一日の異なった時間における平均トラフィック負荷が、著しく変化することもある。いくつかのUEがビデオ・ストリーミングおよび大きなファイルのダウンロードのような広帯域のアプリケーションを用いたとき、上りリンクおよび下りリンク比が著しく変わることがある。
再構成は、下記の条件のいずれかを満足しない場合に必要とされる。
再構成は、現行のUL−DL構成が上りリンク対下りリンク・トラフィック比に整合しない場合、特に、ネットワーク・アグリゲートされたトラフィック負荷対能力比が高いか、またはシステムが過負荷のときにも必要とされる。現在は、システム情報手順の変更が用いられている。この処理は、無線リソース管理(RRC:radio resource control)レイヤ手順である。これは、長時間を要し、瞬間的なトラフィック負荷の変化に対して調整できない。瞬間的なトラフィック負荷の変化が一時的なこともある。ネットワーク構成が変更されるまでに、トラフィック負荷がすでに、再び正常状態に変化していることもある。かくして、また別の再構成が必要とされる。さらに悪いことに、TDDシステムは、下りリンクおよび上りリンク送信の間の干渉を回避するために、同じUL−DL構成を有するように設計されているので、1つのセルにおけるUL−DL構成の変更は、近接セルにおけるUL−DL構成の変更のきっかけとなる。それゆえに、(システム情報の変更を用いた)UL−DL構成の変更は、RRCレベルで極めて高コストであり、いくつかの場合、これを回避することが有益である。
物理(PHY)レイヤの上りリンク−下りリンク再構成に関するいくつかの考察が、以下に詳述される。リアルタイムのトラフィック負荷変動を考慮すると、よりフレキシブルな時間領域の上りリンク−下りリンク再構成が、トラフィック変動特性に追随することができる。かくして、システム情報変更手順の他に、PHYレイヤの再構成がサポートされる。PHYレイヤ手順は、大部分の一時的なトラフィック負荷変動を扱う。システム情報変更手順は、トラフィック変化が極めて著しく、PHYレイヤ手順が変化を扱えないときにだけ用いられる。
eNBは、チャネル・リソースおよびUEの振舞いを完全に制御する。様々な制御情報を運ぶために、いくつかの下りリンク制御情報(DCI)フォーマットが規定されている。例えば、DCIフォーマット0は、物理上りリンク共有チャネル(PUSCH)のスケジューリングに用いられる。DCIフォーマット1は、物理下りリンク共有チャネル(PDSCH)符号語のスケジューリングに用いられる。そのうえ、DCIフォーマット3は、物理上りリンク制御チャネル(PUCCH)および物理上りリンク共有チャネル(PUSCH)に対する、2ビットの電力調整を含んだ送信電力制御(TPC:transmit power control)コマンドの送信に用いられる。
下りリンク・サブフレームにおいて、UEは、物理下りリンク制御チャネル(PDCCH)をモニターし、PDCCHを復号しようと試みる筈である。本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレームnに位置するPDCCHにより、PHYレイヤ手順を用いて、既存の上りリンクおよび下りリンク割当てを動的に修正し、新しい上りリンク・サブフレームに動的に切り替えられる(例えば、変換または再構成される)下りリンク・サブフレームn+kに、PUSCH送信を割当てることが可能である。そのうえ、サブフレームn+kに位置するPDCCHを用いて、同じサブフレームn+kにおける物理下りリンク共有チャネル(PDSCH)割当てを短縮または削除することが可能である。現行の仕様書に従って、下りリンク・サブフレームnに位置するPDCCHは、サブフレームn+kでのPUSCH送信に対応付けられていない。それゆえに、サブフレームnにおけるPDCCH検出は、下りリンク・サブフレームn+kを上りリンク・サブフレーム(例えば、スペシャル・サブフレーム・タイプ2)に切り替える(例えば、変換または再構成する)ように、UEに暗黙的に指令するために用いることができる。
下りリンク・サブフレームにおけるPDCCHおよびPHICHが、PUSCHスケジューリングおよびPUSCH送信のACK/NACKフィードバックと対応付けられていることがある。この場合、下りリンク制御シンボルが消されることはない(例えば、下りリンク・サブフレームが、上りリンク・サブフレームに完全に変換または再構成されることはできない)。例えば、下りリンク・サブフレームが上りリンク・サブフレームに完全に変換されるとすれば、このPUSCHスケジューリングに依存する上りリンク・サブフレーム、および所定の下りリンク・サブフレームにおけるPHICHフィードバックを必要とする上りリンク・サブフレームは、空にされる必要があろう。これは、トラフィック負荷に合せるために上りリンク・サブフレームの数を増やすという目的に矛盾する。
他方、下りリンク・サブフレームにいかなる上りリンク対応付けもない場合(例えば、所定の下りリンク・サブフレームではいかなるPUSCH電力制御、PUSCHスケジューリング、およびいかなるPHICHフィードバックも許可されていないとき)、それが上りリンク・サブフレームの直後に続くのであれば、所定の下りリンク・サブフレームは、上りリンク・サブフレームに完全に変換される。しかしながら、所定のサブフレームが別の下りリンク・サブフレームの後に続くのであれば、上りリンク送信のための時間前進を調整するガード期間が必要とされる。
下りリンクから上りリンクへのサブフレーム変換は、PHYレイヤ通知によって制御される。すべてのレガシーUE(例えば、3GPPリリース8、9および/または10に準拠するUE)は、サブフレームを依然として下りリンク・サブフレームとして指定し、PDCCHを探してそれをモニターする。PDCCHが存在しない場合、レガシーUEは、所定のサブフレームでの不連続送信(DTX:discontinuous transmission)を仮定する。動的なサブフレーム変換をサポートする他のUEは、PHYレイヤ通知に従って、所定のサブフレームを上りリンク・サブフレームとして用いることができる。
動的な上りリンクおよび下りリンク(再)構成(例えば、変換)が適用されるとき、(例えば、以前の3GPPリリースによる)すべての既存の上りリンク−下りリンク対応付けを維持することが望ましい。本明細書に開示されるシステムおよび方法は、一時的および/または部分的な下りリンクから上りリンクへの変換のために、現行の仕様書のスペシャル・サブフレームを拡張する。本明細書に開示されるスペシャル・サブフレーム拡張版または新しいスペシャル・サブフレームは、「スペシャル・サブフレーム・タイプ2」または「S2」と呼ばれる。加えて、または代わりに、新しいスペシャル・サブフレームまたはスペシャル・サブフレーム・タイプ2は、ハイブリッド・サブフレーム、フレキシブル・サブフレーム、拡張可能なスペシャル・サブフレームなどと呼ばれてもよい。
LTE−TDDにおける上りリンク・サブフレームでは、スケジューリングされたPUCCHおよび/またはPUSCH送信を有するUEだけがチャネル上で送信を行うことができる。他のUEは、チャネルを感知しない。それゆえに、いくつかの理由で、PHYレイヤにおける上りリンク・サブフレームから下りリンク・サブフレームへの動的な変更は、既存のPHYレイヤ通知では可能でない。
第1に、PDCCHは、同じサブフレームでのPDSCH送信をスケジューリングする。しかしながら、UEは、下りリンク・サブフレームに切り替えられる(例えば、変換される)であろう上りリンク・サブフレームでは、PDSCHをスケジューリングするためにPDCCHをモニターすることはない。
第2に、eNBは、下りリンク・サブフレームに切り替えられる(例えば、変換される)であろう上りリンク・サブフレームでのPUSCH送信の割当ても回避することが可能であろう。しかしながら、この上りリンク・サブフレームでのPUCCHによるACK/NACKフィードバックまたはPUSCH送信を防止するために、eNBは、ACK/NACKフィードバックと対応付けられたサブフレームにおけるPDSCH割当ても回避することがある。例えば、この下りリンク対応付けの一組のサブフレームでは、すべてのUEに対していかなるPDSCH送信も発生することはない。これは、上りリンク・サブフレームを下りリンク・サブフレームに変換するという目的に矛盾する。例として、より多くの下りリンク・サブフレームが必要とされるにも係わらず、ACK/NACK対応付けの問題ゆえに、より多くの下りリンク・サブフレームを空にしなければならない。
スペシャル・サブフレーム・タイプ2の構造に関するさらなる詳細は、以下の通りである。(スペシャル・サブフレーム・タイプ2と混同すべきではない)標準的スペシャル・サブフレームは、下りリンクから上りリンクへの切り替えに用いられる。標準的スペシャル・サブフレームでは、チャネル・リソースの大部分が下りリンク送信に割当てられるのに対して、上りリンクには短時間(例えば、1つかまたは2つのシンボル)が割当てられる。スペシャル・サブフレーム・タイプ2(S2)は、すべての必要な下りリンク通知(例えば、PUSCHスケジューリングおよびPHICHフィードバックに関する制御情報)を維持する一方で、より多くのリソースを上りリンク送信に提供することを目指す。PDCCH送信だけを維持し、リソースの残りをPUSCH送信に割当てることによって、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換される。
PDCCH DCIフォーマット0を用いたPUSCHスケジューリングでは、PUSCH割当ては、スタートRBのインデックスとRBの数とによって表される連続的なリソースブロック(RB)からなるブロックである。スペシャル・サブフレーム・タイプ2のためのPUSCH割当てにおいて、各サブキャリアに使用可能なリソース要素(RE:resource element)は、上りリンク・パイロット時間スロット(UpPTS)領域におけるシンボルの数と同じにするとよい。例えば、割当てられるREの数は、割当てられるRBの数×各RBにおける12サブキャリア×各サブキャリアにおける使用可能なシンボルの数である。スペシャル・サブフレーム・タイプ2の構造に関するさらなる詳細は、以下の通りである。
標準的スペシャル・サブフレームと同様に、スペシャル・サブフレーム・タイプ2は、3つのフィールドを有する。標準的スペシャル・サブフレームでは、3つのフィールドは、下りリンク・パイロット時間スロット(DwPTS)、ガード期間(GP)および上りリンク・パイロット時間スロット(UpPTS)である。便宜上、スペシャル・サブフレーム・タイプ2における3つのフィールドも、DwPTS、GPおよびUpPTSと呼ばれる。スペシャル・サブフレーム・タイプ2における3つのフィールドは、標準的スペシャル・サブフレームにおけるのと同じ名前を用いて呼ばれるが、留意すべきは、スペシャル・サブフレーム・タイプ2における3つのフィールドの特性が、標準的スペシャル・サブフレームにおける同名のフィールドの特性と異なっても、同様でも、および/または同じでもよいことである。例として、スペシャル・サブフレーム・タイプ2では、標準的スペシャル・サブフレームにおけるのと比べて、より多くのデータがUpPTSで運ばれる。
スペシャル・サブフレーム・タイプ2(S2)は、必要な下りリンク通知を維持する一方で、増加したリソースを上りリンク送信に提供することを目指す。例えば、スペシャル・サブフレーム・タイプ2は、必要に応じてPDCCH領域を維持するが、いかなるPDSCH割当ても有さない。スペシャル・サブフレーム・タイプ2におけるリソースの大部分は、PUSCH送信に割当てられる。すべての上りリンク制御フィードバックは、既存の上りリンク・サブフレームと対応付けられるので、スペシャル・サブフレーム・タイプ2では、いかなるPUCCH割当ておよびPUCCH送信も許可されることはない。
スペシャル・サブフレーム・タイプ2では、DwPTSは、必要な下りリンク制御通知(例えば、PDCCHおよびPHICH)だけを提供するように制限される。PDCCHは、上りリンク・サブフレームでのPUSCH送信をスケジューリングするために用いられる。しかしながら、スペシャル・サブフレーム・タイプ2におけるPDCCHは、PDSCH送信をスケジューリングすることがないので、スペシャル・サブフレーム・タイプ2におけるDwPTSのサイズは、通常の下りリンク・サブフレームにおけるDwPTSより小さくてもよい。例えば、スペシャル・サブフレーム・タイプ2におけるリソースブロックの数が10より多いとき、PDCCHに用いられる直交周波数分割多重(OFDM)シンボルの数は、1つかまたは2つに制限されるべきである。そのうえ、PDCCHに用いられるOFDMシンボルの数は、スペシャル・サブフレーム・タイプ2におけるリソースブロックの数が10以下であるとき、2つにすべきである。
ガード期間(GP)は、UEが、上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス(CP:cyclic prefix)構成を有する場合、スペシャル・サブフレーム・タイプ2におけるGPは、1つのOFDMシンボルの長さを有する。上りリンクおよび下りリンクが異なったサイクリックプレフィックス(CP)構成を有する場合、GPは、1つより少ないか、または1つより多いOFDMシンボルとする。しかしながら、切り替えタイミングを確保するために、もし存在するならば、スペシャル・サブフレーム・タイプ2におけるGPは、少なくとも
1456・Ts
の長さを有するとよい。
現行のUL−DL構成において、下りリンク・サブフレームが、PUSCHスケジューリング、電力制御および、任意の上りリンク送信へのPHICHフィードバックとの対応付けを有さない場合、下りリンク・サブフレームは、いかなる予約されたPDCCH領域も持たない(例えば、DwPTS長が0の)スペシャル・サブフレーム・タイプ2に変換される。下りリンク・サブフレームが、上りリンク・サブフレームのすぐに後に(あるいは、おそらくいくつかの構成において、スペシャル・サブフレーム・タイプ2の後に)ある場合、下りリンク・サブフレームは、いかなるGPも持たない上りリンク・サブフレームに完全に変換される。変換されるべき下りリンク・サブフレームが、下りリンク・サブフレームの後にある場合、例えば、第1のOFDM符号長がGPとして予約され、一方では、すべての他のOFDMシンボルが上りリンク送信に割当てられる。
スペシャル・サブフレーム・タイプ2の一構成において、DwPTSフィールドの長さおよびUpPTSフィールドの長さは、DwPTS、GPおよびUpPTSの全長が
30720・Ts=1
msに等しいことを前提として、表(2)に示される。スペシャル・サブフレーム・タイプ2の構造に関するさらなる詳細は、以下の通りである。
以下の表(3)は、同じ構成をOFDMシンボルの数の観点から提供するものである。PDCCHに1つのOFDMシンボルが用いられる場合、上りリンク送信のために通常のサイクリックプレフィックス(CP)が構成されるのであれば、UpPTSは、12個のOFDMシンボルを有し、上りリンク送信のために拡張されたCPが構成されるのであれば、10個のOFDMシンボルを有する。PDCCHに2つのOFDMシンボルが用いられる場合、上りリンク送信のために通常のCPが構成されるのであれば、UpPTSは、11個のOFDMシンボルを有し、上りリンク送信のために拡張されたCPが構成されるのであれば、9個のOFDMシンボルを有する。いかなる予約されたPDCCH領域も持たない(例えば、DwPTS長が0の)スペシャル・サブフレーム・タイプ2に関して、変換されるべき下りリンク・サブフレームが上りリンク・サブフレームの直後にある場合、すべてのシンボルが上りリンク割当てに用いられる。しかしながら、変換されるべき下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、第1のOFDMシンボル長がGPとして予約され、一方では、すべての他のOFDMシンボルが上りリンク送信に割当てられる。
スペシャル・サブフレーム・タイプ2の変換ルールおよびPHYレイヤ通知に関する詳細は、以下の通りである。PUSCH送信は、UEを対象とするサブフレームnにおける上りリンクDCIフォーマットを持つPDCCHによって、および/またはサブフレームnでのPHICH送信によってスケジューリングされる。対応するPUSCH送信は、PDCCHおよびPHICH情報に従って、サブフレームn+kで調整され、ここでFDDに関して、k=4であり、TDDに関して、kは、(3GPP TS 36.213における表8−2から)以下の表(4)に示される。なお、「UL」は上りリンクを示し、「DL」は下りリンクを示す。
現行の3GPP仕様書に従うと、TDDでは、いかなるPUSCH送信も下りリンク・サブフレームにおいてスケジューリングされるべきではない。上りリンク・サブフレームにおけるPUSCH割当ては、下りリンク・サブフレームへの1対1の対応付けマッピングを有する。例えば、TDD UL/DL構成1〜6および通常のHARQ動作に関して、UEは、UEを対象とするサブフレームnにおける、上りリンクDCIフォーマット0を持つPDCCHの検出、および/またはPHICH送信の際に、サブフレームn+kでの対応するPUSCH送信を、PDCCHおよびPHICH情報に従って調整する。kは、表(4)に示されている。現行の仕様書に従うと、PUSCH割当てのためのDCIフォーマット0を運ぶことができない、あるいはPHICHフィードバックを有することができない、いくつかの下りリンク・サブフレームがある。
本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換される。これは、例えば、1つ以上のDCIフォーマット0 PUSCH送信が、(現行の3GPPリリース8、9および10の仕様書では、PUSCH割当てのためのDCIフォーマット0を有することが許可されていない)下りリンク・サブフレームに割当てられたとき、あるいは以前に割当てられたスペシャル・サブフレーム・タイプ2に対するPHICHフィードバックが必要とされるときに発生する。
スペシャル・サブフレーム・タイプ2に関する対応付けは、以下のように規定される。サブフレームn−4におけるDCIフォーマット0を持つPDCCHは、下りリンク・サブフレームnをスペシャル・サブフレーム・タイプ2に変換する。サブフレーム番号nを持つスペシャル・サブフレーム・タイプ2に対するACK/NACKフィードバックは、サブフレームn+6でレポートされる。一構成において、変換されたサブフレームnでのPUSCH送信に対するACK/NACKは、サブフレームn+6におけるPHICH上で運ばれる。加えて、サブフレームn+6におけるPDCCHがPHICHをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームn+10での新しいデータ送信または再送信をスケジューリングすることもできる。
別の構成では、変換されたサブフレームnでのPUSCH送信に対するいかなるPHICHフィードバックもなく、UEは、PHICH値をACKと見做す。そのうえ、サブフレームn+6におけるPDCCHがACKをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームn+10での新しいデータ送信または再送信をスケジューリングすることもできる。サブフレームn+10での再送信のスケジューリングは、サブフレームnでのPUSCH送信に対するNACKを示す。UEがPDCCHを何も検出しない場合、UEは、サブフレームn+10でPUSCHを送信することはない。TDDは、5msおよび10msの両方の構成に共通の10個の間隔を有し、n+6=(n−4)+10なので、PHICHおよびDCIフォーマット0を持つPDCCH割当ては、常に同じ下りリンク・サブフレーム・インデックス番号を有する。
言い換えれば、サブフレーム番号nを持つスペシャル・サブフレーム・タイプ2のPUSCHは、スペシャル・サブフレーム・タイプ2の4サブフレーム前にある下りリンク・サブフレーム(例えば、サブフレーム番号n−4を持つ下りリンク・サブフレーム)のPDCCHまたはPHICHフィードバックでスケジューリングされる。サブフレーム番号kを持つスペシャル・サブフレーム・タイプ2でのPUSCH送信のACK/NACKフィードバックは、サブフレーム番号n+6を持つ下りリンク・サブフレームにおけるPHICH上で、または明示的なPDCCHスケジューリングによってレポートされる。スペシャル・サブフレーム・タイプ2の対応付けに関するさらなる詳細は、以下の通りである。
一例において、(上掲の表(1)に示されるような)現行の上りリンクおよび下りリンク(UL−DL)構成5では、1つだけの上りリンク・サブフレームがサブフレーム番号i=2に存在する。そのうえ、PUSCH割当ては、前のフレームのサブフレーム番号i=8におけるPDCCH DCIフォーマット0またはPHICHフィードバックによって通知される。現行の3GPP仕様書に従って、この構成では、すべての他の下りリンク・サブフレームは、PDCCH DCIフォーマット0またはPHICHフィードバックを運ぶことがない。
しかしながら、本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレーム番号i=3でのPUSCH送信をスケジューリングするために、PDCCH DCIフォーマット0がサブフレーム番号i=9に割当てられた場合、次のフレームのサブフレーム番号i=3を持つ対象下りリンク・サブフレームが、スペシャル・サブフレーム・タイプ2に変換される。PUSCH送信は、割当てられたPUSCHリソース上で運ばれる。PUSCH送信のACK/NACKは、次に、サブフレーム番号i=9上でレポートされる。
下りリンク・サブフレームからスペシャル・サブフレーム・タイプ2への変換は、一時的かつ動的であってもよい。いくつかの構成において、下りリンク・サブフレームは、上記の条件下においてのみ、スペシャル・サブフレーム・タイプ2に変換される。その他の場合は、下りリンク・サブフレームは、通常の下りリンク・サブフレームとして機能する。かくして、変換および遷移は、自律的に生じ、いかなる追加の通知も必要ではない。
スペシャル・サブフレームを予期しないレガシーUEは、これを通常の下りリンク・サブフレームとして扱う。スペシャル・サブフレーム・タイプ2にPDCCHが存在するとき、レガシーUEにとって何も変化はない。スペシャル・サブフレーム・タイプ2にPDCCHが存在しないとき、レガシーUEは、PDCCHを首尾よく検出できないので、このサブフレームに関してDTXをレポートする。リリース11以降のUEは、本明細書に開示されるシステムおよび方法に従って、必要とされる上りリンク−下りリンク対応付け、およびスペシャル・サブフレーム・タイプ2でのデータ送信を行う。
スペシャル・サブフレーム・タイプ2構造およびPUSCHリソース割当ての決定に関するさらなる詳細は、以下の通りである。スペシャル・サブフレーム・タイプ2では、PUSCH割当てに利用可能なリソース要素(RE)が、UpPTS領域またはフィールドにおけるOFDMシンボルの数によって決定される。従って、スペシャル・サブフレーム・タイプ2上でのPUSCHスケジューリングの前に、スペシャル・サブフレーム・タイプ2の構成が、eNBおよび1つ以上のUEに知られているとよい。UEは、所定のPUSCHリソース上でデータ符号化および多重化を行うために、この構成を必要とする。そのうえ、eNBは、PUSCHデータを受信して復号するために、同じ情報を必要とする。
下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換される場合、構成の決定に関する手順の一例は、以下の通りである。スペシャル・サブフレーム・タイプ2に変換されるべき下りリンク・サブフレーム(例えば、「対象下りリンク・サブフレーム」)は、上記のようなPHYレイヤ通知およびルールによって決定される。対象下りリンク・サブフレームに関して、この手順は、下りリンク・サブフレーム変換のためのスペシャル・サブフレーム・タイプ2構造をいかに決定するかを説明する。
現行のUL−DL構成において、対象下りリンク・サブフレームが、PUSCHスケジューリング、電力制御、および任意の上りリンク送信へのPHICHフィードバックとの対応付けを有さない場合、対象下りリンク・サブフレームは、いかなる予約されたPDCCH領域も持たない(例えば、DwPTS長が0の)スペシャル・サブフレーム・タイプ2に変換される。対象下りリンク・サブフレームが上りリンク・サブフレーム(あるいは、おそらくいくつかの構成において、スペシャル・サブフレーム・タイプ2)の直後にある場合、対象下りリンク・サブフレームは、いかなるガード期間(GP)も持たない上りリンク・サブフレームに完全に変換される。しかしながら、対象下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、第1のOFDMシンボル長がGPとして予約され、一方では、すべての他のOFDMシンボルが上りリンク送信に割当てられる。
標準的なUL−DL構成において、対象下りリンク・サブフレームが、PUSCHスケジューリング、電力制御、および任意の上りリンク送信へのPHICHフィードバックとの対応付けを有する場合、対象下りリンク・サブフレームは、予約されたPDCCH領域またはフィールドを持つスペシャル・サブフレーム・タイプ2に変換される。この場合、PDCCH領域の長さがさらに決定される。
LTEネットワークにおいて、物理制御フォーマット・インジケータ・チャネル(PCFICH)は、サブフレームでのPDCCHの送信に用いられるOFDMシンボルの数についての情報を運ぶ。PCFICHは、PDCCHのためのOFDMシンボルの数がゼロより大きいときに送信される。
予約されたPDCCH領域またはフィールドを持つスペシャル・サブフレーム・タイプ2のPDCCH長を決定するために、いくつか代わりの手法が用いられてもよい。第1の代替手段では、スペシャル・サブフレーム・タイプ2は、PDCCH領域またはフィールドの長さが固定された構成を用いる。一構成において、リソースブロック(RB)の数が10より多い場合、PDCCHのために1つのOFDMシンボルが予約され、RBの数が10以下である場合、2つのOFDMシンボルが予約される。別の構成では、PDCCHのために常に2つのOFDMシンボルが予約されてもよい。固定された構成は、eNBに明示的な通知を用いて(例えば、システム情報におけるようなRRC通知で)伝達される。
PDCCH長が固定された構成を持つ一構成では、PCFICHは、スペシャル・サブフレーム・タイプ2に必要とされることはない。別の構成では、PCFICHは、スペシャル・サブフレーム・タイプ2に含まれ、PDCCHのために予約されたOFDMシンボルの数に対する所定の構成に従う。PCFICHで通知され、PDCCHに用いられるOFDMシンボルの数は、スペシャル・サブフレーム・タイプ2においてPDCCHのために予約されたOFDMシンボルの数以下とされる。例えば、スペシャル・サブフレーム・タイプ2においてPDCCHのために予約されたOFDMシンボルの数が2つであれば、PCFICHは、PDCCH上のペイロードに依存して、PDCCHに用いられるシンボルの数を1つかまたは2つに構成するとよい。スペシャル・サブフレーム・タイプ2の構成が一旦設定されると、eNBおよび1つ以上のUEは、この構成に従って、然るべくPUSCHスケジューリングおよびPUSCH送信を行う。
第2の代替手段では、PDCCH長は、PCFICHによって決定される。しかしながら、スペシャル・サブフレーム・タイプ2では、PCFICH情報(例えば、PDCCH領域の長さ)が初めにUEに知られていないので、UEは、最小PDCCHサイズを持つデフォルト設定を用いてデータを処理しなければならない。それゆえに、UEは、スペシャル・サブフレーム・タイプ2における最小PDCCHサイズ(例えば、RBの数が10より多い場合、PDCCHに1つのOFDMシンボル、RBの数が10以下である場合、2つのOFDMシンボル)を仮定して、データ符号化および多重化を行う。
スペシャル・サブフレーム・タイプ2におけるPCFICHの検出の際に、スペシャル・サブフレーム・タイプ2にPUSCHスケジューリングを持つUEは、PCFICHからPDCCHのためのOFDMシンボルの数を取得する。PCFICHがデフォルト最小PDCCHサイズにおけるのと同じOFDMシンボルの数を指示する場合、符号化および多重化されたデータは、変更なしに送信される。しかしながら、PCFICHによって与えられるPDCCH領域がデフォルト値より大きい場合、上りリンク送信は、PCFICHからのOFDMシンボルの数によって決定されるスペシャル・サブフレーム・タイプ2構造を用いる。例えば、選択されたスペシャル・サブフレーム・タイプ2構造によって取って代わられたOFDMシンボル中の符号化および多重化されたデータは、パンクチャして除かれる。かくして、所定のOFDMシンボルではいかなるPUSCH送信も発生することはない。
一例において、通常のCPを上りリンクおよび下りリンクの両方に仮定する。スペシャル・サブフレーム・タイプ2にPUSCH割当てを持つUEは、PDCCHのための1つのOFDMシンボルと、それに続く1OFDMシンボル長のGPとのデフォルト設定を仮定する。従って、データ符号化および多重化は、サブフレームにおけるサブキャリア当り12個のシンボルを用いて行われる。UEは、次に、スペシャル・サブフレーム・タイプ2におけるPCFICHを検出する。PCFICHがPDCCHのための1つのOFDMシンボルを指示する場合、PUSCHは、すべての符号化および多重化されたデータを用いて送信される。しかしながら、PCFICHがPDCCHのための2つのOFDMシンボルを指示する場合、スペシャル・サブフレーム・タイプ2構造は、DwPTSのための2つのOFDMシンボル、GPのための1つのOFDMシンボル、およびPUSCH送信のための10個のOFDMシンボルを有するべきである。UEは、そのときには第4のOFDMシンボル上のすべての符号化および多重化されたデータをパンクチャして除き、スペシャル・サブフレーム・タイプ2のサブキャリアにおける10個のOFDMシンボルでのPUSCH送信をもたらす。
PHYレイヤを動的に下りリンクから上りリンクに変換するためのスペシャル・サブフレーム・タイプ2の使用に関するさらなる詳細は、以下の通りである。上記のように、PHYレイヤでの上りリンク・サブフレームから下りリンク・サブフレームへの動的な変更は、既存のPHYレイヤ通知では可能でない。従って、この場合、システム情報変更手順を用いることもできる。しかしながら、下りリンク・サブフレームから上りリンク・サブフレームへの変換は、上記のようにスペシャル・サブフレーム・タイプ2を用いて、PHYレイヤ手順によって動的に行われるとよい。
スペシャル・サブフレーム・タイプ2を用いた下りリンクから上りリンクへの変換のいくつかの利益は、以下の通りである。本明細書に開示されるシステムおよび方法に従って、下りリンクから上りリンクへの変換は、現行のPHYレイヤの上りリンク−下りリンク対応付けを拡張する。例えば、サブフレーム番号nを持つスペシャル・サブフレーム・タイプ2のPUSCH割当ては、サブフレーム番号n−4を持つ下りリンク・サブフレームにおけるPDCCHまたはPHICHフィードバックによってスケジューリングされる。そのうえ、サブフレーム番号nを持つスペシャル・サブフレームでのPUSCH送信のPHICHフィードバックは、サブフレーム番号n+6を持つ下りリンク・サブフレーム中とされる。
そのうえ、本明細書に開示されるシステムおよび方法は、いずれの既存の上りリンク−上りリンク対応付けも壊さない(例えば、スペシャル・サブフレーム・タイプ2において、PUCCHは、何も必要ないか、あるいは許可されない)。また、サブフレーム変換は、動的、自律的かつフレキシブルである。加えて、対応付けルールを満たすことができる場合、任意の下りリンク・サブフレームがスペシャル・サブフレームに変換される。このように、1つ以上の下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2のサブフレームに変換される。
提案される下りリンクから上りリンクへの変換は、システムにとって低コストである。現行の上りリンク割当てが上りリンク・トラフィックを扱えない場合、必要に応じて、または所望通りに、下りリンク・サブフレームは、PHYレイヤ手順を用いてスペシャル・サブフレーム・タイプ2のサブフレームに動的に変換される。かくして、提案される手法は、システム情報変更手順を用いてUL−DL構成を変更することなく、増加した上りリンク送信の大部分のトラフィック変動を扱うことができる。
一例において、ネットワークUL−DL構成は、初期化され、より多くの下りリンク・サブフレームによって構成される(例えば、UL−DL構成は、ピーク下りリンク・トラフィック負荷に基づくか、あるいは下りリンク送信側にバイアスを持つ上りリンク対下りリンク・トラフィック比に基づいてもよい)。通常の状況下では、ネットワークにおける下りリンク・トラフィックは、上りリンクより高いであろう。1つ以上のUEがデータ量の多いアプリケーションを開始した場合、あるいはピコセルへのトラフィック負荷分散のシナリオにおいては、トラフィック負荷が不均衡になることがある。
下りリンクから上りリンクへの動的な変換のためにPHYレイヤ通知を行うとき、いくつかのガイドラインが適用される。第一に、サブフレーム0およびサブフレーム5は、現行のUL−DL構成におけるように、専ら下りリンク・サブフレームとされ、スペシャル・サブフレーム・タイプ2に変換されることはない。そのうえ、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されるとき、上りリンク・サブフレームもしくは別のスペシャル・サブフレーム・タイプ2の直後にあるサブフレームは、(変換のための)第1の、および/または優先されるサブフレームと見做される。
次に、図面を参照して様々な構成が記述される。なお、図面において、同様の参照番号は、機能的に同様の要素を示す。本明細書において図面に一般的に記述され、説明されるようなシステムおよび方法は、多種多様に異なった構成に配置され、設計されてもよい。従って、図面に表現されるようないくつかの構成の以下のさらに詳細な記述は、請求される範囲を限定する意図はなく、システムおよび方法を単に代表するに過ぎない。
図1は、下りリンク・サブフレームを変換するためのシステムおよび方法が実装されるevolved Node B(eNB)160および1つ以上の端末装置(UE)102の一構成を示すブロック図である。1つ以上のUE102は、1本以上のアンテナ122a〜nを用いてevolved Node B(eNB)160と通信する。例えば、UE102は、1つ以上のアンテナ122a〜nを用いてeNB160へ電磁信号を送信し、eNB160から電磁信号を受信する。eNB160は、1つ以上のアンテナ180a〜nを用いてUE102と通信する。留意すべきは、いくつかの構成において、eNB160がNode B、home evolved Node B(HeNB)または他の種類の基地局であってもよいことである。
UE102およびeNB160は、相互に通信するために1つ以上のチャネル119、121を用いる。例えば、UE102は、1つ以上の上りリンク・チャネル121を用いてeNB160へ情報またはデータを送信する。上りリンク・チャネル121の例は、物理上りリンク制御チャネル(PUCCH)および物理上りリンク共有チャネル(PUSCH)などを含む。eNB160も、例として、1つ以上の下りリンク・チャネル119を用いて1つ以上のUE102へ情報またはデータを送信する。下りリンク・チャネル119の例は、物理下りリンク制御チャネル(PDCCH)、物理下りリンク共有チャネル(PDSCH)などを含む。他の種類のチャネルを用いてもよい。
1つ以上のUE102のそれぞれは、1つ以上のトランシーバ118、1つ以上の復調器114、1つ以上のデコーダ108、1つ以上のエンコーダ150、1つ以上の変調器154およびUE操作部124を含む。例えば、UE102では1つ以上の受信および/または送信経路が用いられる。便宜上、単一のトランシーバ118、デコーダ108、復調器114、エンコーダ150および変調器154だけが示されるが、構成に依存して、複数の並列要素(例えば、トランシーバ118、デコーダ108、復調器114、エンコーダ150および変調器154)が用いられる。
トランシーバ118は、1つ以上の受信機120および1つ以上の送信機158を含む。1つ以上の受信機120は、1つ以上のアンテナ122a〜nを用いてeNB160から信号を受信する。例えば、受信機120は、1つ以上の受信信号116を生成するために、信号を受信してダウンコンバートする。1つ以上の受信信号116は、復調器114に供給される。1つ以上の送信機158は、1つ以上のアンテナ122a〜nを用いてeNB160へ信号を送信する。例えば、1つ以上の送信機158は、1つ以上の変調信号156をアップコンバートして送信する。
復調器114は、1つ以上の復調信号112を生成するために、1つ以上の受信信号116を復調する。1つ以上の復調信号112は、デコーダ108に供給される。UE102は、信号を復号するためにデコーダ108を用いる。デコーダ108は、1つ以上の復号信号106、110を生成する。例えば、第1のUE復号信号106は、受信されたペイロード・データ104を備える。第2のUE復号信号110は、オーバーヘッド・データおよび/または制御データを備える。例えば、第2のUE復号信号110は、1つ以上の操作を行うためにUE操作部124によって用いられるデータを供給する。
本明細書では、用語「部」は、特定の要素またはコンポーネントが、ハードウェア、ソフトウェアあるいはハードウェアとソフトウェアとの組み合わせで実装されることを意味する。しかしながら、留意すべきは、本明細書に「部」として示される任意の要素が、代わりにハードウェアで実装されてもよいことである。例えば、UE操作部124は、ハードウェア、ソフトウェアまたは両方の組み合わせで実装されてもよい。
一般に、UE操作部124は、UE102がeNB160と通信することを可能にする。UE操作部124は、UE下りリンク・サブフレーム変換部132を含む。UE下りリンク・サブフレーム変換部132は、スペシャル・サブフレーム・タイプ2構造134を含む。
UE下りリンク・サブフレーム変換部132は、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換する。留意すべきは、1つ以上の下りリンク・サブフレームが変換されることである。例えば、表(1)に下りリンク・サブフレームとして示される1つ以上のサブフレームが、スペシャル・サブフレーム・タイプ2のサブフレームに変換される。例として、図1に示されるように、1つ以上のUE102およびeNB160が、無線フレームにおけるいくつかのサブフレームが下りリンク・サブフレームとして指定された特定の構成に従って動作している。しかしながら、本明細書に開示されるシステムおよび方法を用いて、UE102は、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換することができる。
上記のように、スペシャル・サブフレーム・タイプ2は、eNB160が、より多くの通信リソースを上りリンク送信に動的かつ一時的に割当てることを可能にする。これは、(例えば、必要または有益なときに)1つ以上のUE102が、より多くの上りリンク・データをeNB160へ送信することを可能にする。
UE下りリンク・サブフレーム変換部132は、下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換するために、スペシャル・サブフレーム・タイプ2構造134を用いる。例えば、スペシャル・サブフレーム・タイプ2構造134は、いくつかの状況において、スペシャル・サブフレーム・タイプ2の構造を規定する。例として、スペシャル・サブフレーム・タイプ2の構造は、対応付けが対象下りリンク・サブフレーム(例えば、変換されるべき下りリンク・サブフレーム)に対応するかどうかに依存して、
対象下りリンク・サブフレームのすぐ前が上りリンク・サブフレームであるか下りリンク・サブフレームであるかに依存して、および/または、スペシャル・サブフレーム・タイプ2に含まれてよい(あるいは含まれない)PDCCHの長さに依存して、変化する。
UE操作部124は、1つ以上の受信機120に情報184を提供する。例えば、UE操作部124は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づいて、送信をいつ受信すべきか、あるいはいつすべきでないかを受信機(単数または複数)120に通知する。
UE操作部124は、復調器114に情報138を提供する。例えば、UE操作部124は、eNB160からの送信に予想される変調パターンを復調器114に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。
UE操作部124は、デコーダ108に情報136を提供する。例えば、UE操作部124は、eNB160からの送信に予想される符号化法をデコーダ108に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。
UE操作部124は、エンコーダ150に情報142を提供する。情報142は、符号化されるべきデータおよび/または符号化に関する命令を含む。例えば、UE操作部124は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づいて、送信データ146および/または制御情報142を符号化するようにエンコーダ150に命令する。例として、UE操作部124は、いくつかの構成において、符号化および多重化のために最小PDCCH長を仮定するようにエンコーダ150に通知する。
エンコーダ150は、送信データ146および/またはUE操作部124によって供給された他の情報142を符号化する。例えば、データ146および/または他の情報142の符号化は、誤り検出および/または訂正符号化、送信のための空間、時間および/または周波数リソースへのデータのマッピング、多重化などを伴う。エンコーダ150は、変調器154に符号化データ152を供給する。
UE操作部124は、変調器154に情報144を供給する。例えば、UE操作部124は、eNB160への送信に用いられるべき変調型(例えば、コンステレーション・マッピング)を変調器154に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。変調器154は、1つ以上の送信機158に1つ以上の変調信号156を供給するために、符号化データ152を変調する。
UE操作部124は、1つ以上の送信機158に情報140を提供する。この情報140は、1つ以上の送信機158に対する命令を含む。例えば、UE操作部124は、eNB160へ信号をいつ送信すべきかを1つ以上の送信機158に命令する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。例として、1つ以上の送信機158は、スペシャル・サブフレーム・タイプ2に変換された下りリンク・サブフレームの間に送信する。1つ以上の送信機158は、1つ以上のeNB160へ変調信号(単数または複数)156をアップコンバートして送信する。
eNB160は、1つ以上のトランシーバ176、1つ以上の復調器172、1つ以上のデコーダ166、1つ以上のエンコーダ109、1つ以上の変調器113およびeNB操作部182を含む。例えば、eNB160では1つ以上の受信および/または送信経路を用いる。便宜上、単一のトランシーバ176、デコーダ166、復調器172、エンコーダ109および変調器113だけが示されるが、構成に依存して、複数の並列要素(例えば、トランシーバ176、デコーダ166、復調器172、エンコーダ109および変調器113)が用いられる。
トランシーバ176は、1つ以上の受信機178および1つ以上の送信機117を含む。1つ以上の受信機178は、1つ以上のアンテナ180a〜nを用いてUE102から信号を受信する。例えば、受信機178は、1つ以上の受信信号174を生成するために、信号を受信してダウンコンバートする。1つ以上の受信信号174は、復調器172に供給される。1つ以上の送信機117は、1つ以上のアンテナ180a〜nを用いてUE102へ信号を送信する。例えば、1つ以上の送信機117は、1つ以上の変調信号115をアップコンバートして送信する。
復調器172は、1つ以上の復調信号170を生成するために、1つ以上の受信信号174を復調する。1つ以上の復調信号170は、デコーダ166に供給される。eNB160は、信号を復号するためにデコーダ166を用いる。デコーダ166は、1つ以上の復号信号164、168を生成する。例えば、第1のeNB復号信号164は、受信されたペイロード・データ162を備える。第2のeNB復号信号168は、オーバーヘッド・データおよび/または制御データを備える。例えば、第2のeNB復号信号168は、1つ以上の操作を行うために、eNB操作部182によって用いられるデータを提供する。
eNB操作部182は、ネットワーク・トラフィック・モニター部126およびeNB下りリンク・サブフレーム変換部128を含む。ネットワーク・トラフィック・モニター部126は、eNB160と1つ以上のUE102との間に発生する上りリンクおよび下りリンク・トラフィック(例えば、通信)の量をモニターする。例えば、ネットワーク・トラフィック・モニター部126は、現行の上りリンクおよび/または下りリンク割当てが現トラフィック負荷に対して十分であるかどうかを判定する。
eNB下りリンク・サブフレーム変換部128は、1つ以上の下りリンク・サブフレームが1つ以上のスペシャル・サブフレーム・タイプ2のサブフレームに変換されるかどうかを制御する。例えば、eNB下りリンク・サブフレーム変換部128は、現行の上りリンク・トラフィック割当てが現上りリンク・トラフィック負荷を扱うには不十分であることをネットワーク・トラフィック・モニター部126が示した場合、下りリンク・サブフレームを上りリンク・サブフレームに変換するように1つ以上のUE102に通知するために用いられる、物理(PHY)レイヤ通知を発生させる。
eNB下りリンク・サブフレーム変換部128は、スペシャル・サブフレーム・タイプ2構造130を含む。スペシャル・サブフレーム・タイプ2構造130は、いくつかの状況において、スペシャル・サブフレーム・タイプ2の構造を規定する。例として、スペシャル・サブフレーム・タイプ2の構造は、対応付けが対象下りリンク・サブフレーム(例えば、変換されるべき下りリンク・サブフレーム)に対応するかどうかに依存して、上りリンクまたは下りリンク・サブフレームが対象下りリンク・サブフレームの前に来るかどうかに依存して、および/または、スペシャル・サブフレーム・タイプ2に含まれるとよい(あるいは含まれなくてよい)PDCCHの長さに依存して、変化する。
eNB操作部182は、1つ以上の受信機178に情報190を提供する。例えば、eNB操作部182は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づいて、送信をいつ受信すべきか、あるいはいつすべきでないかを受信機(単数または複数)178に通知する。
eNB操作部182は、復調器172に情報188を提供する。例えば、eNB操作部182は、UE(単数または複数)102からの送信に予想される変調パターンを復調器172に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。
eNB操作部182は、デコーダ166に情報186を提供する。例えば、eNB操作部182は、UE(単数または複数)102からの送信に予想される符号化法をデコーダ166に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。
eNB操作部182は、エンコーダ109に情報101を提供する。情報101は、符号化されるべきデータおよび/または符号化のための命令を含む。例えば、eNB操作部182は、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づいて、送信データ105および/または制御情報101を符号化するようにエンコーダ109に命令する。加えて、または代わりに、情報101は、スケジューリング情報、HARQデータ、チャネル割当ておよび/または他の制御情報を指示するPHYレイヤ通知(例えば、PDCCH、PHICHなど)のような符号化されるべきデータを含む。
エンコーダ109は、送信データ105、および/またはeNB操作部182によって提供される他の情報101を符号化する。例えば、データ105および/または他の情報101の符号化は、誤り検出および/または訂正符号化、送信のための空間、時間および/または周波数リソースへのデータのマッピング、多重化などを伴う。エンコーダ109は、変調器113に符号化データ111を供給する。送信データ105は、UE102へ伝えられるべきネットワーク・データを含む。
eNB操作部182は、変調器113に情報103を提供する。この情報103は、変調器113に対する命令を含む。例えば、eNB操作部182は、UE(単数または複数)102への送信に用いられるべき変調型(例えば、コンステレーション・マッピング)を変調器113に通知する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。変調器113は、1つ以上の送信機117に1つ以上の変調信号115を供給するためにデータ111を変調する。
eNB操作部182は、1つ以上の送信機117に情報192を提供する。この情報192は、1つ以上の送信機117に対する命令を含む。例えば、eNB操作部182は、UE(単数または複数)102へ信号をいつ送信すべきか(あるいはいつすべきでないか)を1つ以上の送信機117に命令する。いくつかの構成において、これは、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2に変換されているかどうかに基づく。例として、1つ以上の送信機117は、スペシャル・サブフレーム・タイプ2に変換された下りリンク・サブフレームの部分またはすべての間、送信することはない。1つ以上の送信機117は、1つ以上のUE102へ変調信号(単数または複数)115をアップコンバートして送信する。
留意すべきは、下りリンク・サブフレームは、eNB160から1つ以上のUE102へ送信され、上りリンク・サブフレームは、1つ以上のUE102からeNB160へ送信されることである。そのうえ、標準的スペシャル・サブフレームでは、eNB160も、1つ以上のUE102もデータを送信する。スペシャル・サブフレーム・タイプ2では、1つ以上のUE102は、データを送信する。しかしながら、スペシャル・サブフレーム・タイプ2では、eNB160は、データを送信してもよく、しなくてもよい。
図2は、eNB160上で下りリンク・サブフレームを変換するための方法200の一構成を示すフロー図である。eNB160は、スペシャル・サブフレーム・タイプ2変換のための通知用サブフレームおよび1つ以上の対象下りリンク・サブフレームを決定する(ステップ201)。通知用サブフレームは、下りリンク・サブフレーム、標準的スペシャル・サブフレームまたはスペシャル・サブフレーム・タイプ2であってもよい。通知用サブフレームおよび対象下りリンク・サブフレームの対は、然るべき分離間隔(例えば、4つのサブフレーム)を有するべきである。そのうえ、通知用下りリンク・サブフレームは、PHICHあるいはPDCCH上でのPUSCHスケジューリング、および/またはPUSCH送信に対するACK/NACKフィードバックに関する対応付けを有さなくてもよい。対象下りリンク・サブフレームは、一構成におけるスペシャル・サブフレーム・タイプ2の数に基づいて所定の順序によって決定される。
eNB160は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきかどうかを判定する(ステップ202)。例えば、eNB160は、現行のトラフィック割当ておよび現トラフィック負荷に基づいて、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきかどうかを判定する(ステップ202)。
一構成において、10個のサブフレームの期間を仮定し、
NU
個の上りリンク・サブフレーム、およびスペシャル・サブフレームを含む(10−
NU
)個の下りリンク・サブフレームからなるTDD UL−DL構成を仮定する。ネットワーク・リソースまたは能力が1に正規化され、アグリゲートされた上りリンクおよびアグリゲートされた下りリンク・トラフィック負荷が、それぞれ
λU
および
λDであると仮定する。ここで、
λU
および
λD
は、チャネル使用のパーセンテージとして正規化された(必要な制御シグナリングを含む)上りリンクおよび下りリンク・トラフィック負荷である。
オペレータは、いくつか所望の負荷比「目標」を持つネットワーク(例えば、eNB160)を、その収益モデルに対するオペレータの選好に基づいて構成する。実際のトラフィック特性は、2つの様態を含む。第1の様態は、全トラフィック負荷対能力比であり、次式で示される。
λ=(λU+λD)
第2の様態は、上りリンク対下りリンク・トラフィック比であり、次式で示される。
上りリンク対下りリンク・トラフィック比は、オペレータの目標または所望の負荷比に一致しても、しなくてもよい。
ネットワーク・アグリゲートされたトラフィック負荷対能力比が低いとき、上りリンク・トラフィックおよび下りリンク・トラフィック負荷が、次式
でそれぞれ示されるように、割当てられた上りリンク・サブフレームおよび下りリンク・サブフレームによってサポートされる場合、UL−DL構成は、受け入れ可能である。
いくつかの構成において、現上りリンク・トラフィック負荷が、割当てられた上りリンク・サブフレームによって受け入れられるのに比べて、より大きい(例えば、次式が満足されない)場合、
および/または、現下りリンク・トラフィック負荷が、割当てられた下りリンク・サブフレームを満たしていない場合、eNB160は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すると判定する(ステップ202)。
加えて、または代わりに、現上りリンク対下りリンク・トラフィック比
が、目標上りリンク対下りリンク・トラフィック比と比較して、ある量大きい場合、eNB160は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すると判定する(ステップ202)。対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきかどうかを判定する(ステップ202)ために、他の手法が、さらに、あるいは代わりに用いられてもよい。
eNB160が対象下りリンク・サブフレームを変換しないと判定した(ステップ202)場合、eNB160は、対象下りリンク・サブフレームを変換することはなく、スペシャル・サブフレーム・タイプ2変換のための通知サブフレームおよび対象下りリンク・サブフレームを決定する(ステップ201)ために戻る。
eNB160が対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すると判定した(ステップ202)場合、eNB160は、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理(PHY)レイヤ通知を送信する(ステップ204)。例えば、eNB160は、特定のUEに対して、DCIフォーマット0を持つPDCCHを発生させて送信(ステップ204)してもよく、あるいはPHICHを発生させて送信(ステップ204)してもよい。DCIフォーマット0を持つPDCCHの送信204は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきであることを暗黙的に示す。
eNB160は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定する(ステップ206)。例えば、eNB160は、対象下りリンク・サブフレームが、(例えば、電力制御、スケジューリングなどに関して)予想される上りリンク・サブフレームと対応付けられているかどうかを判定する。例として、eNB160は、上りリンク電力制御対応付け、PUSCH対応付け、PUSCH送信に対するACK/NACKフィードバック対応付け、PHICH対応付け、もしくはいくつか他の対応付けが、対象下りリンク・サブフレームに対応するかどうかを判定する(ステップ206)。
eNB160が、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに関して存在すると判定した(ステップ206)場合、eNB160は、対象下りリンク・サブフレームを、PDCCHを持つスペシャル・サブフレーム・タイプ2に変換する(ステップ208)。例えば、eNB160は、PDCCHのためにスペシャル・サブフレーム・タイプ2の一部分を予約する。eNB160は、スペシャル・サブフレーム・タイプ2において、データをDwPTS領域で送信する。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、eNB160は、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する(ステップ210)。いくつかの構成において、この判定210は、標準的上りリンク・サブフレームに基づくとよい。すべてのUL−DL構成において、標準的スペシャル・サブフレームは、上りリンク・サブフレームが後に続く。それゆえに、スペシャル・サブフレーム・タイプ2は、上りリンク・サブフレームまたは下りリンク・サブフレームの後ろにのみある。
いくつかの構成において、スペシャル・サブフレーム・タイプ2のサブフレームは、この判定210に関して、上りリンク・サブフレームと見做されることも、あるいは見做されないこともある。例えば、スペシャル・サブフレーム・タイプ2(S2)が別のS2の直後にある場合、前のS2は、上りリンクとして扱われる。しかしながら、いくつかの場合、eNB160は、第2のS2のみでUE102をスケジューリングする。かかる場合、前のS2は、UE102には知られない。これは、問題を生じかねない。しかしながら、この問題は、前のサブフレームもS2であるときにのみ第2のS2が許可されるように、S2の位置が明確に規定されていれば、解決することができる。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、eNB160は、対象下りリンク・サブフレームを、ガード期間(GP)を持たず、PDCCHを持たないスペシャル・サブフレーム・タイプ2に変換する(ステップ212)。この場合、対象下りリンク・サブフレームは、上りリンク・サブフレームに完全に変換されるとよい。eNB160は、スペシャル・サブフレーム・タイプ2でデータを受信することができる。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、eNB160は、対象下りリンク・サブフレームを、GPを持ち、PDCCHを持たないスペシャル・サブフレーム・タイプ2に変換する(ステップ214)。例えば、eNB160は、GPのためにスペシャル・サブフレーム・タイプ2の一部分を予約する。GPは、UE102が上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス(CP)構成を有する場合、スペシャル・サブフレーム・タイプ2におけるGPは、1つのOFDMシンボルの長さを有する。上りリンクおよび下りリンクが異なったサイクリックプレフィックス(CP)構成を有する場合、GPは、1つより少ないか、または1つより多いOFDMシンボルとする。しかしながら、切り替えタイミングを確保するために、スペシャル・サブフレーム・タイプ2のGPは、少なくとも
1456・Ts
の長さを有するとよい。
図3は、UE102上で下りリンク・サブフレームを変換するための信号を受信する方法300の一構成を示すフロー図である。UE102は、対象下りリンク・サブフレームに関するサブフレーム変換を指示する物理(PHY)レイヤ通知を受信する(ステップ302)。例えば、UE102は、DCIフォーマット0を持つPDCCHを受信(ステップ302)してもよく、あるいはPHICHを受信(ステップ302)してもよい。DCIフォーマット0を持つPDCCHの受信302は、対象下りリンク・サブフレームをスペシャル・サブフレーム・タイプ2に変換すべきであることを暗黙的に示す。
UE102は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在するかどうかを判定する(ステップ304)。例えば、UE102は、対象下りリンク・サブフレームが、(例えば、電力制御、スケジューリングなどに関して)予想される上りリンク・サブフレームと対応付けられているかどうかを判定する。例として、UE102は、上りリンク電力制御対応付け、PUSCH対応付け、PUSCH送信に対するACK/NACKフィードバック対応付け、PHICH対応付け、もしくはいくつかの他の対応付けが、対象下りリンク・サブフレームに対応するかどうかを判定する(ステップ304)。
UE102が上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在すると判定した(ステップ304)場合、UE102は、対象下りリンク・サブフレームを、PDCCHを持つスペシャル・サブフレーム・タイプ2に変換する(ステップ306)。例えば、UE102は、PDCCHのためにスペシャル・サブフレーム・タイプ2の一部分を予約する。UEは、スペシャル・サブフレーム・タイプ2でデータを送信し、データを受信する。この場合、PDCCHの長さを決定する必要がある。PDCCHの長さを決定するための手法が、以下にさらに詳細に記述される。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在しない場合、UE102は、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続くかどうかを判定する(ステップ308)。いくつかの構成において、この判定308は、標準的上りリンク・サブフレームに基づくとよい。いくつかの構成において、サブフレーム・タイプ2のサブフレームは、この判定308に関して、上りリンク・サブフレームと見做されることも、あるいは見做されないこともある。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続けば、UE102は、対象下りリンク・サブフレームを、ガード期間(GP)を持たず、PDCCHを持たないスペシャル・サブフレーム・タイプ2に変換する(ステップ310)。この場合、対象下りリンク・サブフレームは、上りリンク・サブフレームに完全に変換される。UE102は、スペシャル・サブフレーム・タイプ2でデータを送信する。
上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在せず、対象下りリンク・サブフレームが上りリンク・サブフレームのすぐ後に続かなければ、UE102は、対象下りリンク・サブフレームを、GPを持ち、PDCCHを持たないスペシャル・サブフレーム・タイプ2に変換する(ステップ312)。例えば、UE102は、GPのためにスペシャル・サブフレーム・タイプ2の一部分を予約する。GPは、UE102が上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス(CP)構成を有する場合、スペシャル・サブフレーム・タイプ2におけるGPは、1つのOFDMシンボルの長さを有する。上りリンクおよび下りリンクが異なったサイクリックプレフィックス(CP)構成を有する場合、GPは、1つより少ないか、または1つより多いOFDMシンボルとする。しかしながら、切り替えタイミングを確保するために、スペシャル・サブフレーム・タイプ2のGPは、少なくとも
1456・Ts
の長さを有するとよい。
図4は、物理下りリンク制御チャネル(PDCCH)の長さを決定する方法400の一構成を示すフロー図である。例えば、図4は、UE102が対象下りリンク・サブフレームをPDCCHを持つスペシャル・サブフレーム・タイプ2に変換306しているときに用いられる一手法を示す。
UE102は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在すると判定する(ステップ402)ことがある。UE102は、そのときには対象下りリンク・サブフレームのためのリソースブロック(RB)の数が10以下であるかどうかを判定する(ステップ404)。
対象下りリンク・サブフレームのためのリソースブロックの数が10以下でない(例えば、数が10より大きい)場合、UE102は、PDCCHのために1つのOFDMシンボルを予約する(ステップ406)。対象下りリンク・サブフレームのためのリソースブロックの数が10以下である場合、UE102は、PDCCHのために2つのOFDMシンボルを予約する(ステップ408)。この手法は、対象下りリンク・サブフレームのためのリソースブロックの数に基づいて固定数のシンボルが用いられる「固定」手法と見做すことができる。いくつかの構成において、UE102は、この手法を用いるべきであることを示すeNB160からの信号を受信する。
図5は、物理下りリンク制御チャネル(PDCCH)の長さを決定する方法500の別の構成を示すフロー図である。例えば、図5は、UE102が対象下りリンク・サブフレームをPDCCHを持つスペシャル・サブフレーム・タイプ2に変換する(ステップ306)ときに用いられる別の手法を示す。
UE102は、上りリンク−下りリンク対応付けが対象下りリンク・サブフレームに対して存在すると判定する(ステップ502)ことがある。図5に示される手法では、PDCCH長は、PCFICHに基づいて決定される。しかしながら、スペシャル・サブフレーム・タイプ2では、PCFICH情報(例えば、PDCCH領域の長さ)が初めにUEに知られていないこともあるので、UE102は、最小PDCCHサイズを持つデフォルト設定を用いてデータを処理しなければならない。それゆえに、UE102は、スペシャル・サブフレーム・タイプ2における最小PDCCHサイズを仮定して、データ符号化および多重化を行う(ステップ504)。例えば、UE102は、対象下りリンク・サブフレームのためのRBの数が10より大きい場合、PDCCHのために1つのOFDMシンボルを、対象下りリンク・サブフレームのためのRBの数が10以下である場合、2つのOFDMシンボルを仮定する。
スペシャル・サブフレーム・タイプ2におけるPCFICHの検出の際に、スペシャル・サブフレーム・タイプ2にPUSCHスケジューリングを持つUEは、PCFICHからPDCCHのためのOFDMシンボルの数を取得する。UE102は、PCFICHが最小(仮定された)PDCCHサイズに等しいサイズを指示するかどうかを判定する(ステップ506)。PCFICHが、仮定された最小PDCCHサイズにおけるのと同じOFDMシンボルの数を指示する場合、UE102は、符号化および多重化されたデータをいずれの変更もなしに送信する(ステップ510)。
しかしながら、PCFICHによって与えられるPDCCH領域がデフォルト値より大きい場合、上りリンク送信は、PCFICHからのOFDMシンボルの数によって決定されるスペシャル・サブフレーム・タイプ2構造を用いる。例えば、PCFICHが最小(仮定された)PDCCHサイズより大きいサイズを指示する場合、UE102は、スペシャル・サブフレーム・タイプ2からのデータをパンクチャする(ステップ508)。例として、選択されたスペシャル・サブフレーム・タイプ2構造によって取って代わられたOFDMシンボル中の符号化および多重化されたデータは、パンクチャして除かれる。かくして、所定のOFDMシンボルではいかなるPUSCH送信も発生することはない。
図6は、本明細書に開示されるシステムおよび方法に従って用いられる無線フレーム694の一例を示す図である。この無線フレーム694構造は、時分割複信(TDD)手法に適用可能である。各無線フレーム694は、
Tf=307200・Ts=10
ミリ秒(ms)の長さを有し、ここで
Tf
は無線フレーム694持続時間であり、
Ts
は
秒に等しい時間単位である。無線フレーム694は、それぞれが
153600・Ts=5
msの長さを有する2つの半フレーム696を含む。各半フレーム696は、それぞれが
30720・Ts=1
msの長さを有する5つのサブフレーム623a〜e、623f〜jを含む。
本明細書に開示されるシステムおよび方法に従って、用いられるサブフレーム623のいくつかのタイプは、下りリンク・サブフレーム、上りリンク・サブフレーム、標準的スペシャル・サブフレーム631およびスペシャル・サブフレーム・タイプ2を含む。図6に示される例では、2つの標準的スペシャル・サブフレーム631a〜bが無線フレーム694に含まれる。
第1の標準的スペシャル・サブフレーム631aは、下りリンク・パイロット時間スロット(DwPTS)625a、ガード期間(GP)627aおよび上りリンク・パイロット時間スロット(UpPTS)629aを含む。この例では、第1の標準的スペシャル・サブフレーム631aは、サブフレームone 623bに含まれる。第2の標準的スペシャル・サブフレーム631bは、下りリンク・パイロット時間スロット(DwPTS)625b、ガード期間(GP)627bおよび上りリンク・パイロット時間スロット(UpPTS)629bを含む。この例では、第2の標準的スペシャル・サブフレーム631bは、サブフレームsix 623gに含まれる。DwPTS625a〜bおよびUpPTS629a〜bの長さは、DwPTS625、GP627およびUpPTS629の各組の全長が
30720・Ts=1
msであることを前提として、3GPP TS 36.211の表4.2−1に示される。
各サブフレームi 623a〜j(この例では、iはサブフレームzero 623a(例えば0)からサブフレームnine 623j(例えば9)に及ぶサブフレームを示す)は、各サブフレーム623における長さが
Tslot=15360・Ts=0.5
msの2つのスロット
2i
および
2i+1
として定義される。例えば、サブフレームzero(例えば0)623aは、第1のスロット698を含めて、2つのスロットを含む。
本明細書に開示されるシステムおよび方法に従って、下りリンクから上りリンクへの切り替えポイント周期が5msおよび10msの両方のUL−DL構成が用いられる。図6は、5msの切り替えポイント周期を持つ無線フレーム694の一例を示す。下りリンクから上りリンクへの切り替えポイント周期が5msの場合、各半フレーム696が標準的スペシャル・サブフレーム631a〜bを含む。下りリンクから上りリンクへの切り替えポイント周期が10msの場合、スペシャル・サブフレームは、第1の半フレーム696だけに存在する。
サブフレームzero(例えば、0)623aおよびサブフレームfive(例えば、5)623eならびにDwPTS625a〜bは、下りリンク送信のために予約される。UpPTS629a〜b、および標準的スペシャル・サブフレーム(単数または複数)631a〜bのすぐ後に続くサブフレーム(単数または複数)(例えば、サブフレームtwo 623cおよびサブフレームseven 623h)は、上りリンク送信のために予約される。複数のセルがアグリゲートされた場合、UE102は、すべてのセルにわたって同じUL−DL構成を仮定し、かつ異なったセルにおけるスペシャル・サブフレーム(単数または複数)のガード期間(GP)が、少なくとも
1450・Ts
の重なりを有すると仮定する。
図6に示されるサブフレーム623の1つ以上が、用いられるUL−DL構成に依存して、上りリンク・サブフレームに変換されてもよい。例えば、上掲の表(1)に示されるようなUL−DL構成5を仮定すると、サブフレームthree(例えば、3)623dは、下りリンク・サブフレーム633として構成されているとき、スペシャル・サブフレーム・タイプ2に変換されてもよい。
図7は、上りリンク−下りリンク対応付けの例を示す図である。TDD UL−DL構成A 735aにおけるサブフレーム723aの第1の例(例えば、上掲の表(1)に示されるようなUL−DL構成1)は、下りリンク送信に対するACK/NACKフィードバック対応付け737a〜d、PUSCH送信に対する下りリンク・スケジューリング対応付け739a〜b、および上りリンク送信に対するACK/NACKフィードバック対応付け741a〜bを示す。この例に関連するサブフレーム番号749aが示される。
この例では、第1の無線フレーム794aにおける下りリンク・サブフレーム0および標準的スペシャル・サブフレーム1での下りリンク送信のACK/NACKは、第1の無線フレーム794aにおける上りリンク・サブフレーム7でレポートされ、対応付け737aとして示される。第1の無線フレーム794aにおける下りリンク・サブフレーム4での下りリンク送信のACK/NACKは、第1の無線フレーム794aにおける上りリンク・サブフレーム8でレポートされ、対応付け737bとして示される。同様に、第1の無線フレーム794aにおける下りリンク・サブフレーム5および標準的スペシャル・サブフレーム6での下りリンク送信のACK/NACKは、第2の無線フレーム794bにおける上りリンク・サブフレーム2でレポートされ、対応付け737cとして示される。第1の無線フレーム794aにおける下りリンク・サブフレーム9での下りリンク送信のACK/NACKは、第2の無線フレーム794bにおける上りリンク・サブフレーム3でレポートされ、対応付け737dとして示される。
例を続けると、第1の無線フレーム794aにおける標準的スペシャル・サブフレーム1は、第1の無線フレーム794aにおける上りリンク・サブフレーム7でのPUSCH送信をスケジューリングし、対応付け739aとして示される。第1の無線フレーム794aにおける下りリンク・サブフレーム4は、第1の無線フレーム794aにおける上りリンク・サブフレーム8でのPUSCH送信をスケジューリングし、対応付け739bとして示される。同様に、第1の無線フレーム794aにおける標準的スペシャル・サブフレーム6は、第2の無線フレーム794bにおける上りリンク・サブフレーム2でのPUSCH送信をスケジューリングする(図7に示されない)。
例を続けると、第1の無線フレーム794aにおける下りリンク・サブフレーム9は、第2の無線フレーム794bにおける上りリンク・サブフレーム3でのPUSCH送信をスケジューリングする(図7に示されない)。第1の無線フレーム794aにおける上りリンク・サブフレーム7でのPUSCH送信のACK/NACKは、第2の無線フレーム794bにおける標準的スペシャル・サブフレーム1でレポートされ、対応付け741aとして示される。第1の無線フレーム794aにおける上りリンク・サブフレーム8でのPUSCH送信のACK/NACKは、第2の無線フレーム794bにおける下りリンク・サブフレーム4でレポートされ、対応付け741bとして示される。同様に、第1の無線フレーム794aにおける上りリンク・サブフレーム2でのPUSCH送信のACK/NACKは、第1の無線フレーム794aにおける標準的スペシャル・サブフレーム6でレポートされる(図7に示されない)。第1の無線フレーム794aにおける上りリンク・サブフレーム3でのPUSCH送信のACK/NACKは、第1の無線フレーム794aにおける下りリンク・サブフレーム9でレポートされる(図7に示されない)。
TDD UL−DL構成B 735bにおけるサブフレーム723bの第2の例(例えば、上掲の表(1)に示されるようなUL−DL構成2)は、下りリンク送信に対するACK/NACKフィードバック対応付け737e〜f、PUSCH送信に対する下りリンク・スケジュール対応付け739c〜d、および上りリンク送信に対するACK/NACKフィードバック対応付け741c〜dを示す。この例に関連するサブフレーム番号749bが示される。
この例では、第3の無線フレーム794cにおける下りリンク・サブフレーム4、5、6および8での下りリンク送信のACK/NACKは、第4の無線フレーム794dにおける上りリンク・サブフレーム2でレポートされ、対応付け737eとして示される。同様に、第3の無線フレーム794cの下りリンク・サブフレーム9、および第4の無線フレーム794dにおける下りリンク・サブフレーム0、1および3での下りリンク送信のACK/NACKは、第4の無線フレーム794dにおける上りリンク・サブフレーム7でレポートされ、対応付け737fとして示される。
例を続けると、第3の無線フレーム794cにおける下りリンク・サブフレーム3は、第3の無線フレーム794cにおける上りリンク・サブフレーム7でのPUSCH送信をスケジューリングし、対応付け739cとして示される。同様に、第3の無線フレーム794cにおける下りリンク・サブフレーム8は、第4の無線フレーム794dにおける上りリンク・サブフレーム2でのPUSCH送信をスケジューリングし、対応付け739dとして示される。
例を続けると、第3の無線フレーム794cにおける上りリンク・サブフレーム7でのPUSCH送信のACK/NACKは、第4の無線フレーム794dにおける下りリンク・サブフレーム3でレポートされ、対応付け741cとして示される。同様に、第4の無線フレーム794dにおける上りリンク・サブフレーム2でのPUSCH送信のACK/NACKは、第4の無線フレーム794dにおける下りリンク・サブフレーム8でレポートされ、対応付け741dとして示される。
第1の例と第2の例とを比較したときに、気付きうるのは、たとえ2つの例の間で1つのサブフレーム723だけが異なるに過ぎないとしても、対応付け737、739、741のいずれも同じでないことである。留意すべきは、図7において「D」が下りリンク・サブフレーム743を示し、「U」が上りリンク・サブフレーム745を示し、「S」が標準的スペシャル・サブフレーム747を示すことである。
図8は、スペシャル・サブフレーム・タイプ2(S2)851の構造を示す図である。(スペシャル・サブフレーム・タイプ2(S2)851と混同すべきではない)標準的スペシャル・サブフレームは、下りリンクから上りリンクへの切り替えに用いられる。標準的スペシャル・サブフレームでは、チャネル・リソースの大部分が下りリンク送信に割当てられるのに対して、上りリンクには短時間(例えば、1つかまたは2つのシンボル)が割当てられる。しかしながら、スペシャル・サブフレーム・タイプ2(S2)851は、すべての必要な下りリンク通知(例えば、PUSCHスケジューリングおよびPHICHフィードバックに関する制御情報)を維持する一方で、より多くのリソースを上りリンク送信に提供することができる。(もしあれば)PDCCH送信だけを維持し、リソースの残りを(例えば、可能なガード期間855とともに)PUSCH送信に割当てることによって、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2(S2)851に変換される。
PDCCH DCIフォーマット0を用いたPUSCHスケジューリングでは、PUSCH割当ては、スタートRBのインデックスとRBの数とによって表される連続的なリソースブロック(RB)からなるブロックである。スペシャル・サブフレーム・タイプ2(S2)851のためのPUSCH割当てにおいて、各サブキャリアに使用可能なリソース要素(RE)は、上りリンク・パイロット時間スロット(UpPTS)857領域におけるシンボルの数と同じにするとよい。
標準的スペシャル・サブフレームと同様に、スペシャル・サブフレーム・タイプ2(S2)851は、3つのフィールド853、855、857を有する。標準的スペシャル・サブフレームでは、3つのフィールドは、下りリンク・パイロット時間スロット(DwPTS)、ガード期間(GP)および上りリンク・パイロット時間スロット(UpPTS)である。便宜上、スペシャル・サブフレーム・タイプ2(S2)851における3つのフィールドも、DwPTS853、GP855およびUpPTS857)と呼ばれる。スペシャル・サブフレーム・タイプ2(S2)851における3つのフィールドは、標準的スペシャル・サブフレームにおけるのと同じ名前を用いて呼ばれるが、留意すべきは、スペシャル・サブフレーム・タイプ2(S2)851における3つのフィールドの特性が、標準的スペシャル・サブフレームにおける同じ名前のフィールドの特性と異なっても、同様でも、および/または同じでもよいことである。
留意すべきは、スペシャル・サブフレーム・タイプ2(S2)851が下りリンク・サブフレームを置き換えることができる(一方、標準的スペシャル・サブフレームはできない)という点で、スペシャル・サブフレーム・タイプ2(S2)851が標準的スペシャル・サブフレームと異なることである。スペシャル・サブフレーム・タイプ2(S2)851は、標準的スペシャル・サブフレームがそのUpPTSで運ぶのに比べて、より多くのデータをUpPTS857で運ぶことができる。
スペシャル・サブフレーム・タイプ2(S2)851は、必要な下りリンク・シグナリングを維持する一方で、増加したリソースを上りリンク送信に提供する。例えば、スペシャル・サブフレーム・タイプ2(S2)851は、必要に応じてPDCCH領域を維持するが、いかなるPDSCH割当ても有さない。スペシャル・サブフレーム・タイプ2(S2)851におけるリソースの大部分は、PUSCH送信に割当てられる。すべての上りリンク制御フィードバックは、既存の上りリンク・サブフレームと対応付けられるので、スペシャル・サブフレーム・タイプ2(S2)851ではいかなるPUCCH割当ておよびPUCCH送信も許可されることはない。
スペシャル・サブフレーム・タイプ2(S2)851では、DwPTS853は、必要な下りリンク制御通知(例えば、PDCCHおよびPHICH)だけを提供するように制限される。PDCCHは、上りリンク・サブフレームでのPUSCH送信をスケジューリングするために用いられる。しかしながら、スペシャル・サブフレーム・タイプ2(S2)851におけるPDCCHは、PDSCH送信をスケジューリングすることはないので、スペシャル・サブフレーム・タイプ2(S2)851におけるDwPTS853のサイズは、通常の下りリンク・サブフレームにおけるDwPTSより小さくてもよい。例えば、スペシャル・サブフレーム・タイプ2(S2)851におけるリソースブロックの数が10より大きいとき、PDCCHに用いられる直交周波数分割多重(OFDM)シンボルの数は、1つかまたは2つに制限される。そのうえ、スペシャル・サブフレーム・タイプ2(S2)851におけるリソースブロックの数が10以下であるとき、PDCCHに用いられるOFDMシンボルの数は、2つにするとよい。
ガード期間(GP)855は、UE102が上りリンク送信のための時間前進を調整することを可能にする。上りリンクおよび下りリンクが同じサイクリックプレフィックス(CP)構成を有する場合、スペシャル・サブフレーム・タイプ2(S2)851におけるGP855は、1つのOFDMシンボルの長さを有するべきである。上りリンクおよび下りリンクが異なったサイクリックプレフィックス(CP)構成を有する場合、GPは、1つより少ないか、または1つより多いOFDMシンボルにするとよい。しかしながら、切り替えタイミングを確実にするために、スペシャル・サブフレーム・タイプ2(S2)851の(もし存在するならば)GP855は、(もし用いられるならば)少なくとも
1456・Ts
の長さを有するべきである。
現行のUL−DL構成において、下りリンク・サブフレームがPUSCHスケジューリング、電力制御および任意の上りリンク送信へのPHICHフィードバックとの関連付けを有さない場合、下りリンク・サブフレームは、いかなる予約されたPDCCH領域も持たない(例えば、DwPTS853長が0の)スペシャル・サブフレーム・タイプ2(S2)851に変換される。現行のUL−DL構成において、下りリンク・サブフレームがPUSCHスケジューリング、電力制御および任意の上りリンク送信へのPHICHフィードバックとの関連付けを有さず、下りリンク・サブフレームが上りリンク・サブフレームのすぐに後(あるいは、おそらくいくつかの構成においてスペシャル・サブフレーム・タイプ2(S2)851の後)にある場合、下りリンク・サブフレームは、いかなるGP855も持たない上りリンク・サブフレームに完全に変換される。現行のUL−DL構成において、下りリンク・サブフレームがPUSCHスケジューリング、電力制御および任意の上りリンク送信へのPHICHフィードバックとの関連付けを有さず、変換されるべき下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、例えば、第1のOFDMシンボル長がGP855として予約され、一方では、すべての他のOFDMシンボルが上りリンク送信に割当てられる。
スペシャル・サブフレーム・タイプ2(S2)851の一構成において、DwPTS853の長さおよびUpPTS857の長さは、DwPTS853、GP855およびUpPTS857の全長が
30720・Ts=1
msに等しいことを前提として、表(5)に示される。スペシャル・サブフレーム・タイプ2(S2)851の構造に関するさらなる詳細は、以下の通りである。
以下の表(6)は、同じ構成をOFDMシンボルの数の観点から提供するものである。PDCCHのために1つのOFDMシンボルが用いられる場合、UpPTS857は、上りリンク送信のために通常のサイクリックプレフィックス(CP)が構成されるのであれば12個のOFDMシンボルを、あるいは上りリンク送信のために拡張されたCPが構成されるのであれば10個のOFDMシンボルを有する。PDCCHのために2つのOFDMシンボルが用いられる場合、UpPTS857は、上りリンク送信のために通常のCPが構成されるのであれば、11個のOFDMシンボル、あるいは上りリンク送信のために拡張されたCPが構成されるのであれば、9個のOFDMシンボルを有する。いかなる予約されたPDCCH領域も持たない(例えば、DwPTS853長が0の)スペシャル・サブフレーム・タイプ2(S2)851に関して、対象下りリンク・サブフレーム(例えば、変換されるべき下りリンク・サブフレーム)が上りリンク・サブフレームの直後にある場合、すべてのシンボルが上りリンク割当てに用いられる。しかしながら、対象下りリンク・サブフレームが下りリンク・サブフレームの後にある場合、第1のOFDMシンボル長がGP855として予約され、一方では、すべての他のOFDMシンボルが上りリンク送信に割当てられる。
図9は、本明細書に開示されるシステムおよび方法による下りリンク・サブフレーム変換の一例を示す図である。より具体的には、図9は、いくつかのサブフレーム923を示し、同図中、(以前は下りリンク・サブフレームであった)サブフレームnがスペシャル・サブフレーム・タイプ2(S2)963に変換される。加えて、図9は、スペシャル・サブフレーム・タイプ2(S2)変換ルールおよびPHYレイヤ通知を示す。
本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレームがスペシャル・サブフレーム・タイプ2(S2)963に変換される。これは、例えば、1つ以上のDCIフォーマット0 PUSCH送信が、(現行の3GPPリリース8、9および10の仕様書では、PUSCH割当てのためのDCIフォーマット0を有することが許可されていない)下りリンク・サブフレームに割当てられたとき、あるいは以前に割当てられたスペシャル・サブフレーム・タイプ2に対するPHICHフィードバックが必要とされるときに発生する。
スペシャル・サブフレーム・タイプ2(S2)951に対する対応付けは、以下のように規定される。所定のUL−DL構成に関して、下りリンク・サブフレームn−4は、PUSCHスケジューリング、および上りリンク送信に対するPHICHまたはPDCCHフィードバックとの対応付けを有さなくてもよい。下りリンク・サブフレームn−4(例えば、DCIフォーマット0を持つPDCCHを含んだ下りリンク・サブフレーム943a)は、(例えば、以前は下りリンク・サブフレームであった)下りリンク・サブフレームn963をスペシャル・サブフレーム・タイプ2(S2)951に変換する。例として、対応付けA959は、サブフレームn−4(例えば、下りリンク・サブフレーム943a)におけるPUSCHのスケジューリングが、サブフレームnをスペシャル・サブフレーム・タイプ2(S2)951に変換することを特定する。サブフレームn−4における制御情報に従って、サブフレームnがスペシャル・サブフレーム・タイプ2(S2)951に変換される。PUSCH割当てを持つ1つ以上のUE102は、サブフレームnで送信を行うことができる。
サブフレーム番号nを持つスペシャル・サブフレーム・タイプ2に対するACK/NACKフィードバックは、サブフレームn+6(例えば、下りリンク・サブフレーム943b)でレポートされる。例として、対応付けB961は、スペシャル・サブフレーム・タイプ2(S2)951に対するACK/NACKがサブフレームn+6でレポートされることを特定する。留意すべきは、この対応付け959、961が無線フレーム境界を越えて適用されてもよいことである。
一構成において、変換されたサブフレームnでのPUSCH送信に対するACK/NACKは、下りリンク・サブフレームn+6におけるPHICH上で運ばれる。随意的に、サブフレームn+6におけるPDCCHがPHICHをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームn+10での新しいデータの送信または再送信をスケジューリングすることもできる。
別の構成では、変換されたサブフレームnにPUSCH送信に対するいかなるPHICHもないことがあり、UE102は、PHICH値をACKと見做す。そのうえ、サブフレームn+6におけるPDCCHがACKをオーバーライドし、その送信が新しい送信であるか否かを示すことによって、サブフレームn+10での新しいデータ送信または再送信をスケジューリングすることもできる。再送信のスケジューリングは、以前のPUSCH送信に対するNACKを示す。UE102がPDCCHを何も検出しない場合、UE102は、サブフレームn+10でPUSCHを送信することはない。TDDは、5msおよび10msの両方の構成に共通の10個の間隔を有し、n+6=(n−4)+10なので、PHICHおよびDCIフォーマット0を持つPDCCH割当ては、常に同じ下りリンク・サブフレーム・インデックス番号を有する。
言い換えれば、サブフレーム番号nを持つスペシャル・サブフレーム・タイプ2(S2)951のPUSCHは、スペシャル・サブフレーム・タイプ2(S2)951の4サブフレーム前にある下りリンク・サブフレーム(例えば、標準的な構成においてPUSCHスケジューリング、およびPUSCH送信に対するACK/NACKフィードバックに関するいかなる既存の対応付けもない、サブフレーム番号n−4を持つ下りリンク・サブフレーム943a)のPDCCHまたはPHICHフィードバックでスケジューリングされる。サブフレーム番号nを持つスペシャル・サブフレーム・タイプ2(S2)951でのPUSCH送信のACK/NACKフィードバックは、サブフレーム番号n+6を持つ下りリンク・サブフレーム943bにおいてPHICH上で、あるいは明示的なPDCCHスケジューリングによってレポートされる。
いくつかの構成において、nは、サブフレーム番号またはインデックスiの周期的な組における現サブフレームを示す。サブフレーム番号またはインデックスiは、0から9に及び、各周期が無線フレームに対応する。従って、数kがnに加えられるか、またはnから引かれて、iの周期の範囲(例えば、0≦i≦9)を越えた場合、結果は、異なった無線フレームにおけるサブフレームを特定する。例として、n+k=iは、n=9およびk=4の場合、現無線フレームの次の無線フレームにおけるサブフレームi=3を特定する。言い換えれば、インデックスは、モジュラー関数mod(n+k)=iによって表すことができて、(n+k)=iであれば、これらは同じ無線フレーム中にある。(n+k)≧10であれば、i=mod(n+k)=n+k−10であり、サブフレーム・インデックスiは、現無線フレームの次の無線フレーム中にある。
図9に示される例に従って、eNB160は、スペシャル・サブフレーム・タイプ2(S2)951に変換された対象下りリンク・サブフレームの4サブフレーム前にある、下りリンク・サブフレーム943aでPHYレイヤ通知を送信し、UE(単数または複数)102はこれを受信する。1つ以上のUE102および随意的にeNB160は、スペシャル・サブフレーム・タイプ2(S2)951でデータを送信(および/または受信)する。eNB160は、スペシャル・サブフレーム・タイプ2(S2)951に変換された対象下りリンク・サブフレームの6サブフレーム後にある、下りリンク・サブフレーム943bでACK/NACKデータを送信し、UE(単数または複数)102は、これを受信する。ACK/NACKデータは、スペシャル・サブフレーム・タイプ2(S2)951でUE(単数または複数)102からeNB160へ送信されたデータに対応する。
図10は、本明細書に開示されるシステムおよび方法による下りリンク・サブフレーム変換の別の例を示す図である。留意すべきは、図10において「D」が下りリンク・サブフレーム1043を示し、「U」が上りリンク・サブフレーム1045を示し、「S」が標準的スペシャル・サブフレーム1047を示し、「S2」がスペシャル・サブフレーム・タイプ2(S2)1051を示すことである。
この例において、(上掲の表(1)に示されるような)上りリンクおよび下りリンク(UL−DL)構成5は、サブフレームの第1の組1023aでは、下りリンク・サブフレーム変換なしに用いられ、サブフレームの第2の組1023bでは、下りリンク・サブフレーム変換して用いられる。構成5では、サブフレームの第1および第2の組1023a〜bに対応するサブフレーム番号1049a〜bに従って、それぞれのサブフレーム番号i=2に1つだけ上りリンク・サブフレーム1045が存在する。
サブフレームの両方の組1023a〜bにおいて、PUSCH割当ては、現フレーム1094a〜bの前のフレームのサブフレーム番号i=8におけるPDCCH DCIフォーマット0またはPHICHフィードバックによって通知される。例えば、PUSCH送信に対する下りリンク・スケジューリング対応付け1039a〜bが、サブフレームの両方の組1023aに示される。現行の3GPP仕様書(例えば、リリース8、9および10)によれば、構成5では、すべての他の下りリンク・サブフレームは、PDCCH DCIフォーマット0またはPHICHフィードバックを運ぶことができない。
しかしながら、本明細書に開示されるシステムおよび方法に従って、下りリンク・サブフレーム1043番号i=3でのPUSCH送信をスケジューリングする(あるいはPHICH上でPUSCH送信を肯定する)ためにPDCCH DCIフォーマット0が前のフレームのサブフレーム番号i=9に割当てられている場合、現フレーム1094bの下りリンク・サブフレーム1043番号i=3は、スペシャル・サブフレーム・タイプ2(S2)1051に変換される。このように、PUSCH送信に対する下りリンク・スケジューリング対応付け1039cが用いられる。割当てられたPUSCHリソース上でPUSCH送信を運ぶことができる。
図10に示されるように、サブフレームの両方の組1023a〜bにおいて、上りリンク送信に対するACK/NACKフィードバック対応付け1041a〜bは、対応するACK/NACK情報が下りリンク・サブフレーム1043番号i=8で通信されることを特定するために、上りリンク・サブフレーム番号i=2に対して用いられる。サブフレームの第2の組1023bでは、スペシャル・サブフレーム・タイプ2(S2)1051でのPUSCH送信のACK/NACKは、上りリンク送信に対するACK/NACKフィードバック1041cに従って、サブフレーム番号i=9上でレポートされる。
下りリンク・サブフレーム1043からスペシャル・サブフレーム・タイプ2(S2)1051への変換は、一時的かつ動的であってもよい。いくつかの構成において、下りリンク・サブフレーム1043は、上記の条件下においてのみ、スペシャル・サブフレーム・タイプ2(S2)1051に変換される。その他の場合は、通常の下りリンク・サブフレーム1043として機能する。このように、変換および遷移は、自律的に生じ、いかなる追加の通知も必要ではない。
スペシャル・サブフレームを予期しないレガシーUEは、スペシャル・サブフレーム・タイプ2(S2)1051を通常の下りリンク・サブフレーム1043として扱う。スペシャル・サブフレーム・タイプ2(S2)1051にPDCCHが存在するとき、レガシーUEにとって何も変化はない。スペシャル・サブフレーム・タイプ2(S2)1051にPDCCHが存在しないとき、レガシーUEは、PDCCHを首尾よく検出できないので、このサブフレームに関してDTXをレポートする。リリース11以降のUE102は、本明細書に開示されるシステムおよび方法に従って、必要とされる上りリンク−下りリンク対応付け、およびスペシャル・サブフレーム・タイプ2(S2)1051でのデータ送信を行う。
本明細書に開示されるシステムおよび方法は、既存の(例えば、3GPPリリース8、9および10による)対応付け1037、1039、1041を維持する一方で、下りリンク・サブフレーム1043のスペシャル・サブフレーム・タイプ2(S2)1051への変換を提供する。例えば、スペシャル・サブフレーム・タイプ2(S2)1051)を持つ第2のサブフレームの組1023bにおける、下りリンク送信に対するACK/NACKフィードバック対応付け1037bは、第1のサブフレームの組1023aにおける、下りリンク送信に対するACK/NACKフィードバック対応付け1037aと同じである。同様に、PUSCH送信に対する既存の下りリンク・スケジューリング対応付け1039a、1039b、および上りリンク送信に対するACK/NACKフィードバック対応付け1041a、1041bは、維持される。
図11は、端末装置(UE)1102に利用される様々なコンポーネントを示す。UE1102は、上記のUE102として利用されてもよい。UE1102は、UE1102の動作を制御するプロセッサ1169を含む。プロセッサ1169は、CPUと呼ぶこともできる。メモリ1175は、リードオンリーメモリ(ROM:read−only memory)、ランダムアクセスメモリ(RAM:random access memory)、これら2つの組み合わせ、あるいは情報を記憶する任意のタイプのデバイスを含み、プロセッサ1169に命令1171aおよびデータ1173aを与える。メモリ1175の一部分は、不揮発性ランダムアクセスメモリ(NVRAM:non−volatile random access memory)も含んでもよい。命令1171bおよびデータ1173bは、プロセッサ1169にも存在する。プロセッサ1169に読み込まれた命令1171bおよび/またはデータ1173bは、プロセッサ1169による実行または処理のために読み込まれた、メモリ1175からの命令1171aおよび/またはデータ1173aも含んでもよい。命令1171bは、本明細書に開示される方法300、400、500の1つ以上を実装するためにプロセッサ1169によって実行される。
UE1102は、データの送信および受信を可能にするために1つ以上の送信機1158および1つ以上の受信機1120が入った筺体も含む。送信機(単数または複数)1158および受信機(単数または複数)1120は、1つ以上のトランシーバ1118に組み合わされてもよい。1つ以上のアンテナ1122a〜nは、筺体に取り付けられ、トランシーバ1118に電気的に結合される。
UE1102の様々なコンポーネントは、データバスに加えて、電力バス、制御信号バスおよびステータス信号バスを含む、バスシステム1181によって一緒に結合される。しかしながら、明確さのために、図11では様々なバスがバスシステム1181として示される。UE1102は、信号処理用デジタル信号プロセッサ(DSP:digital signal processor)1177を含むこともできる。UE1102は、UE1102の機能へのユーザ・アクセスを提供する通信インタフェース1179を含むこともできる。図11に示されるUE1102は、具体的なコンポーネントのリストではなく、機能ブロック図である。
図12は、evolved Node B(eNB)1260に利用される様々なコンポーネントを示す。eNB1260は、先述のeNB160として利用されてもよい。eNB1260は、UE1102に関する上述のコンポーネントと同様のコンポーネントを含むことができ、プロセッサ1283、プロセッサ1283に命令1285aおよびデータ1287aを与えるメモリ1289、プロセッサ1283中に存在しても、あるいは読み込まれてもよい命令1285bおよびデータ1287b、(1つの以上のトランシーバ1276に組み合わされてもよい)1つ以上の送信機1217および1つ以上の受信機1278が入った筺体、トランシーバ(単数または複数)1276に電気的に結合された1つ以上のアンテナ1280a〜n、バスシステム1295、信号処理用DSP 1291、通信インタフェース1293などを含む。命令1285bは、本明細書に開示される方法200を実施するために、プロセッサ1283によって実行される。
用語「コンピュータ可読媒体」は、コンピュータまたはプロセッサによってアクセスされる任意の利用可能な媒体を指す。用語「コンピュータ可読媒体」は、本明細書では、非一時的かつ有形のコンピュータおよび/またはプロセッサ可読媒体を示す。限定ではなく、例として、コンピュータ可読またはプロセッサ可読媒体は、RAM、ROM、EEPROM、CD−ROMまたは他の光ディスク記憶、磁気ディスク記憶もしくは他の磁気記憶デバイス、あるいは、命令の形態の所望のプログラムコードまたはデータ構造を載せるか、または記憶するために用いられ、コンピュータまたはプロセッサによってアクセスされる任意の他の媒体を備えてもよい。ディスク(disk)およびディスク(disc)は、本明細書では、コンパクトディスク(CD:compact disc)、レーザディスク(laser disc)、光ディスク(optical disc)、デジタルバーサタイルディスク(DVD:digital versatile disc)、フロッピーディスク(floppy disk)およびBlu−ray(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、磁気的にデータを再生し、一方でディスク(disc)は、レーザを用いて光学的にデータを再生する。
留意すべきは、本明細書に記述される方法の1つ以上が、ハードウェアで実装されてもよい、および/またはハードウェアを用いて行われてもよいことである。例えば、本明細書に記述される方法の1つ以上は、チップセット、特定用途向け集積回路(ASIC:application−specific integrated circuit)、大規模集積回路(LSI:large−scale integrated circuit)または集積回路などで実装されてもよく、および/またはそれらを用いて実現されてもよい。
本明細書に開示される方法のそれぞれは、記述される方法を実現するための1つ以上のステップまたは動作を含む。本方法のステップおよび/または動作は、特許請求の範囲から逸脱することなく、相互に交換されても、および/または単一のステップに組み合わされてもよい。言い換えれば、記述される方法の適切な操作のために、ステップまたは動作の特定の順序が、必要とされない限り、特許請求の範囲から逸脱することなく、特定のステップおよび/または動作の順序および/または使用が修正されてもよい。
当然のことながら、特許請求の範囲は、上記に説明されたまさにその構成およびコンポーネントには限定されない。特許請求の範囲から逸脱することなく、本明細書に記述される配置、操作、ならびにシステム、方法、および装置の詳細に様々な修正、変更および変形がなされてもよい。