特表 2022-542341 Ｖ２Ｘ通信装置のためのＤＣＩの通信装置及び通信方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-10-03

(54)【発明の名称】Ｖ２Ｘ通信装置のためのＤＣＩの通信装置及び通信方法

(51)【国際特許分類】

   H04W 72/12 20090101AFI20220926BHJP

   H04W 92/18 20090101ALI20220926BHJP

   H04W 72/04 20090101ALI20220926BHJP

【ＦＩ】

H04W72/12 110

H04W92/18

H04W72/04 136

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021576760

(86)(22)【出願日】2020-06-25

(85)【翻訳文提出日】2021-12-23

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

(87)【国際公開番号】W WO2021021015

(87)【国際公開日】2021-02-04

(31)【優先権主張番号】10201907070S

(32)【優先日】2019-07-31

(33)【優先権主張国・地域又は機関】SG

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．３ＧＰＰ

(71)【出願人】

【識別番号】514136668

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

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

(74)【代理人】

【識別番号】110002952

【氏名又は名称】弁理士法人鷲田国際特許事務所

(72)【発明者】

【氏名】カン ヤン

(72)【発明者】

【氏名】コウ ティアン ミン ベンジャミン

(72)【発明者】

【氏名】ホァン レイ

(72)【発明者】

【氏名】トラン ズワーン タオング

(72)【発明者】

【氏名】リ イーフェイ

(72)【発明者】

【氏名】アルーン プラサド アニータ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067DD34

5K067EE02

5K067EE10

5K067EE25

(57)【要約】

本開示は、Ｖ２Ｘ通信装置のためのＤＣＩの通信装置及び通信方法を提供する。通信装置は、動作中に通信装置が受信モードにあるか否かを示すメッセージを生成する回路と、動作中にメッセージを通信装置に送信する送信機とを有する基地局を含む。

【特許請求の範囲】

【請求項1】

通信装置であって、
動作中に前記通信装置が受信モードにあるか否かを示すメッセージを受信する受信機と、
動作中に前記通信装置が前記受信モードにないとき、信号を送信する送信機と、
を有する通信装置。

【請求項2】

前記メッセージは、前記通信装置が前記受信モードにある受信ウィンドウを示し、前記受信機は、前記通信装置が前記受信モードにあるとき、送信ブロック（ＴＢ）を受信するよう構成される、
請求項１に記載の通信装置。

【請求項3】

前記メッセージは、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）のフォーマットである、
請求項１に記載の通信装置。

【請求項4】

基地局であって、
動作中に通信装置が受信モードにあるか否かを示すメッセージを生成する回路と、
動作中に前記メッセージを前記通信装置に送信する送信機と、
を有する基地局。

【請求項5】

動作中に送信側の通信装置からスケジューリング情報を受信する受信機を更に有し、
前記スケジューリング情報は、前記通信装置を識別する、
請求項４に記載の基地局。

【請求項6】

前記スケジューリング情報は、複数の通信装置を識別し、
前記メッセージは、前記複数の通信装置がグループキャストの受信モードにあるか否かを示し、
前記送信機は、前記メッセージを前記複数の通信装置に送信する、
請求項５に記載の基地局。

【請求項7】

前記スケジューリング情報は、複数の通信装置を識別し、
前記メッセージは、前記複数の通信装置がブロードキャストの受信モードにあるか否かを示し、
前記送信機は、前記メッセージを前記複数の通信装置に送信する、
請求項５に記載の基地局。

【請求項8】

前記送信機は更に、前記送信側の通信装置にＤＣＩを送信するよう構成され、
前記ＤＣＩは、前記メッセージが前記通信装置に送信されたことを示す、
請求項５に記載の基地局。

【請求項9】

前記メッセージは、前記通信装置が前記受信モードにある受信ウィンドウを示し、
前記通信装置は、前記受信ウィンドウの間に送信ブロック（ＴＢ）を受信するよう構成される、
請求項４に記載の基地局。

【請求項10】

前記受信ウィンドウは、前記ＴＢを受信するためのリソース割当ての周波数及びタイミング情報を含む、
請求項９に記載の基地局。

【請求項11】

前記受信ウィンドウは、前記ＴＢを受信するためのインデックスを含む、
請求項９に記載の基地局。

【請求項12】

前記受信ウィンドウは、前記ＴＢを受信するためのリソースプール設定を含む、
請求項９に記載の基地局。

【請求項13】

前記受信ウィンドウは、前記ＴＢを受信するためのリソース割当て及び変調符号化方式（ＭＣＳ）に関する完全な情報を含み、
前記ＴＢのためのＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）上のＳＣＩ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージの送信は放棄される、
請求項９に記載の基地局。

【請求項14】

前記メッセージは、ＤＣＩのフォーマットである、
請求項４に記載の基地局。

【請求項15】

通信装置の通信方法であって、
通信装置が受信モードであるか否かを示すメッセージを生成することと、
前記メッセージを前記通信装置に送信することと、
を有する通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

以下の開示は、ＮＲ（Ｎｅｗ Ｒａｄｉｏ）通信のための通信装置及び通信方法に関し、より詳細には、Ｖ２Ｘ通信装置のためのＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）の通信装置及び通信方法に関する。

【背景技術】

【0002】

Ｖ２Ｘ通信は、車両が公道及び他の道路の利用者と相互作用することを可能にし、従って、自律車両を現実のものにする上で重要な要素と考えられている。

【0003】

このプロセスを加速するため、５Ｇ ＮＲベースのＶ２Ｘ通信（互換的にＮＲ Ｖ２Ｘ通信と呼ばれる）が、高度なＶ２Ｘサービスのための技術的解決策を特定するため３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）によって議論され、これを介して車両（すなわち、Ｖ２Ｘアプリケーションをサポートする通信装置又はユーザ装置（ＵＥ）と互換的に呼ばれる）は、サイドリンク（ＳＬ）を介して他の近くの車両、インフラストラクチャノード及び／又は歩行者と自らの状態情報をやりとりすることができる。状態情報は、位置、速度、方位等の情報を含む。

【0004】

そのようなＶ２Ｘ通信では、少なくとも２つのＳＬリソース割当モードが３ＧＰＰによって議論されている。リソース割当モード１では、ＳＬ送信のために端末によって使用されるＳＬリソースは、基地局（ＢＳ）によってスケジューリングされる。リソース割当モード２では、ＵＥは、ＢＳ／ネットワークによって設定されたＳＬリソース又は事前に設定されたＳＬリソース内でＳＬ送信リソースを決定し、すなわち、ＢＳはスケジューリングしない。リソース割当てに関する３ＧＰＰスタディはまた、リソースが異なる送信ブロック（ＴＢ）の複数の送信に対して選択されるセミパーシステント方式と、リソースが各ＴＢ送信に対して選択されるダイナミック方式とのコンテクストにおいて、モード２（ａ）のためのセンシング及びリソース選択手順を検討する。

【0005】

３ＧＰＰ ＴＳＧ ＲＡＮ Ｍｅｅｔｉｎｇ ＃８３のドキュメントＲＰ－１９０７６６において議論されるように、ＮＲサイドリンクによる５Ｇ Ｖ２Ｘに関するＷＩＤ（Ｗｏｒｋ Ｉｔｅｍ Ｄｅｓｃｒｉｐｔｉｏｎ）では、以下の項目が検討される。
－ネットワーク内カバレッジ、ネットワーク外カバレッジ及び部分的なネットワークカバレッジを考慮して、Ｖ２Ｘサービスに対するサイドリンクユニキャスト、サイドリンクグループキャスト及びサイドリンクブロードキャストをサポートするのに必要なＮＲサイドリンク解決策の指定
－モード１：ＵｕがＵＥと基地局との間の論理インタフェースを参照する検討結果によるＮＲ ＵｕとＬＴＥ ＵｕとによってスケジューリングされるＮＲサイドリンク
－モード２：検討結果によるＮＲ ＵｕとＬＴＥ Ｕｕとによる設定及びサイドリンク事前設定に基づくセンシング及びリソース選択手順
－ＵＥのモード１及びモード２の同時設定のサポート
・当該設定における送信機ＵＥの動作は、モード１のみ及びモード２のみの設計後に議論されるべきである。
・受信機ＵＥは、送信機ＵＥによって利用されるリソース割当モードを知ることなく送信を受信できる。

【0006】

しかしながら、Ｖ２Ｘ通信装置のためのＤＣＩの通信装置及び方法に関する議論はされていない。

【0007】

従って、Ｖ２Ｘ通信装置のためのＤＣＩの実現可能な技術的解決策を提供する通信装置及び方法が必要とされる。さらに、他の望ましい特徴及び特性が、添付の図面及び本開示の背景と共に、以下の詳細な説明及び添付の請求項から明らかになるであろう。

【発明の概要】

【0008】

非限定的及び例示的な実施例は、Ｖ２Ｘ通信装置のためのＤＣＩの通信装置及び方法を提供することを容易にする。

【0009】

本開示の第１の実施例によると、通信装置であって、動作中に前記通信装置が受信モードにあるか否かを示すメッセージを受信する受信機と、動作中に前記通信装置が前記受信モードにないとき、信号を送信する送信機と、を有する通信装置が提供される。

【0010】

本開示の第２の実施例によると、基地局であって、動作中に通信装置が受信モードにあるか否かを示すメッセージを生成する回路と、動作中に前記メッセージを前記通信装置に送信する送信機と、を有する基地局が提供される。

【0011】

本開示の第３の実施例によると、通信方法であって、通信装置が受信モードであるか否かを示すメッセージを生成することと、前記メッセージを前記通信装置に送信することと、を有する通信方法が提供される。

【0012】

全体的又は特定の実施例は、システム、方法、集積回路、コンピュータプログラム、記憶媒体又はそれらの何れか選択的な組み合わせとして実現されてもよいことが留意されるべきである。

【0013】

開示された実施例の更なる利益及び利点は、明細書及び図面から明らかになるであろう。利益及び／又は利点は、明細書及び図面の様々な実施例及び特徴によって個別に取得されてもよく、これらは、そのような利益及び／又は利点の１つ以上を得るために全てが提供される必要はない。

【図面の簡単な説明】

【0014】

本開示の実施例は、単なる例示として図面と共に以下に記載される説明から当業者により良好に理解され、容易に明らかになるであろう。

【図1】３ＧＰＰ ＮＲシステムの例示的なアーキテクチャを示す。

【図2】ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す概略図である。

【図3】ＲＲＣ接続設定／再設定手順のためのシーケンス図である。

【図4】ｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ｍＭＴＣ（ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）及びＵＲＬＬＣ（Ｕｌｔｒａ Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）の利用シナリオを示す概略図である。

【図5】非ローミングシナリオのための例示的な５Ｇシステムアーキテクチャを示すブロック図である。

【図6】ｇＮｏｄｅＢ（ｇＮＢ）又は基地局が、典型的にＶ２Ｘ通信においてＤＣＩ（すなわち、ＤＣＩ＿Ｘ）をどのように利用するかを示す概略図を示す。

【図7】各種実施例によるｇＮＢ又は基地局がＶ２Ｘ通信においてＤＣＩ＿Ｙをどのように利用するかを示す概略図を示す。

【図8】各種実施例によるｇＮＢ又は基地局がＶ２Ｘ通信においてＤＣＩ＿Ｙをどのように利用するかを示す概略図を示す。

【図9】各種実施例によるｇＮＢ又は基地局がＶ２Ｘ通信においてグループキャストのためのＤＣＩ＿Ｙをどのように利用するかを示す概略図を示す。

【図10】各種実施例によるｇＮＢ又は基地局がＶ２Ｘ通信においてＤＣＩ＿ＹとしてＤＣＩ＿Ｘをどのように利用するかを示す概略図を示す。

【図11】各種実施例によるｇＮＢ又は基地局がＶ２Ｘ通信においてブロードキャストのためのＤＣＩ＿Ｙをどのように利用するかを示す概略図を示す。

【図12】各種実施例によるｇＮＢ又は基地局がＶ２Ｘ通信においてＤＣＩ＿Ｙをどのように利用するかの他の具体例を示す概略図を示す。

【図13】各種実施例による典型的なＤＣＩ＿Ｘメッセージのフォーマットを示す。

【図14】各種実施例によるＤＣＩ＿Ｙメッセージのフォーマットを示す。

【図15】各種実施例による受信ウィンドウがＤＣＩ＿Ｙメッセージにおいてどのように通知されるかの具体例を示す。

【図16】各種実施例による受信ウィンドウがＤＣＩ＿Ｙメッセージにおいてどのように通知されるかの具体例を示す。

【図17】各種実施例による受信ウィンドウがＤＣＩ＿Ｙメッセージにおいてどのように通知されるかの具体例を示す。

【図18】各種実施例による受信ウィンドウがＤＣＩ＿Ｙメッセージにおいてどのように通知されるかの具体例を示す。

【図19】各種実施例による受信ウィンドウがＤＣＩ＿Ｙメッセージにおいてどのように通知されるかの具体例を示す。

【図20】各種実施例による通信方法を示すフロー図を示す。

【図21】各種実施例による通信装置の概略的な具体例を示す。通信装置は、本開示の各種実施例によるＵＥ又はｇＮＢ／基地局として実現されてもよく、Ｖ２Ｘ通信のためのＤＣＩに対して設定されてもよい。

【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】

上述されるように、Ｔｘ ＵＥ６０４がＳＬ ＴＢ６１０をＲｘ ＵＥ６０６に送信しているときと同時にＲｘ ＵＥ６０６が送信している場合、Ｒｘ ＵＥ６０６は、Ｔｘ ＵＥ６０４からＳＬ ＴＢ６１０を受信することができない。

【0050】

従って、本発明は、Ｒｘ ＵＥがＴｘ ＵＥから送信を受信するようにスケジューリングされるよう改良された通信手順を提案する。

【0051】

以下の段落では、特定の例示的な実施例が、１つ以上の通信装置がＴｘ ＵＥからの送信の欠落を回避することを効果的に可能にするｇＮＢ／基地局と１つ以上のターゲット通信装置との間のＶ２Ｘ通信機構を参照して説明される。

【0052】

サイドリンクモード－１で送信される特定のＴＢについて、ｇＮＢ又は基地局によってリソース割当てのためＴｘ ＵＥに送信されるＤＣＩ＿Ｘ（ＬＴＥ Ｖ２ＸにおけるＤＣＩ＿５Ａとして）に加えて、ｇＮＢはまた、当該ＴＢのための独立したＤＣＩを用いてＲｘ ＵＥをスケジューリングする。

【0053】

図７は、各種実施例によるＶ２Ｘ通信においてｇＮＢ又は基地局がどのようにＤＣＩ＿Ｙを利用するかを示す概略図７００を示す。Ｔｘ ＵＥ７０４がＲｘ ＵＥ７０６にＳＬ ＴＢ７１０を送信するのに利用しうるリソース割り当て情報を提供するためにＤＣＩ＿Ｘ７０８をＴｘ ＵＥ７０４に送信することに加えて、基地局７０２はまた、Ｒｘ ＵＥ７０６にメッセージ（すなわち、ＤＣＩ＿Ｙ７１２）を送信する。ＤＣＩ＿Ｙ７１２は、Ｒｘ ＵＥ７０６が予想されるＳＬ ＴＢ７１０のための受信モードにあることを示すよう規定される新たなＤＣＩフォーマットであってもよい。効果的には、Ｒｘ ＵＥ７０６は、ＤＣＩ＿Ｙ７１２を受信することによってＳＬ ＴＢ７１０の送信を予想するようスケジューリングされるため、ＳＬ ＴＢ７１０の受信を失う可能性が少ない。

【0054】

ＤＣＩ＿Ｘ及びＤＣＩ＿Ｙのコンテンツについて、最小の要求は以下のように規定されてもよい。
－ＤＣＩ＿Ｘ：ＳＬ ＴＢを送信するためｇＮＢ又は基地局によって許可される時間周波数リソース及び（明示的又は暗黙的）Ｔｘ ＵＥ識別（ＩＤ）情報
－ＤＣＩ＿Ｙ：許可された時間周波数リソースの“受信ウィンドウ”及び（明示的又は暗黙的）Ｒｘ ＵＥ ＩＤ情報
－“受信ウィンドウ”は、許可された時間周波数リソースのタイミング情報を少なくとも含んでもよい。

【0055】

さらに、Ｒｘ ＵＥは、Ｔｘ ＵＥと同じｇＮＢ又は基地局（同一又は異なるセル）とＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるべきである。

【0056】

図８は、各種実施例によるＶ２Ｘ通信においてｇＮＢ又は基地局がどのようにＤＣＩ＿Ｙを利用するかを示すメッセージフロー８００を示す。ＳＬ ＴＢ８１０が、例えば、ユニキャストによってＴｘ ＵＥ８０４によってＲｘ ＵＥ８０６に送信されるシナリオについて、Ｔｘ ＵＥ８０４はまず、図８のステップ１に示されるように、サービングｇＮＢ８０２にスケジューリング情報８１４を送信してもよい。スケジューリング情報８１４は、スケジューリングリクエストと、少なくともＲｘ ＵＥ８０６の宛先ＩＤ（例えば、ＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）、Ｌ１／Ｌ２宛先ＩＤなど）を含むレポートとを有してもよい。そして、ｇＮＢ８０２は、図８のステップ２に示されるように、ＳＬ ＴＢ８１０のリソース割当てに関する専用のＤＣＩ＿Ｘ８０８をＴｘ ＵＥ８０４に送信してもよい。ｇＮＢ８０２はまた、図８のステップ３に示されるように、ＳＬ ＴＢ８１０のための受信ウィンドウを示す専用のＤＣＩ＿Ｙ８１２をＲｘ ＵＥ８０６に送信してもよい。ＤＣＩ＿Ｘ８０８において通知されるような許可されたリソースを使用して、Ｔｘ ＵＥ８０４は、図８のステップ４に示されるように、ＰＳＣＣＨ上で送信されるＳＬ ＴＢ８１０のための制御情報と共に、ＰＳＳＣＨ上でＳＬ ＴＢ８１０をＲｘ ＵＥ８０６に送信する。Ｒｘ ＵＥ８０６は、ＳＬ ＴＢ８１０の送信を受信するため、ＤＣＩ＿Ｙ８１２に示される受信ウィンドウ内で受信専用モードにある。効果的には、Ｒｘ ＵＥ８０６は、ＳＬ ＴＢ８１０が予想されるときには送信せず、従って、半二重問題が回避される。

【0057】

ＤＣＩ＿Ｙ８１２は、ｇＮＢ８０２からＴｘ ＵＥ８０４へのＤＣＩ＿Ｘ８０８の送信前、送信後又は送信と同時にＲｘ ＵＥ８０６に送信されてもよいことが理解されるであろう。Ｔｘ ＵＥ８０４は、ＤＣＩ＿Ｘ８１０及びＤＣＩ＿Ｙ８１２に対してＵＥの復号化が完了した後、ＰＳＣＣＨ上で送信されるＳＬ ＴＢ８１０に対する制御情報と共に、ＰＳＳＣＨ上でＴＢ８１０をＲｘ ＵＥ８０６に送信してもよい。

【0058】

各種実施例において、ＳＬ ＴＢは、グループキャストによってＲｘ ＵＥのグループへの送信のためにスケジューリングされてもよい。図９は、各種実施例によるＶ２Ｘ通信におけるグループキャストのためｇＮＢ又は基地局がどのようにＤＣＩ＿Ｙを利用するかを示す概略図９００を示す。図７及び図８に示されるような具体例と同様に、Ｔｘ ＵＥ９０４はまずｇＮＢ９０２にスケジューリング情報を送信してもよい。スケジューリング情報は、スケジューリングリクエストと、送信されるべきＳＬ ＴＢ９１０がグループキャストのためのものであることを示す宛先グループＩＤを少なくとも含むレポートとを有してもよい。この情報に基づいて、ｇＮＢ９０２は、ＳＬ ＴＢ９１０の送信のためのリソーススケジューリングのためにＵｕを介してＤＣＩ＿Ｘ９０８をＴｘ ＵＥ９０４に送信すると共に、ＳＬ ＴＢ９１０の送信を受信するための受信ウィンドウを示すため、宛先グループＩＤによって識別されるように、Ｕｕを介してＲｘ ＵＥ９０６のグループにメッセージ（すなわち、ＤＣＩ＿Ｙ９１２）を送信してもよい。Ｒｘ ＵＥ９０６のグループは、複数のＵＥであってもよい。ＤＣＩ＿Ｙ９１２は、Ｒｘ ＵＥ９０６のグループに向けられる単一のメッセージとして受信されてもよい。一実施例では、ｇＮＢ９０２はまた複数のＤＣＩ＿Ｙメッセージを送信してもよく、各ＤＣＩ＿Ｙ９１２は、ＳＬ ＴＢ４１０の受信ウィンドウを通知するため、グループ内の複数のＲｘ ＵＥ９０６のそれぞれに送信される。従って、ＳＬ ＴＢ９１０は、その後にＤＣＩ＿Ｘ９０８に示され、ＤＣＩ＿Ｙ９１２に示される受信ウィンドウ内において割り当てられたリソースを利用して、ＰＳＣＣＨ及びＰＳＳＣＨ上でＴｘ ＵＥ９０４からＲｘ ＵＥ９０６のグループに送信される。

【0059】

各種実施例において、ＤＣＩ＿Ｘメッセージは、ＤＣＩ＿Ｙメッセージとして送信されてもよい。図１０は、各種実施例によるＶ２Ｘ通信においてｇＮＢ又は基地局がどのようにＤＣＩ＿ＸをＤＣＩ＿Ｙとして利用しうるかを示す概略図１０００を示す。図８及び図９に示す具体例と同様に、ＵＥ１００４はまずｇＮＢ１００２にスケジューリング情報を送信してもよい。スケジューリング情報は、スケジューリングリクエストと、送信されるべきＳＬ ＴＢ１０１０がグループキャスト又はブロードキャストのためのものであることを示す宛先ＩＤを少なくとも含むレポートとを有してもよい。宛先ＩＤは、グループＩＤ、Ｌ１／Ｌ２宛先ＩＤ、セッションＩＤ、サービスインデックスなどを含んでもよい。この情報に基づいて、ｇＮＢ１００２は、ＳＬ ＴＢ１０１０の送信のためのリソーススケジューリングのために、ＤＣＩ＿Ｘ１００８をＵｕを介しＴｘ ＵＥ１００４に送信してもよい。同じＤＣＩ＿Ｘ１００８がまた、ＳＬ ＴＢ１０１０の送信を受信するための受信ウィンドウを示すため、宛先ＩＤによって識別されるＲｘ ＵＥ１００６のグループにＵｕを介しＤＣＩ＿Ｙ１０１２メッセージとして送信されてもよい。Ｒｘ ＵＥ１００６のグループは、複数のＵＥであってもよい。ＤＣＩ＿Ｙ１０１２は、Ｒｘ ＵＥ１００６のグループに向けられた単一のメッセージとして受信されてもよい。一実施例では、ｇＮＢ５０２はまた、複数のＤＣＩ＿Ｙ１０１２メッセージを送信してもよく、ここで、各ＤＣＩ＿Ｙ１０１２は、ＳＬ ＴＢ１０１０の受信ウィンドウを通知するため、グループ内の複数のＲｘ ＵＥ１００６のそれぞれに送信される。従って、ＳＬ ＴＢ１０１０は、その後にＤＣＩ＿Ｘ１００８に示され、ＤＣＩ＿Ｙ１０１２に示されるような受信ウィンドウ内において割り当てられたリソースを利用して、ＰＳＣＣＨ及びＰＳＳＣＨ上でＴｘ ＵＥ１００４からＲｘ ＵＥ１００６のグループに送信される。本実施例においてＤＣＩ＿Ｘ１００８がまたＤＣＩ＿Ｙ１０１２として使用されるとき、ＤＣＩ＿Ｘ１００８は、Ｔｘ ＵＥ ＩＤ及びＲｘ ＵＥグループＩＤの両方を含みうる。

【0060】

各種実施例において、ＳＬ ＴＢは、意図されたＲｘ ＵＥへのブロードキャスト送信としてスケジューリングされてもよい。図１１は、各種実施例によるＶ２Ｘ通信におけるブロードキャストのためｇＮＢ又は基地局がどのようにＤＣＩ＿Ｙを利用するかを示す概略図１１００を示す。図８及び図１０に示される具体例と同様に、Ｔｘ ＵＥ６０４はまず、ｇＮＢ１１０２にスケジューリング情報を送信してもよい。スケジューリング情報は、スケジューリングリクエストと、送信されるべきＳＬ ＴＢ１１１０が１つ以上のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータ／インジケータと共にブロードキャストするためのものであることを示す宛先ＩＤを少なくとも含むレポートとを有してもよい。１つ以上のＱｏＳパラメータ／インジケータは、５Ｇ ＱｏＳ識別子（５ＱＩ）、Ｖ２Ｘ ５ＱＩ（ＶＱＩ）、遅延、プライオリティ及び他の同様のインジケータを含んでもよい。宛先ＩＤは、グループＩＤ、Ｌ１／Ｌ２宛先ＩＤ、セッションＩＤ、サービスインデックスなどを含んでもよい。この情報に基づいて、ｇＮＢ１１０２は、ＳＬ ＴＢ１１１０の送信のためのリソーススケジューリングのためにＵｕを介してＤＣＩ＿Ｘ１１０８をＴｘ ＵＥ１１０４に送信すると共に、ＳＬ ＴＢ１１１０の送信を受信するための受信ウィンドウを少なくとも通知するため宛先ＩＤによって識別されるＲｘ ＵＥ１１０６のグループへのブロードキャストとしてメッセージ（すなわち、ＤＣＩ＿Ｙ１１１２）を送信してもよい。Ｒｘ ＵＥ１１０６のグループは、複数のＵＥであってもよい。従って、ＳＬ ＴＢ１１１０は、ＤＣＩ＿Ｘ１１０８に示され、ＤＣＩ＿Ｙ１１１２に示されるような受信ウィンドウ内の割り当てられたリソースを利用して、ＰＳＣＣＨ上で送信されるＳＬ ＴＢ１１１０に対する制御情報と共に、Ｔｘ ＵＥ１１０４からＲｘ ＵＥ１１０６のグループにＰＳＳＣＨ上でブロードキャストとして送信される。

【0061】

各種実施例において、ＳＬ ＴＢは、ＰＳＳＣＨのみでの送信のためにスケジューリングされてもよい。図１２は、各種実施例によるｇＮＢ又は基地局がＰＳＳＣＨ上でのみＳＬ ＴＢ送信のためにどのようにＤＣＩ＿Ｙを利用するかを示す概略図１２００を示す。図７及び図８に示す具体例と同様に、Ｔｘ ＵＥ１２０４はまず、ｇＮＢ１２０２にスケジューリング情報を送信する。スケジューリング情報は、スケジューリングリクエストと、１つ以上のＲｘ ＵＥを識別する宛先ＩＤを少なくとも含むレポート１２０６とを有してもよい。この情報に基づいて、ｇＮＢ１２０２は、ＳＬ ＴＢ１２１０の送信を受信するための受信ウィンドウを通知するため、宛先ＩＤによって識別されるような１つ以上のＲｘ ＵＥ１２０６にＵｕを介しメッセージ（すなわち、ＤＣＩ＿Ｙ１２１２）を送信してもよい。ＤＣＩ＿Ｙ１２１２は更に、ＳＬ ＴＢ１２１０の送信のリソース割当て、変調符号化方式などに関する完全な情報を含んでもよい。ｇＮＢ１２０２はまた、ＳＬ ＴＢ１２１０の送信のためのリソーススケジューリングのためにＵｕを介しＤＣＩ＿Ｘ１２０８をＴｘ ＵＥ１２０４に送信してもよく、ここで、ＤＣＩ＿Ｘ１２０８は更に、ＤＣＩ＿Ｙ（すなわち、ＤＣＩ＿Ｙ１２１２）がＲｘ ＵＥ１２０６に送信されることを示す情報を含む。ＤＣＩ＿Ｙ１２１２は、ＤＣＩ＿Ｘ１２０８のＴｘ ＵＥ１２０２への送信前、送信後又は送信と同時にＲｘ ＵＥに送信されてもよいことが理解されるであろう。

【0062】

従って、ＤＣＩ＿Ｙ１２１２がＲｘ ＵＥ１２０６にリソース割当てのための完全な情報をすでに提供しているとき、ＳＬ ＴＢ１２１０は、ＤＣＩ＿Ｘ１２０８に示され、ＤＣＩ＿Ｙ１２１２に示されるような受信ウィンドウ内において割り当てられたリソースを利用して、Ｔｘ ＵＥ１２０４からＲｘ ＵＥ１２０６にＰＳＳＣＨ上でのみ送信されてもよい。効果的には、ＳＬ ＴＢ１２１０のためのＰＳＣＣＨ上でのＳＣＩ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）の送信は、サイドリンクオーバヘッド及び送信電力を低減するため放棄されてもよい。本実施例は、ＳＬ ＴＢのユニキャスト、グループキャスト及びブロードキャスト送信に適用可能であってもよいことが理解されるであろう。

【0063】

図１３は、各種実施例による典型的なＤＣＩ＿Ｘ１３００のフォーマットを示す。ＤＣＩ＿Ｘ１３００は、例えば、図８のステップ１及び２に示されるように、Ｔｘ ＵＥからのスケジューリング情報の受信に応答して、ｇＮＢ又は基地局からＴｘ ＵＥに送信されてもよい。ＤＣＩ＿Ｘ１３００は、周波数領域リソースを示すフィールド、時間領域リソースを示すフィールド、他の用途のためのビットのフィールド、リザーブドビットのフィールド、及びＲＮＴＩによってスクランブリングされるＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）のフィールドを含んでもよい。

【0064】

周波数領域リソースを示すフィールドは、例えば、１つ以上のサブチャネル（すなわち、周波数時間リソーステーブル１３０２に示されるようなＳｕｂＣＨ＿０及びＳｕｂＣＨ＿１）を示す情報を有してもよい。周波数領域の粒度は、リソースブロック（ＲＢ）又はサブチャネルの形式であってもよい。周波数領域において、３ＧＰＰはサブチャネルをいくつかの連続したＲＢとして定義してもよく、１ＲＢは１２個の連続したサブキャリアを含んでもよい。各サブキャリア間隔は、２^μ＊１５ｋＨｚであってもよく、ここで、μはニューメロロジを表す整数である。

【0065】

時間領域リソースを示すフィールドは、例えば、１つ以上のタイムスロット（すなわち、周波数時間リソーステーブル１３０２に示されるようなＳｌｏｔ^ＳＬ _１）を示す情報を含んでもよい。時間領域の粒度は、サブフレーム、スロット又は直交周波数分割多重（ＯＦＤＭ）シンボルの形式であってもよい。時間領域では、３ＧＰＰは、１フレームを１０ｍｓ、１サブフレームを１ｍｓと規定し、１サブフレームに２^μ個のスロットがあってもよい。また、ノーマルサイクリックプリフィックス（ＣＰ）について１スロットあたり１４ＯＦＤＭシンボルあり、拡張ＣＰについて１２ＯＦＤＭシンボルがあってもよい。周波数又は時間領域におけるリソース割当ては、連続的（すなわち、開始位置＋持続時間を含む）又は非連続的（すなわち、ビットマップの形式）であってもよい。

【0066】

周波数領域リソースを示すフィールド及び時間領域リソースを示すフィールドからの情報は、ＳＬ ＴＢ送信のためのリソース割当てに利用されてもよく、周波数領域リソースを示すフィールド及び周波数領域リソースを示すフィールドによって示される時間周波数リソース（すなわち、周波数時間リソーステーブル１３０２の斜線部分）は、図６～１２に示されるように、Ｔｘ ＵＥからＲｘ ＵＥへのＳＬ ＴＢの送信など、サイドリンク送信のために利用されてもよい。さらに、ＣＲＣによりスクランブリングされたＲＮＴＩのためのフィールドは、例えば、Ｔｘ ＵＥのＩＤなどのＵＥを識別する情報を含んでもよい。図６～１２に示すような上述した具体例におけるＤＣＩ＿Ｘは、ＤＣＩ＿Ｘ１３００のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。

【0067】

図１４は、各種実施例によるＤＣＩ＿Ｙ１４００のフォーマットを示す。ＤＣＩ＿Ｙ１４００は、図のステップ１及び２に示されるように、Ｔｘ ＵＥからのスケジューリング情報の受信に応答して、ｇＮＢ又は基地局から１つ以上のＲｘ ＵＥに送信されてもよい。ＤＣＩ＿Ｙ１４００は、受信ウィンドウを示すフィールド、他の目的のためのビットのフィールド、リザーブドビットのフィールド、及びＲＮＴＩによってスクランブリングされるＣＲＣのフィールドを含んでもよい。受信ウィンドウを示すフィールドは、Ｒｘ ＵＥがＳＬ受信専用モードであるべき１つ以上のタイムスロット（すなわち、周波数時間リソーステーブル１４０２に示されるようなＳｌｏｔ^ＳＬ _１）を示すタイミング情報を含んでもよく、これにより、Ｒｘ ＵＥはＳｌｏｔ^ＳＬ _１の期間中にＴｘ ＵＥから送信されるであろうＳＬ ＴＢを受信することができる。さらに、ＣＲＣによりスクランブリングされるＲＮＴＩフィールドは、例えば、Ｒｘ ＵＥのＩＤのようなＵＥを識別する情報を含んでもよい。図６～１２に示されるような上述した具体例におけるＤＣＩ＿Ｙは、ＤＣＩ＿Ｙ１４００のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。

【0068】

図１５は、各種実施例によるＤＣＩ＿Ｙメッセージにおいて受信ウィンドウがどのように通知されるかの具体例を示す図である。本具体例では、ＤＣＩ＿Ｘ１５００及びＤＣＩ＿Ｙ１５０２は、周波数領域リソースを示すフィールド、時間領域リソースを示すフィールド、他の目的のためのビットのフィールド、ＳＬフラグを示すフィールド、リザーブドビットのフィールド、及びＲＮＴＩによってスクランブリングされるＣＲＣのフィールドを含んでもよい。ＤＣＩ＿Ｙは、ＤＣＩ＿Ｘ１５００としてリソース割当ての完全な情報（すなわち、周波数領域リソースフィールド及び時間領域リソースフィールドから）を含んでもよく、受信モードインジケータが規定されてもよい。受信モードインジケータは、受信モードを示す１ビットフラグ（すなわち、ＳＬ＿Ｆｌａｇ）であってもよい。例えば、“０”の値を有するフラグは受信専用モードを示す一方、“１”の値を有するフラグは非受信専用モード（又はその逆）を示してもよい。さらに、このフラグフィールドは、ＤＣＩ＿Ｘ１５００においてエンプティであってもよい。フラグフィールドは、周波数領域リソースを示すフィールド及び時間領域リソースを示すフィールドからのリソース割当ての完全な情報と共に、Ｒｘ ＵＥが受信モードにあるか否かを示すと共に、Ｒｘ ＵＥが対応するＴｘ ＵＥからＳＬ ＴＢ送信を受信する受信ウィンドウを示す。図６～１２に示すような上述した具体例におけるＤＣＩ＿Ｘ及びＤＣＩ＿Ｙは、ＤＣＩ＿Ｘ１５００及びＤＣＩ＿Ｙ１５０２のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。

【0069】

図１６は、各種実施例によるＤＣＩ＿Ｙメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。本具体例では、ＤＣＩ＿Ｘ１６００は、周波数領域リソースを示すフィールド、時間領域リソースを示すフィールド、他の目的のためのビットのフィールド、リザーブドビットのフィールド、及びＲＮＴＩによってスクランブリングされるＣＲＣのフィールドを含んでもよい（又は構成されてもよい）。一方、対応するＤＣＩ＿Ｙ１６０２は、ＤＣＩ＿Ｙ１６０２において周波数領域リソースを示すフィールドが省略されるように、時間領域リソースを示すフィールド、他の用途のためのビットのフィールド、リザーブドビットのフィールド、及びＲＮＴＩによってスクランブリングされるＣＲＣのフィールドを含んでもよい（又は構成されてもよい）。従って、ＤＣＩ＿Ｘ１６００は、ＳＬ ＲＢの送信のためのリソース割当ての完全な時間周波数情報（すなわち、ＤＣＩ＿Ｘ１６００における周波数領域リソースを示すフィールド及び時間領域リソースを示すフィールド）を有してもよいが、ＤＣＩ＿Ｙ１６０２は、リソース割当てのタイミング情報（すなわち、ＤＣＩ＿Ｙ１６０２における時間領域リソースを示すフィールドから）のみを含んでもよい。さらに、受信モードインジケータは、例えば、ＤＣＩ＿Ｘ１５００及びＤＣＩ＿Ｙ１５５０２におけるＳＬフラグフィールドに類似しうる１ビットフラグとして規定されてもよい。あるいは、受信モードインジケータは、ＤＣＩ＿Ｙ１５０２における周波数領域リソースを示すフィールドの欠落が受信専用モードを暗黙的に示すように、暗黙的であってもよい。図６～１２に示すような上述した具体例におけるＤＣＩ＿Ｘ及びＤＣＩ＿Ｙは、ＤＣＩ＿Ｘ１６００及びＤＣＩ＿Ｙ１６０２のものと同一又は同様のフォーマットであってもよいことが理解されるであろう。

【0070】

図１７は、各種実施例によるＤＣＩ＿Ｙメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。ＤＣＩ＿Ｙメッセージは、Ｒｘ ＵＥがＴｘ ＵＥからＳＬ ＴＢの送信を受信する受信モードにある間に受信ウィンドウを示すためのインデックス１７００を含んでもよい。インデックス１７００は、ＲＣＣ設定又は事前設定されてもよいインデックステーブル１７０２を参照してもよい。例えば、ＤＣＩ＿Ｙは値“２”のインデックスを示してもよい。インデックステーブル１７０２を参照すると、インデックス値“２”の下、受信ウィンドウは、少なくとも“１”のスロットオフセット、“３”のスタートシンボル及び“４”のシンボル長によって決定されてもよい。従って、ＳＬ ＴＢを受信する受信ウィンドウは、斜線部１７０４によって示されるように、次のスロットのシンボル“３”から始まり、４シンボルの長さにわたって続き、次のスロットのシンボル“６”で終了する次のスロット（すなわち、“１”のスロットオフセットの後）においてスケジューリングされる。インデックステーブル１７０２は、時間領域のみを示してもよい。しかしながら、それは、ＤＣＩ及びＳＬが同じキャリア上にあることを意味しない。むしろ、Ｒｘ ＵＥは、何れかのキャリアからのＳＬ ＴＢの送信を予想する受信ウィンドウの間に受信モードにありうる。図６～１２に示されるような上述した具体例におけるＤＣＩ＿Ｙは、図１７のインデックス１７００と同じフォーマットの受信ウィンドウを示しうることが理解される。

【0071】

図１８は、各種実施例によるＤＣＩ＿Ｙメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。ＤＣＩ＿Ｙメッセージは、Ｒｘ ＵＥがＴｘ ＵＥからＳＬ ＴＢの送信を受信する受信モードにある受信ウィンドウを示すためのインデックス１８００を含んでもよい。インデックス１８００は、ＲＣＣ設定又は事前設定されうるインデックス／ビットマップテーブル１８０２を参照してもよい。例えば、ＤＣＩ＿Ｙは、値“２”のインデックスを示してもよい。インデックス／ビットマップテーブル１８０２を参照すると、インデックス値“２”の下、受信ウィンドウは、対応するハーフスロットフォーマット、すなわち、ＤＤＸＸＸＸＸに基づいて決定されてもよい。従って、ＳＬ ＴＢを受信するための受信ウィンドウは、斜線領域１８０４及び１８０６によって示されるように、各スロットの７シンボル毎の第１及び第２シンボルにおいてスケジューリングされる（“ＤＤＸＸＸＸＸ”におけるシンボル“ＤＤ”によって表される）。異なる文字／数字／ビットが、受信ウィンドウ又はインデックス／ビットマップテーブル１８０２における他のリソースの使用を表すのに使用されてもよいことが理解されるであろう。インデックス／ビットマップテーブル１８０２は、時間領域のみを示してもよい。しかしながら、それは、ＤＣＩ及びＳＬが同じキャリア上にあることを意味しない。むしろ、Ｒｘ ＵＥは、何れかのキャリアからのＳＬ ＴＢの送信を予想する受信ウィンドウの間に受信モードにあってもよい。また、図６～１２に示すような上述した具体例におけるＤＣＩ＿Ｘ及びＤＣＩ＿Ｙは、図１８のインデックス１８００と同じフォーマットで受信ウィンドウを通知してもよいことが理解されるであろう。

【0072】

図１９は、各種実施例によるＤＣＩ＿Ｙメッセージにおいて受信ウィンドウがどのように通知されるかの他の具体例を示す。Ｒｘ ＵＥがＴｘ ＵＥからＳＬ ＴＢ送信を受信する受信ウィンドウは、Ｔｘ ＵＥの送信プール１９０２とＲｘ ＵＥの送信プール１９０４との間のタイミング差を考慮することによって、例えば、Ｒｘ ＵＥの受信プール１９００の形式のリソースプール設定を介しＤＣＩ＿Ｙメッセージにおいて通知されてもよい。一般に、Ｒｘ ＵＥは、Ｔｘ ＵＥが送信中であって、Ｒｘ ＵＥが送信中でない受信モードにあるべきである。従って、適切な受信ウィンドウは、長さ１９０６に沿ったＲｘプールのエリアに存在してもよい。リソースプール設定は、事前設定又はＲＲＣ設定されてもよい。図６～１２に示されるような上述された具体例におけるＤＣＩ＿Ｙは、図１９に示されるのと同じフォーマットでリソースプール設定を介して受信ウィンドウを通知しうることが理解されるであろう。

【0073】

各種実施例において、制御シグナリングを受信していないときの関連するＵＥの挙動が指定されてもよい。一実施例では、Ｒｘ ＵＥがＤＣＩ＿Ｙの送信を失った場合、ＰＳＣＣＨ送信が受信されたか否かにかかわらず、Ｒｘ ＵＥ及びＴｘ ＵＥの挙動は従来のＵＥ挙動に従ってもよく、ＳＬ ＴＢをどのように進めるかを決定することは、Ｔｘ ＵＥ次第である。他の実施例では、Ｒｘ ＵＥがＰＳＣＣＨ送信を失ったが、ＤＣＩ＿Ｙを正しく受信した場合、Ｒｘ ＵＥは、予想されるＳＬ ＴＢが失われたことをｇＮＢに報告してもよく、ｇＮＢは、失ったＳＬ ＴＢの再送のためＴｘ ＵＥをスケジューリングしてもよい。代替的な応答では、Ｒｘ ＵＥがＤＣＩ＿Ｙ又はＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）、ＭＡＣ制御エレメント（ＭＡＣ ＣＥ）、ＲＲＣなどの他の何らかのソースを介し関連するＴｘ ＵＥ情報を有する場合に限って、Ｒｘ ＵＥは、ＰＳＦＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｆｅｅｄｂａｃｋ Ｃｈａｎｎｅｌ）上で非アクノリッジメント（ＮＡＣＫ）をＴｘ ＵＥにフィードバックしてもよい。他の代替的な応答では、Ｒｘ ＵＥはＤＣＩ＿Ｙを破棄してもよく、ＳＬ ＴＢをどのように進めるか、すなわち、ＰＳＦＣＨ設計に応じて決定することは、Ｔｘ ＵＥ次第であってもよい。他の実施例では、Ｒｘ ＵＥがＰＳＣＣＨ及びＤＣＩ＿Ｙの双方を失った場合、Ｒｘ ＵＥ及びＴｘ ＵＥの挙動は、従来のＵＥ挙動に従ってもよく、ＳＬ ＴＢをどのように進めるかを決定するのはＴｘ ＵＥ次第である。

【0074】

各種実施例において、ブラインド再送は、モード１通信のために放棄されてもよい。各種実施例において、本解決策は、ライセンスバンド及びＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｔｒａｎｓｐｏｒｔａｔｉｏｎ Ｓｙｓｔｅｍ）帯域の双方に適用可能であってもよい。各種実施例において、本解決策は、モード１のみを有するか、又はモード１及び２を同時に有するＵＥに適用可能であってもよい。各種実施例において、Ｒｘ ＵＥへのＤＣＩ＿Ｙの送信は、Ｔｘ ＵＥへのＤＣＩ＿Ｘの送信が周期的（又はセミパーシステント）であるとき、周期的（又はセミパーシステント）であってもよい。各種実施例において、Ｔｘ ＵＥは、ＤＣＩ＿ＹがＲｘ ＵＥに送信される必要があるか否かをｇＮＢに要求してもよい。各種実施例において、ＤＣＩ＿Ｙが必要か否かは、トラヒックのタイプ、サービスのタイプ、又はＶＱＩ、５ＱＩ、遅延、プライオリティなどのＱｏＳパラメータ／インジケータに関連付けされてもよい。

【0075】

図２０は、各種実施例による通信方法を示すフロー図２０００を示す。ステップ２００２において、通信装置が受信モードにあるか否かを示すメッセージが生成されてもよい。ステップ２００４において、メッセージが通信装置に送信されてもよい。

【0076】

図２１は、図６～２０に示されるような各種実施例によるＶ２Ｘ通信を確立するため実現可能な通信装置２１００の概略的な部分断面図を示す。通信装置１６００は、各種実施例によるＵＥ又は基地局として実現されてもよい。

【0077】

通信装置１６００の各種機能及び処理が階層的モデルによるレイヤに構成される。モデルでは、下位レイヤは、３ＧＰＰ ５Ｇ ＮＲ仕様に従って上位レイヤに報告し、そこから命令を受信する。簡単化のため、階層的モデルの詳細は本開示では説明されない。

【0078】

図２１に示されるように、通信装置２１００は、回路２１１４、少なくとも１つの無線送信機２１０２、少なくとも１つの無線受信機１６０４及び少なくとも１つのアンテナ２１１２（簡単化のため、１つのアンテナのみが例示のため図２１に示される）を含んでもよい。回路２１１４は、無線ネットワークにおける１つ以上の他の通信装置との通信の制御を含む、少なくとも１つのコントローラ２１０６が実行するよう設計されるタスクのソフトウェア及びハードウェアにより支援される実行において利用される少なくとも１つのコントローラ２１０６を含んでもよい。回路２１１４は更に、少なくとも１つの送信信号生成器１６０８と、少なくとも１つの受信信号プロセッサ２１１０とを含んでもよい。少なくとも１つのコントローラ２１０６は、１つ以上の他の通信装置に少なくとも１つの無線送信機２１０２を介し送信される信号を生成する少なくとも１つの送信信号生成器２１０８（例えば、通信装置２１００が基地局である場合には、ＤＣＩ＿Ｘ及びＤＣＩ＿Ｙであり、通信装置２１００がＵＥである場合には、信号）と、少なくとも１つのコントローラ２１０６の制御の下で１つ以上の他の通信装置から少なくとも１つの無線受信機２１０４を介し受信した信号を処理するための少なくとも１つの受信信号プロセッサ２１１０（例えば、通信装置２１００がＵＥである場合には、ＤＣＩ＿Ｘ及びＤＣＩ＿Ｙであり、通信装置２１００が基地局である場合には、スケジューリング情報）とを制御してもよい。少なくとも１つの送信信号生成器２１０８及び少なくとも１つの受信信号プロセッサ２１１０は、図２１に示されるように、上述した機能に対して少なくとも１つのコントローラ２１０６と通信する通信装置２１００のスタンドアローンモジュールであってもよい。あるいは、少なくとも１つの送信信号生成器２１０８及び少なくとも１つの受信信号プロセッサ２１１０は、少なくとも１つのコントローラ２１０６に含まれてもよい。これらの機能モジュールの構成はフレキシブルであって、実際のニーズ及び／又は要求に応じて変更されてもよいことが当業者に理解されるであろう。データ処理、格納及び他の関連する制御装置は、適切な回路ボード及び／又はチップセット上に備えることが可能である。各種実施例では、動作中に、少なくとも１つの無線送信機２１０２、少なくとも１つの無線受信機２１０４及び少なくとも１つのアンテナ２１１２は、少なくとも１つのコントローラ２１０６によって制御されてもよい。

【0079】

通信装置２１００は、動作中にＶ２Ｘ通信においてＤＣＩを実現するのに必要とされる機能を提供する。例えば、通信装置２１００はＵＥであってもよく、無線受信機２１０４は、動作中に通信装置が受信モードにあるか否かを示すメッセージを受信してもよい。送信機２１０２は、動作中に通信装置が受信モードにないとき、信号を送信してもよい。

【0080】

メッセージは、通信装置２１００が受信モードにある受信ウィンドウを示してもよく、無線受信機２１０４は、通信装置１６００が受信モードにあるとき、送信ブロック（ＴＢ）を受信するよう構成される。メッセージは、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）のフォーマットであってもよい。

【0081】

例えば、通信装置２１００は、基地局であってもよく、回路２１１４は、動作中に通信装置が受信モードにあるか否かを示すメッセージを送信してもよい。送信機２１０２は、動作中にメッセージを通信装置に送信してもよい。メッセージは、ＤＣＩのフォーマットであってもよい。

【0082】

無線受信機２１０４は、動作中に送信側の通信装置からスケジューリング情報を受信してもよく、スケジューリング情報は通信装置を識別する。スケジューリング情報は、複数の通信装置を識別してもよく、メッセージは、通信装置がグループキャストのための受信モードにあるか否かを示してもよく、送信機２１０２は、メッセージを複数の通信装置に送信してもよい。

【0083】

無線受信機２１０４は、動作中に送信側の通信装置からスケジューリング情報を受信してもよく、スケジューリング情報は通信装置を識別する。スケジューリング情報は、複数の通信装置を識別してもよく、メッセージは、通信装置がブロードキャストのための受信モードにあるか否かを示してもよく、送信機２１０２は、メッセージを複数の通信装置に送信してもよい。

【0084】

送信機２１０２は更に、送信側の通信装置にＤＣＩを送信するよう構成されてもよく、ＤＣＩは、メッセージが通信装置に送信されたことを示す。

【0085】

メッセージは、通信装置が受信モードにある受信ウィンドウを通知してもよく、通信装置は、受信ウィンドウの間に送信ブロック（ＴＢ）を受信するよう構成される。受信ウィンドウは、ＴＢを受信するためのリソース割当ての周波数及びタイミング情報を含んでもよい。受信ウィンドウは、ＴＢを受信するためのリソースプール設定を含んでもよい。受信ウィンドウは、ＴＢを受信するためのリソース割当て及び変調符号化方式（ＭＣＳ）に関する完全な情報を含んでもよく、ＴＢのためのＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）上のＳＣＩ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージの送信は放棄される。

【0086】

上述したように、本開示の実施例は、ＳＬ ＴＢ送信の欠落の軽減又は回避を効果的に可能にするＶ２Ｘ通信装置のためのＤＣＩを実現する先進的な通信システム、通信方法及び通信装置を提供する。

【0087】

本開示は、ソフトウェア、ハードウェア又はハードウェアと連動するソフトウェアによって実現することができる。上述した各実施例の説明に用いた各機能ブロックは、集積回路等のＬＳＩによって部分的又は全体的に実現可能であり、各実施例で説明される各処理は、同一のＬＳＩ又はＬＳＩの組み合わせによって部分的又は全体的に制御されてもよい。ＬＳＩは、個別にチップとして形成されていてもよいし、あるいは、機能ブロックの一部又は全部を含むように１つのチップが形成されていてもよい。ＬＳＩは、それに結合されたデータ入出力を含んでもよい。ここで、ＬＳＩとは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩとして呼ばれうる。しかし、集積回路を実現する技術はＬＳＩに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを用いて実現されてもよい。さらに、ＬＳＩ内部に配置される回路セルの接続及び設定が再設定可能なＬＳＩ又はリコンフィギュラブルプロセッサの製造後にプログラミング可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）が利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現することができる。半導体技術や他の派生技術の進歩の結果として、将来の集積回路技術がＬＳＩに取って代わる場合、機能ブロックは、将来の集積回路技術を用いて集積化することができる。バイオテクノロジーも適用できる。

【0088】

本開示は、通信装置と呼ばれる、通信機能を有する何れかのタイプの装置、デバイス又はシステムによって実現することができる。

【0089】

通信装置は、送受信機及び処理／制御回路を有してもよい。送受信機は、受信機及び送信機を含み、及び／又は機能してもよい。送受信機は、送信機及び受信機として、アンプ、ＲＦ変調器／復調器などを含むＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールと、１つ以上のアンテナとを含んでもよい。

【0090】

そのような通信装置のいくつかの非限定的な例は、電話機（例えば、携帯（セル）電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例えば、ラップトップ、デスクトップ、ネットブック）、カメラ（例えば、デジタルスチル／ビデオカメラ）、デジタルプレーヤ（デジタルオーディオ／ビデオプレーヤ）、ウェアラブルデバイス（例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス／遠隔医療（リモートヘルス及びリモート医療）デバイス、及び通信機能を提供する車両（例えば、自動車、飛行機、船舶）、並びにそれらの様々な組み合わせを含む。

【0091】

通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス（例えば、家電、ライティング、スマートメータ、制御パネル）、自動販売機及び“Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）”のネットワークにおける他の何れかの“物”など、非携帯型又は固定型である何れかのタイプの装置、デバイス又はシステムを含んでもよい。

【0092】

通信は、例えば、セルラシステム、無線ＬＡＮシステム、衛星システムなど、及びそれらの様々な組み合わせを介してデータを交換することを含んでもよい。

【0093】

通信装置は、本開示に記載された通信の機能を実行する通信デバイスに結合されたコントローラ又はセンサなどのデバイスを含んでもよい。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号又はデータ信号を生成するコントローラ又はセンサを含んでもよい。

【0094】

通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャファシリティと、上記の非限定的な例におけるものなどの装置と通信又は制御する他の何れかの装置、デバイス又はシステムを含んでもよい。

【0095】

各種実施例のいくつかの性質がデバイスを参照して説明されたが、対応する方法はまた各種実施例の方法に適用され、その逆もあることが理解されるであろう。

【0096】

多数の変形及び／又は修正が広範に説明されるような本開示の趣旨又は範囲から逸脱することなく特定の実施例に示されるような本開示に対して行われてもよいことは、当業者に理解されるであろう。従って、本実施例は、全てに関して限定でなく例示的であるとみなされるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【国際調査報告】