本開示は、D2D通信における、グループキャスト通信とユニキャスト通信との間の移行を実現するために、上記の観点からなされる。
本開示の第1の態様において、無線通信方法が提供され、該方法は、第1のユーザ機器(UE)と第2のUEとが、グループキャストの通信タイプにおかれるべきときに、第1のUEから第2のUEに第1のダウンリンク制御情報(DCI)を送信するステップであって、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができ、第1のDCIに続く第1の潜在的な物理ダウンリンク共有チャネル(PDSCH)が、グループIDでスクランブルをかけられる、第1のDCIを送信するステップと、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第1のUEから第2のUEに第2のDCIを送信するステップであって、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、第2のUEのUE IDでスクランブルをかけられる、第2のDCIを送信するステップと、を含み、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれ第2のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。
本開示の第2の態様において、無線通信方法が提供され、該方法は、第1のユーザ機器(UE)から第2のUEに、第1のダウンリンク制御情報(DCI)を送信するステップと、第1のUEから第2のUEに、第2のDCIを送信するステップと、を含み、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかどうか、を示し、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示し、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、第2のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
本開示の第3の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、送信ユニットを備え、送信ユニットは、UEと第2のUEとが、グループキャストの通信タイプにおかれるべきときに、第2のUEに第1のダウンリンク制御情報(DCI)を送信するように構成され、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができ、第1のDCIに続く第1の潜在的な物理ダウンリンク共有チャネル(PDSCH)が、グループIDでスクランブルをかけられ、また、送信ユニットは、UEと第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第2のUEに第2のDCIを送信するように構成され、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、第2のUEのUE IDでスクランブルをかけられ、UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれ第2のUEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。
本開示の第4の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、第1のダウンリンク制御情報(DCI)および第2のDCIを第2のUEに送信するように構成される送信ユニットを備え、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、UEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかどうか、を示し、UEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示し、UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、第2のUEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
本開示の第5の態様において、無線通信方法が提供され、該方法は、第1のユーザ機器(UE)と第2のUEとが、グループキャストの通信タイプにおかれるべきときに、第1のUEが、第2のUEから送信される第1のダウンリンク制御情報(DCI)を受信するステップであって、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができ、第1のDCIに続く第1の潜在的な物理ダウンリンク共有チャネル(PDSCH)が、グループIDでスクランブルをかけられる、第1のDCIを受信するステップと、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第1のUEが、第2のUEから送信される第2のDCIを受信するステップであって、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、第1のUEのUE IDでスクランブルをかけられる、第2のDCIを受信するステップと、を含み、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれ第1のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。
本開示の第6の態様において、無線通信方法が提供され、該方法は、第1の(UE)が、第2のUEから送信される第1のダウンリンク制御情報(DCI)を受信するステップと、第1のUEが、第2のUEから送信される第2のDCIを受信するステップと、を含み、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかどうか、を示し、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示し、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、第1のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
本開示の第7の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、受信ユニットを備え、受信ユニットは、UEと第2のUEとが、グループキャストの通信タイプにおかれているときに、第2のUEから送信される第1のダウンリンク制御情報(DCI)を受信するように構成され、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができ、第1のDCIに続く第1の潜在的な物理ダウンリンク共有チャネル(PDSCH)が、グループIDでスクランブルをかけられ、また、受信ユニットは、UEと第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第2のUEから送信される第2のDCIを受信するように構成され、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、UEのUE IDでスクランブルをかけられ、UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれUEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。
本開示の第8の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、第2のUEから送信される第1のダウンリンク制御情報(DCI)および第2のDCIを受信するように構成される受信ユニットを備え、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、UEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかどうか、を示し、UEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示し、UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、UEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
加えて、本開示は、D2D通信においてリソーススケジューリングを実現するためになされる。
本開示の第9の態様において、リソース割振りのための無線通信方法が提供され、該方法は、第1のユーザ機器(UE)から第2のUEに、リソース割振りのためのダウンリンク制御情報(DCI)を送信するステップを含み、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
第9の態様では、好ましくは、リソース割振りパターンおよび/または送信寿命が、物理リソースブロック(PRB)インデックスおよび/またはDCIの数、および/または、制御チャネル要素(CCE)インデックスおよび/またはDCIの数、によって暗黙に示されてよい。
第9の態様では、好ましくは、リソース割振りパターンおよび/または送信寿命が、物理リソースブロック(PRB)インデックスおよび/または第2のUEに割り振られた物理ダウンリンク共有チャネル(PDSCH)の数、によって暗黙に示されてよい。
第9の態様では、好ましくは、リソース割振りパターンおよび/または送信寿命が、物理リソースブロック(PRB)インデックスおよび/または第2のUEに割り振られた物理ダウンリンク共有チャネル(PDSCH)と、DCIとの間の数の差、によって暗黙に示されてよい。
第9の態様では、好ましくは、DCIが、3GPP Release8〜11で定義されたDCIフォーマットを使用することができるが、但し、3GPP Release8−11で定義されたDCIフォーマットの数ビットを使用して、DCIにリソース割振りパターンおよび/または送信寿命を示すことを除く。
第9の態様では、好ましくは、リソース割振りパターンには、周波数ホッピングパターン、送信時間(または送信間隔)、および/または送信継続時間、を含むことができる。
第9の態様では、好ましくは、リソース割振りパターンをDCIに示すための情報が、リソース割振りパターンインデックスを示し、このインデックスによって、無線リソース制御(RRC)層で構成されるリソース割振りパターンセットから、リソース割振りパターンを選択できるように、リソース割振りパターンを、示すことができる。
第9の態様では、好ましくは、リソース割振りの型を、DCIの数フィールドによって共同で、示すこともできる。
本開示の第10の態様において、リソース割振りのための無線通信方法が提供され、該方法は、第1のユーザ機器(UE)から第2のUEに、第1のリソース割振り型のための第1のダウンリンク制御情報(DCI)、または、第2のリソース割振り型のための第2のDCIのいずれかを送信するステップを含み、第1のDCIが、第1の無線ネットワーク一時的識別子(RNTI)でスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられる。
本開示の第11の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、UEから第2のUEに、リソース割振りのためのダウンリンク制御情報(DCI)を送信するように構成される送信ユニットを備え、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
本開示の第12の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、第1のリソース割振り型のための第1のダウンリンク制御情報(DCI)、または、第2のリソース割振り型のための第2のDCIのいずれかを、第2のUEに送信するように構成される送信ユニットを備え、第1のDCIが、第1の無線ネットワーク一時的識別子(RNTI)でスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられる。
本開示の第13の態様において、リソース割振りのための無線通信方法が提供され、該方法は、第1のユーザ機器(UE)が、第2のUEから送信されるリソース割振りのためのダウンリンク制御情報(DCI)を受信するステップを含み、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
本開示の第14の態様において、リソース割振りのための無線通信方法が提供され、該方法は、第1のユーザ機器(UE)が、第2のUEから送信される、第1のリソース割振り型のための第1のダウンリンク制御情報(DCI)、または、第2のリソース割振り型のための第2のDCI、のいずれかを受信するステップを含み、第1のDCIが、第1の無線ネットワーク一時的識別子(RNTI)でスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられる。
本開示の第15の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、第2のUEから送信されるリソース割振りのためのダウンリンク制御情報(DCI)を受信するように構成される受信ユニットを備え、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
本開示の第16の態様において、無線通信のためのユーザ機器(UE)が提供され、該装置は、第2のUEから送信される、第1のリソース割振り型のための第1のダウンリンク制御情報(DCI)、または、第2のリソース割振り型のための第2のDCIのいずれかを、受信するように構成される受信ユニットを備え、第1のDCIが、第1の無線ネットワーク一時的識別子(RNTI)でスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられる。
第9の態様のための好ましい解決方法は、第10〜第16の態様にも適用されることに留意されたい。
上記の記載は概要であり、したがって、必然的に、単純化、一般化、および、詳細の省略、を含む。本明細書に記載される装置および/またはプロセスおよび/または他の主題の、他の態様、特徴、および利点が、本明細書に記載される教示において明らかになるであろう。概要は、発明を実施するための形態において以下でさらに説明される概念を、選択して簡略化された形式で紹介するために提供される。本概要では、請求される主題の重要な特徴または主要な特徴を特定することは意図されず、請求される主題の範囲を決定する支援として使用されることも意図されない。
本開示の上述の特徴および他の特徴については、以下の説明および添付の特許請求の範囲から、添付の図面と併せて理解することにより、完全に明らかとなるであろう。これらの図面が、本開示に係るいくつかの実施形態のみを示し、したがって、本開示の範囲を制限するものとみなされないという理解の上で、本開示が、添付の図面の使用を通して、追加の特定性および詳細と共に説明される。
以下の詳細な説明において、添付の図面が参照され、添付の図面は該説明の一部を成す。図面において、文脈において特に指定されない限り、同様の符号が典型的には、同様の構成要素を特定する。本開示の態様が、多種多様な異なる構成で、配置、置き換え、組み合わせ、および設計されてよく、その構成の全てが、明示的に企図され、かつ、本開示の一部を形成することは容易に理解されるであろう。
(実施形態1)
D2D通信では、ユニキャスト通信は、1つのUEが別のUEと通信することを意味し、グループキャスト通信は、1つのUEが複数の他のUEと通信することを意味する。後者は、eNBとの通常の無線通信における、eNBブロードキャストのシステム情報に類似している。本明細書においてグループキャストは、ブロードキャストおよびマルチキャストを含むこともでき、グループキャストは、1つのUEが、グループキャストプロトコルを使用して、複数の潜在的な他のUEに、情報をブロードキャストすることを意味するだけであり、情報を受信している複数の他のUEが実際に存在しなければならないことを意味するのではないことに留意されたい。図2は、D2D通信におけるグループキャスト通信およびユニキャスト通信の一例を示す。グループキャスト通信では、1つのUEが、通常の無線ネットワークにおいてeNBとして機能するマスタUEとして構成され、複数の他のUEが、マスタUEとの通信を同時に行うことができるスレーブUEとして働く。一方、ユニキャスト通信では、2つのUEが、ピアツーピアで互いに通信する。
D2D通信をさらに効率よく行うために、2つの通信タイプ(ユニキャストおよびグループキャスト)は、D2D通信において頻繁に切り替わる必要があり得る。図3は、グループキャスト通信をユニキャストに移行させる必要があり得る、シナリオを示す。図3の左側では、マスタUEが、4つのスレーブUEにトラフィックをブロードキャスト(グループキャスト)する。この場合、多くのスレーブUEが同じグループに存在しており、グループキャスト通信の効率が高いため、グループキャストの通信タイプが好ましい可能性がある。しかし、いくつかのUEがグループキャストのグループを去り、少しのスレーブUEだけがグループに残っているときは、グループキャストの利点が小さくなる。ユニキャストは、この点ではより好ましいことがある。図3の右側では、2つのスレーブUEだけがグループに残っており、通信タイプが、ユニキャストに変更されることが好ましい可能性がある。図4は、ユニキャスト通信を、グループキャストに移行させる必要があり得るシナリオを示す。図4の左側では、2つのUEだけが通信しているので、ユニキャスト通信が示される。しかし、新しいUEが加わると、図4の右側に示すように、グループキャストがより好ましくなり得る。現実のD2Dのシナリオでは、状況がもっと複雑である可能性があり、各UEが、1つのUEとのユニキャストを行い、別のグループに対してマスタUEとして動作することができることに留意されたい。サービスおよびメンバが頻繁に変更されると、ユニキャストとグループキャストとの間の移行も、頻繁になり得る。したがって、グループキャストとユニキャストとの間の速い、柔軟性のある移行をいかに実現するかは、D2D通信には重要な問題となる。
本開示の実施形態1では、UEが、ユニキャストまたはグループキャストのいずれかを介して柔軟に通信することができ、ユニキャストとグループキャストとの間を高速で移行することができる、無線通信方法が提供される。詳細には、図5は、本開示の実施形態1による、無線通信方法500のフローチャートを示す。通信方法500は、第1のUE(マスタUE)と第2のUE(スレーブUE)とが、グループキャストの通信タイプにおかれるべきときに、第1のUEから第2のUEに第1のダウンリンク制御情報(DCI)を送信するステップ501であって、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができ、第1のDCIに続く第1の潜在的な物理ダウンリンク共有チャネル(PDSCH)が、グループIDでスクランブルをかけられる、第1のDCIを送信するステップ501と、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第1のUEから第2のUEに第2のDCIを送信するステップ502であって、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、第2のUEのUE IDでスクランブルをかけられる、第2のDCIを送信するステップ502と、を含む。第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれ第2のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。ステップ501およびステップ502は、定義された条件に従って、選択的に実行されることに留意されたい。
上記の通信方法では、2つのDCIが定義され、そのうちの第1のDCIが、グループキャストに使用され、第2のDCIがユニキャストに使用される。1つのUE(第1のUEまたはマスタUE)が、他のUE(第2のUEまたはスレーブUE)と、グループキャスト様式で通信しようとするとき、すなわち、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれるべきときに、マスタUEが第1のDCI(グループキャストDCI)をスレーブUEに送信する。グループキャストDCIは、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができる(インジケーション様式については後述する)。スレーブUEがグループキャストDCIを受信すると、スレーブUEは、また、DCIがグループキャストDCIであることを、通信タイプのインジケーションを介して認識し、グループキャストDCIに続く、潜在的なPDSCHを復号するためのグループIDを取得する。潜在的なPDSCHとは、グループIDが上記のグループIDである、UEグループのUEに関するデータを搬送するPDSCH(存在する場合には)である。このようにして、第1のUEと第2のUEとは、グループキャスト通信におかれるべく移行または継続することができ、第1のUEは、グループキャストDCIが受信された後に、データを第2のUEを含むUEグループにブロードキャストすることができる。
第1のUEが、第1のDCIを送信すると、第1のUEおよび第2のUEが、2つの異なる通信状態、すなわち、ユニキャスト状態またはグループキャスト状態、におかれ得る。第1のUEおよび第2のUEが、ユニキャスト状態(すなわち、ユニキャストの通信タイプ)におかれている場合、第1のUEが第1のDCIを送信すると、第1のDCIは、第2のUEのUE IDでスクランブルをかけられ、第2のUEが、第2のUEには既知であるUE IDを用いて、第1のDCIを復号できるようにされる。第2のUEが第1のDCIを受信して、その第1のDCIをそのUE IDを用いて復号すると、第2のUEは、第1のUEが、ブロードキャストを介して第2のUEと通信すべきであることを認識し、グループIDを取得する。そして、第2のUEは、グループIDを使用して、グループIDでスクランブルがかけられた潜在的なPDSCHを復号することができる。第2のUEが、通信タイプを認識し、グループIDを取得した後、第1のUEおよび第2のUEは、グループキャスト状態(すなわち、グループキャストの通信タイプ)になり、第1のUEが、グループIDを使用してDCIにスクランブルをかけ、これを次回送信することができる。対照的に、第1のUEおよび第2のUEが、グループキャスト状態(すなわち、グループキャストの通信タイプ)におかれている場合、第1のUEが第1のDCIを送信すると、第1のDCIは、グループキャストのUEグループのグループIDでスクランブルをかけられ、第2のUEが、第2のUEには既知であるグループIDを用いて、第1のDCIを復号できるようにする(グループIDは、前回のグループキャストDCIを介して、第2のUEに送信済みである)。ユニキャスト状態におかれている第1のUEおよび第2のUEには、第2のUEが、第1のUEとグループキャストUEグループを形成していない、いずれの状況も含まれることに留意されたい。例えば、第1のUEおよび第2のUEが、最初に通信を開始するとき、または、第1のUEが、グループキャストUEグループから、例えば、後述する第2のDCIによって、解放された後、第1のUEおよび第2のUEは、ユニキャスト状態(すなわち、ユニキャストの通信タイプ)におかれる。したがって、第2のUEが、第1のUEとグループキャストUEグループを、例えば、第1のDCIによって、形成済みの場合は、第1のUEおよび第2のUEがグループキャスト状態(すなわち、グループキャストの通信タイプ)におかれる。
加えて、第1のUEおよび第2のUEがグループキャストの通信タイプにおかれるべきということは、第1のUEおよび第2のUEが、ユニキャスト状態またはブロードキャスト状態におかれているかどうかに係わらず、第1のUEがこの第1のDCIを送信すると、第1のDCIが受信された後に、第1のUEおよび第2のUEがグループキャストを介して通信するということ、例えば、第2のUEが、後に続く可能性のあるPDSCHを、自身のUE IDではなくグループIDを用いて復号し、第1のUEが、このグループIDを使用して、第2のUEへの次の可能性のあるDCIにスクランブルをかける、ということを意味する。第1のUEおよび第2のUEがユニキャスト状態におかれている場合、第1のUEが第1のDCIを送信すると、通信タイプがグループキャストのタイプに移行し、この第1のDCIに対応する可能性のあるPDSCHが、グループIDでスクランブルをかけられる。第1のUEおよび第2のUEがグループキャスト状態におかれている場合、第1のUEが第1のDCIを送信すると、通信タイプはグループキャストのタイプを継続する。通信タイプのインジケーションは、ユニキャストまたはグループキャストという絶対的タイプのインジケーションの代わりに、切り替わるタイプのインジケーションとすることもできることに留意されたい。換言すると、通信タイプは、通信タイプが変更されるかどうかを示すことができる。
一方、1つのUE(第1のUE)が、別のUE(第2のUE)と、ユニキャスト様式で通信しようとするとき、すなわち、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第1のUEが第2のDCI(ユニキャストDCI)を第2のUEに送信する。ユニキャストDCIは、ユニキャストの通信タイプを示すことができる(インジケーション様式については後述する)。第2のUEがユニキャストDCIを受信すると、第2のUEは、DCIがユニキャストDCIであることを、通信タイプのインジケーションを介して認識し、第2のUEは、自らのUE IDを使用してユニキャストDCIに続く潜在的なPDSCHを復号する。潜在的なPDSCHとは、第2のUEに関するデータを搬送するPDSCH(ある場合には)である。このようにして、第1のUEと第2のUEとは、ユニキャスト通信におかれるべく移行または継続することができる。
第1のDCIと同様に、第1のUEが第2のDCIを送信すると、第1のUEと第2のUEとが、2つの異なる通信状態、すなわち、ユニキャスト状態またはグループキャスト状態、におかれ得る。第1のUEおよび第2のUEが、ユニキャスト状態(すなわち、ユニキャストの通信タイプ)におかれている場合、第1のUEが第2のDCIを送信すると、第2のDCIは、第2のUEのUE IDでスクランブルをかけられ、第2のUEが、第2のUEには既知であるUE IDを用いて、第2のDCIを復号できるようにされる。第2のUEが第2のDCIを受信して、その第2のDCIをそのUE IDを用いて復号すると、第2のUEは、第1のUEが、ユニキャストを介して第2のUEと通信すべきであることを認識する。そして、第2のUEは、自らのUE IDを使用して、自らのUE IDでスクランブルがかけられた潜在的なPDSCHを復号することができる。第2のUEが通信タイプを認識した後、第1のUEおよび第2のUEは、ユニキャスト状態(すなわち、ユニキャストの通信タイプ)におかれるべく継続する。対照的に、第1のUEおよび第2のUEが、グループキャスト状態(すなわち、グループキャストの通信タイプ)におかれている場合、第1のUEが第2のDCIを送信すると、第2のDCIは、グループキャストのUEグループのグループIDでスクランブルをかけられ、第2のUEが、第2のUEには既知であるグループIDを用いて、第2のDCIを復号できるようにされる。第2のUEが第2のDCIを受信して、その第2のDCIをグループIDを用いて復号すると、第2のUEは、第1のUEが、ユニキャストを介して第2のUEと通信すべきであることを認識し、通信タイプがグループキャストからユニキャストに移行する。第1のDCIと同様に、第1のUEおよび第2のUEがユニキャストの通信タイプにおかれるべきということは、第1のUEおよび第2のUEが、ユニキャスト状態またはブロードキャスト状態におかれているかどうかに係わらず、第1のUEがこの第2のDCIを送信すると、第2のDCIが受信された後に、第1のUEおよび第2のUEがユニキャストを介して通信するということ、例えば、第2のUEが、後に続く可能性のあるPDSCHを、グループIDではなく自身のUE IDを用いて復号し、第1のUEが、第2のUEのUE IDを使用して、第2のUEへの次に可能性のあるDCIにスクランブルをかける、ということを意味する。第1のUEおよび第2のUEがユニキャスト状態におかれている場合、第1のUEが第1のDCIを送信すると、通信タイプがユニキャストのタイプを継続し、この第1のDCIに対応する可能性のあるPDSCHが、第2のUEのUE IDでスクランブルをかけられる。第1のUEおよび第2のUEがグループキャスト状態におかれている場合、第1のUEが第1のDCIを送信すると、通信タイプはユニキャストのタイプに移行する。
要するに、本開示の実施形態1では、UEが、ユニキャストまたはグループキャストを介して柔軟に通信することができ、ユニキャストとグループキャストとの間を高速で移行することができる。UEが、ユニキャストからグループキャストへの移行、または、グループキャスト状態の継続を望むときに、第1のDCI(グループキャストDCI)が送信されてもよい。UEが、グループキャストからユニキャストへの移行、または、ユニキャスト状態の継続を望むときに、第2のDCI(ユニキャストDCI)が送信されてもよい。
図6は、本開示の実施形態1による、ユニキャストからグループキャストへの移行の一例を示す。図6の上側では、UE601がUE602〜605と、それぞれユニキャストを介して通信している。この状況では、UE601は、(E)PDCCH((エンハンスド)物理ダウンリンク制御チャネル)のユニキャストDCIと、PDSCHとをそれぞれ、UE602〜605のそれぞれに送信することができ、ユニキャストDCIとPDSCHとの両方がそれぞれのUE IDでスクランブルをかけられる。UE601が、通信タイプを、ユニキャストからグループキャストに移行することを望むときに、図6の下側に示すように、UE601(マスタUE)が、それぞれのUE IDでスクランブルをかけられたグループキャストDCIを、グループキャストUEグループに含まれることになる各UE(本例ではUE602〜605)に送信することができ、グループキャストUEグループのグループIDでスクランブルをかけられた共有のPDSCHを送信する。そして、グループキャストUEグループの全てのUE(UE602〜605)が、共有のPDSCH内のデータを、グループIDで復号することにより、取得することができる。移行後、グループキャストUEグループ内のUEが、ブロードキャストを介して通信を継続し、マスタUE601は、次に、グループIDでスクランブルをかけられた1つの共有のグループキャストDCIを、全てのUE602〜605に次回送信し(図示せず)、UE602〜605は、共有のグループキャストDCIを、図6の下側に示す移行のプロセス中に、グループキャストDCIを介して送信済みのグループIDで、復号することができる。
加えて、実施形態1によると、通信タイプがグループキャストである場合、マスタUEが、グループキャストDCI(現在のグループキャストDCI)を送信すると、スレーブUEは、前回のグループキャストDCIによって示されたグループIDを使用して、現在のグループキャストDCIを復号することができ、かつ、復号に使用されるグループIDが、現在のグループキャストDCIによって示されるグループIDと同じであるかどうか、をさらに検査することができる。2つのグループIDが同じではない場合、エラーが発生しているか、後に続くPDSCHが別のグループIDでスクランブルをかけられていて、問題のスレーブUE用のものではない、と推測することができる。そのような挙動は、仮想CRC(サイクリックリダンダンシーチェック)に類似しており、グループキャスト通信のロバスト性を高めることができる。
実施形態1の第1の例では、好ましくは、第1のDCIは、第2のDCIと同じものとすることができるが、但し、グループキャストの通信タイプには有用ではない、第2のDCI内のビットに対応する、第1のDCI内のビットを使用して、グループIDおよび/または通信タイプを示すことを除く。例えば、第2のDCI(ユニキャストDCI)は、3GPP Release8〜11で定義されるような既存のDCIフォーマットを使用することができるが、但し、DCIフォーマットの1ビットが、通信タイプを示すのに使用されることが必要であってもよいことを除き、また、第1のDCI(グループキャストDCI)も、同じDCIフォーマットを第2のDCIとして使用するが、但し、DCIフォーマットのグループキャストの通信タイプには有用ではないような数ビット(またはフィールド)が、グループIDおよび/または通信タイプを示すのに再利用されることを除く。
グループキャスト通信では、HARQ(ハイブリッド自動再送要求(Hybrid Automatic Repeat Request))、CSI(チャネル状態情報(Channel State Information))フィードバック、SRS(サウンディング参照信号(Sounding Reference Signal))の、スレーブUE向け送信を行うことは難しく、なぜなら、このことにより、特に、同じグループキャストUEグループ内のスレーブUEの数が大きいときに、マスタUEへの非常に多くのフィードバックオーバーヘッドが生ずるからである。グループ通信で、全てのスレーブUEのCSI情報に基づき、緻密なスケジューリング/リンク適応/電力制御を行うことは不可能である。したがって、少なくとも、後に続くビットまたは既存のDCIフォーマットでファイルされたビットが、再利用され得る。
−キャリアインジケータ−0〜3ビット(例えば、1ビットを、ユニキャストとグループキャストの両方の通信について通信タイプを示すのに使用することができる)
−HARQプロセス番号−3ビット
−リダンダンシーバージョン−2ビット
−新しいデータインジケータ−1ビット
−PUCCH用TPCコマンド−2ビット
−SRS要求−0〜1ビット
−変調および符号化方式(Modulation and coding scheme:MCS)−5ビット(固定MCSは、グループ通信用とする)
その中で、HARQに関連するビットは、HARQがグループキャスト通信には使用されないため、最優先して再利用され、CSI、SRS、およびMCSのビットは、2番目に優先して再利用される。加えて、キャリアアグリゲーションは、D2D通信には関係がなく、CIF(Carrier Indicator Field)も再利用され得る。例えば、CIFの1bitが「0」のとき、ユニキャストであることを示し、そのようなビットが「1」のときに、グループキャストであることを示す。さらに、TM10または他のTMモードでは、PMI(Precoding Matrix Indication)インデックス、またはPQI(PDSCH RE Mapping and Quasi−Co−Location Indicator)を使用して、通信タイプを示すことができる。例えば、PMIインデックス0は、ユニキャストを意味し、PMIインデックス1は、グループキャストを意味する。
さらに、通信タイプは、インデックスグループキャストDCI(第1のDCI)またはユニキャストDCI(第2のDCI)の、物理リソースブロック(PRB)インデックスまたは制御チャネル要素(CCE)によって、暗黙に示されてよい。例えば、PRBインデックスが奇数ならば、ユニキャスト通信であることを意味し、PRBインデックスが偶数ならば、グループキャスト通信であること意味する。代替えとして、通信タイプは、第2のUE向けの潜在的なPDSCHのPRBインデックス、または、潜在的なPDSCHとDCI(EPDCCH)との間のPRBインデックスの差、によって暗黙に示されてよい。
上記の実施形態1の第1の例では、第1のDCIおよび第2のDCIが、同じ既存のDCIフォーマットを使用するため、新しいDCIを設計する労力を省くことができ、ブラインド検出の時間を減少させることもできる。
実施形態1の第2の例では、新しいDCIが、グループキャスト通信について設計され、新しいグループキャストDCIが、通信タイプおよびグループIDを示すことができ、ならびに、ビットをパディングして、ユニキャストに使用されるDCI(ユニキャストDCIであって、これは、第1の例で説明したように、既存のDCIフォーマットを使用することができる)にマッチするようにすることにより、柔軟性のある長さを有することができる。換言すると、第1のDCI(新しく設計されたグループキャストDCI)は、通信タイプを示すためのビットと、グループIDを示すための複数のビットとを含み、第2のDCIと同じ長さを有するように、追加のビットでパディングされる。この第2の例では、第1のDCIと第2のDCIの長さが同じであるため、ブラインド検出の時間が増加することはない。
加えて、実施形態1については、DCI内の空間を節約するために、第1のDCIにグループIDを示すためのビットが、グループIDインデックスを示し、このグループIDインデックスによって、無線リソース制御(RRC)層で構成されるグループIDセットからグループIDを選択できるように、グループIDを示すことができる。換言すると、複数のグループIDから成るグループIDセットが、RRC層を介して構成され、物理層のDCIが、グループIDインデックスをスレーブUEに対して示す必要があるだけとすることができる。スレーブUEは、グループIDインデックスに対応するグループIDを選択することができる。例えば、セット内のグループIDの数が16である場合、グループIDインデックスを示すのに必要なのは、4ビットのみである。しかし、通常は、グループIDは16ビット必要とすることがあり、したがって、12ビットはDCI用に確保される。
さらに、本開示の実施形態1の代替えまたは変形として、通信タイプ(または、タイプ切替情報)が、DCIより高い層(RRC/MAC)によって示されてもよい。
実施形態1では、上記の方法を実行するためのUEが提供される。図7は、本開示の実施形態1による、UE700を示すブロック図である。UE700は、送信ユニット701を備える。送信ユニット701は、UE700と第2のUEとが、グループキャストの通信タイプにおかれるべきときに、第1のDCIを第2のUEに送信するように構成されてよく、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDとを示すことができ、第1のDCIに続く第1のPDSCHが、グループIDでスクランブルをかけられ、また、送信ユニット701は、UE700と第2のUEとがユニキャストの通信タイプにおかれるべきときに、第2のDCIを第2のUEに送信するように構成されてもよく、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、第2のUEのUE IDでスクランブルをかけられる。UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれ第2のUEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。
本開示によるUE700は、関連するプログラムを実行して、種々のデータを処理し、UE700内のそれぞれのユニットの操作を制御するための、CPU(中央処理装置)710、CPU710による種々の処理および制御を実行するために必要な種々のプログラムを記憶するためのROM(Read Only Memory)713、CPU710による処理および制御の手続きにて一時的に生成される中間データを記憶するためのRAM(Random Access Memory)715、および/または、種々のプログラム、データなどを記憶するための記憶ユニット717、を選択的に含んでもよい。上記の送信ユニット701、CPU710、ROM713、RAM715および/または記憶ユニット717など、は、データバスおよび/またはコマンドバス720を介して相互に接続されてもよく、互いに信号を送信してもよい。
上記で説明したようなそれぞれのユニットは、本開示の範囲を限定するものではない。本開示の一実装形態によると、上記の送信ユニット701の機能は、ハードウェアによって実装されてもよく、上記のCPU710、ROM713、RAM715および/または記憶ユニット717は、必ずしも必要なわけではない。代替えとして、上記の送信ユニット701の機能はまた、上記のCPU710、ROM713、RAM715および/または記憶ユニット717などと組み合わせて、関数ソフトウェアによって実装されてもよい。
したがって、受信側では、実施形態1は、図8に示すような無線通信方法800として実装可能である。詳細には、方法800は、第1のUE(スレーブUE)と第2のUE(マスタUE)とが、グループキャストの通信タイプにおかれるべきときに、第1のUEが、第2のUEから送信される第1のダウンリンク制御情報(DCI)を受信するステップ801であって、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができ、第1のDCIに続く第1の潜在的な物理ダウンリンク共有チャネル(PDSCH)が、グループIDでスクランブルをかけられる、第1のDCIを受信ステップ801と、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第1のUEが、第2のUEから送信される第2のDCIを受信するステップ802であって、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、第1のUEのUE IDでスクランブルをかけられる、第2のDCIを受信するステップ802と、を含む。第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれ第1のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。受信側の「第1のUE」および「第2のUE」とは、送信側のそれと逆のものを意味し、すなわち、受信側からの第1のUEは、スレーブUEとすることができ、受信側からの第2のUEは、マスタUEとすることができることに留意されたい。
加えて、受信側のUEも、実施形態1に従って提供される。図9は、本開示の実施形態1による、UE900を示すブロック図である。UE900は、受信ユニット901を備える。受信ユニット901は、UE900と第2のUEとが、グループキャストの通信タイプにおかれるべきときに、第2のUEから送信される第1のダウンリンク制御情報(DCI)を受信するように構成されてよく、第1のDCIが、グループキャストの通信タイプと、グループキャストのUEグループのグループIDと、を示すことができ、第1のDCIに続く第1の潜在的な物理ダウンリンク共有チャネル(PDSCH)が、グループIDでスクランブルをかけられる。受信ユニット901は、UE900と第2のUEとが、ユニキャストの通信タイプにおかれるべきときに、第2のUEから送信される第2のDCIを受信するべくさらに構成されてよく、第2のDCIが、ユニキャストの通信タイプを示すことができ、第2のDCIに続く第2の潜在的なPDSCHが、UEのUE IDでスクランブルをかけられる。UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれUEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、それぞれグループIDでスクランブルをかけられる。
本開示によるUE900は、関連するプログラムを実行して、種々のデータを処理し、UE900内のそれぞれのユニットの操作を制御するための、CPU(中央処理装置)910、CPU910による種々の処理および制御を実行するために必要な種々のプログラムを記憶するためのROM(Read Only Memory)913、CPU910による処理および制御の手続きにて一時的に生成される中間データを記憶するためのRAM(Random Access Memory)915、および/または、種々のプログラム、データなどを記憶するための記憶ユニット917、を選択的に含んでもよい。上記の受信ユニット901、CPU910、ROM913、RAM915および/または記憶ユニット917など、は、データバスおよび/またはコマンドバス920を介して相互に接続されてもよく、互いに信号を送信してもよい。
上記で説明したようなそれぞれのユニットは、本開示の範囲を限定するものではない。本開示の一実装形態によると、上記の受信ユニット901の機能は、ハードウェアによって実装されてもよく、上記のCPU910、ROM913、RAM915および/または記憶ユニット917は、必ずしも必要なわけではない。代替えとして、上記の受信ユニット901の機能はまた、上記のCPU910、ROM913、RAM915および/または記憶ユニット917などと組み合わせて、関数ソフトウェアによって実装されてもよい。
(実施形態2)
D2D通信のためのグループキャストとユニキャストとの間の、速い、柔軟性のある移行を実現するために、実施形態2によると、マスタUEから、2つのDCIが同時に送信されてよく、スレーブUEが、どちらの通信タイプ(グループキャストまたはユニキャスト)を使用すべきかを判定するために、両DCIを復号する。詳細には、図10は、本開示の実施形態2による、無線通信方法1000のフロー図である。方法1000は、第1のUE(マスタUE)から第2のUE(スレーブUE)に、第1のダウンリンク制御情報(DCI)を送信するステップ1001と、第1のUEから第2のUEに、第2のDCIを送信するステップ1002と、を含む。方法1000では、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきか、を示し、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示す。加えて、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、第2のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
実施形態2によると、2つのDCIが、第1のUEによって一度に送信され、第2のUEが、ブラインド検出によって、両DCIを受信して復号し、両DCIの特定のフィールド(例えば、リソース割振りフィールド)を検査する。第2のUEは、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかを、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうか、に基づいて、決定することができる。例えば、特定のフィールドが同じである場合、ユニキャストが示され、特定のフィールドが異なる場合、グループキャストが示され、逆も同様である。第1のUEと第2のUEとが、グループキャストの通信タイプにおかれるべきであると示されるときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示す。グループIDは、グループIDでスクランブルをかけられた、後に続く可能性のあるPDSCHを、第2のUEが復号するために使用される。加えて、実施形態1と同様に、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、第2のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
実施形態2の一例として、第1のDCIが、既存のDCIフォーマットを使用し、第2のDCIが、グループIDのインジケーションを含む新しく設計されたDCIである。第2のDCIのリソース割振り(特定のフィールド)が、第1のDCIのものと同じときは、第1のUEと第2のUEとが、ユニキャストを介して通信する。第2のDCIのリソース割振り(特定のフィールド)が、第1のDCIのものと異なるときは、第1のUEと第2のUEとが、グループキャストを介して通信し、リソース割振りが、第2のDCIの後に続き、第2のUEは、第2のDCIに示されるグループIDを使用して、潜在的なPDSCHを復号することができる。
さらに、実施形態1と同様に、DCI内の空間を節約するために、第1のDCIおよび/または第2のDCIにグループIDを示すためのビットが、グループIDインデックスを示し、このグループIDインデックスによって、無線リソース制御(RRC)層で構成されるグループIDセットからグループIDを選択できるように、グループIDを示すことができる。
実施形態2では、上記の方法を実行するための送信側のUEも、提供される。送信ユニットを備える、実施形態2による送信側のUEは、実施形態1によるUE700と同様の構成を持つが、但し、以下の点を除く。送信ユニットは、第2のUEに、第1のDCIおよび第2のDCIを送信するように構成され、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、UEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかどうか、を示し、UEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示し、UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、第2のUEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
したがって、受信側では、実施形態2は、図11に示すような無線通信方法1100として実装可能である。詳細には、方法1100は、第1のUE(スレーブUE)が、第2のUE(マスタUE)から送信される第1のダウンリンク制御情報(DCI)を受信するステップ1101と、第1のUEが、第2のUEから送信される第2のDCIを受信するステップ1102と、を含み、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかどうか、を示し、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示し、第1のUEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、第1のUEのUE IDでスクランブルをかけられ、第1のUEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。受信側の「第1のUE」および「第2のUE」とは、送信側のそれと逆のものを意味し、すなわち、受信側からの第1のUEは、スレーブUEであり、受信側からの第2のUEは、マスタUEであることに留意されたい。
さらに、実施形態2により、上記の方法を実行するための受信側のUEも、提供される。受信ユニットを備える、実施形態2による受信側のUEは、実施形態1によるUE900と同様の構成を持つが、但し、以下の点を除く。受信ユニットは、第2のUEから送信される、第1のダウンリンク制御情報(DCI)および第2のDCIを受信するように構成され、第1のDCIおよび第2のDCIの特定のフィールドが同じであるかどうかが、UEと第2のUEとが、ユニキャストの通信タイプにおかれるべきか、グループキャストの通信タイプにおかれるべきかどうか、を示し、UEと第2のUEとが、グループキャストの通信タイプにおかれるべきときは、第1のDCIおよび第2のDCIの少なくとも一方が、グループキャストのUEグループのグループIDを示し、UEと第2のUEとが、ユニキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、UEのUE IDでスクランブルをかけられ、UEと第2のUEとが、グループキャストの通信タイプにおかれている場合は、第1のDCIおよび第2のDCIを送信する際、第1のDCIおよび第2のDCIが、グループIDでスクランブルをかけられる。
(実施形態3)
D2D通信に関する、別の重要な問題は、グループキャスト通信においてリソース割振りをどのように行うのか、である。ユニキャストのようなきめ細かいリソース割振りは、1つのアプローチであるが、多くの設計、例えば、CSIフィードバック、HARQ、電力制御、およびリンク適応、を必要とすることがある。したがって、大きな標準化の努力が必要である。加えて、フィードバックオーバーヘッドが大きいために、全てのスレーブユーザに対してHARQを考慮するのは合理的ではない可能性がある。本質的または最小限の機能をまず設計して、基本の通信を保証すべきである。リソース割振りを解決する別の解決方法は、D2Dグループキャスト通信のための粗いリソース割振りを行うこと、すなわち、HARQ無しの、固定MCSと潜在的な電力制御、および固定されたリソースの位置、を行うことである。SPS(Semi−Persistent Scheduling)は、現行のリリースでサポートされており、準静的リソース割振り方法の一種である。しかし、SPSは、周期的なリソース割振りをサポートするだけであり、これは、潜在的には、D2Dについて柔軟性があり効率的であるのではない。加えて、SPSは、ユニキャスト通信向けのものであり、グループキャスト通信向けではない。別のアプローチは、粗いリソース割振りを、高層のシグナリング(RRC/MAC)により構成することであるが、そのようなアプローチは低速であり、RRCシグナリング相互作用が、一般に数百マイクロ秒を必要とするため、遅れずに調整することができない。
本開示の実施形態3によると、図12に示すような、リソース割振りのための無線通信方法1200が提供される。方法1200は、第1のユーザ機器(UE)から第2のUEに、リソース割振りのためのダウンリンク制御情報(DCI)を送信するステップ1201を含み、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
実施形態3では、DCIが、特にグループキャスト通信について、D2D通信のリソース割振りのためのリソース割振りパターンおよび送信寿命を、暗黙または明示的に示す。本明細書において、送信寿命とは、リソース割振りがどの程度の期間存続するのかを意味し、TTI(Transmission Time Interval)の単位とすることができる。本明細書において、リソース割振りパターンとは、送信寿命内で、どのようにパターンを割り振るのかについての任意の情報を指す。例えば、リソース割振りパターンには、周波数ホッピングパターン、送信時間、および/または、送信継続時間、を含むことができる。図13は、2つの例示的な周波数ホッピングパターンを示す。周波数ホッピングパターン1では、同じ周波数のリソースが割り振られ、一方、周波数ホッピングパターン2では、異なる周波数のリソースが、異なるタイムスロットで割り振られており、すなわち、周波数ホッピングが実現されている。送信時間とは、送信寿命内に、送信が何回行われるのかを意味し、送信継続時間とは、1つの送信がどの程度の期間存続するのかを意味する。図14は、リソース割振りパターンの2つの例を示す。上側の例では、送信寿命(TL)が9TTI、送信時間(TS)が9、および、送信継続時間(TD)が1TTI、であり、したがって、得られるリソース割振りは、9TTIの間継続するリソース割振りである。下側の例では、送信寿命が10TTI、送信時間が3、および、送信継続時間が2TTI、であり、図示されるリソース割振りは、送信が、時間領域内に均等に割り振られると仮定することにより得られるものである。図14は、実施形態3の単なる一例であり、リソース割振りパターンは、任意の適切なパターンとすることができることに留意されたい。加えて、割振りパターンの定義に使用された上記のパラメータも、単なる例であり、他の適切なパラメータと置き換えられてよく、例えば、送信時間を、2つの送信の間の時間距離を表す送信間隔と置き換えることができる。図14の上側の例では、送信間隔が0TTIであり、下側の例では、送信間隔が2TTIである。さらに、周波数ホッピングパターンは、時間領域パターンと組み合わせられてもよい。
実施形態3の代替えまたは変形として、リソース割振りパターンおよび/または送信寿命は、より高層(RRC/MAC)によってシグナリングされてもよく、または、仕様で指定されてもよい。
実施形態3では、リソース割振りパターンをDCIに(暗黙または明示的に)示すための情報が、リソース割振りパターンインデックスを示し、このインデックスによって、無線リソース制御(RRC)層で構成されるリソース割振りパターンセットから、リソース割振りパターンを選択できるように、リソース割振りパターンを、示すことができる。換言すると、複数のリソース割振りパターンから成るリソース割振りパターンセットが、RRC層で構成され、DCIのみが、セット内のどのリソース割振りパターンが選択されるのかを示す必要がある。このようにして、リソース割振りパターンを示すためのビットを、減らすことができる。
実施形態3では、DCIで必要なビットをできるだけ減らすために、好ましくは、リソース割振りパターンおよび/または送信寿命が、物理リソースブロック(PRB)インデックスおよび/またはDCIの数、および/または、制御チャネル要素(CCE)インデックスおよび/またはDCI((E)PDCCH)の数、によって暗黙に示されてよい。例えば、開始CCEインデックス=16とは、送信時間もしくは送信寿命が16TTIである、または、リソース割振りパターンが、RRCで構成されるセット内のインデックス「16」のリソース割振りパターンを使用する、ということを意味するものとしてよい。代替えとして、アグリゲーションレベル(特定のCCE番号に相当する)=8とは、送信時間もしくは送信寿命が8TTIである、または、リソース割振りパターンが、RRCで構成されるセット内のインデックス「8」のリソース割振りパターンを使用する、ということを意味するものとしてよい。加えて、PRBおよびCCEのインジケーションの組み合わせも、可能である。本例では、ホッピングパターンは、高層(RRC/MAC)により構成されるものとしてよい。
代替えとして、リソース割振りパターンおよび/または送信寿命が、PRBインデックスおよび/または第2のUEに割り振られたPDSCHの数、によって暗黙に示されてもよい。上記の(E)PDCCHのインジケーションと同様に、例えば、開始PRBインデックス=16とは、送信時間もしくは送信寿命が16TTIである、または、リソース割振りパターンが、RRCで構成されるセット内のインデックス「16」のリソース割振りパターンを使用する、ということを意味するものとしてよい。
代替えとして、リソース割振りパターンおよび/または送信寿命が、PRBインデックスおよび/または第2のUEに割り振られたPDSCHと、DCI((E)PDCCH)との間の数の差、によって暗黙に示されてもよい。上記の(E)PDCCHのインジケーションと同様に、例えば、PDSCHとEPDCCHとの間のPRBインデックスの差=16とは、送信時間もしくは送信寿命が16TTIである、または、リソース割振りパターンが、RRCで構成されるセット内のインデックス「16」のリソース割振りパターンを使用する、ということを意味するものとしてよい。
実施形態3では、好ましくは、DCIが、3GPP Release8〜11で定義されるようないずれの既存のDCIフォーマットも使用することができるが、但し、3GPP Release8−11で定義されたDCIフォーマットの数ビットを使用して、DCIにリソース割振りパターンおよび/または送信寿命を示すことを除く。実施形態1において説明したように、D2D通信では、特にグループキャスト通信において、既存のDCIフォーマットの多くのビットまたはフィールドが有用でないことがあり、したがって、上記のリソース割振りに再利用することができる。例えば、コンパクトなDCI(例えば、DCIフォーマット1C)を想定する場合、少なくとも以下のビットを再利用することができる。変調および符号化方式−5ビット(MCSが固定、またはRRCによって上記リソース割振りに既に構成済み、と仮定する)。通常のDCI(例えば、DCIフォーマット1A/2C/2D)を想定する場合、HARQ無し、CSI/SRS要求無し、と想定されるため、以下のような多くのフィールドが再利用できる。変調および符号化方式−5ビット;HARQプロセス番号−3ビット(FDD)、4ビット(TDD);リダンダンシーバージョン−2ビット。加えて、DCIフォーマット型は、リソース割振りの型を暗黙に示すために使用することもできる。本明細書において、リソース割振りの型とは、DCIで使用されるリソース割振りの型を意味し、例えば、従来の周期的な割振りモード、SPS周期的割振りモード、または、実施形態3においてD2D通信について定義した割振りモード(D2D割振りモードと呼ばれる)、などである。例えば、DCI2Dを使用して、実施形態3で定義した割振りモード、または、SPS周期的割振りモードを暗黙に示すことができ、DCI1Aを使用して、従来の継続的割振りモードを暗黙に示すことができる。
代替えとして、リソース割振りの型を、DCIの数フィールドによって共同で、示すこともできる。例えば、SPSアクティブ化と、D2D割振りのアクティブ化との間の差が、表1において示され、ここではDCI2Xを想定する。
表1に示すように、表1に挙げたフィールドが、SPSアクティブ化に関する値を持つものとして検出される場合、DCIはSPSモードを示し、SPSがアクティブにされる。表1に挙げたフィールドが、D2D割振りのアクティブ化に関する値を持つものとして検出される場合、DCIはD2D割振りモードを示し、D2D割振りモードがアクティブにされる。
代替えとして、割振り型を、異なる無線ネットワーク一時的識別子(RNTI)によって違いを付けることもできる。この解決法によると、図15に示すように、リソース割振りのための無線通信方法1500が提供され、該方法は、第1のUEから第2のUEに、第1のリソース割振り型のための第1のDCI、または、第2のリソース割振り型のための第2のDCIのいずれかを送信するステップ1501を含み、第1のDCIが、第1のRNTIでスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられる。無線通信方法1500によると、割振り型を、異なるRNTIによって区別することができる。例えば、第1のDCIおよび第1のRNTIは、SPSモード用であり、第2のDCIおよび第2のRNTIは、D2D割振りモード用である。
実施形態3では、上記の方法を実行するための送信側のUEも、提供される。送信ユニットを備える、実施形態3による送信側のUEは、実施形態1によるUE700と同様の構成を持つが、但し、以下の点を除く。送信ユニットは、UEから第2のUEに、リソース割振りのためのダウンリンク制御情報(DCI)を送信するように構成され、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
実施形態3では、上記の方法を実行するための送信側の別のUEも、提供される。送信ユニットを備える、実施形態3による送信側のUEは、実施形態1によるUE700と同様の構成を持つが、但し、以下の点を除く。送信ユニットは、第1のリソース割振り型のための第1のダウンリンク制御情報(DCI)、または、第2のリソース割振り型のための第2のDCIのいずれかを、第2のUEに送信するように構成され、第1のDCIが、第1の無線ネットワーク一時的識別子(RNTI)でスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられる。
したがって、受信側では、実施形態3は、図16に示すような無線通信方法1600として実装可能である。詳細には、方法1600は、第1のUEが、第2のUEから送信されるリソース割振りのためのダウンリンク制御情報(DCI)を受信するステップ1601を含み、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
加えて、受信側では、実施形態3は、図17に示すような無線通信方法1700として実装可能である。詳細には、方法1700は、第1のUEが、第2のUEから送信される、第1のリソース割振り型のための第1のダウンリンク制御情報(DCI)、または、第2のリソース割振り型のための第2のDCI、のいずれかを受信するステップ1701を含み、第1のDCIが、第1の無線ネットワーク一時的識別子(RNTI)でスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられる。受信側の「第1のUE」および「第2のUE」とは、送信側のそれと逆のものを意味することに留意されたい。
さらに、実施形態3により、上記の方法を実行するための受信側のUEも、提供される。受信ユニットを備える、実施形態3による受信側のUEは、実施形態1によるUE900と同様の構成を持つが、但し、以下の点を除く。受信ユニットは、第2のUEから送信されるリソース割振りのためのダウンリンク制御情報(DCI)を受信するように構成され、DCIは、リソース割振りパターンおよび送信寿命を示すことができる。
さらに、実施形態3により、上記の方法を実行するための受信側の別のUEも、提供される。受信ユニットを備える、実施形態3による受信側のUEは、実施形態1によるUE900と同様の構成を持つが、但し、以下の点を除く。受信ユニットは、第2のUEから送信される、第1のリソース割振り型のための第1のダウンリンク制御情報(DCI)、または、第2のリソース割振り型のための第2のDCI、のいずれかを受信するように構成され、第1のDCIが、第1の無線ネットワーク一時的識別子(RNTI)でスクランブルをかけられ、第2のDCIが、第1のRNTIとは異なる第2のRNTIでスクランブルをかけられ得る。
上記の実施形態を組み合わせて、新しい実施形態を形成することが可能であり、詳細には、実施形態3を実施形態1または実施形態2と組み合わせて、ユニキャスト−グループキャスト両方の移行およびリソース割振りを実行することが可能であることに留意されたい。
本発明は、ソフトウェア、ハードウェア、または、ハードウェアと連携するソフトウェアによって、実現することができる。上記に記載した各実施形態の説明において使用した各機能ブロックは、集積回路としてのLSIによって実現することができる。それらは、チップとして個々に形成されてもよく、または、1つのチップが、機能ブロックの一部または全てを含むように形成されてもよい。ここで、LSIとは、集積の度合いの違いに応じて、IC、システムLSI、スーパーLSI、または、ウルトラLSI、を指してよい。しかし、集積回路を実装する技術は、LSIに限定されず、専用回路または汎用プロセッサを使用することにより実現されてもよい。加えて、LSI製造後にプログラムが可能なFPGA(Field Programmable Gate Array)、または、LSI内部に配置された回路セルの接続および設定を再構成することが可能な、リコンフィギュラブルプロセッサ、が使用されてもよい。さらに、各機能ブロックの計算を、例えば、DSPまたはCPUを含む計算手段を使用することによって実行することができ、各機能の処理ステップは、実行用プログラムとして、記録媒体に記録されてもよい。さらに、LSIを構成する集積回路を実装するための技術が、半導体技術または他の派生的な技術の進歩に従って、出現する際には、機能ブロックが、そのような技術を使用することにより統合され得ることは明らかである。
本発明は、明細書において提示される記載および公知の技術に基づき、本発明の内容および範囲から逸脱することなく、当業者により、種々に変更または修正されることを意図しており、そのような変更および修正は、保護されるべく請求される範囲内にあることに留意されたい。さらに、本発明の内容から逸脱しない範囲で、上記で説明した実施形態の構成要素が、任意に組み合わせられてもよい。