特許 6343347 Ｄ２Ｄ通信方法、Ｄ２Ｄ通信対応ワイヤレスデバイス、およびｅＮｏｄｅ Ｂ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6343347

(24)【登録日】2018年5月25日

(45)【発行日】2018年6月13日

(54)【発明の名称】Ｄ２Ｄ通信方法、Ｄ２Ｄ通信対応ワイヤレスデバイス、およびｅＮｏｄｅ Ｂ

(51)【国際特許分類】

   H04W 76/14 20180101AFI20180604BHJP

   H04W 72/12 20090101ALI20180604BHJP

   H04W 92/18 20090101ALI20180604BHJP

   H04W 72/04 20090101ALI20180604BHJP

【ＦＩ】

   H04W76/14

   H04W72/12 110

   H04W92/18

   H04W72/04

【請求項の数】17

【全頁数】16

(21)【出願番号】特願2016-543715(P2016-543715)

(86)(22)【出願日】2014年3月31日

(65)【公表番号】特表2017-516323(P2017-516323A)

(43)【公表日】2017年6月15日

(86)【国際出願番号】CN2014074357

(87)【国際公開番号】WO2015149215

(87)【国際公開日】20151008

【審査請求日】2016年10月20日

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100105050

【弁理士】

【氏名又は名称】鷲田 公一

(72)【発明者】

【氏名】ワン リレイ

(72)【発明者】

【氏名】鈴木 秀俊

(72)【発明者】

【氏名】ロアー ヨアヒム

(72)【発明者】

【氏名】星野 正幸

【審査官】 三枝 保裕

(56)【参考文献】

【文献】 米国特許出願公開第２０１３／０１５００６１（ＵＳ，Ａ１）

【文献】 Samsung，Mode 1 resource allocation for D2D broadcast communication[online]，3GPP TSG-RAN WG1♯76b R1-141307，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_76b/Docs/R1-141307.zip＞，２０１４年 ３月２２日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ通信方法であって、
Ｄ２Ｄ送信を実施するために前記Ｄ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを、前記Ｄ２Ｄ送信に対するリソースをスケジューリングするｅＮｏｄｅ Ｂ（ｅＮＢ）に報告するステップ、
を含み、
前記推奨されるＭＣＳまたは前記推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものであり、
第一チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズは、メディアアクセス制御（ＭＡＣ）シグナリングを介して前記ｅＮＢに報告され、前記第一チャネルとは異なる第二チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズは、無線リソース制御（ＲＲＣ）シグナリングを介して前記ｅＮＢに報告される、
Ｄ２Ｄ通信方法。

【請求項2】

前記推奨されるＭＣＳを報告する場合に、バッファ状態報告（ＢＳＲ）も前記Ｄ２Ｄ通信対応ワイヤレスデバイスから前記ｅＮＢに報告される、
請求項１に記載のＤ２Ｄ通信方法。

【請求項3】

前記ＭＡＣシグナリングにおいて、前記推奨されるＭＣＳが、前記ＢＳＲと同じＭＡＣ制御要素（ＣＥ）中または前記ＢＳＲとは異なるＭＡＣ ＣＥ中で報告される、
請求項２に記載のＤ２Ｄ通信方法。

【請求項4】

前記推奨されるリソースサイズを報告する場合に、バッファ状態報告（ＢＳＲ）が、前記Ｄ２Ｄ通信対応ワイヤレスデバイスから前記ｅＮＢに報告されない、
請求項１に記載のＤ２Ｄ通信方法。

【請求項5】

前記ＭＡＣシグナリングにおいて、複数の前記第一チャネルに対する前記推奨されるＭＣＳもしくは前記推奨されるリソースサイズが、別々のＭＡＣ ＣＥ中で報告される、または、複数の前記第一チャネルに対する前記推奨されるＭＣＳもしくは前記推奨されるリソースサイズが同一のＭＡＣ ＣＥ中で報告される、請求項１に記載のＤ２Ｄ通信方法。

【請求項6】

前記推奨されるＭＣＳの前記報告のトリガは、前記ＢＳＲの前記報告のトリガと同一である、
請求項２に記載のＤ２Ｄ通信方法。

【請求項7】

前記推奨されるＭＣＳの前記報告、または、前記推奨されるＭＣＳおよび前記ＢＳＲの前記報告は、チャネル状態の変化によってトリガされる、
請求項２に記載のＤ２Ｄ通信方法。

【請求項8】

前記ＭＡＣシグナリングにおいて、相異なる用途状況に対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズが、別々のＭＡＣ ＣＥ、または、同一のＭＡＣ ＣＥ中で報告される、
請求項１に記載のＤ２Ｄ通信方法。

【請求項9】

端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ送信に対するリソースをスケジューリングするために、ｅＮｏｄｅ Ｂ（ｅＮＢ）によって実施されるＤ２Ｄ通信方法であって、
前記Ｄ２Ｄ通信対応ワイヤレスデバイスから報告された、前記Ｄ２Ｄ送信を実施するために前記Ｄ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを受信するステップ、
を含み、
前記推奨されるＭＣＳまたは前記推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものであり、
前記ステップは、第一チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズを、メディアアクセス制御（ＭＡＣ）シグナリングを介して受信し、前記第一チャネルとは異なる第二チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズを、無線リソース制御（ＲＲＣ）シグナリングを介して受信する、
Ｄ２Ｄ通信方法。

【請求項10】

端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスであって、
Ｄ２Ｄ送信を実施するために前記Ｄ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを、前記Ｄ２Ｄ送信に対するリソースをスケジューリングするｅＮｏｄｅ Ｂ（ｅＮＢ）に報告する報告部、
を含み、
前記推奨されるＭＣＳまたは前記推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものであり、
前記報告部は、第一チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズを、メディアアクセス制御（ＭＡＣ）シグナリングを介して前記ｅＮＢに報告し、前記第一チャネルとは異なる第二チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズを、無線リソース制御（ＲＲＣ）シグナリングを介して前記ｅＮＢに報告する、
Ｄ２Ｄ通信対応ワイヤレスデバイス。

【請求項11】

前記推奨されるＭＣＳを報告する場合に、バッファ状態報告（ＢＳＲ）も前記Ｄ２Ｄ通信対応ワイヤレスデバイスから前記ｅＮＢに報告される、
請求項１０に記載のＤ２Ｄ通信対応ワイヤレスデバイス。

【請求項12】

前記ＭＡＣシグナリングにおいて、前記推奨されるＭＣＳが、前記ＢＳＲと同じＭＡＣ制御要素（ＣＥ）中または前記ＢＳＲとは異なるＭＡＣ ＣＥ中で報告される、
請求項１１に記載のＤ２Ｄ通信対応ワイヤレスデバイス。

【請求項13】

前記推奨されるリソースサイズを報告する場合に、バッファ状態報告（ＢＳＲ）が、前記Ｄ２Ｄ通信対応ワイヤレスデバイスから前記ｅＮＢに報告されない、
請求項１０に記載のＤ２Ｄ通信対応ワイヤレスデバイス。

【請求項14】

前記ＭＡＣシグナリングにおいて、複数の前記第一チャネルに対する前記推奨されるＭＣＳもしくは前記推奨されるリソースサイズが、別々のＭＡＣ ＣＥ中で報告される、または、複数の前記第一チャネルに対する前記推奨されるＭＣＳもしくは前記推奨されるリソースサイズが同一のＭＡＣ ＣＥ中で報告される、
請求項１０に記載のＤ２Ｄ通信対応ワイヤレスデバイス。

【請求項15】

前記推奨されるＭＣＳの前記報告のトリガは、前記ＢＳＲの前記報告のトリガと同一である、請求項１０に記載のＤ２Ｄ通信対応ワイヤレスデバイス。

【請求項16】

前記推奨されるＭＣＳの前記報告、または、前記推奨されるＭＣＳおよび前記ＢＳＲの前記報告は、チャネル状態の変化によってトリガされる、
請求項１０に記載のＤ２Ｄ通信対応ワイヤレスデバイス。

【請求項17】

端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ送信に対するリソースをスケジューリングするためのｅＮｏｄｅ Ｂ（ｅＮＢ）であって、
前記Ｄ２Ｄ通信対応ワイヤレスデバイスから報告された、前記Ｄ２Ｄ送信を実施するために前記Ｄ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを受信する受信部、
を含み、
前記推奨されるＭＣＳまたは前記推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものであり、
前記受信部は、第一チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズを、メディアアクセス制御（ＭＡＣ）シグナリングを介して受信し、前記第一チャネルとは異なる第二チャネルに対する前記推奨されるＭＣＳまたは前記推奨されるリソースサイズを、無線リソース制御（ＲＲＣ）シグナリングを介して受信する
ｅＮＢ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、端末間（Ｄ２Ｄ：ｄｅｖｉｃｅ ｔｏ ｄｅｖｉｃｅ）通信の分野に関し、具体的には、Ｄ２Ｄの通信方法、Ｄ２Ｄ通信対応（Ｄ２Ｄ−ｅｎａｂｌｅｄ）ワイヤレスデバイス、およびｅＮｏｄｅ Ｂ（ｅＮＢ）に関する。

【背景技術】

【0002】

端末間（Ｄ２Ｄ）通信はデバイス間での直接通信であって、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）リリース１２における新しいテーマである。Ｄ２Ｄ通信は、ワイヤレスネットワークカバレッジを使って（例えば商業用途（ｃｏｍｍｅｒｃｉａｌ ｃａｓｅ））、もしくはネットワークカバレッジを使わないで（例えば公共安全用途（ｐｕｂｌｉｃ ｓａｆｅｔｙ））行うことができる。図１は、ワイヤレスネットワークカバレッジを使う場合および使わない場合の例示的なＤ２Ｄ通信を示す。図１の左側では、ＵＥ１０１およびＵＥ１０２は、ｅＮＢ１０３のワイヤレスネットワークカバレッジ内にあるが、これらは直接相互に（すなわち、ｅＮＢ１０３を介さずに）通信しており、ｅＮＢ１０３は、同期化、リソーススケジューリングなどに使われている。図１の右側では、ＵＥ１０４およびＵＥ１０５は、ワイヤレスネットワークカバレッジ内になく、これらは直接相互に通信している。

【0003】

３ＧＰＰ ＲＡＮ１＃７６会議は、ネットワークカバレッジ内（ＩＮＣ：ｉｎ ｎｅｔｗｏｒｋ−ｃｏｖｅｒａｇｅ）状況（ｓｃｅｎａｒｉｏ）におけるベースライン法を、ｅＮＢスケジューリングベースのリソース配分（モード１）にすること、および、カバレッジ端またはカバレッジ外（ＯＯＣ：ｏｕｔ−ｏｆ−ｃｏｖｅｒａｇｅ）状況におけるベースライン法を、ＵＥ自体の選択に基づくリソース配分（モード２）にすることを合意した。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本開示は、上記を考慮し、Ｄ２Ｄ通信のリソース配分手順における推奨される（ｒｅｃｏｍｍｅｎｄｅｄ）変調および符号化スキーム（ＭＣＳ：ｍｏｄｕｌａｔｉｏｎ ａｎｄ ｃｏｄｉｎｇ ｓｃｈｅｍｅ）またはリソースサイズについての報告（ｒｅｐｏｒｔｉｎｇ）スキームを提案するために行われる。

【0005】

本開示の第一態様において、端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ通信方法が提供される。本方法は、Ｄ２Ｄ送信を実施するためにＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ：ｍｏｄｕｌａｔｉｏｎ ａｎｄ ｃｏｄｉｎｇ ｓｃｈｅｍｅ）または推奨されるリソースサイズを、メディアアクセス制御（ＭＡＣ：ｍｅｄｉａ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）シグナリングまたは無線リソース制御（ＲＲＣ：ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）シグナリングを介して、Ｄ２Ｄ送信に対するリソースをスケジューリングするｅＮｏｄｅ Ｂ（ｅＮＢ）に報告する。該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。

【0006】

本開示の第二態様において、端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ送信に対するリソースをスケジューリングするｅＮｏｄｅ Ｂ（ｅＮＢ）によって実施されるＤ２Ｄ通信方法が提供される。本方法は、Ｄ２Ｄ通信対応ワイヤレスデバイスから、メディアアクセス制御（ＭＡＣ）シグナリングまたは無線リソース制御（ＲＲＣ）シグナリングを介して報告された、Ｄ２Ｄ送信を実施するためにＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを受信する。該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。

【0007】

本開示の第三態様において、端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスが提供される。本デバイスは、Ｄ２Ｄ送信を実施するためにＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを、メディアアクセス制御（ＭＡＣ）シグナリングまたは無線リソース制御（ＲＲＣ）シグナリングを介して、Ｄ２Ｄ送信に対するリソースをスケジューリングするｅＮｏｄｅ Ｂ（ｅＮＢ）に報告するよう構成された報告部を含み、該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。

【0008】

本開示の第四態様において、端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ送信に対するリソースをスケジューリングするｅＮｏｄｅ Ｂ（ｅＮＢ）が提供される。本ｅＮＢは、Ｄ２Ｄ通信対応ワイヤレスデバイスから、メディアアクセス制御（ＭＡＣ）シグナリングまたは無線リソース制御（ＲＲＣ）シグナリングを介して報告された、Ｄ２Ｄ送信を実施するためにＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを受信するよう構成された受信部を含み、該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。

【0009】

前述は要約であり、しかして必要上、細部の簡略化、一般化、および省略を包含する。本明細書に記載された、これらデバイスおよび／またはプロセスおよび／または他の主題の、他の態様、特徴、および利点は、本明細書中で説明する教示の中で明らかとなろう。上記の要約は、簡潔な形で概念の選択を紹介するために提示されたものであり、これらの概念は、後記の開示を実施するための形態においてさら深く説明される。この要約は、請求対象主題の重要な特徴または本質的特徴を識別することを意図されたものでなく、または請求対象主題の範囲を定めるための助力として用いるよう意図されたものでもない。

【0010】

本開示の前述のおよび他の特徴は、添付の図面と併せ、以下の説明および添付の特許請求の範囲を理解することによってさらに十分に明らかになろう。これらの図面が単に本開示によるいくつかの実施形態を示すものであり、したがって本開示の範囲を限定するものでないことを理解した上で、これら添付の図面を用いてさらなる具体性および詳細さをもって本開示を説明することとする。

【図面の簡単な説明】

【0011】

【図1】ワイヤレスネットワークカバレッジを用いる、および用いない例示的なＤ２Ｄ通信を示す。

【図2】Ｄ２Ｄ通信における、ｅＮＢによる例示的なリソース配分手順を示す。

【図3】本開示の或る実施形態による、Ｄ２Ｄ通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ通信方法のフローチャートを示す。

【図4】データチャネル、制御チャネル、およびディスカバリチャネルに対する、例示的な異なる報告方式を概略的に示す。

【図5】（ａ）および（ｂ）は、公共安全用途における状況および商業用途における状況に対する例示的なＭＣＳ報告方式を概略的に示す。

【図6】本開示の別の実施形態による、ｅＮＢによって実施されるＤ２Ｄ通信方法のフローチャートを示す。

【図7】本開示の或る実施形態による、Ｄ２Ｄ通信方法を用いた例示的なリソース配分手順を概略的に示す。

【図8】（ａ）および（ｂ）は、本開示の或る実施形態による、図２に示された例示的なリソース配分手順に基づく、Ｄ２Ｄ通信方法を用いた別の例示的なリソース配分手順を概略的に示す。

【図9】（ａ）および（ｂ）は、本開示の或る実施形態による、図２に示された例示的なリソース配分手順に基づく、Ｄ２Ｄ通信方法を用いた別の例示的なリソース配分手順を概略的に示す。

【図10】本開示の或る実施形態による、Ｄ２Ｄ通信対応ワイヤレスデバイスを示すブロック図である。

【図11】本開示の或る実施形態による、ｅＮＢを示すブロック図である。

【発明を実施するための形態】

【0012】

以下の詳細な説明において、添付の図面を参照し、これら図面は説明の一部を形成する。これらの図面において、類似の記号は、文脈上別途に指定されていなければ、通常、類似の構成要素を識別する。当然のことながら、本開示の態様は、種々様々の異なる構成に、配置、代替、組み合わせ、および設計することが可能で、これらの全ては、本開示の内と明確に見なされその一部とされる。

【0013】

なお、本明細書中で、一部の説明はユーザ装置（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）に基づいて行われことになるが、但し、本開示中のＤ２Ｄ通信対応ワイヤレスデバイスは、ＵＥに限定されるものでなく、例えば、Ｄ２Ｄワイヤレス通信能力を有するノートブック、パッド、センサ、または他のデバイスであってよい。

【0014】

ＩＮＣ状況におけるＤ２Ｄ通信に対しては、Ｄ２Ｄ送信に対するリソースをスケジュールするためにｅＮＢが使われる。したがって、ｅＮＢが、Ｄ２Ｄ送信に対し必要なリソースサイズを判定するために、Ｄ２Ｄ送信を実施しようとするＤ２Ｄ通信対応ワイヤレスデバイスは、バッファ状態報告（ＢＳＲ：ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔ）などいくつかの情報をｅＮＢに報告することが必要になり得る。

【0015】

図２は、Ｄ２Ｄ通信における、ｅＮＢによる例示的なリソース配分手順を示す。基本的には７つのステップが含まれる。

【0016】

ステップ１）ネットワークカバレッジ内（ＩＮＣ）の全てのＵＥは、ｅＮＢに同期し、或るＩＮＣ ＵＥの近辺のカバレッジ外（ＯＯＣ）ＵＥは、そのＩＮＣ ＵＥに同期する。

【0017】

ステップ２）ＩＮＣ ＵＥ群は、ｅＮＢからＤ２Ｄ構成情報（リソースプール構成、ＰＲＡＣＨチャネルなど）を受信する。

【0018】

ステップ３）同期元（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｏｕｒｃｅ）Ｄ２Ｄ ＵＥ（図中ではＩＮＣの送信側ＵＥとして示されている）は、周期的にリソースプール構成などを（おそらくは、２００ｍｓ〜数秒といった長周期のＰＤ２ＤＳＣＨで）報知（ｂｒｏａｄｃａｓｔ）する。

【0019】

ステップ４）ＩＮＣの送信側ＵＥは、ｅＮＢへのＤ２Ｄスケジューリング要求およびバッファ状態報告（ＢＳＲ）をトリガする。

【0020】

ステップ５）ｅＮＢは、要求されたＤ２Ｄスケジューリング要求に対し、Ｄ２Ｄ通信のためのリソースを割り当てる。

【0021】

ステップ６）ＩＮＣの送信側ＵＥがｅＮＢからリソース割り当てを受信した場合、該ＵＥは、スケジューリング割り当て（ｓｃｈｅｄｕｌｉｎｇ ａｓｓｉｇｎｍｅｎｔ）をスケジューリング割り当てプールで送信する。

【0022】

ステップ７）ＩＮＣの送信側ＵＥは、データリソースプールでデータを送信する。ＩＮＣおよびＯＯＣ両方の受信側ＵＥは、スケジューリング割り当てを検知しそれに応じてデータを受信する。

【0023】

ここでは、基本的には、Ｄ２Ｄ通信のＭＣＳについての想定は、例えばＱＰＳＫに固定されている。それゆえ、ステップ４）で、ＵＥは、ｅＮＢが必要なＤ２Ｄリソースサイズを計算するために十分なＢＳＲだけを報告する。他方で、動的なＭＣＳは、Ｄ２Ｄがチャネル変動に適応して効率的な送信を行うために極めて有用である。それゆえ、Ｄ２Ｄ通信対応ＵＥにとって、Ｄ２ＤのＭＣＳをｅＮＢに報告することは有用である。そうしない場合、ｅＮＢが正確なリソース配分を行うのが困難である。例えば、Ｄ２Ｄ送信に対し、１６ＱＡＭが適切であり、１０個のＰＲＢが必要であるとした場合、仮に、ｅＮＢがかかる状況を知らずに、必要なＰＲＢのサイズを計算するのにＱＰＳＫを使い続ければ、２０個のＰＲＢを割り当てることになり、リソースを大きく無駄使いすることになろう。

【0024】

したがって、必要なＤ２ＤリソースサイズをｅＮＢが計算するために、ｅＮＢにはＭＣＳも報告する必要があり得る。これまでのところ、ＬＴＥのＷＡＮ中には、Ｄ２Ｄ通信対応ＵＥがＤ２ＤチャネルのＭＣＳをｅＮＢに報告することをサポートするメカニズムはない。一つの解決策は、Ｄ２Ｄ通信対応ＵＥがＬ１中のＣＱＩ報告メカニズムを再使用することである。しかしながら、かかるメカニズムは、大きな仕様上の影響を与えることになろう。例えば、新規の報告モードおよびタイミングが必要となる。且つ、Ｌ１アップリンクでＣＱＩを報告することが、ＬＴＥ ＷＡＮ ＵＥのフィードバックに影響を与えかねず、ＬＴＥ ＷＡＮのパフォーマンスが劣化することになろう。そのために、本開示では新規のＭＣＳ報告メカニズムが提供される。あるいは、ＵＥは、ｅＮＢがリソース配分を実施するために、Ｄ２Ｄ送信に対して推奨されるリソースサイズを直接ｅＮＢに報告することもできる。このときには、ｅＮＢはＭＣＳ情報を知る必要はない。これに応じ、本開示はリソースサイズの報告メカニズムも提供する。

【0025】

図３は、本開示の或る実施形態による、Ｄ２Ｄ通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ通信方法のフローチャートを示す。方法３００は、Ｄ２Ｄ送信を実施するためにＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨されるＭＣＳまたは推奨されるリソースサイズを、ＭＡＣシグナリングまたはＲＲＣシグナリングを介して、Ｄ２Ｄ送信に対するリソースをスケジューリングするｅＮＢに報告するステップ３０１を含み、該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。本開示の本実施形態によれば、推奨されるＭＣＳまたは推奨されるリソースサイズが、ＭＡＣシグナリング（例えば、ＭＡＣ制御要素（ＭＡＣ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ, ＭＡＣ ＣＥ）で）またはＲＲＣシグナリングを介して報告されることになる。これにより、ｅＮＢは、Ｄ２Ｄ送信に対しよりきめ細かなリソース配分を実施することができよう。

【0026】

Ｄ２Ｄ通信においては、例えば、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、およびＤ２Ｄディスカバリチャネルがあり得る。本開示によれば、推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものとすることができる。言い換えれば、報告される推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルのチャネル条件を表すものとすることができる。具体的には、各チャネルに対する推奨されるＭＣＳまたは推奨されるリソースサイズを別々のＭＡＣ ＣＥ中で報告することもでき、複数のチャネルに対する推奨されるＭＣＳまたは推奨されるリソースサイズを同一のＭＡＣ ＣＥ中で報告することも可能である。さらに、各チャネルの特性を相異ならせることができる。例えば、ディスカバリチャネルは数秒の周期性で比較的に低速で送信されるが、データは数十ミリ秒で送信できる。したがって、少なくとも２つの相異なるチャネルに対する推奨されるＭＣＳまたは推奨されるリソースサイズは異なえて報告することができる。例えば、Ｄ２Ｄデータに対するＭＣＳおよびＤ２Ｄ制御に対するＭＣＳはＭＡＣシグナリングで（例えば、ＭＡＣ ＣＥ中で）報告することができ、ディスカバリチャネルに対するＭＣＳはＲＲＣシグナリングを使って報告することが可能である。言い換えれば、第一チャネルに対する推奨されるＭＣＳまたは推奨されるリソースサイズは、ＭＡＣシグナリングを介して報告でき、第一チャネルと異なる第二チャネルに対する推奨されるＭＣＳまたは推奨されるリソースサイズは、ＲＲＣシグナリングを介して報告することができる。さらに、ディスカバリチャネルはより長い周期性を有し得るので、その適切なＭＣＳまたはリソースサイズは、データチャネルおよび制御チャネルのものよりも遅く報告しトリガすることが可能である。図４は、データチャネル、制御チャネル、およびディスカバリチャネルに対する、例示的な相異なる報告方式を概略的に示す。図４に示されるように、Ｄ２Ｄデータチャネルに対するＭＣＳは最も高い頻度で送信され、Ｄ２Ｄ制御チャネルに対するＭＣＳは二番目に高い頻度で送信され、Ｄ２Ｄディスカバリチャネルに対するＭＣＳは最小の頻度で送信されている。この例であれば、Ｄ２Ｄデータチャネルに対するＭＣＳおよびＤ２Ｄ制御チャネルに対するＭＣＳはＭＡＣ ＣＥ中で報告することができ、Ｄ２Ｄディスカバリに対するＭＣＳはＲＲＣシグナリングを介して報告することが可能である。

【0027】

さらに、上記で説明したように、推奨されるＭＣＳを報告する場合に、Ｄ２Ｄ対応ワイヤレスデバイスからｅＮＢに、ｅＮＢが必要なリソースサイズを計算するため、バッファ状態報告（ＢＳＲ）も報告することができる。ＭＣＳをＢＳＲと併せて同時に報告すればよい。例えば、推奨されるＭＣＳを、ＢＳＲとともに同じＭＡＣ ＣＥ中で報告することができる。この場合、既存のシグナリングを再利用する利点がある。但し、ＢＳＲとは異なるＭＡＣ ＣＥで推奨されるＭＣＳを報告することも可能である。

【0028】

他方、推奨されるリソースサイズを報告する場合には、ｅＮＢは、必要なリソースサイズを計算するためにＢＳＲを必要とせず、受信された推奨されるリソースサイズによってリソースサイズを決めることができるので、Ｄ２Ｄ通信対応ワイヤレスデバイスからｅＮＢにＢＳＲを報告する必要はないであろう。但し、ＢＳＲは他の目的でも報告され得る。本開示において、推奨されるリソースサイズは、例えばＰＲＢペアの合計数（各サブフレームの周波数領域中のＰＲＢの数掛けるサブフレームの数）とすることが可能である。

【0029】

さらに、本開示において、ＭＣＳまたは推奨されるリソースサイズの報告には、ＭＡＣ ＣＥの一つのフォーマットだけを、すなわち、ＭＡＣ ＣＥの短フォーマットか長フォーマットかの区別をなくして、使用すればよい。また一方、本開示によれば、Ｄ２Ｄに対し、論理チャネルグループ（ＬＣＧ：Ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ ｇｒｏｕｐ）の概念を採用することも可能である。この場合、ＭＣＳ ＭＡＣ ＣＥまたはリソースサイズのＭＡＣ ＣＥに対し短または長フォーマットを再使用することができ、短ＭＣＳフォーマットに対し、予備または新規の論理チャネルＩＤ（ＬＣＧ ＩＤ：ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ ＩＤ）を使用することができる。さらに、Ｄ２Ｄ ＭＣＳまたは推奨されるリソースサイズに対するＭＡＣ ＣＥの優先度は、Ｄ２Ｄ ＢＳＲに対するＭＡＣ ＣＥに続くようにすることが可能である。例えば、ＭＣＳおよびＢＳＲのＭＡＣ ＣＥの優先度は、トラフィックの種類または報告の種類の如何によって、ＬＴＥのＭＡＣ ＣＥよりも低く、またはＬＴＥのＭＡＣ ＣＥの一部よりも高くてよい。

【0030】

本開示において、好ましくは、推奨されるＭＣＳの報告のトリガは、ＬＴＥ中に定義される対応規格を参照するＢＳＲの報告のトリガと同じにすることができる。これに換えて、推奨されるＭＣＳの報告、または推奨されるＭＣＳおよびＢＳＲ両方の報告をチャネル状態の変化によってトリガすることも可能である。例えば、チャネル中の変化によって、推奨されるＤ２Ｄ ＭＣＳがある事前定義された閾値の分変化したとき、ＵＥが、Ｄ２Ｄ ＭＣＳ、またはＤ２Ｄ ＭＣＳおよびＢＳＲの両方をｅＮＢに報告するようにし、ｅＮＢがこれに応じてＤ２Ｄリソース配分を更新するようにできよう。同様に、推奨されるリソースサイズの報告のトリガも、ＬＴＥ規格中のＢＳＲをトリガするための条件またはチャネル状態の変化に基づいて行うことができる。

【0031】

さらに、Ｄ２Ｄ通信対応ワイヤレスデバイスが推奨されるＭＣＳを得るために、Ｄ２Ｄ通信対応ワイヤレスデバイスは、例えば、潜在的な受信側Ｄ２Ｄ通信対応ＵＥのＤ２ＤＳＳ／ＰＤ２ＤＳＣＨの平均ＲＳＲＰ、または同期化ヘッドのＤ２ＤＳＳ／ＰＤ２ＤＳＣＨのＲＳＲＰなど、特定の測定結果に基づいて、ＭＣＳを算定することが可能である。これにより、推奨されるリソースサイズについて、Ｄ２Ｄ通信対応ワイヤレスデバイスは、送信対象のビット数、および該Ｄ２Ｄ通信対応ワイヤレスデバイスによって算定されたＭＣＳに基づいて、リソースサイズ（例えば、ＰＲＢペアの合計数）を計算することができる。

【0032】

さらに、Ｄ２Ｄ通信は、公共安全用途および商業用途など複数用途の状況をサポートすることができる。相異なる用途の状況に対して、推奨されるＭＣＳまたは推奨されるリソースサイズを報告するために相異なるまたは同一のＭＡＣシグナリングまたはＲＲＣシグナリングを用いることが可能である。例えば、相異なる用途の状況に対する推奨される諸ＭＣＳまたは推奨される諸リソースサイズを、別々のＭＡＣ ＣＥあるいは同一のＭＡＣ ＣＥ中で報告することができる。図５（ａ）および図５（ｂ）は、公共安全用途における状況および商業用途における状況に対する例示的なＭＣＳ報告方式を概略的に示す。図５（ａ）に示されるように、Ｄ２Ｄ商業用途に対し一つのＭＣＳ ＭＡＣ ＣＥが使用され、Ｄ２Ｄ公共安全用途（ｐｕｂｌｉｃ ｓａｆｅｔｙ ｃａｓｅ）に対し別のＭＣＳ ＭＡＣ ＣＥが使用されている。これら２つのＭＣＳ ＭＡＣ ＣＥは相互に独立しており、相異なるサブフレーム中で報告することが可能である。この場合、公共安全用途およびＤ２Ｄ商業用途のこれらのＤ２Ｄ ＭＣＳ報告は、ＭＡＣ ＣＥの同じフォーマットも使用することができ、ＭＡＣ ＣＥに意図されているのがどの用途かの解釈は、該ＭＡＣ ＣＥを送信しているサブフレームの数の如何によって、またはいくつかの条件の如何によって決まる（例えば、ＵＥが、ＰＵＳＣＨをスケジュールするため公共安全関連ＤＣＩを受信している場合、ＰＵＳＣＨ中の関連ＭＣＳ報告は、確実に公共安全用途である）。他方、図５（ｂ）に示されるように、Ｄ２Ｄ商業用途およびＤ２Ｄ公共安全用途の両方を反映するために、一つの共通のＭＣＳ ＭＡＣ ＣＥを使用することが可能である。

【0033】

本開示によれば、図６に示されるように、Ｄ２Ｄ通信に関わるｅＮＢの側で、Ｄ２Ｄ通信対応ワイヤレスデバイスによって実施予定のＤ２Ｄ送信に対するリソースをスケジューリングするため、ｅＮＢによって実施されるＤ２Ｄ通信方法６００が提供される。方法６００は、Ｄ２Ｄ通信対応ワイヤレスデバイスから、ＭＡＣシグナリングまたはＲＲＣシグナリングを介して報告された、Ｄ２Ｄ送信を実施するためにＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨されるＭＣＳまたは推奨されるリソースサイズを受信するステップ６０１を含み、該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。

【0034】

なお、ＭＣＳ報告に対する前述の提案は、Ｄ２Ｄについて報告するパワーヘッドルーム報告（ＰＨＲ：ｐｏｗｅｒ ｈｅａｄｒｏｏｍ ｒｅｐｏｒｔ）に対して用いることも可能である。例えば、相異なるＰＨＲ ＭＡＣ ＣＥ群が、それぞれ、制御、データ、およびディスカバリのチャネルに用いられ、あるいは同じＭＡＣ ＣＥがこれら全てのチャネルを報告する。

【0035】

以降に、Ｄ２Ｄ通信におけるリソース配分手順に、本開示の実施形態によるＤ２Ｄ通信方法を適用するいくつかの具体的な例を詳しく説明する。なお、これらの例は、説明のためにだけ用いられるのであって、決して本開示の範囲を限定するため用いられているものではない。

【0036】

第一の例において、図７は、本開示の或る実施形態によるＤ２Ｄ通信方法を用いた例示的なリソース配分手順を概略的に示しており、この図７に示されるように、基本的には３つのステップが関与する。ステップａ）で、ＩＮＣ Ｔｘ（送信側）ＵＥは、ｅＮＢにＢＳＲ／ＭＣＳ ＭＡＣ ＣＥ（群）を報告する。ステップｂ）で、ｅＮＢは、必要なＤ２Ｄリソースサイズを計算し、かかるリソースをＤ２Ｄ Ｔｘ ＵＥに割り当てる。ステップｃ）で、Ｄ２Ｄ Ｔｘ ＵＥは、ステップｂ）で得たリソースサイズを使ってＤ２Ｄ報知を行う。報知されたリソースサイズは、ＩＮＣ Ｒｘ（受信側）ＵＥおよびＯＯＣ Ｒｘ ＵＥによって受信が可能である。

【0037】

図８（ａ）および図８（ｂ）は、本開示の或る実施形態による、図２に示された例示的なリソース配分手順に基づく、Ｄ２Ｄ通信方法を用いたリソース配分手順の第二の例を概略的に示す。図８（ａ）はリソース配分手順の一般的な導入例であり、この図８（ａ）に示されるように、図８（ａ）と図２との間の違いは、送信側Ｄ２Ｄ通信対応ＵＥ（ＩＮＣ Ｔｘ ＵＥ）からｅＮＢに、ＢＳＲとともに（ステップ４に示されるように）ＭＣＳが報告されるということである。上記のため、送信側Ｄ２Ｄ通信対応ＵＥは、ＭＣＳを報告する前に、例えば、潜在的な受信側Ｄ２Ｄ通信対応ＵＥのＤ２ＤＳＳの平均ＲＳＲＰに基づいて、ＭＣＳの測定を実行することになる。ｅＮＢは、ステップ４からのＭＣＳ／ＢＳＲ報告に基づいて必要なＤ２Ｄリソースサイズを計算し、ステップ５で、そのＤ２Ｄリソース配分の指示を送信することになる。かかる指示はＭＣＳを含んでも含まなくてもよい。ステップ５でＭＣＳが示されない場合、それは、ｅＮＢが、リソースサイズを計算するためにＵＥによって推奨されたＭＣＳを用いていることを意味する。ステップ５で、ｅＮＢによって明示で示されたＭＣＳは、Ｄ２Ｄ通信対応ＵＥに対するＭＣＳ使用の確認と見なすことができよう。また、一部の場合において、ｅＮＢは、リソースの状況によっては、Ｄ２Ｄ通信対応ＵＥから報告されたＭＣＳを覆すこともできよう。ステップ５の後、ステップ６および７において、Ｄ２Ｄ通信対応ＵＥはＤ２Ｄ通信を実行することになる。重要なことには、ステップ６において、送信側Ｄ２Ｄ通信対応ＵＥによって送信されたスケジューリング割り当てには、動的ＭＣＳ送信をサポートするためのＭＣＳ情報を含めることが可能である。

【0038】

第二の例において、図８（ａ）中のステップ４および５における、送信側Ｄ２Ｄ通信対応ＵＥとｅＮＢとの間の詳細なシグナリングのやり取りについては、図８（ｂ）を参照することができる。図８（ｂ）に示されるように、基本的には、ＵＥは、ＰＵＣＣＨ中の専用スケジューリング要求（Ｄ−ＳＲ：ｄｅｄｉｃａｔｅｄ ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ）をｅＮＢに送信することになり（ステップａ）、このとき、ｅＮＢは、ＬＴＥ ＷＡＮ ＰＵＳＣＨリソースを割り当てるために、ＬＴＥ ＷＡＮ（Ｅ）ＰＤＣＣＨ中でＤＣＩを割り当てることになる（ステップｂ）。特定のＭＣＳ測定に基づいて（例えば、全ての潜在的受信側Ｄ２Ｄ通信対応ＵＥのＤ２ＤＳＳの平均ＲＳＲＰに基づいて）、ＵＥは、割り当てられたＰＵＳＣＨで、ＢＳＲおよびＭＣＳ ＭＡＣ ＣＥを同時に報告することになる（ステップｃ）。その後、ｅＮＢは、Ｄ２Ｄリソース配分のためのＤＣＩを送信することになる。

【0039】

図９（ａ）および図９（ｂ）は、本開示の或る実施形態による、図２に示された例示的なリソース配分手順に基づく、Ｄ２Ｄ通信方法を用いたリソース配分手順の第三の例を概略的に示す。この第三の例は第二の例と類似である。違いは、第三の例中の送信側Ｄ２Ｄ通信対応ＵＥが、自分のトラフィック状況およびＭＣＳ測定に基づいて必要なリソースサイズを計算し、これによりステップ４で、ＢＳＲおよびＭＣＳ ＭＡＣ ＣＥ（群）の代わりに（ＭＡＣ ＣＥに関して）推奨されるリソースサイズをｅＮＢに報告することになること、だけにある。図９（ａ）中のステップ４および５についての詳細な動きについては、図９（ｂ）を参照することができる。図９（ｂ）と図８（ｂ）との間の唯一の違いは、図９（ｂ）中のＤ２Ｄ ＵＥは、必要なリソースサイズを自分で計算することになり、ＢＳＲおよびＭＣＳ ＭＡＣ ＣＥの代わりに、（図９（ｂ）中のステップｃに示されるように）かかるリソースサイズを反映した一つのＭＡＣ ＣＥがｅＮＢに報告されることである。ｅＮＢは、Ｄ２Ｄ通信対応ＵＥ（Ｄ２Ｄ ＵＥ）のＭＣＳ状況を知らないので、図９（ｂ）のステップｄに示されるように、ｅＮＢが、ＭＣＳを示す必要はない。

【0040】

上記において、本開示の諸実施形態による、Ｄ２Ｄ通信におけるリソース配分手順のいくつかの具体的な例を詳しく説明している。しかしながら、これらの例は説明目的のためだけに用いられているのであって、決して本開示の範囲を限定するものでないことに留意する。

【0041】

本開示において、端末間（Ｄ２Ｄ）通信対応ワイヤレスデバイス（例えば、Ｄ２Ｄ通信対応ＵＥ）が提供される。図１０は、本開示の或る実施形態による、Ｄ２Ｄ通信対応ワイヤレスデバイス１０００を示すブロック図である。Ｄ２Ｄ通信対応ワイヤレスデバイス１０００は、Ｄ２Ｄ送信を実施するためにＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを、メディアアクセス制御（ＭＡＣ）シグナリングまたは無線リソース制御（ＲＲＣ）シグナリングを介して、Ｄ２Ｄ送信に対するリソースをスケジューリングするｅＮｏｄｅ Ｂ（ｅＮＢ）に報告するよう構成された、報告部１００１を含み、該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。

【0042】

本開示によるＤ２Ｄ通信対応ワイヤレスデバイス１０００は、随意的に、ワイヤレスデバイス１０００中の様々なデータを処理し、それぞれの構成部のオペレーションを制御する関連プログラムを実行するためのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（中央処理装置））１０１０、ＣＰＵ１０１０によって様々なプロセスおよび制御を実施するため必要な様々なプログラムを格納するためのＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（読み取り専用メモリ））１０１３、ＣＰＵ１０１０によってプロセスおよび制御の手順の中で一時的に生成される中間データを格納するためのＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ランダムアクセスメモリ））１０１５、および／または様々なプログラム、データなどを格納するためのストレージ部１０１７を含んでよい。上記の報告部１００１、ＣＰＵ１０１０、ＲＯＭ１０１３、ＲＡＭ１０１５、および／またはストレージ部１０１７などは、データおよび／またはコマンドバス１０２０を介して相互接続し、相互の間で信号を送信することができる。

【0043】

前述のそれぞれの構成部は本開示の範囲を限定するものではない。本開示の一つの実装によれば、上記の報告部１００１の機能はハードウェアによって実装することが可能で、上記のＣＰＵ１０１０、ＲＯＭ１０１３、ＲＡＭ１０１５、および／またはストレージ部１０１７は不必要にすることができる。あるいは、上記の報告部１００１の機能は、上記のＣＰＵ１０１０、ＲＯＭ１０１３、ＲＡＭ１０１５、および／またはストレージ部１０１７などと組み合わせた機能ソフトウェアによって実装することも可能である。

【0044】

さらに、本開示では、前述の方法を実施するためのｅＮＢも提供される。図１１は、Ｄ２Ｄ通信対応ワイヤレスデバイスによって実施されるＤ２Ｄ送信に対するリソースをスケジューリングするためのｅＮＢ１１００を示すブロック図である。ｅＮＢ１１００は、Ｄ２Ｄ通信対応ワイヤレスデバイスから、メディアアクセス制御（ＭＡＣ）シグナリングまたは無線リソース制御（ＲＲＣ）シグナリングを介して報告された、Ｄ２Ｄ送信を実施するためＤ２Ｄ通信対応ワイヤレスデバイスによって使用されるべき推奨される変調および符号化スキーム（ＭＣＳ）または推奨されるリソースサイズを受信するよう構成された、受信部１１０１を含み、該推奨されるＭＣＳまたは推奨されるリソースサイズは、Ｄ２Ｄデータチャネル、Ｄ２Ｄ制御チャネル、および／またはＤ２Ｄディスカバリチャネルに対するものである。

【0045】

本開示によるｅＮＢ１１００は、随意的に、ｅＮＢ１１００中の様々なデータを処理し、それぞれの構成部のオペレーションを制御する関連プログラムを実行するためのＣＰＵ（中央処理装置）１１１０、ＣＰＵ１１１０によって様々なプロセスおよび制御を実施するため必要な様々なプログラムを格納するためのＲＯＭ（読み取り専用メモリ）１１１３、ＣＰＵ１１１０によってプロセスおよび制御の手順の中で一時的に生成される中間データを格納するためのＲＡＭ（ランダムアクセスメモリ）１１１５、および／または様々なプログラム、データなどを格納するためのストレージ部１１１７を含んでよい。上記の受信部１１０１、ＣＰＵ１１１０、ＲＯＭ１１１３、ＲＡＭ１１１５、および／またはストレージ部１１１７などは、データおよび／またはコマンドバス１１２０を介して相互接続し、相互の間で信号を送信することができる。

【0046】

前述のそれぞれの構成部は本開示の範囲を限定するものではない。本開示の一つの実装によれば、上記の受信部１１０１の機能はハードウェアによって実装することが可能で、上記のＣＰＵ１１１０、ＲＯＭ１１１３、ＲＡＭ１１１５、および／またはストレージ部１１１７は不必要にすることができる。あるいは、上記の受信部１１０１の機能は、上記のＣＰＵ１１１０、ＲＯＭ１１１３、ＲＡＭ１１１５、および／またはストレージ部１１１７などと組み合わせた機能ソフトウェアによって実装することも可能である。

【0047】

なお、本方法についての前述した説明は、これらデバイスにも適用され、しかしてここではこれらの詳細は省略する。

【0048】

本開示は、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアとの共同によって実現することができる。前述した各実施形態の説明中で用いられた各機能ブロックは、集積回路としてＬＳＩによって実現が可能である。これらは、チップ群として個別に形成することができ、または、一つのチップを、これら機能ブロックの一部または全部を含むように形成することも可能である。このＬＳＩは、集積度合いの差の如何によって、ＩＣ、システムＬＳＩ、超ＬＳＩ、または極超ＬＳＩと言及することができる。但し、集積回路を実装する技術は、ＬＳＩに限定されるものでなく専用の回路または汎用プロセッサを使用することによっても実現できる。加えて、ＬＳＩの製造の後、プログラムが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ（フィールドプログラマブルゲートアレイ））、またはＬＳＩ内部に配置された回路セルの接続および設定を再構成できる再構成可能プロセッサを使用してもよい。さらに、各機能ブロックの計算は、例えば、ＤＳＰまたはＣＰＵを含め、計算手段を用いて実施することができ、各機能の処理ステップは、実行のためのプログラムとして記録媒体上に記録することが可能である。なおその上に、半導体技術または他の派生的な技術の進展に伴って、ＬＳＩにとって代わる集積回路を実装する技術が出現したときには、かかる技術の使用によってこの機能ブロックを集積することが可能なのは明らかである。

【0049】

なお、本開示は、当業者が、本明細書で提示した説明および既知の技術に基づいて、本開示の内容および範囲から逸脱することなく、多様に変更または修改されることを意図しており、かかる変更および応用は、保護対象として請求される範囲に含まれる。さらに、本開示の内容を逸脱しない範囲内で、前述した実施形態の構成要素を任意に組み合わせることが可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】