JP7643394B2 - 端末デバイス及び端末デバイスにより実行される方法 - Google Patents

Description

本開示の非限定的かつ例示的な実施形態は、一般的に、無線通信の技術分野に関し、特に、データ伝送のためのリソースマッピングの方法、デバイス及び装置、並びにデータ受信のための方法、デバイス及び装置に関する。

新しい無線アクセスシステム（Ｎｅｗ Ｒａｄｉｏ ａｃｃｅｓｓ ｓｙｓｔｅｍ）は、ＮＲシステム又はＮＲネットワークとも呼ばれる、次世代通信システムである。３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ワーキンググループのＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）＃７１会議では、ＮＲシステムの研究が認められた。ＮＲシステムは、例えば、拡張モバイルブロードバンド、大規模なマシンタイプの通信、超信頼性・低遅延通信などの要求が含まれる、技術レポートＴＲ３８．９１３で定義されたすべての利用状況、要求、配置状況に対処する単一の技術フレームワークを目的とし、１００Ｇｈｚまでの周波数を考慮する。

データレートの性能を改善するために、３ＧＰＰロング・ターム・エボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）において、ダウンリンク伝送とアップリンク伝送の両方にＬＡＡ（Ｌｉｃｅｎｓｅ Ａｓｓｉｓｔｅｄ Ａｃｃｅｓｓ）が導入された。ＬＴＥネットワークがＮＲプロジェクトでより広い帯域幅の波形が研究されることにつれて次の進化段階に入ると、ＬＡＡネットワークが５Ｇ ＮＲシステムへと発展していくのは当然のことである。

ＮＲ免許不要帯域とＬＴＥ免許不要帯域とが類似するため、ＬＴＥシステムのＬＡＡで使用される多くの機能（ＣＣＡ（Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）、ＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）メカニズムなど）はそのまま維持される。ただし、明らかな相違点もいくつかあり、そのうちの１つは、ＮＲシステムがはるかに大きな最大伝送帯域幅をサポートすることにある。現在、ＬＡＡ及びＷｉ－Ｆｉは共に２０ＭＨｚの帯域幅を有し、そのため、ＮＲシステムが例えば８０ＭＨｚ以上のより広い帯域幅を有する単一のキャリア帯域をサポートする場合について、何らかの方法を設計する必要がある。

この目的のため、本開示では、先行技術における問題点の少なくとも一部を軽減又は少なくとも緩和するために、無線通信システムにおけるデータ伝送のためのリソースマッピング及びデータ受信の新しいソリューションが提供される。

本開示の第１の側面によれば、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される、データ伝送のためのリソースマッピングの方法が提供される。この方法は、データ伝送のためのリソース要素をサブ帯域幅の順にマッピングすることと、複数のサブ帯域幅のそれぞれにおいて、リソース要素を、まず、周波数領域の順に、そして、時間領域の順にマッピングすることと、を有する。

本開示の第２の側面によれば、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される、データ受信方法が提供される。この方法は、サブ帯域幅の順にリソース要素でデータを受信することと、複数のサブ帯域幅のそれぞれにおいて、まず、周波数領域の順に、そして、時間領域の順にリソース要素でデータを受信することと、を有する。

本開示の第３の側面によれば、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される、伝送デバイスが提供される。伝送デバイスは、トランシーバと、プロセッサと、を備える。プロセッサは、データ伝送のためのリソース要素をサブ帯域幅の順にマッピングし、複数のサブ帯域幅のそれぞれにおいて、まず、周波数領域の順に、そして、時間領域の順にリソース要素をマッピングするように構成されている。

本開示の第４の側面によれば、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される、受信デバイスが提供される。受信デバイスは、トランシーバを備え、トランシーバは、サブ帯域幅の順にリソース要素でデータを受信し、複数のサブ帯域幅のそれぞれにおいて、まず、周波数領域の順に、そして、時間領域の順にリソース要素でデータを受信するように構成されている。

本開示の第５の側面によれば、ネットワークデバイスが提供される。伝送デバイスは、プロセッサと、メモリと、を備える。メモリは、プロセッサに接続され、プログラムコードを有し、そのプログラムコードは、プロセッサ上で実行されると、ネットワークデバイスに第１の側面の動作を実行させる。

本開示の第６の側面によれば、受信デバイスが提供される。端末デバイスは、プロセッサと、メモリと、を備える。メモリは、プロセッサに接続され、プログラムコードを有し、そのプログラムコードは、プロセッサ上で実行されると、端末ノードに第２の側面の動作を実行させる。

本開示の第７の側面によれば、コンピュータプログラムコードを有するコンピュータ読み取り可能な記憶媒体が提供され、そのコンピュータプログラムコードは、実行されると、装置に、第１の側面の任意の実施形態にかかる方法における動作を実行させるように構成されている。

本開示の第８の側面によれば、コンピュータプログラムコードを有するコンピュータ読み取り可能な記憶媒体が提供され、そのコンピュータプログラムコードは、実行されると、装置に、第２の側面の任意の実施形態にかかる方法における動作を実行させるように構成されている。

本開示の第９の側面によれば、第７の側面にかかるコンピュータ読み取り可能な記憶媒体を含むコンピュータプログラム製品が提供される。

本開示の第１０の側面によれば、第８の側面にかかるコンピュータ読み取り可能な記憶媒体を含むコンピュータプログラム製品が提供される。

本開示の実施形態によれば、データ伝送のためのリソースマッピングへの効果的なソリューションが提供されることで、より広い帯域幅を有する新しい無線アクセスシステムは、ＷｉＦｉのような免許不要帯域での他の通信と良好に共存することができる。

本開示の上記特徴及び他の特徴は、添付の図面を参照しつつ実施形態で示される実施例への詳細な説明を通してより明らかになる。添付の図面全体において、同じ参照符号は同じ又は類似の構成要素を表す。

既存のソリューションにおける符号ブロック群（ＣＢＧ：ｃｏｄｅ ｂｌｏｃｋ ｇｒｏｕｐ）に基づく再送を模式的に示す。

キャリア帯域の一部がＷｉＦｉによって占有されている場合を模式的に示す。

本開示の一実施形態にかかるデータ伝送のためのリソースマッピングの方法のフローチャートを模式的に示す。

本開示の一実施形態にかかるキャリア帯域幅分割及びリソースマッピングの例を模式的に示す。

本開示の一実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの他の例を模式的に示す。

本開示の一実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの別の例を模式的に示す。

本開示の一実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの他の例を模式的に示す。

本開示の一実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの別の例を模式的に示す。

本開示の一実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの更に別の例を模式的に示す。

本開示の一実施形態にかかるダウンリンクデータ伝送のためのリソースマッピングの例示的な方法のフローチャートを模式的に示す。

本開示の一実施形態にかかるアップリンクデータ伝送のためのリソースマッピングの例示的な方法のフローチャートを模式的に示す。

本開示の一実施形態にかかるデータ受信の方法のフローチャートを模式的に示す。

本開示の一実施形態にかかるダウンリンクデータを受信するための方法のフローチャートを模式的に示す。

本開示の一実施形態にかかるアップリンクデータを受信するための方法のフローチャートを模式的に示す。

本開示の一実施形態にかかるダウンリンクデータ伝送のためのリソースマッピング用の装置のブロック図を模式的に示す。

本開示の一実施形態にかかるアップリンクデータ伝送のためのリソースマッピング用の装置のブロック図を模式的に示す。

本開示の一実施形態にかかるダウンリンクデータを受信するための装置のブロック図を模式的に示す。

本開示の実施形態にかかるアップリンクデータを受信するための装置のブロック図を模式的に示す。

本明細書で説明される、ｇＮＢのようなネットワークノードとして具現化され、又はそれが備えられる装置１９１０と、ＵＥのような端末デバイスとして具現化され、又はそれが備えられる装置１９２０の簡略ブロック図を模式的に示す。

以下、添付の図面を参照しながら実施形態を通して本開示で提供されるソリューションを詳細に説明する。これらの実施形態は、当業者が本開示をより理解し、かつ実施するために提供されるものにすぎず、いかなる形で本開示の範囲を限定するものではないことを理解されたい。

添付の図面において、本開示の様々な実施形態は、ブロック図、フローチャート、及び他の図で示されている。フローチャート又はブロック図内の各ブロックは、本開示において、特定の論理機能を実行するための１つ又は複数の実行可能命令を含むモジュール、プログラム、又はコードの一部を表すことができ、必ずしも必要ではないブロックを点線で示している。さらに、これらのブロックは、方法のステップを実行するための特定の順序で示されているが、実際には、それらは必ずしも示された順序に厳密に従って実行されなくてもよい。例えば、それらは逆の順序や同時に実行されてもよく、実行の順序はそれぞれの動作の性質に依存する。なお、ブロック図及び／又はフローチャート内の各ブロック、並びにそれらの組み合わせは、特定の機能／動作を実行するための専用のハードウェアベースのシステムによって、又は専用のハードウェアとコンピュータ命令との組み合わせによって実装されてもよいことに留意すべきである。

一般的に、特許請求の範囲で使用されるすべての用語は、本明細書で他に明示的に定義されていない限り、その技術分野におけるそれらの通常の意味に従って解釈されるべきである。「１つ（ａ）／１つ（ａｎ）／前記（ｔｈｅ）／この（ｓａｉｄ）［要素、デバイス、コンポーネント、手段、ステップなど］」に対する全ての言及は、特にそうではないと明示的に述べられていない限り、複数のそのようなデバイス、コンポーネント、手段、ユニット、ステップなどを除外するものではなく、少なくとも１つの要素、デバイス、コンポーネント、手段、ユニット、ステップなどの例を指すものとして素直に解釈されるべきである。さらに、本明細書で使用される不定冠詞「１つ（ａ）／１つ（ａｎ）」は、複数のそのようなステップ、ユニット、モジュール、デバイス、及びオブジェクトなどを除外するものではない。

さらに、本開示の文脈において、ユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）は、端末、モバイル端末（ＭＴ：Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、加入者局、ポータブル加入者局、移動局（ＭＳ：Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、又はアクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）を指してもよいし、ＵＥ、端末、ＭＴ、ＳＳ、ポータブル加入者局、ＭＳ、又はＡＴの機能の一部又は全てが含まれてもよい。さらに、本開示の文脈では、用語「ＢＳ」は、例えば、ノードＢ（ＮｏｄｅＢ又はＮＢ）、ｅｖｏｌｖｅｄ ＮｏｄｅＢ（ｅＮｏｄｅＢ又はｅＮＢ）、ｇＮＢ（次世代ＮｏｄｅＢ）、Ｒａｄｉｏ Ｈｅａｄｅｒ（ＲＨ）、Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ（ＲＲＨ）、リレー、又はフェムト、ピコなどの低電力ノードを表してもよい。

背景技術で述べたように、ＮＲシステムは、はるかに大きな最大伝送帯域幅をサポートしており、現在、ＬＡＡとＷｉ－Ｆｉは共に２０ＭＨｚの帯域幅を持っている。したがって、ＮＲシステムが例えば８０ＭＨｚ以上のより広い帯域幅を有する単一のキャリア帯域をサポートする場合について、何らかの方法が設計される必要がある。

例示の目的のために、図１は、既存のソリューションにおける符号ブロック群（ＣＢＧ：ｃｏｄｅ ｂｌｏｃｋ ｇｒｏｕｐ）に基づく再送を模式的に示す。図１に示すように、時間シンボルが高優先サービスによって先取りされる可能性がある超高信頼性・低遅延通信（ＵＲＬＬＣ：Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）では、ＣＢＧに基づく再送が使用される。すなわち、伝送ブロック（ＴＢ：ｔｒａｎｓｐｏｒｔ ｂｌｏｃｋ）を時間領域で複数のＣＢＧに分割する。ハイブリッド自動再送要求－肯定応答（ＨＡＲＱ－ＡＣＫ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ － Ａｃｋｎｏｗｌｅｄｇｅ）フィードバック及び再送は、ＣＢＧレベルで行うことができる。言い換えれば、いくつかのＯＦＤＭシンボルが他のより高い優先サービスによって先取りされている場合、先取りされたＯＦＤＭシンボルを有するＣＢＧのみが影響を受け、再送される必要があるが、他のＣＢＧは正常にデコードされることができ、再送する必要がない。

ＮＲシステムにおいて、複数の帯域のキャリアアグリゲーションが２０ＭＨｚの帯域幅（すなわち、１帯域あたり１ＴＢ）で行われる場合に、何ら問題が発生しないかもしれない。しかし、単一のキャリア帯域の帯域幅が８０ＭＨｚ、１００ＭＨｚ以上の広帯域を有する場合、何らかの問題が発生する可能性があり、ＣＢＧに基づく再送でも問題に対処できない。例えば、２０ＭＨｚのＷｉ－Ｆｉ信号のようなサブ帯域干渉は、全帯域のＮＲ伝送をブロックすることになる。

図２は、キャリア帯域の一部がＷｉＦｉによって占有される場合を模式的に示す。図２に示すように、ＮＲ－Ｕのキャリア帯域幅は、例えば８０ＭＨｚであってもよく、ＷｉＦｉ又はＬＡＡのキャリア帯域幅は２０ＭＨｚである。既存のＬＢＴのメカニズムでは、Ｗｉ－Ｆｉがチャネルリソースを占有してしまうと、ＴＢを複数のＣＢＧに分割しても、ＮＲシステムは８０ＭＨｚ全体を伝送することができない。これは、免許不要帯域では、ＣＣＡはリアルタイムの評価であり、伝送直前にチャネルが突然にビジー状態になる場合、伝送信号を調整したり、レートマッチしたりする時間が残されておらず、パンクチャすることしかできないからである。このように、現在のソリューションによれば、ＬＢＴに起因して一度パンクチャされてしまうと、１つのＴＢ内の全てのＣＢＧは、正常にデコードできないことになる。

この目的のため、本開示では、先行技術における問題点の少なくとも一部を軽減又は少なくとも緩和することができる、データ伝送のためのリソースマッピングの新規なソリューションが提案されている。本開示では、サブ帯域幅に基づく新規なリソースマッピングソリューションが提案されており、ここで、キャリア帯域幅がさらに複数のサブ帯域幅に分割され、再送がサブ帯域幅に基づいて実行され得る。したがって、ＷｉＦｉ伝送によって影響を受けるサブ帯域幅のみが、ＮＲ伝送に使用されることはできない。以下、さらに図３～図１９を参照して、本開示で提案されているソリューションを詳細に説明する。ただし、以下の実施形態は例示の目的で提供されることに過ぎず、本開示はこれに限定されるものではないことを理解されたい。

図３は、本開示の一実施形態にかかる無線通信システムにおけるデータのためのリソースマッピングの方法３００のフローチャートを模式的に示す。方法３００は、データ伝送デバイス、例えば、ダウンリンクデータ伝送のためのｅＮＢ、又はアップリンクデータ伝送のための端末デバイスで実行されてもよい。

図３に示すように、ステップ３０１において、データ伝送のためのリソース要素は、まず、サブ帯域幅の順にマッピングされ、ここで、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される。

上述したように、キャリア帯域幅はさらに複数のサブ帯域幅に分割され、再送はサブ帯域幅に基づいて実行され得る。したがって、ＷｉＦｉ伝送によって影響を受けるサブ帯域幅のみが、ＮＲ伝送に使用されることはできない。

本開示の実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの例を模式的に示す図４を参照する。図４に示すように、８０ＭＨｚのキャリア帯域幅が例として示され、キャリア帯域幅は、さらに４つのサブ帯域幅ＳＢＷ０、ＳＢＷ１、ＳＢＷ２、及びＳＢＷ３に分割される。リソースマッピングにおいて、まず、サブ帯域幅の順にリソースマッピングを実行する。例えば、リソースマッピングは、まずＳＢＷ０に、次にＳＢＷ１に、その次にＳＢＷ２に、最後にＳＢＷ３に実行される。

再び図３を参照して、ステップ３０２において、複数のサブ帯域幅のそれぞれにおいて、リソース要素は、まず周波数領域の順に、そして、時間領域の順にマッピングされる。言い換えれば、リソース要素は、まず、サブ帯域幅にサブキャリアが残らなくなるまで、周波数領域の順にマッピングされ、そして、次の時間領域のリソースにマッピングされる。

再び図４を参照する。リソース要素は、まず、第１のＣＢＧについて左半分のＳＢＷ０にマッピングされ、そして、第２のＣＢＧについて右半分のＳＢＷ０にマッピングされる。次に、リソース要素は、同様にＳＢＷ１、ＳＢＷ２、ＳＢＷ３にマッピングされ得る。

ＷｉＦｉが伝送前に突然にＳＢＷを占有する場合、ＳＢＷ内のＣＢＧのみが影響を受け、再送される必要がある。図５に示すように、ＷｉＦｉはＳＢＷ１のリソース要素を占有する。これにより、ＳＢＷ１は、ＣＢＧの伝送に使用されることができず、パンクチャされる。よって、ＳＢＷ１内の２つのＣＢＧのみが影響を受け、再送される必要がある。したがって、本開示では、再送は、サブ帯域幅レベルで実行されることができ、より広い帯域幅を有するＮＲシステムは、ＬＡＡ及びＷｉＦｉと良好に共存することができる。

また、ＷｉＦｉの帯域境界がサブ帯域幅の境界に揃わない場合、ＷｉＦｉは１つ以上のサブ帯域幅を占有する場合もある。このような場合には、１つ以上のサブ帯域幅が影響を受けることになる。図６に示すように、ＷｉＦｉ信号は、ＳＢＷ１の一部とＳＢＷ２の一部を占有している。このような場合、ＳＢＷ１及びＳＢＷ２のいずれもＣＢＧの伝送に使用されることができず、かつ、これによって、ＳＢＷ１及びＳＢＷ２における４つのＣＢＧが影響を受け、再送される必要がある。

本開示の一実施形態では、ＷｉＦｉの影響をさらに低減するために、キャリア帯域幅をより狭いサブ帯域幅に分割することができる。図７は、本開示の一実施形態にかかるキャリア帯域幅を分割する場合におけるリソースマッピングの他の例を模式的に示す。図７において、キャリア帯域幅は、図４の４つのサブ帯域幅の代わりに、８つのサブ帯域幅に分割されている。リソース要素は、依然として同様の方法でマッピングされる。すなわち、リソース要素は、まず、第１のＣＢＧの第１半分のビットに対して左半分のＳＢＷ０にマッピングされ、そして、第１のＣＢＧの第２半分のビットに対して右半分のＳＢＷ０にマッピングされる。次に、リソース要素は、同様にＳＢＷ１～ＳＢＷ７にマッピングされることができる。図７において、ＣＢＧは、ちょうど、サブ帯域幅のすべてのリソース要素を使用する。

図８は、本開示の一実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの別の例を模式的に示す。図８に示すように、ＷｉＦｉの帯域境界がサブ帯域幅の境界に揃う場合、２つのサブ帯域幅のみが影響を受け、これは図５の場合と同様である。しかし、ＷｉＦｉの帯域境界がサブ帯域幅の境界に揃わない場合、サブ帯域幅を狭くすることで、さらなる利点が得られる。本開示の一実施形態にかかるキャリア帯域幅分割の場合におけるリソースマッピングの更に別の例を模式的に示す図９を参照する。図９に示すように、ＷｉＦｉの帯域境界は、サブ帯域幅の境界に揃わず、かつ、これによって、ＳＢＷ２、ＳＢＷ３及びＳＢＷ４が占有されている。この場合、３つのＣＢＧのみが影響を受け、再送される必要がある。したがって、図６に示すものと比較して、影響を受けるＣＢＧの数は少ない。

一般的に言えば、帯域幅を多く分割するほどサブ帯域幅が狭くなり、より多くのリソース利用が可能になる。

ＮＲシステムの８０ＭＨｚ帯域では、サブ帯域幅の典型的な数は１、４、及び８であり、ＮＲシステムの１００ＭＨｚ帯域では、サブ帯域幅の典型的な数は１、５、及び１０であり得る。“１”は既存のソリューションとの互換性のために使用され、“４”、“８”及び“５”、“１０”は、デコード遅延とリソース利用率のバランスをとるために使用される。

上述した方法は、ダウンリンクデータ伝送とアップリンクデータ伝送の両方に使用されることができる。以下、例示の目的のために、ダウンリンクデータ伝送とアップリンクデータ伝送の方法について、それぞれ図１０と図１１を用いて説明する。

まず、本開示の一実施形態にかかるダウンリンクデータ伝送のためのリソースマッピングの例示的な方法のフローチャートを模式的に示す図１０を参照する。方法１０００は、ｇＮＢのようなネットワークデバイス又は他の任意の適切なネットワークデバイスで実行されることができる。

図１０に示すように、ステップ１００１において、データ伝送のためのリソース要素は、まず、サブ帯域幅の順にマッピングされ、ここで、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される。ステップ１００２において、複数のサブ帯域幅のそれぞれにおいて、リソース要素は、まず、周波数領域の順にマッピングされ、そして、時間領域の順にマッピングされる。言い換えれば、リソース要素は、まず、サブ帯域幅にサブキャリアが残らなくなるまで、周波数領域の順にマッピングされ、そして、次の時間領域のリソースにマッピングされる。

ステップ１００１及び１００２における動作は、図３におけるステップ３０１及び３０２における動作と実質的に同じであり、したがって、ここで詳しく説明しない。詳細については、図３～図９に関する上記説明を参照することができる。

さらに、ステップ１００３において、ｇＮＢは、さらに、サブ帯域幅のＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ）によってスクランブルされたダウンリンク制御情報においてリソース占有指示を伝送してもよい。

ＷｉＦｉが１つ以上のサブ帯域幅を占有している場合、隣接の帯域が伝送されないと、占有されているサブ帯域幅内でいくつかのエッジＲＢが伝送されない可能性がある。このように、ＤＣＩを送るための物理ダウンリンク制御チャネル（ＰＤＣＣＨ：ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を監視するための上位層パラメータによって提供されるＳＢＷ－ＩＮＴ－ＲＮＴＩは、どのＲＢがデータ伝送に使用されないかを示すために、ＵＥに信号通知することができる。ダウンリンク制御指示（ＤＣＩ：ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｄｉｃａｔｉｏｎ）のうちの１ビットは、スケジュールされたＰＤＣＣＨの伝送後にＳＢＷ－ＩＮＴ－ＲＮＴＩを監視するか否かを端末デバイスに信号通知するために使用され得る。

リソース占有指示は、ＰＤＳＣＨ周波数リソース割当のタイプ０と同じである。リソース占有指示は、ＳＢＷ－ＩＮＴ－ＲＮＴＩによって端末デバイスによって識別される。ＳＢＷ－ＩＮＴ－ＲＮＴＩによってスクランブルされる共通ＤＣＩと、欠落したＣＢＧの再送は、伝送バーストの最大チャネル占有時間（ＭＣＯＴ：Ｍａｘｉｍｕｍ Ｃｈａｎｎｅｌ Ｏｃｃｕｐａｎｃｙ Ｔｉｍｅ）内に発生してもよい。

さらに、制御チャネルは１バーストで伝送されなければならないため、ＰＤＣＣＨの伝送を確保するソリューションが必要である。既存のＬＡＡでは、ＣＣＡに対して、指数ランダムバックオフを有するｃａｔ．４ＬＢＴが規定されている。ＣＣＡを使用するとき、互いに近い帯域では、端末デバイスは、一方の帯域での伝送と他方の帯域でのリスンを同時に行うことができない。この点について、ＣＡの場合に対応するために、以下の２タイプが用意されている。
● タイプＡ：分散型で、各帯域が独立してＬＢＴを行うことができる。ＬＢＴが完了したキャリアのみがチャネルにアクセスできる。早期にＬＢＴが完了したキャリアは、後続のキャリアを待つことができるが、これは実装に依存する。
● タイプＢ：集中型で、プライマリキャリアのみがＬＢＴを行う。完了後、すべてのキャリアに高速ＣＣＡを行い、アイドルキャリアはその時点でチャネルにアクセスできるようになる。

しかしながら、キャリアはより広い帯域を有するため、本開示では、サブ帯域幅レベルでＬＢＴ動作を行うことが提案されている。すなわち、複数のサブ帯域幅を含むサブ帯域幅群をまとめてＬＢＴに用いる。また、ＬＢＴでのＰＤＣＣＨの伝送を確保するために、２タイプの伝送も提案されている。
● タイプＡ：
複数のサブ帯域幅がＬＢＴ用のサブ帯域幅群を形成する。分散型である各サブ帯域幅は、独立してＬＢＴを行うことができる。ＬＢＴが完了したキャリアのみがチャネルにアクセスできる。
各サブ帯域幅は、ＬＡＡタイプＡとしてバックオフタイマーを持っている。各サブ帯域幅群において複数のＣＯＲＥＳＥＴ機会が提供されている。例えば、ＬＢＴ動作で使用される各サブ帯域幅には、制御情報伝送機会が設けられている。ｇＮＢは、これらの機会のいずれか及び／又はすべてにおいて、ＰＤＣＣＨを伝送してもよい。したがって、ＰＤＣＣＨは、サブ帯域幅がＬＢＴに起因してどのようにブロックされても、常に伝送され得る。
ｇＮＢは、その処理能力に基づいて、これらの機会にＰＤＣＣＨを伝送してもよい。ｇＮＢが十分に高い処理速度を有しない場合には、パンクチャされることしかできない。このような場合、ｇＮＢは、サブ帯域幅のそれぞれにＰＤＣＣＨを伝送する必要がある。一方、ｇＮＢが十分に高い処理速度を有する場合、サブ帯域幅のいずれかを選択することができる。このような場合、ＰＤＣＣＨ用のサブ帯域幅を所定のパターンで選択することができる。例えば、ＬＢＴ動作におけるこれらの制御情報伝送機会について、それぞれのサブ帯域幅の周波数の順序に基づいて優先順位を決定することができる。このようにすれば、端末デバイスは、ブラインド検出ではなく、それぞれのサブ帯域幅の周波数に基づく優先順位に従い制御情報を検出することができる。
● タイプＢ：
複数のサブ帯域幅がＬＢＴ用のサブ帯域幅群を形成する。集中型であり、かつプライマリキャリアのみがＬＢＴを行う。完了後、すべてのキャリアに高速ＣＣＡが行われ、このとき、アイドルキャリアがチャネルにアクセスできるようになる。
プライマリ帯域幅群は、ＬＡＡタイプＢとしてバックオフタイマーを持っている。ＰＤＣＣＨの伝送を確保するために、ＣＯＲＥＳＥＴがプライマリサブ帯域幅内に位置しなければならない。すなわち、制御情報伝送スケジューリングに基づいてプライマリサブ帯域幅を選択すべきである。この場合、ＰＤＣＣＨは、常に伝送されるプライマリ帯域幅群内にある。

なお、ＰＤＣＣＨの伝送を確保するための上記のソリューションは、ここで提案されているリソースマッピングを参照して記述されているが、このソリューションは、提案されているリソースマッピングに依存するものではない。実際には、このソリューションは、ＰＤＣＣＨの伝送を確保することを必要とする他の場合にも使用することができる。

アップリンクデータ伝送における動作は、ダウンリンクデータ伝送における動作とは異なる。次に、図１１を参照して、本開示の一実施形態にかかるアップリンクデータ伝送のためのリソースマッピングの例示的な方法を説明する。この方法は、ＵＥのような端末デバイス又は他の任意の適切な端末デバイスで実行されることができる。

図１１に示すように、ステップ１１０１において、データ伝送のためのリソース要素は、まず、サブ帯域幅の順にマッピングされ、ここで、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される。ステップ１１０２において、複数のサブ帯域幅のそれぞれにおいて、リソース要素は、まず、周波数領域の順にマッピングされ、そして、時間領域の順にマッピングされる。言い換えれば、リソース要素は、まず、サブ帯域幅にサブキャリアが残らなくなるまで、周波数領域の順にマッピングされ、そして、次の時間領域のリソースにマッピングされる。

ステップ１１０１及び１１０２における動作は、図３のステップ３０１及び３０２における動作と実質的に同じであり、したがって、ここで詳しく説明しない。詳細については、図３～図９に関する上記説明を参照することができる。

ステップ１１０３にさらに示されるように、ステップ１１０１及び１１０２でのマッピング動作の前に、端末デバイスは、先に、ネットワークデバイスから伝送能力情報を受信してもよい。伝送能力情報は、ネットワークデバイスが、サブ帯域幅に基づくリソースマッピングが実行可能なサブ帯域幅伝送モードをサポートするかどうかを示してもよい。言い換えれば、伝送能力情報は、本開示で提案されているリソースマッピングがネットワークデバイスによってサポートされるかどうかを示すために使用される。通常、ｇＮＢは、伝送の一部が存在しない場合や、誤ってデコードされたソフト情報をバッファリングしていない場合にブラインド検出を行うことができれば、サブ帯域幅伝送モードをサポートすることができる。この伝送能力情報は、例えば無線リソース制御（ＲＲＣ：ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）シグナリングを介して端末デバイスに伝送することができる。

ｇＮＢは、サブ帯域幅伝送モードをサポートすることができる場合、サブ帯域幅伝送モードを有効にするかどうかを決定することもできる。したがって、ステップ１１０４において、端末デバイスは、サブ帯域幅伝送モードが有効であるかどうかを示す伝送モード情報をさらに受信してもよい。例えば、以下の２つのモードを設定することができる。
● モード１：
サブ帯域幅伝送は無効であり、これは、スケジュールされた帯域の一部がＬＢＴのために伝送できない場合、ＵＥはキャリア帯域全体で何も伝送しないことを意味する。スケジューリング検証はｇＮＢによって実装され、これは、ｇＮＢがチャネルアクセス確率を増加させることができることを意味し、例えばＭＣＯＴ内で２５ｕｓの高速ＣＣＡを行う。
● モード２：
サブ帯域幅伝送が有効である。サブ帯域幅に基づくリソースマッピングは、ＣＢＧの一部のみが影響を受けることを確保するために使用される。

モード１又はモード２は、許可ＤＣＩの１ビットによってｇＮＢから信号通知され得る。

このように、ネットワークデバイスがサブ帯域幅伝送モードをサポートすることを示す伝送能力情報と、サブ帯域幅伝送モードが有効であることを示す伝送モード情報に応答して、サブ帯域幅に基づくリソースマッピング（ステップ１１０１及び１１０２の動作）が実行される。

次に、図１２～図１４を参照して、本開示の実施形態にかかるデータ受信の例示的な方法を説明する。

まず、本開示の一実施形態にかかるデータ受信の方法のフローチャートを模式的に示す図１２を参照する。図１２に示すように、ステップ１２０１において、リソース要素において、サブ帯域幅の順にデータを受信し、ここで、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される。上述したように、キャリア帯域幅はさらに複数のサブ帯域幅に分割され、再送はサブ帯域幅に基づいて実行され得る。

その後、ステップ１２０２において、複数のサブ帯域幅のそれぞれにおいて、データは、まず、周波数領域の順に、そして、時間領域の順に、リソース要素で受信される。言い換えれば、データは、まず、サブ帯域幅にサブキャリアが残らなくなるまで、周波数領域の順にリソース要素で受信され、そして、次の時間領域のリソースで受信される。

ＮＲシステムの８０ＭＨｚ帯域では、サブ帯域幅の典型的な数は、１、４、及び８であり、ＮＲシステムの１００ＭＨｚ帯域では、サブ帯域幅の典型的な数は、１、５、及び１０であり得る。“１”は既存のソリューションとの互換性のために使用され、“４”、“８”及び“５”、“１０”はデコード遅延とリソース利用率のバランスをとるために使用される。

ＣＢＧへのキャリア帯域の分割又はマッピングされたリソース要素の詳細については、図３～図１１を参照して上記の説明を参照することができる。

上述のデータ受信方法は、ダウンリンクデータ伝送とアップリンクデータ伝送の両方に使用されることができる。以下、例示の目的のために、ダウンリンクデータ伝送とアップリンクデータ伝送のための方法について、それぞれ図１３と図１４を用いて説明する。

まず、本開示の実施形態にかかるダウンリンクデータを受信する例示的な方法のフローチャートを模式的に示す図１３を参照する。この方法は、ＵＥのような端末デバイス又は他の任意の適切な端末デバイスで実行されることができる。

図１３に示すように、ステップ１３０１において、リソース要素において、サブ帯域幅の順にデータを受信し、ここで、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される。上述したように、キャリア帯域幅はさらに複数のサブ帯域幅に分割され、再送はサブ帯域幅に基づいて実行され得る。

ステップ１３０２において、複数のサブ帯域幅のそれぞれにおいて、データは、まず、周波数領域の順に、そして、時間領域の順に、リソース要素で受信される。言い換えれば、データは、まず、サブ帯域幅にサブキャリアが残らなくなるまで、周波数領域の順にリソース要素で受信され、そして、次の時間領域のリソースで受信される。

ステップ１３０１及び１３０２における動作は、図１２のステップ１２０１及び１２０２における動作と実質的に同じであり、したがって、ここで詳しく説明しない。詳細については、図３～図１２に関する上記説明を参照することができる。

ステップ１３０３において、ｇＮＢは、さらに、サブ帯域幅のＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ）によってスクランブルされたダウンリンク制御情報においてリソース占有指示を受信してもよい。

上述したように、ＷｉＦｉが１つ以上のサブ帯域幅を占有している場合、隣接の帯域が伝送されないと、占有されているサブ帯域幅内でいくつかのエッジＲＢが伝送されない可能性がある。このように、ＤＣＩを送るための物理ダウンリンク制御チャネル（ＰＤＣＣＨ：ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を監視するための上位層パラメータによって提供されるＳＢＷ－ＩＮＴ－ＲＮＴＩは、どのＲＢがデータ伝送に使用されないかを示すために、ＵＥに信号通知することができる。ダウンリンク制御指示（ＤＣＩ：Ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｄｉｃａｔｉｏｎ）のうちの１ビットは、スケジュールされたＰＤＣＣＨの伝送後にＳＢＷ－ＩＮＴ－ＲＮＴＩを監視するか否かを端末デバイスに信号通知するために使用され得る。

リソース占有指示は、ＰＤＳＣＨ周波数リソース割当のタイプ０と同じである。端末デバイスは、ＳＢＷ－ＩＮＴ－ＲＮＴＩによって該端末デバイスのリソース占有指示を識別することができる。ＳＢＷ－ＩＮＴ－ＲＮＴＩによってスクランブルされた共通ＤＣＩと、欠落したＣＢＧの再送は、伝送バーストの最大チャネル占有時間（ＭＣＯＴ：Ｍａｘｉｍｕｍ Ｃｈａｎｎｅｌ Ｏｃｃｕｐａｎｃｙ Ｔｉｍｅ）内に発生してもよい。

さらに、ステップ１３０４において、そのようなリソース占有指示を受信したことに応答して、端末デバイスは、ストレージにおける対応するデータであって成功にデコードされなかったデータを削除してもよい。ＨＡＲＱとは異なり、サブ帯域幅が突然にＷｉＦｉによって占有されている場合、伝送信号を調整したり、レートマッチしたりする時間がなく、その結果、サブ帯域幅はパンクチャされることになる。このような場合には、ＣＢＧは伝送されないので、対応する成功にデコードされなかったデータを格納しても意味がない。したがって、これらのデータはストレージから削除されることができる。

また、制御チャネルは１バーストで伝送されなければならないため、ＰＤＣＣＨの伝送を確保するソリューションが必要である。そこで、上述したタイプＡでは、ＬＢＴ動作におけるこれらの制御情報伝送機会について、それぞれのサブ帯域幅の周波数の順序に基づいて優先順位を決定すれば、端末デバイスは、それぞれのサブ帯域幅の周波数に基づく優先順位に従って、制御情報を検出することができる。また、タイプＡの他の場合やタイプＢでは、既存のＬＡＡと同様に、端末デバイスはＰＤＣＣＨを検出してもよい。

アップリンクデータ受信時の動作は、ダウンリンクデータ伝送時の動作とは異なる。次に、図１４を参照して、本開示の一実施形態にかかるアップリンクデータ伝送のためのリソースマッピングの例示的な方法を説明する。この方法は、ＢＳのようなネットワークデバイス、又は他の任意の適切なネットワークデバイスで実行されることができる。

図１４に示すように、ステップ１４０１において、リソース要素において、サブ帯域幅の順にデータを受信し、ここで、データ伝送のためのキャリア周波数帯域が複数のサブ帯域幅に分割される。上述したように、キャリア帯域幅はさらに複数のサブ帯域幅に分割され、再送はサブ帯域幅に基づいて実行され得る。

ステップ１４０２において、複数のサブ帯域幅のそれぞれにおいて、データは、まず、周波数領域の順に、そして、時間領域の順に、リソース要素で受信される。言い換えれば、データは、まず、サブ帯域幅にサブキャリアが残らなくなるまで、周波数領域の順にリソース要素で受信され、そして、次の時間領域のリソースで受信される。

ステップ１４０１及び１４０２における動作は、図１２のステップ１２０１及び１２０２における動作と実質的に同じであり、したがって、ここで詳しく説明しない。詳細については、図３～図１２に関する上記説明を参照することができる。

ステップ１４０３にさらに示されるように、ステップ１４０１及び１４０２においてサブ帯域幅に基づくアップリンクデータを受信する前に、ネットワークデバイスは、先に伝送能力情報を端末デバイスに伝送してもよい。伝送能力情報は、ネットワークデバイスが、サブ帯域幅に基づくリソースマッピングが実行可能なサブ帯域幅伝送モードをサポートするかどうかを示してもよい。言い換えれば、伝送能力情報は、本開示で提案されているリソースマッピングがネットワークデバイスによってサポートされるかどうかを示すために使用される。通常、ｇＮＢは、伝送の一部が存在しない場合や、誤ってデコードされたソフト情報をバッファリングしていない場合にブラインド検出を行うことができれば、サブ帯域幅伝送モードをサポートすることができる。この伝送能力情報は、例えば無線リソース制御（ＲＲＣ：ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）シグナリングを介して端末デバイスに伝送することができる。

ｇＮＢは、サブ帯域幅伝送モードをサポートすることができる場合、サブ帯域幅伝送モードを有効にするかどうかを決定することもできる。したがって、ステップ１４０４において、ネットワークデバイスは、サブ帯域幅伝送モードが有効であるかどうかを示す伝送モード情報をさらに伝送してもよい。上述したように、モード１は、サブ帯域幅伝送が無効であるモードを示す。モード２は、サブ帯域幅伝送が有効であるモードを示す。モード１又はモード２は、許可ＤＣＩのうちの１ビットによってｇＮＢから信号通知され得る。

このように、ネットワークデバイスがサブ帯域幅伝送モードをサポートすることを示す伝送能力情報と、サブ帯域幅伝送モードが有効であることを示す伝送モード情報に応答して、サブ帯域幅に基づくデータ受信（ステップ１４０１、１４０２の動作）が実行される。

ここまで、データ受信の実施形態は、図１２～図１４を参照して簡単に説明される。しかし、受信デバイスでの動作は伝送デバイスでの動作に対応していることが理解され、したがって、動作のいくつかの詳細については、図３～図１１に関する上記説明を参照することができる。

以上、キャリア帯域が複数のサブ帯域幅に分割され、リソース要素が、まず、サブ帯域幅の順にマッピングされ、それぞれのサブ帯域幅において、リソース要素が、まず、周波数領域にマッピングされ、そして、時間領域にマッピングされることが記載されている。しかし、サブ帯域幅のそれぞれにおいて、リソース要素を、まず、時間領域に、そして、周波数領域にマッピングすることも可能であることが理解されたい。

図１５は、本開示の実施形態にかかる無線通信システムにおけるダウンリンクデータ伝送のためのリソースマッピング用の装置のブロック図をさらに模式的に示す。装置１５００は、ネットワークデバイス、例えばｅＮＢ、又は他の同様のネットワークデバイスで実装され得る。

図１５に示すように、装置１５００は、リソースマッピングモジュール１５０１を備えてもよい。データ伝送のためのキャリア周波数帯域は、複数のサブ帯域幅に分割される。リソースマッピングモジュール１５０１は、データ伝送のためのリソース要素をサブ帯域幅の順にマッピングし、複数のサブ帯域幅のそれぞれにおいて、リソース要素を、まず、周波数領域の順に、そして、時間領域の順にマッピングするように構成されてもよい。

装置１５００は、指示伝送モジュール１５０２をさらに備えてもよい。指示伝送モジュール１５０２は、サブ帯域幅のＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ）によってスクランブルされたダウンリンク制御情報においてリソース占有指示を伝送するように構成されてもよい。リソース占有指示は、どのリソースが占有されているかを端末デバイスに通知し、伝送される。

本開示の一実施形態では、ＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）動作は、サブ帯域幅レベルで実行され、ＬＢＴ動作で使用される各サブ帯域幅は、ＰＤＣＣＨの伝送を確保するように、制御情報の伝送機会を有してもよい。

本開示の他の実施形態では、ＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）動作がサブ帯域幅レベルで実行され、制御情報伝送スケジューリングに基づいてプライマリサブ帯域幅が選択される。このようにすることで、ＰＤＣＣＨの伝送を確保することも可能となる。

図１６は、本開示の一実施形態にかかる無線通信システムにおけるアップリンクデータ伝送のためのリソースマッピング用の装置のブロック図を模式的に示す。装置１６００は、例えばＵＥなどの端末デバイスで実装されてもよい。

図１６に示すように、装置１６００は、リソースマッピングモジュール１６０１を備えてもよい。データ伝送のためのキャリア周波数帯域は、複数のサブ帯域幅に分割される。リソースマッピングモジュール１６０１は、データ伝送のためのリソース要素をサブ帯域幅の順にマッピングし、複数のサブ帯域幅のそれぞれにおいて、リソース要素を、まず、周波数領域の順にマッピングし、そして、時間領域の順にマッピングするように構成されてもよい。

本開示の一実施形態では、装置１６００は、能力受信モジュール１６０２及びモード受信モジュール１６０３をさらに備えてもよい。能力受信モジュール１６０２は、ネットワークデバイスが、サブ帯域幅に基づくリソースマッピングが実行可能なサブ帯域幅伝送モードをサポートするかどうかを示す伝送能力情報を受信するように構成されてもよい。モード受信モジュール１６０３は、サブ帯域幅伝送モードが有効であるかどうかを示す伝送モード情報を受信するように構成されてもよい。リソースマッピングモジュール１６０１は、ネットワークデバイスがサブ帯域幅伝送モードをサポートすることを示す伝送能力情報と、サブ帯域幅伝送モードが有効であることを示す伝送モード情報とに応答して、リソース要素をマッピングするように構成されている。

伝送能力情報は、ＲＲＣシグナリングで受信されてもよい。伝送モード情報は、ダウンリンク制御指示で受信されてもよい。

図１７は、本開示の一実施形態にかかる無線通信システムにおけるダウンリンクデータ受信のための装置のブロック図を模式的に示す。装置１７００は、例えばＵＥなどの端末デバイスで実装されてもよい。

図１７に示すように、装置１７００は、データ受信モジュール１７０１を備えてもよい。データ伝送のためのキャリア周波数帯域は、複数のサブ帯域幅に分割される。データ受信モジュール１７０１は、リソース要素において、サブ帯域幅の順にデータを受信し、複数のサブ帯域幅のそれぞれにおいて、リソース要素において、まず、周波数領域の順に、そして、時間領域の順にデータを受信するように構成されてもよい。

本開示の一実施形態では、装置１７００は、指示受信モジュール１７０２及びデータ削除モジュール１７０３をさらに備えてもよい。指示受信モジュール１７０２は、サブ帯域幅のＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ）によってスクランブルされたダウンリンク制御情報においてリソース占有指示を受信するように構成されてもよい。データ削除モジュール１７０３は、リソース占有指示を受信したことに応答して、ストレージにおける対応するデータであって成功にデコードされなかったデータを削除するように構成されてもよい。

図１８は、本開示の一実施形態にかかる無線通信システムにおけるアップリンクデータ受信のための装置のブロック図を模式的に示す。装置１８００は、例えばｇＮＢなどのネットワークデバイスで実装されてもよい。

図１８に示すように、装置１８００は、データ受信モジュール１８０１を備えてもよい。データ伝送のためのキャリア周波数帯域は、複数のサブ帯域幅に分割される。データ受信モジュール１８０１は、リソース要素において、サブ帯域幅の順にデータを受信し、複数のサブ帯域幅のそれぞれにおいて、リソース要素において、まず、周波数領域の順に、そして、時間領域の順にデータを受信するように構成されてもよい。

本開示の一実施形態では、装置１８００は、能力伝送モジュール１８０２及びモード伝送モジュール１８０３をさらに備えてもよい。能力伝送モジュール１８０２は、ネットワークデバイスがサブ帯域幅に基づくリソースマッピングが実行可能なサブ帯域幅伝送モードをサポートするかどうかを示す伝送能力情報を伝送するように構成されてもよい。モード伝送モジュール１８０３は、サブ帯域幅伝送モードが有効であるかどうかを示す伝送モード情報を伝送するように構成されてもよい。データ受信モジュール１８０１は、ネットワークデバイスがサブ帯域幅伝送モードをサポートすることを示す伝送能力情報と、サブ帯域幅伝送モードが有効であることを示す伝送モード情報とに応答して、サブ帯域幅に基づいてリソース要素でデータを受信するように構成されてもよい。

伝送能力情報は、ＲＲＣシグナリングで受信されてもよい。伝送モード情報は、ダウンリンク制御指示で受信されてもよい。

ここまで、装置１５００～１８００を図１５～図１８を参照して簡単に説明する。装置１５００～１８００は、図３～図１４を参照して説明した機能を実現するように構成されてもよいことに留意されたい。したがって、これらの装置におけるモジュールの動作の詳細については、図３～図１４を参照する方法のそれぞれのステップに関して行われたそれらの記述を参照することができる。

なお、装置１５００～１８００の構成要素は、ハードウェア、ソフトウェア、ファームウェア、及び／又はそれらの任意の組み合わせで具現化されてもよい。例えば、装置１５００～１８００の構成要素は、それぞれ、回路、プロセッサ、又は任意の他の適切な選択肢のデバイスによって具現化されてもよい。

前述の例は例示のためにのみ示されており限定されるものではなく、本開示はそれに限定されないことが、当業者にとって理解される。本明細書で提供される教示から多くの変形、追加、削除及び修正を容易に想定することができ、これらの変形、追加、削除及び修正はすべて本開示の保護範囲に含まれる。

さらに、本開示のいくつかの実施形態では、装置１５００～１８００は、少なくとも１つのプロセッサを備えてもよい。本開示の実施形態と共に使用するために適した少なくとも１つのプロセッサは、一例として、既に知られているかまたは将来開発される汎用及び専用プロセッサの両方を含んでもよい。装置１５００～１８００は、少なくとも１つのメモリをさらに備えてもよい。少なくとも１つのメモリは、例えば、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、及びフラッシュメモリデバイスどの半導体メモリデバイスを含んでもよい。少なくとも１つのメモリは、コンピュータ実行可能命令のプログラムを格納するために使用されてもよい。プログラムは、ハイレベル及び／またはローレベルの適合可能または解釈可能な任意のプログラミング言語で記述できる。実施形態によれば、コンピュータ実行可能命令は、少なくとも１つのプロセッサにより、装置１５００～１８００に、少なくとも図３～図１４を参照して説明した方法にかかる動作を実行させるように構成されることができる。

図１９は、本明細書で説明される、ｇＮＢのようなネットワークノードとして具現化され、又はそれが備えられる装置１９１０と、ＵＥのような端末デバイスとして具現化され、又はそれが備えられる装置１９２０の簡略ブロック図を模式的に示す。

装置１９１０は、データプロセッサ（ＤＰ：ｄａｔａ ｐｒｏｃｅｓｓｏｒ）などの少なくとも１つのプロセッサ１９１１と、プロセッサ１９１１に接続される少なくとも１つのメモリ（ＭＥＭ：ｍｅｍｏｒｙ）１９１２とを備える。装置１９１０は、プロセッサ１９１１に接続される伝送機ＴＸ及び受信機ＲＸ１９１３をさらに備えてもよく、伝送機ＴＸ及び受信機ＲＸ１９１３は装置１９２０に通信可能に接続するように動作できる。ＭＥＭ１９１２は、プログラム（ＰＲＯＧ：ｐｒｏｇｒａｍ）１９１４を格納する。ＰＲＯＧ１９１４は、関連するプロセッサ１９１１上で実行されると、装置１９１０が本開示の実施形態、例えば方法３００、１０００、１２００、１４００に従って動作することをイネーブルする命令を含んでもよい。少なくとも１つのプロセッサ１９１１と少なくとも１つのＭＥＭ１９１２の組み合わせは、本開示の様々な実施形態を実施するのに適合された処理手段１９１５を形成することができる。

装置１９２０は、ＤＰなどの少なくとも１つのプロセッサ１９１１と、プロセッサ１９１１に接続される少なくとも１つのＭＥＭ１９２２とを備える。装置１９２０は、プロセッサ１９２１に接続される適切なＴＸ／ＲＸ１９２３をさらに備えてもよく、ＴＸ／ＲＸ１９２３は装置１９１０と無線通信するように動作できる。ＭＥＭ１９２２は、ＰＲＯＧ１９２４を格納する。ＰＲＯＧ１９２４は、関連するプロセッサ１９２１上で実行されると、装置１９２０が本開示の実施形態に従って動作し、例えば、方法３００、１１００、１２００、１３００を実行することをイネーブルする命令を含んでもよい。少なくとも１つのプロセッサ１９２１と少なくとも１つのＭＥＭ１９２２との組み合わせは、本開示の様々な実施形態を実施するのに適合された処理手段１９２５を形成することができる。

本開示の様々な実施形態は、プロセッサ１９１１、１９２１のうちの１つ以上によって実行可能なコンピュータプログラム、ソフトウェア、ファームウェア、ハードウェア、又はそれらの組み合わせによって実施されてもよい。

ＭＥＭ１９１２及び１９２２は、ローカルの技術的環境に適した任意のタイプのものでもよく、非限定的な例として、半導体ベースのメモリデバイス、磁気メモリデバイス及びシステム、光学メモリデバイス及びシステム、固定メモリ及びリムーバブルメモリなど、任意の適切なデータ記憶技術を使用して実施されてもよい。

プロセッサ１９１１及び１９２１は、ローカルの技術的環境に適した任意のタイプでもよく、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）及びマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つ以上を含んでもよい。

さらに、本開示は、上述のようなコンピュータプログラムを含むキャリアも提供してもよく、ここで、キャリアは、電子信号、光信号、無線信号、又はコンピュータ可読記憶媒体のうちの１つである。コンピュータ読み取り可能な記憶媒体は、例えば、光学コンパクトディスク、又はＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、フラッシュメモリ、磁気テープ、ＣＤ－ＲＯＭ、ＤＶＤ、Ｂｌｕｅ－ｒａｙディスクなどのような電子メモリデバイスでもよい。

本明細書で説明された技術は、様々な手段で実施されてもよい。そのため、実施形態で説明された対応する装置の１つ又は複数の機能を実施する装置は、従来技術の手段を備えるだけでなく、実施形態で説明された対応する装置の１つまたは複数の機能を実施するための手段を備え、別々の機能ごとに別々の手段を備えてもよいし、２つ以上の機能を実施するように設定される手段を備えてもよい。例えば、これらの技術は、ハードウェア（１つ以上の装置）、ファームウェア（１つ以上の装置）、ソフトウェア（１つ以上のモジュール）、またはそれらの組み合わせで実施されてもよい。ファームウェアまたはソフトウェアの場合、本明細書で説明された機能を実行するモジュール（例えば、手順、機能など）を介して実施されてもよい。

本明細書における例示的な実施形態は、上記のように、方法及び装置のブロック図及びフローチャート図を参照して説明された。ブロック図及びフローチャート図の各ブロック、並びにブロック図及びフローチャート図におけるブロックの組み合わせは、それぞれ、コンピュータプログラム命令を含む様々な手段によって実施できることが理解される。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、または機械を製造するための他のプログラマブルデータ処理装置にロードされ、コンピュータまたは他のプログラマブルデータ処理装置で実行される命令が、フローチャートのブロックで特定された機能を実行するための手段を形成するようにしてもよい。

本明細書は多くの具体的な実装の詳細を含むが、これらはいかなる実施または特許請求の範囲を限定するものではなく、むしろ特定の実装形態の特定の実施形態に特有の機能の説明として解釈されるべきである。本明細書において別々の実施形態の文脈で説明された特定の特徴は、単一の実施形態において組み合わせて実施されることもできる。逆に、単一の実施形態の文脈で説明された様々な特徴は、別々にまたは任意の適切なサブコンビネーションで複数の実施形態で実施されることもできる。さらに、特徴が特定の組み合わせで動作するものとして上記のように説明され、当初はそのように特許請求されていても、請求された組み合わせからの１つ以上の特徴は、場合によって、その組み合わせから除外することができ、請求された組み合わせはサブコンビネーションまたはサブコンビネーションのバリエーションに向けられてもよい。

技術の進歩につれて、本発明の概念を様々な方法で実施できることは、当業者にとって明らかである。上記の実施形態は、本開示を限定するものではなく説明するために提供され、当業者が容易に理解するように、本開示の意図及び範囲から逸脱することなく修正及び変更することができる。そのような修正及び変更は、本開示の範囲及び添付の特許請求の範囲内に含まれると見なされる。本開示の保護範囲は、添付の特許請求の範囲によって定義される。

Claims (2)

1. 端末デバイスにより実行される方法であって、
   ネットワークデバイスから、ダウンリンクリソースのサブ帯域幅パターンに基づいて、ダウンリンク伝送のためのキャリアの複数のサブ帯域幅の少なくとも１つでＰＤＣＣＨを受信することと、
   アップリンク伝送のためのキャリアの複数のチャネルの少なくとも１つでＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）を実行することと、を含み、
   前記サブ帯域幅パターンは、複数のＣＯＲＥＳＥＴ機会に関連付けられ、前記サブ帯域幅パターンは、どのサブ帯域幅がＰＤＣＣＨ検出のためのものであるかを示し、
   前記端末デバイスは、前記アップリンク伝送のための前記キャリアの前記複数のチャネルの１つにアクセスできない場合には、前記アップリンク伝送のための前記キャリア内の前記複数のチャネルでの伝送を行わない、方法。
2. 端末デバイスであって、
   プロセッサと、
   前記プロセッサに結合され、命令を格納するメモリと、を備え、
   前記命令は、前記プロセッサによって実行されると、
   ネットワークデバイスから、ダウンリンクリソースのサブ帯域幅パターンに基づいて、ダウンリンク伝送のためのキャリアの複数のサブ帯域幅の少なくとも１つでＰＤＣＣＨを受信することと、
   アップリンク伝送のためのキャリアの複数のチャネルの少なくとも１つでＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）を実行することと、を前記端末デバイスに実行させ、
   前記サブ帯域幅パターンは、複数のＣＯＲＥＳＥＴ機会に関連付けられ、前記サブ帯域幅パターンは、どのサブ帯域幅がＰＤＣＣＨ検出のためのものであるかを示し、
   前記端末デバイスは、前記アップリンク伝送のための前記キャリアの前記複数のチャネルの１つにアクセスできない場合には、前記アップリンク伝送のための前記キャリア内の前記複数のチャネルでの伝送を行わない、端末デバイス。

Images