(57)【要約】  ダイレクト通信をサポートして柔軟なリソースプールの共有を提供するアドバンスト無線通信システム、および、アドバンスト無線通信システムにて使用される方法を開示する。該方法は、第１ＵＥが、設定された共有領域と関連づけられたダイレクト通信チャネルの少なくとも１つのリソースプールの利用率を測定し、前記第１ＵＥが、少なくとも１つの第２ＵＥへ、前記少なくとも１つのリソースプールの選択されたリソースプールを識別するサイドリンク制御情報（ＳＣＩ）を送信し、前記第１ＵＥが、前記少なくとも１つの第２ＵＥへ、前記ＳＣＩと関連づけられたデータを、前記選択されたリソースプールにおいて送信する。【選択図】図６
2019532571.tif 000002
【特許請求の範囲】
【請求項１】
ダイレクト通信をサポートして柔軟なリソースプールの共有を提供するアドバンスト無線通信システムにて用いられる方法であって、
第１ＵＥが、設定された共有領域と関連づけられたダイレクト通信チャネルの少なくとも１つのリソースプールの利用率を測定し、
前記第１ＵＥが、少なくとも１つの第２ＵＥへ、前記少なくとも１つのリソースプールの選択されたリソースプールを識別するサイドリンク制御情報（ＳＣＩ）を送信し、
前記第１ＵＥが、前記少なくとも１つの第２ＵＥへ、前記ＳＣＩと関連づけられたデータを、前記選択されたリソースプールにおいて送信する、
方法。
【請求項２】
前記共有領域は、基地局によって設定される、
請求項１記載の方法。
【請求項３】
前記共有領域は、ブロードキャストシグナリングによって設定される、
請求項１または２に記載の方法。
【請求項４】
前記共有領域は、事前設定される、
請求項１記載の方法。
【請求項５】
前記ＳＣＩは、前記選択されたリソースプールを識別する、プール識別子（ｐｏｏｌ＿ＩＤ）を含む、
請求項１から４のいずれか１項に記載の方法。
【請求項６】
前記リソースプールは、サブプールを含む、
請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記第１ＵＥは、前記測定された利用率を基地局へ報告し、それに応じて、前記データの送信のためのリソースプールのインジケータを受信する、
請求項１記載の方法。
【請求項８】
前記第１ＵＥは、前記第１ＵＥへ指定されたリソースプールにおいて、前記ＳＣＩを送信する、
請求項１記載の方法。
【請求項９】
前記少なくとも１つのリソースプールは、時分割多重化または周波数分割多重化された、複数のリソースプールを含む、
請求項１から８のいずれか１項に記載の方法。
【請求項１０】
前記共有領域は、スケジュールのために個別に設定される複数の領域、および、各リソースプールの複数のデータ部分を含む、
請求項９記載の方法。
【請求項１１】
前記共有領域は、ローカライズされるか、分散されるか、または、リソースプールの全スケジューリング部分として、定義される、
請求項１記載の方法。
【請求項１２】
前記共有領域は、時間および周波数において互いに隣接する無線リソースブロック（ＲＢ）群の集まりによってローカライズされるように、定義される、
請求項１１記載の方法。
【請求項１３】
前記共有領域は、時間においておよび／または周波数において分散された、選択されたＲＢ群のセットによって分散されるように、定義される、
請求項１１記載の方法。
【請求項１４】
共有され且つ固定されたデータリソース領域群の周波数ドメイン多重化は、各共有領域についての、物理リソースブロック（ＰＲＢ）の開始番号および終了番号によって、定義される、
請求項１３記載の方法。
【請求項１５】
共有され且つ固定されたデータリソース領域群の周波数ドメイン多重化は、ＰＲＢビットマップによって定義される、
請求項１３記載の方法。
【請求項１６】
共有され且つ固定されたデータリソース領域群の時間ドメイン多重化は、各共有領域についての、サブフレームの開始番号および終了番号によって、定義される、
請求項１３記載の方法。
【請求項１７】
共有され且つ固定されたデータリソース領域群の時間ドメイン多重化は、サブフレームビットマップによって定義される、
請求項１３記載の方法。
【請求項１８】
前記少なくとも１つのリソースプールの前記利用率を測定することは、各ＳＣＩについて、スケジューリング割り当て（ＳＡ）復号して複数のデータリソース割り当てを決定すること、ＳＡリソースブロックおよびデータリソースブロックのエネルギーセンシングを行うこと、またはそれらの組み合わせによって、実行される、
請求項１から１７のいずれか１項に記載の方法。
【請求項１９】
活用が十分でないＳＡリソースおよびデータリソースは、次のサイドリンク制御（ＳＣ）期間の間のメッセージ送信のために、前記測定された利用率に応じて、選択される、
請求項１８記載の方法。
【請求項２０】
仮想リソースプールを形成すること、および、
前記仮想リソースプールのスケジューリング部分において前記ＳＣＩを送信し、前記仮想リソースプールのデータ部分において前記関連づけられたデータを送信すること、
を含む、
請求項１記載の方法。
【請求項２１】
前記仮想リソースプールは、ホストプールおよび１つまたは複数のゲストプールを含む、
請求項２０記載の方法。
【請求項２２】
前記ホストプールは、前記第１ＵＥに対してもともと指定されているリソースプールを含む、
請求項２１記載の方法。
【請求項２３】
前記ゲストプールは、前記選択されたリソースプールの１つまたは複数の共有データ領域を含む、
請求項２１記載の方法。
【請求項２４】
前記ホストプールのＳＡ部分は、前記仮想リソースプールの仮想ＳＡ部分を含む、
請求項２１記載の方法。
【請求項２５】
前記仮想リソースプールの仮想データ部分は、前記選択されたリソースプールの共有領域を含む、
請求項２１記載の方法。
【請求項２６】
前記仮想リソースプールの仮想データ部分は、前記ホストプールおよび前記ゲストプールの複数のデータ部分の組み合わせを含む、
請求項２１記載の方法。
【請求項２７】
データリソースの選択およびリソース割り当てのパラメータ群は、前記仮想データ部分に基づいて決定される、
請求項２６記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アドバンスト無線通信に関する。特に、これに限定されないが、本発明は、ＵＥ間の直接通信に関する。
【背景技術】
【０００２】
［略語］
2019532571.tif 000003
2019532571.tif 000004
【０００３】
人口の増加に伴い、高度道路交通システム（ＩＴＳ：Intelligent Transportation Systems）は、将来のスマートシティにとってスマートソリューションの重要な一部になる可能性がある。カーナビゲーションのためのＧＰＳ、車線内アシストおよびクルーズコントロールのためのカーセンサー、ならびに信号機制御のための路側センサーなどの、伝統的なスタンドアロン技術は、車両（例えば、車、バス、および電車）、路側インフラ（例えば、交通ユニット）、ならびに、歩行者およびサイクリストのような脆弱な道路利用者の間のリアルタイム通信を可能とする、より高度な強調システムによって置き換えられる可能性がある。より安全で効率的な都市の移動性に対する需要が高まるにつれて、これは、特に明白である。
【０００４】
協調ＩＴＳ（Ｃ−ＩＴＳ：Cooperative-ITS）は、能動的で予測的な交通管理、鉄道管理、および協調的認識メッセージ（ＣＡＭｓ：Cooperative Awareness Messages）を介して、強化された交通安全を提供することができる。同様に、警告メッセージ、ライブの交通および道路の状況、ならびに車両状況データは、車両間で、および、交通管制センターへおよびから送信され得る。
【０００５】
公共交通機関および私設交通機関の両方のための、ビークルツーエブリシング（Ｖ２Ｘ：Vehicle-to-Everything）通信、インフラツーエブリシング（Ｉ２Ｘ：Infrastructure-to-Everything）通信、および、歩行者ツーエブリシング（Ｐ２Ｘ：Pedestrian-to-Everything）通信を用いた、駐車場の予約／案内／支払い、自動車の故障診断、サービス予約から、自律走行型の自動運転車に至るまでの、革新的なＣ−ＩＴＳのアプリケーションおよびサービスが、考えられている。これを実現するために、超高信頼性、超高速かつ効率的な通信は、システムおよびその将来の進化を可能にするための、重要なキー要素である。
【０００６】
交通ネットワーク内の異なる道路利用者（road users）とインフラノード（infrastructure nodes）との間に中央無線局を経由しない直接無線通信リンクを提供するために、様々な無線アクセス技術がＣ−ＩＴＳに対して提案されている。これらの技術には、IEEE 802.11a（DSRC規格）およびIEEE 802.11p（WAVEまたはVANET規格）が含まれる。しかしながら、これらの技術は、それらの非決定的な振る舞いおよび衝突回避のために、自動車および／または歩行者の交通が非常に混雑している場所および交通の急激な変化がある時のような困難な環境において、要求される超高速および超高信頼性のパフォーマンスを提供しない可能性がある。
【０００７】
もともとはミッションクリティカル（ＭＣ：Mission Critical）アプリケーションでの近接サービス（ＰｒｏＳｅ：Proximity Services）のためのデバイスツーデバイス（Ｄ２Ｄ）ディスカバリおよび通信のために第３世代パートナーシッププロジェクト（３ＧＰＰ）の下で開発された、4G LTE-Advanced（LTE-A）ベースのサイドリンク技術は、その決定論的な振る舞いのために、Ｃ−ＩＴＳのための潜在的な通信ソリューションである可能性がある。さらに、LTE-Aベースのサイドリンク技術は、周波数帯域に関係なく、超高速かつ超高信頼性の性能要件を満たすように、進化する可能性がある。そのため、LTE-Aベースのサイドリンク技術は、多くの政府規制当局のＣ−ＩＴＳアプリケーションおよびサービスによって確保されている５．９ＧＨｚ帯における、Ｃ−ＩＴＳにとってより魅力的な技術である。
【０００８】
IEEEテクノロジとは異なり、LTE-Aサイドリンクテクノロジは、マルチモード動作をサポートし、これにより、デバイスは、セルラーネットワーク制御（モード１またはモード２）の下でカバレッジ内において、または、ネットワーク支援なし（モード２）でカバレッジエリア外において自動的に、機能することができる。
【０００９】
ＬＴＥ−Ａサイドリンクがセルラー周波数で動作するように設定されている場合、ＬＴＥ−Ａサイドリンクは、サイドリンク制御（SC）シグナリングおよびデータ転送ブロック（TB）伝送のために、（ＦＤＤ帯域の場合）アップリンク（ＵＬ）キャリア上の、または、（ＴＤＤ帯域の場合）キャリアの複数のＵＬサブフレーム上の、無線リソースを使用する。カバレッジ内モード１およびモード２の動作の場合、これらの無線リソースは、レイヤ３システム情報ブロック（ＳＩＢ）のブロードキャスト設定シグナリング（Layer-3 System Information Block (SIB) broadcast configuration signalling）を使用して、セルラーネットワーク基地局によって予約される。
【００１０】
ＬＴＥ−Ａサイドリンクがネットワーク外のカバレッジエリア内で動作している場合、１つまたは複数の周波数キャリアおよびモード２通信無線リソース（mode 2 communication radio resources）は、例えばＵＳＩＭを使用することによって、各サイドリンク対応デバイスに対して、事前に設定される。
【００１１】
周波数キャリア上でＬＴＥ−Ａサイドリンクリソース構造を定義するプロセスの一部として、周波数ドメインにおいて複数のリソースブロック（ＲＢ）を有し、且つ、時間ドメインにおいてサイドリンク通信のためのいくつかのサブフレームに亘る、複数の無線リソースのセットが、周波数チャンクおよびサイドリンク制御期間（SC Period：Sidelink Control Period）としてそれぞれ設定または事前設定され、そして、設定可能なリソースプールを形成する。さらに、モード１の通信およびモード２の通信のために、複数のリソースプールが定義されてもよい。
【００１２】
モード１通信では、リソースプールは、サイドリンク制御情報（ＳＣＩ：Sidelink Control Information）を搬送するための複数の無線リソースのスケジューリング割り当て（ＳＡ：Scheduling Assignment）部分と、サイドリンクデータトラフィックおよびセルラーＵＬトラフィックの両方を搬送するために柔軟に使用できる複数の無線リソースの関連部分と、からなる。ＳＡ部分およびその関連データ部分は、ＴＤＭ方式またはＦＤＭ方式で多重化することができる。送信側ユーザ機器（ＵＥ）については、それぞれＳＡ部分内およびサイドリンク／アップリンクトラフィック部分内のＳＣＩおよびサイドリンクデータ送信に使用されるべき正確なリソースは、基地局によってスケジュールされる。
【００１３】
モード１と非常によく似たモード２通信では、リソースプール構造は、また、無線リソースのＳＡ部分および関連データ部分を含み、ＳＡ部分およびその関連データ部分は、ＴＤＭまたはＦＤＭ方式で多重化することができる。しかし、モード１通信とは対照的に、モード２リソースプール内のデータ部分は、サイドリンクデータＴＢ送信にしか使用できず、（ＳＡ部分およびデータ部分の両方における）リソースの選択は、送信側ＵＥによって自律的に行われるべきである。
【００１４】
一般に、ＵＥの数および予想されるトラフィック量は、通常、セルまたはＵＥの送信範囲内で予測可能であるので、ローカル基地局によるサイドリンクリソース割り当ての上記の準静的設定タイプ、または、カバレッジ外エリアに対する事前設定を使用する静的タイプは、MC通信で共通リソースプールを共有する、一般的な目的のProSeに適している。しかしながら、Ｃ−ＩＴＳにおいて異なるＱｏＳ要求を有する複数のサービスおよび／または複数のアプリケーションについては、異なるＱｏＳ要求の複数のサービスおよび／または複数のアプリケーションを共有するための複数の共通リソースプールは、異なる複数のサービスの複数の装置の間におけるシグナリングおよび／またはデータ伝送における衝突、つまり、サービス間のトラフィック衝突により、保証ＱｏＳを提供しない。
【００１５】
この問題を解決するために、３ＧＰＰ ＲＡＮ−ＷＧ１は、リソースプールを時間または周波数において、半静的に（つまり、設定によって）または静的に（つまり、事前設定によって）分割されうる、提案を承認した。ここで、各分割リソースサブプールは、Ｖ２Ｘ、Ｉ２ＸまたはＰ２Ｘ通信などの通信サービスまたは同じＱｏＳの複数のサービスによる使用のために、順番に割り当てられるかまたは設定される。このアプローチは、サービス間トラフィック衝突によって引き起こされるＱｏＳ問題を解決することができるが、トラフィック需要の動的な性質およびローカル基地局からのリソースの遅い再設定のために、リソース利用および／または複雑なスケジューリングにおいてさらなる問題を引き起こす。これは、他のリソースサブプールが十分に活用されていないがすぐには使用できない一方で、或るリソースサブプールがひどく混雑している可能性があるという、シナリオにつながる。
【００１６】
したがって、改善された無線通信システムおよび方法に対する必要性が明らかに存在する。
【００１７】
先行技術の刊行物が本明細書中で言及される場合、この参考文献は、その刊行物がオーストラリアまたは他の国の技術における共通の一般的知識の一部を形成するという承認を構成しない、ことは明らかに理解されるであろう。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
本発明は、上述の不利点の少なくとも１つを少なくとも部分的に克服するかまたは消費者に有用なまたは商業的な選択を提供することができる、アドバンスト無線通信システムで使用するためのシステムおよび方法に関する。
【課題を解決するための手段】
【００１９】
上記を考慮して、本発明の一形態は、広くは、柔軟なリソースプール共有を提供するために直接通信（direct communication）をサポートするアドバンスト無線通信システムにて使用するための方法に存在し、該方法は、第１のＵＥにおいて、設定された共有領域に関連する直接通信チャネルの少なくとも１つのリソースプールの利用率を測定すること、第１のＵＥによって少なくとも１つの第２のＵＥへ、少なくとも１つのリソースプールのうちの選択されたリソースプールを識別するサイドリンク制御情報（ＳＣＩ）を送信すること、および、選択されたリソースプール内の上記ＳＣＩに関連付けられたデータを、第１のＵＥによって少なくとも１つの第２のＵＥへ送信すること、を含む。
【００２０】
上記の共有領域は、基地局によって設定されてもよい。上記の共有領域は、ブロードキャストシグナリングによって設定されてもよい。
【００２１】
上記の共有領域は、事前設定されてもよい。
【００２２】
好ましくは、上記のＳＣＩは、選択されたリソースプールを識別するプール識別子（pool_ID）を含む。
【００２３】
上記のリソースプールは、サブプールを含んでいてもよい。
【００２４】
第１のＵＥは、測定された利用率を基地局に報告し、それに応答して、データを送信するためのリソースプールのインジケータを受信することができる。
【００２５】
第１のＵＥは、第１のＵＥに指定されたリソースプールでＳＣＩを送信することができる。
【００２６】
上記の少なくとも１つのリソースプールは、時分割多重化または周波数分割多重化された複数のリソースプールを含んでいてもよい。
【００２７】
上記の共有領域は、スケジューリングのために独立して設定された複数の領域と各リソースプールのデータ部分とを含むことができる。
【００２８】
上記の共有領域は、ローカライズされて、分散されて、またはリソースプールのスケジューリング部分全体として、定義されてもよい。
【００２９】
上記の共有領域は、時間において及び周波数において互いに隣接している複数の無線リソースブロック（ＲＢｓ）の集まりによってローカライズされるように、定義されてもよい。
【００３０】
上記の共有領域は、時間的におよび／または周波数的に分散された、選択された複数のＲＢのセットによって、分散されるように、定義される。
【００３１】
共有データリソース領域および固定データリソース領域の周波数領域多重化（frequency domain multiplexing）は、各共有領域についての物理リソースブロック（ＰＲＢ：physical resource block）の開始番号（start number）および終了番号（end number）に従って定義されてもよい。
【００３２】
共有データリソース領域および固定データリソース領域の周波数領域多重化は、ＰＲＢビットマップに従って定義されてもよい。
【００３３】
共有領域および固定領域の時間領域多重化（time domain multiplexing）は、各共有領域についてのサブフレームの開始番号および終了番号によって定義されてもよい。
【００３４】
共有データリソース領域および固定データリソース領域の時間領域多重化は、サブフレームビットマップによって定義されてもよい。
【００３５】
少なくとも１つのリソースプールの利用率を測定することは、ＳＡを復号化して各ＳＣＩについての複数のデータリソース割り当てを決定すること、ＳＡ  ＲＢおよびデータＲＢのエネルギーセンシングを行うこと、またはそれらの組み合わせによって、実行されてもよい。
【００３６】
好ましくは、測定された利用率に従って、次のＳＣ期間中のメッセージ送信のために、利用率の低いＳＡリソースおよびデータリソース（ＲＢｓ）が選択される。
【００３７】
上記の方法は、仮想リソースプールを形成することと、仮想リソースプールのスケジューリング部分でＳＣＩを送信して仮想リソースプールのデータ部分で関連データを送信することと、を含んでいてもよい。
【００３８】
上記の仮想リソースプールは、ホストプールと１つ以上のゲストプールとを有していてもよい。
【００３９】
上記のホストプールは、上記の第１のＵＥにもともと指定されたリソースプールを含んでいてもよい。
【００４０】
上記のゲストプールは、上記の選択されたリソースプールの１つ以上の共有データ領域を含んでいてもよい。
【００４１】
上記のホストプールのＳＡ部分は、上記の仮想リソースプールの仮想ＳＡ部分を含んでいてもよい。
【００４２】
上記の仮想リソースプールの仮想データ部分は、上記の選択されたリソースプールの共有領域を含んでいてもよい。
【００４３】
上記の仮想リソースプールの仮想データ部分は、上記のホストプールおよびゲストプールの複数のデータ部分の組み合わせを含んでいてもよい。
【００４４】
データリソース選択およびリソース割り当てのパラメータ群は、上記の仮想データ部分に基づいて決定されてもよい。
【００４５】
本発明の特定の複数の実施形態は、クロスモード１−２の動的なスケジューリングまたはリソース共有を可能にするための、エンハンストモード−２のリソースプール構造および関連する測定／報告の技術を提供する。
【００４６】
本発明の複数の実施形態は、柔軟に設定可能な複数のサブプール（flexible configurable sub-pools）がＦＤＭおよびＴＤＭ方式で配置される、エンハンストモード−２のリソースプール構造を提供し、これにより、異なるＱｏＳを有する異なるタイプの複数のサービスが、互いに保証されたパフォーマンスに影響することなく、同時に同じ複数のリソースプールを供給する、ことを可能にする。
【００４７】
本発明の複数の実施形態は、部分的または全体的に共有される設定可能なリソースサブプールを有する、エンハンストモード２のリソースプール構造と、サービス間トラフィック衝突を最小化または排除してこれにより保証されたＱｏＳを維持しながらシステムリソース全体の利用を最適化するためのメジャメントにおける複数の方法と、を提供する。
【００４８】
本発明の実施形態は、モード−２のサイドリンク通信で使用するための仮想リソースプールを提供し、ここで、仮想リソースプールは、上記の設定されたプライマリ指定サブプール（configured primary designated sub-pool）、および、即時に到来する設定されたプライマリ指定サブプールに先立った、設定されたセカンダリサブプールの複数の共有領域のすべて、を含む。さらに、制御および／またはデータを送信するための構成された仮想リソースプール内の１つ又は複数のチャネルリソースについて競合する際に、１つ又は複数のチャネルインデックスの選択について同じ確率を有しているすべての設定されたセカンダリサブプールの複数の共有領域から、複数のチャネルリソースを考慮してもよく、これにより、チャネル選択の前にリソースサブプールが選択される場合に、輻輳トラヒックが最も輻輳の少ないリソースサブプールへ直接的にあふれるという、一般的な問題を解決する。
【００４９】
本発明の複数の実施形態は、さらに、Ｖ２Ｘで使用するためのＵＲＬＬＣを可能にする、つまり、遅れて到着するパケット群および／または遅延に敏感なデータパケット群を、複数の共有リソースプールを使用して送信することを可能にする、リソース構造および方法を提供する。
【００５０】
本発明の複数の実施形態は、概して、ビークルツーエブリシング（V2X：Vehicle to Everything）通信、インフラストラクチャツーエブリシング（I2X：Infrastructure to Everything）通信、および、歩行者ツーエブリシング（P2X：Pedestrian to Everything）通信において用いられる、ＬＴＥベースのデバイスツーデバイス（D2D：device-to-device）通信技術またはサイドリンク通信技術に関連し、これらは、高度道路交通システム（ITS：Intelligent Transportation Systems）をサポートする。具体的には、基地局およびそのサイドリンク対応のアドバンストＵＥ群にて用いられる、サイドリンクリソースプール構造および関連する方法が開示され、これらは、リソースプールまたはリソースサブプールの柔軟な共有を提供する。
【００５１】
特定の風区数の実施形態では、上記のリソースプール構造および関連する方法は、クロスモード（または、いわゆるモード１およびモード２などのモード間）およびモード内（たとえばモード２内）のリソース共有と、リソース利用を最大化することと、所望のサービス品質（ＱｏＳ）を維持しながらサービス間のトラヒック衝突を最少化することと、を可能にする。
【００５２】
特定の複数の実施形態によれば、設定可能な複数の共有領域を含んでいる、１つ又は複数のリソースプールおよび／または１つ又は複数のリソースサブプールを含む、エンハンストリソースプール構造が、提供される。リソースプールまたはリソースサブプール内の１つまたは複数の共有領域は、データプール／データサブプールに対してだけ、または、制御プール／制御サブプールおよび関連するデータプール／データサブプールに対して独立して、設定または事前設定されてもよい。具体的には、リソースプール／サブプールの設定可能な１つまたは複数の制御共有領域は、サイドリンク制御情報の送信／受信のために、ローカライズされたリソース群、分散されたリソース群、または全体の制御プール／サブプールを含むように、構成されてもよい。制御プール／サブプール内の分散された共有領域は、好ましくはランダムまたは擬似ランダムで、時間および周波数において分散されている、複数の制御チャネルインデックスを含んでいてもよい。
【００５３】
リソースプール／サブプールの設定可能な１つまたは複数のデータ共有領域は、ローカライズされたリソース群、または、分散されたリソース群、または、複数のデータＴＢの送受信のための全体のデータプール／サブプールリソース群を含むように、構成されてもよい。データプール／サブプール内の分散された共有領域は、時間においてまたは周波数において分散されているデータリソース群の、複数のグループを含んでいてもよい。
【００５４】
本発明の別の実施形態では、直接通信が可能であるアドバンストＵＥ群は、モード−１サイドリンク通信を実行するように、設定およびスケジュールされてもよい。設定されたモード−１リソースプールは、プライマリリソースプールを含み、頻繁に使用されるように優先されてもよい。アドバンストＵＥでのみ復号可能な追加のシグナリングを介して、設定された共有領域をセカンダリリソースプールとして有するモード−２エンハンストリソースプールは、必要に応じてトラフィックを監視およびオフロードするために、提供されてもよい。
【００５５】
本発明の実施形態によれば、第１のモード−１ＳＡプールの直後の境界で始まる２つの連続する第１および第２のモード−１ＳＡプール間の、任意の１つまたは複数の共有領域は、第１のモード−１ＳＡプールに属するセカンダリデータプールとして、定義されてもよい。要求に応じてまたは設定された定期的に、アドバンストＵＥは、設定されたセカンダリリソースプールの使用率を測定し、それをサービス基地局に報告してもよい。スケジュールされると、アドバンスＵＥは、そのプライマリモード−１のＳＡプールでＳＣＩ（サイドリンク制御情報）を送信し、関連するセカンダリデータプールで関連のデータＴＢを送信してもよい。さらに、サイドリンクデータ受信を実行する１つまたは複数のアドバンストＵＥは、データＴＢの受信および復号のために、プライマリモード−１データプールおよび任意の設定されたセカンダリデータプールの両方を監視してもよく、これにより、クロスモードリソース共有またはクロスモードスケジューリングが可能となる。これにより、モード−１サイドリンクトラフィックは、共有のために設定された利用率の低いモード−２チャネルリソースへ瞬時に流出することが可能になり、したがって、既に混雑しているモード−１リソースまたは優先順位の高いセルラ通信によって使用されるモード−１リソースを解決するか、または、データＴＢ送信のために次に到来する指定リソースプールに先立った、他の共有リソースプールを使用することによって、遅れて到着した遅延不耐性メッセージの即時配信を可能にする。
【００５６】
本発明の他の態様では、特定のサービスのための直接通信が可能なアドバンストＵＥは、モード−２サイドリンク通信のための複数のプライマリサイドリンクリソースプール／サブプールを用いた、レガシーシグナリングを介して示されてもよい。アドバンストＵＥであるので、アドバンストＵＥは、適切な場合にトラフィック（制御および／またはデータ）を監視およびオフロードするための、１つ又は複数のセカンダリリソースプール／サブプールとして設定された共有領域を有する、他のセカンダリモード−２の１つまたは複数のリソースプール／サブプールを用いて、アドバンストＵＥでのみ復号可能であるように設計されている追加のまたはアドバンストなシグナリングを介して、さらに示されてもよい。１つまたは複数のセカンダリモード−２リソースプール／サブプールは、１つまたは複数のサービスによって主に使用されるために設定されてもよく、これにより、複数のサービスの間で共有するために共通リソースプールが設定されている場合、サービス間トラフィック衝突の解決をアシストする。
【００５７】
本発明の複数の実施形態によれば、個々のサービスごとにリソースプール／サブプールのサービス間トラフィック衝突回避特性とサービストラフィックの不均衡および瞬間的な変化に起因して導入される不十分なリソース利用を解決することとを保持するために、第１のモード−２リソースプール／サブプールの直後の境界で始まる２つの連続したモード−２プライマリリソースプール／サブプール間に設定されたセカンダリリソースの１つ又は複数の示された共通領域（つまり、ＳＡおよびデータ）は、ＳＡまたはデータまたはＳＡおよびデータのために使用するための仮想リソースプール／サブプールを形成している第１のモード−２リソースプール／サブプールに属する１つまたは複数のセカンダリリソースプール／サブプールとして見なされてもよい。任意の複数のＭＡＣ ＰＤＵの送信の前に、アドバンストＵＥは、そのＳＣＩおよび関連データＴＢの送信において利用可能な複数のリソースを識別するために、その構築された仮想リソースプール／サブプールを監視してもよく、ここでは、その複数のプライマリサイドリンクリソースプール／サブプールに属する複数のチャネルリソースが、その複数のセカンダリサイドリンクリソースプール／サブプールに属する複数のチャネルリソースよりも、高い使用の優先度を有している、と考えられてもよい。このことは、その複数のプライマリサイドリンクリソースプール／サブプールに属する複数のリソースが輻輳しているかまたは略完全に使用されている場合にのみ、アドバンストＵＥが、その構築された仮想リソースプール／サブプール内のその複数のセカンダリサイドリンクリソースプール／サブプールに属する複数のチャネルリソースを、制御および／またはデータの送信のために使用する、ことを、暗に示している。
【００５８】
さらに、構築された仮想リソースプール／サブプールに対するＵＥ実装観測スキームからもたらされる、同じカテゴリ（つまり、プライマリ／ホストまたはセカンダリ／ゲスト）の利用可能な複数のチャネルリソース内で、チャネル競合の一部として、アドバンストＵＥは、ＳＡおよびデータＴＢの送信のために、上記の利用可能な複数のリソース内で１つまたは複数のチャネルをランダムに選択してもよい。これにより、自身のリソースプール／サブプールが輻輳しているときに多くのＵＥが最も輻輳の少ないリソースプール／サブプールを選択する傾向があるという論理リソースプール／サブプールベースでチャネル選択が行われる場合、他の輻輳が少ないリソースプール／サブプールをスキップして、輻輳トラヒックが最も輻輳しているリソースプール／サブプールから最も輻輳の少ないリソースプール／サブプールへ直接的に流出するという、ケースを解決している。
【００５９】
本明細書に記載の特徴のいずれも、本発明の範囲内で、本明細書に記載の他の特徴の任意の１つまたは複数と任意の組み合わせで組み合わせることができる。
【００６０】
本明細書におけるいかなる先行技術への言及も、先行技術が共通の一般的知識の一部を形成するという承認または何らかの形態の示唆として解釈されず、またそのように解釈されるべきではない。
【図面の簡単な説明】
【００６１】
本発明の種々の実施形態が添付の図面を参照して説明される。
【００６２】
【図１】図１は、本発明の実施形態による、ＴＤＭサイドリンク通信リソースプール構成を示す。
【００６３】
【図２】図２は、本発明の一実施形態による、ＳＡ部分およびデータ部分についての共有領域および固定領域の分割を示す、リソースサブプールの構成を示す。
【００６４】
【図３Ａ】図３Ａは、本発明の実施形態による、リソースサブプールのＳＡ部分の例示的な分割を示す。
【図３Ｂ】図３Ｂは、本発明の実施形態による、リソースサブプールのＳＡ部分の例示的な分割を示す。
【００６５】
【図４Ａ】図４Ａは、本発明の実施形態による、例示的な情報要素（ＩＥ）を示す。
【図４Ｂ】図４Ｂは、本発明の実施形態による、例示的なリソースプール分割構成を示す。
【００６６】
【図５】図５は、本発明の実施形態による、例示的なリソースプール分割構成を示す。
【００６７】
【図６】図６は、本発明の一実施形態によるデータ通信方法を示す。
【００６８】
【図７】図７は、本発明の実施形態による、クロスモードの共有およびスケジューリングの方法を図示する。
【００６９】
【図８】図８は、本発明の一実施形態によるデータ通信方法を示す。
【００７０】
【図９】図９は、本発明の一実施形態による、クロスサブプール共有およびスケジューリングの方法を示す。
【００７１】
本発明の好ましい特徴、実施形態および変形は、本発明を実施するのに十分な情報を当業者に提供する以下の詳細な説明から識別することができる。詳細な説明は、決して、前述の発明の概要の範囲を限定するものと見なされるべきではない。
【発明を実施するための形態】
【００７２】
メカニズムを提供するシステムおよび方法が記載される。該メカニズムは、基地局が、ある時点でそれの専用データリソースプールまたはサブプールが輻輳している場合に即時データ送信のために別のリソースプールまたは他の１つまたは複数の分割されたリソースサブプールを用いるために、サイドリンクＴＸデバイスへ動的に指示することを可能にするか、または、それのプライマリ専用リソースサブプールが輻輳している場合にデータ送信のために利用可能な１つまたは複数のセカンダリリソースサブプールを用いて、アドバンストサイドリンク対応デバイスを半静的に（semi-statically）設定する（または、事前設定する）ことを可能にする。本明細書に記載の複数の実施形態は、また、クロスモードリソースプール共有（cross modes resource pool sharing）、つまり、データ送信／受信のためにモード２リソースプールを使用する複数のモード１ＴＸデバイスを可能にする。
【００７３】
本明細書で使用されるリソースプールという用語は、周波数キャリアの時間領域および周波数領域の両方における物理的無線リソースの集合を意味し、一般にＬＴＥベースのＤ２Ｄ／サイドリンク通信のために設定され使用される。同様に、ＳＣ期間（SC period）という用語は、リソースプールの期間（time period）／持続期間（duration）としてサイドリンク通信期間を表す。
【００７４】
図１は、本発明の一実施形態によるＴＤＭサイドリンク通信リソースプール構成１００を示す。リソースプール構成１００は、同時の制御およびデータの送信／受信のために共通のサイドリンクリソースプールを共有する、異なるＱｏＳのいくつかのサービスによって引き起こされる、サービス間トラフィック衝突を解決するように設定される。
【００７５】
上記の構成１００は、（周波数領域における）サイズ１０２および（時間領域における）サイズ１０１のＴＤＭサイドリンク通信リソースプール１３０を含む。リソースプール１３０は、異なるサイズを有する複数のサブプール（「サブチャネル」とも呼ばれる）１３１，１３２，１３３，１３４に分割される。
【００７６】
分割された各サブプール１３１，１３２，１３３，１３４は、同じまたは類似のＱｏＳを有する１つまたは複数のサービスによる主な使用（primary use）のためにスケジュールされてもよい。これは、共通リソースプール（common resource pool）内の複数のサービスによって引き起こされるトラフィック間衝突を排除することができる。
【００７７】
分割された各サブプールは、送信側のＵＥ群およびノード群からのサイドリンク制御情報（ＳＣＩ）を搬送するための、スケジューリング割り当て（ＳＡ：Scheduling Assignment）部分と、ＳＡ部分の間に送信されたＳＣＩによってスケジュールされたサイドリンクデータトランスポートブロック（ＴＢｓ：sidelink data Transport Blocks）を搬送するための関連データ部分（associated data portion）とを含む。上記のＳＡ部分およびデータ部分は、時間多重化または周波数多重化されてもよい。
【００７８】
上記のプール構成は、複数のリソースプール１３０を含み、各リソースプール１３０は、分割された複数のサブプール１３１，１３２，１３３，１３４を含む。サブプール１３１、１３２、１３３、１３４のそれぞれは、独立して、時間多重化されたＳＡ部分１３１．１およびデータ部分１３１．２を持つように設定されてもよいし、または、時間多重化されたＳＡ部分１３１．１およびデータ部分１３１．２を持つように設定されてもよい。これにより、以下でさらに詳細に説明されるように、柔軟なリソース共有を可能にする。
【００７９】
リソースサブプールのＳＡ部分および／またはデータ部分は、異なるサービスおよび／またはアプリケーションに加入されている他のＵＥ／ノードによるサイドリンクリソースの柔軟な利用のために使用できる１つまたは複数の共有領域を備えるように、ネットワーク基地局によって設定されるかまたは事前設定されてもよい。これは、専用サブプールが能力（capability）を共有することなく特定のサービスに割り当てられるときに、不均衡で且つ変動するサービストラフィックによって引き起こされる、非効果的なリソース利用の問題を解決するのに、役立ち得る。例えば、設定されている複数の共有領域を有するＰ２Ｘサービスに元々割り当てられていたリソースサブプールは、Ｖ２Ｘサービスメッセージの送信に使用することができ、またその逆も可能である。
【００８０】
図２は、本発明の一実施形態による、ＳＡ部分およびデータ部分についての共有領域および固定領域の分割を示す、リソースサブプール２００の構成を示す。特に、共有領域は、ローカライズされた構成、分散された構成、または全体構成を含む様々なアプローチを使用して、および、ＴＤＭまたはＦＤＭ方式で、ＳＡ部分およびデータ部分に対して独立して設定されてもよい。さらに、１つの手法を使用して設定された共有領域を有するＳＡ部分は、他の手法を使用して設定された共有領域を有するデータ部分と関連付けられてもよい。
【００８１】
サブプール２００は、ＳＡ部分２１０を含み、ここでは、共有領域は、サブプールＡ２１１に示されるようにローカライズされる態様で、ＳＬリソースサブプールごとに設定されてもよいし、サブプールＢ２１５に示されるように分散される態様で設定されてもよいし、または、サブプールＣ ２１８に示されるような全領域に対して設定されてもよい。
【００８２】
サブプールＡ２１１に示されるローカライズされた構成は、互いに隣接し且つ一緒にグループ化されて共有領域２１２，２１４を形成する複数のリソースブロック（ＲＢｓ）の形の複数の無線リソースのサブセットを含む。共有領域２１２、２１４の部分でない他の複数のＳＡリソースは、固定領域２１３を形成する。ＳＡリソースは上部セクション（upper section）と下部セクション（lower section）とに分割されるので、上部セクションに対して定義された共有領域２１２は、ＳＡ反復（SA repetition）のために、下部セクションに対応する共有領域２１４を自動的に有する。これは、図３Ａおよび図３Ｂにさらに例示的に示されている。
【００８３】
サブプールＢ２１５に示す分散構成では、無線リソース群のサブセットは、ＳＡ部分内に分散されているが、一緒にグループ化されて共有領域２１６を形成している。共有領域の部分ではない他の複数のＳＡリソースは、固定領域２１７を形成する。
【００８４】
最後に、サブプールＣ２１８は、共有リソース２１９として設定されているＳＡ部分全体を含み、これは、ＳＬリソース選択の最大の自由度を提供する。
【００８５】
図３Ａおよび３Ｂは、本発明の実施形態による、複数のリソースサブプールの複数のＳＡ部分の例示的な分割３００を示す。
【００８６】
図３Ａでは、ローカライズされた態様での共有領域の例示的な構成で、第１のＳＡ部分３１０が示されている。特に、ネットワークパラメータ（Ｎｆ）３１１は、時間的に互いに隣接している、複数のＳＡ ＲＢの行を表し、共有領域を定義するために使用される。第１のセットのＮｆ値群３１２（つまり、Ｎｆ＝１１，１２，１３，１４，１５）は、ＳＡ上部セクションのための共有領域として設定され、第２のセットのＮｆ値群３１３（つまり、Ｎｆ＝２７，２８，２９，３０，３１）は、下部セクション内の共有領域として設定され、これにより、共有領域２１２と固定領域２１３とのＦＤＭ分割を提供している。
【００８７】
図３Ｂでは、第２のＳＡ部分３２０は、分散された態様での共有領域の例示的な構成で示されている。特に、ＳＡインデックス３２１は、ＳＡ ＲＢを表し、共有領域を定義するために使用される。この場合、１つのセットのＳＡインデックス群３２２（ＳＡインデックス＝４，１０，１７，２３，２４，３０，３７，４３，４４，５０，５７，６３）は、ＡＳ部の上部セクションにおいて共有領域３２２を定義するように設定され、下部セクションにおいて共有領域３２３を定義するように設定される。上記のローカライズされた構成とは対照的に、このタイプの分散された構成は、共有領域／リソースをＳＡ部分全体に分散させることを可能にし、これは、共有領域定義の定義においてさらなる柔軟性を提供する。
【００８８】
ここで図２に戻ると、サブプール２００は、複数のデータ部分２２０を含み、ここで、共有領域は、サブプールＸ２３０およびサブプールＨ２４０に示すように、ＳＬリソースサブプールごとに分散される態様で設定されてもよいし、サブプールＹ２５０およびサブプールＩ２６０に示されるように分散される態様で設定されてもよいし、または、サブプールＺ２７０およびサブプールＪ２８０に示されるように全領域に対して設定されてもよい。サブプールＸ２３０、サブプールＨ２４０、サブプールＹ２５０、およびサブプールＩ２６０に示されるように、データ部分２２０の複数の共有領域は、周波数領域または時間領域において、ローカライズされた態様または分散された態様で、設定されてもよい。
【００８９】
サブプールＸ２３０のデータ部分は、単一の共有領域２３１を含み、これは、固定領域２３２内の残りのデータリソースと時分割多重化（ＴＤＭ）されるように設定されている。これに対して、サブプールＨ２４０のデータ部分は、ローカライズされた共有領域２４１を含み、これは、固定領域２４２と周波数分割多重（ＦＤＭ）されている。
【００９０】
サブプールＹ２５０は、複数の共有領域２５１を含み、これらは、時間領域において固定領域２５２と多重化されるように設定されている。これに対して、サブプールＩ２６０は、複数の共有領域２６１を含み、これらは、周波数領域において固定領域２６２と多重化されるように設定され、これにより、スーパープール構造タイプに基づく構成の柔軟性を可能とする。
【００９１】
最後に、サブプールＺ２７０およびサブプールＪ２８０は、データ部分全体が共有領域２７１，２８１であるように設定されている。
【００９２】
図４Ａは、本発明の実施形態による、例示的な情報要素（ＩＥ）４００を示す。ＩＥ４００は、上述したように、共有領域と固定領域との間の多用途分割構造を可能にする。ＩＥ４００は、ブロードキャスト設定または事前設定の間にリソースサブプールのＳＡ部分およびデータ部分のための１つまたは複数の共有領域を定義する、以下でさらに詳細に説明されるパラメータ群を含む。パラメータ群のリストは網羅的なものではなく、同様の結果を達成するために設定パラメータ群の異なるセットを使用することが可能であることを、当業者は容易に理解するであろう。
【００９３】
最初に、リソースプール／サブプールＩＤ要素４０１は、ＩＥ４００が関係するＳＬリソースサブプールを定義するために使用され、タイプパラメータ４０２は、ＩＥ４００がＳＡ部分またはデータ部分に関係するかどうかを定義する。次いで、タイプパラメータ４０２がＳＡ部分またはデータ部分のいずれを定義するかに応じて、複数の異なるリソース割り当てパラメータが提供される。
【００９４】
ＳＡ部分については、共有要素４０３は、ローカライズされた、分散された、または全体の共有領域が使用されるかどうかを定義する。共有要素４０３がローカライズされた領域を定義する場合、４０４において、最大Ｎｆ／２までのサイズを有するＮｆ値のリストが定義される。共有要素４０３が分散された領域を定義する場合、４０５において、ＳＡ部分についての最大ＳＡインデックスまでのサイズを有するＳＡインデックスのリストが定義される。他の実施形態では、全ての可能なＮｆ値またはＳＡインデックスに対応するビットマップが提供される。共有要素４０３がＳＡ領域全体を定義する場合、ＮｆまたはＳＡインデックスまたはビットマップは提供されない。
【００９５】
データ部分に関しては、共有要素４０６は、ＦＤＭ、ＴＤＭ、または全共有のいずれが使用されるかを定義する。共有要素４０６がＦＤＭ共有を定義する場合、４０７に示すように、共有領域を定義している、物理リソースブロック（ＰＲＢ）の開始番号および終了番号が提供されるか、または、ＰＲＢビットマップが提供される。
【００９６】
共有要素４０６がＴＤＭ共有を定義する場合、４０８に示すように、共有領域を定義している、サブフレームの開始番号と終了番号が提供されるか、または、サブフレームを表すビットマップが提供される。
【００９７】
共有要素４０６が全体の共有を定義する場合、共有領域のさらなる定義は必要ではなく、したがって提供されない。
【００９８】
ＩＥ４００は、図３Ａおよび図３Ｂを参照して上述したものなど、共有領域を定義するのに特に適している。
【００９９】
図４Ｂは、本発明の実施形態による、例示的なリソースプール分割構成５００を示す。構成５００は、周波数分割多重化された複数のサブプールを有するサイドリンクスーパープールに関して示されている。
【０１００】
構成５１０が提供され、ここでは、サイドリンクスーパープール内のリソースサブプール群のＳＡ部分およびデータ部分が、周波数分割多重化されている。リソースサブプールの全ＳＡ部分および／またはデータ部分は、共有領域として設定されてもよく、これにより、ＳＡリソースおよびデータリソースを選択する際の複数のサイドリンクメッセージ送信機についての完全な柔軟性を可能にする。
【０１０１】
サブプール２およびサブプール３の全ＳＡ部分は、共有領域５１２を定義し、サブプール１、サブプール２およびサブプール３の全データ部分は、共有領域５１３を定義する。（サブプール１、サブプール２およびサブプール３からなる）サイドリンクスーパープールの全データ部分は、共有領域５１３を形成し、データＴＢ送信のためにすべてのＵＥによって自由に使用されもよく、これにより、特定のリソースサブプールに集中したヘビーなトラヒック輻輳を回避する。
【０１０２】
構成５１０は、５２０において、異なる２つのＵＥからの２つのメッセージ送信に関して使用中で図示されており、各ＵＥは、自身の指定されたリソースサブプールを有している。
【０１０３】
第１のＵＥは、その指定されたサブプールとして、リソースサブプール１を割り当てられており、第１のＵＥは、サブプール１のＳＡ部分において、そのＳＣＩ５２１を送信する。サブプール１およびサブプール２のデータ部分におけるリソース使用率の過去の観測に基づいて、第１のＵＥは、サブプール１およびサブプール２のデータ部分において、関連データＴＢ５２２，５２３を送信して、サブプール１における更なる輻輳を最少化する。
【０１０４】
第２のＵＥは、その指定されたサブプールとしてリソースサブプール２を割り当てられており、そのＳＣＩ５２４をサブプール２のＳＡ部分で送信する。第１のＵＥと同様に、第２のＵＥは、過去の観測に基づいて、サブプール３およびサブプール２のデータ部分において、関連データＴＢ５２５，５２６を送信して、サブプール２でのトラフィック増加を最小限にする。
【０１０５】
指定されていないリソースサブプールの共有領域がメッセージ送信に利用される、第１および第２のＵＥからのクロスサブプールスケジューリングを容易にするために、（初期のリソースサブプール設定時に指定された）第２のサブプールの識別子（Ｓｕｂ−ｐｏｏｌ＿ＩＤ）が、ＳＣＩの一部として含まれる。
【０１０６】
サブプール１  ５２７、サブプール２  ５２８、およびサブプール３  ５２９に対して、初期リソースプール設定時に、サブプールＩＤ  ００１，００２，００３に関連付けられた複数のサブプールが与えられ、第１のＵＥのための上記のクロスサブプール共有／スケジューリングの例を再利用すると仮定すると、Ｓｕｂ−ｐｏｏｌ＿ＩＤ＝００２は、第１のＵＥがデータＴＢ送信のためにサブプール２のデータ部分の共有領域を利用することを意図するので、５２１における制御シグナリング送信の一部として含まれるべきである。第２のＵＥの制御シグナリング送信５２４についても同様に、データＴＢ送信はサブプール３およびサブプール２の両方にまたがるので、Ｓｕｂ−ｐｏｏｌ＿ＩＤ＝００３は、ＳＣＩの一部として含まれるべきである。
【０１０７】
図５は、本発明の実施形態による、例示的なリソースプール分割構成６００を示す。構成６００は、時分割多重化されたサブプール群を有するサイドリンクスーパープールに関して示されている。
【０１０８】
ＳＡ部分６１１，６１２およびデータ部分６１３，６１４，６１５，６１６の両方に対して、固定領域と共有領域との時間領域多重化が設定されている、構成６１０が示されている。この構成は、サブプール群で使用されることが当初意図されていた、サービスのために大量のリソースを犠牲にすることなく、部分共有を可能にする。
【０１０９】
構成６１０は、６２０における例示的な使用シナリオを参照して示される。ＵＥ＿１およびＵＥ＿２は、サブプール１においてメッセージパケットを送信することを許可されている第１のサービス群に加入しており、ＵＥ＿３は、サブプール２において送信することを許可されている、異なる第２のサービス群に加入している。
【０１１０】
ＵＥ＿１については、複数のメッセージパケットが時間６２１で受信され、それは、サブプール１のＳＣ期間内に送信されるべきＳＣＩ６２１−１および複数のデータＴＢを処理して準備するのに十分な時間量を提供する。しかしながら、サブプール１のデータ部分内の最初のサービストラフィックの輻輳のために、ＵＥ＿１は、１つのデータＴＢ６２１−２を送信するのに十分なリソースを見つけることしかできない。ＵＥ＿１は、一時的に第２のサービス群に割り当てられている、サブプール２の共有領域を監視し、使用率が低いことを確認する。したがって、ＵＥ＿１は、サブプール２のデータ部分内の共有領域を利用して、その第２のデータＴＢ６２１−３が第２のサービス群のトラフィックと衝突しないという高い信頼度で、その第２のデータＴＢ６２１−３を送信する。
【０１１１】
ＵＥ＿２については、メッセージパケットは、時間６２２において、つまり、サブプール１のＳＣ期間の終わりに向かって、受信され、それは、サブプール１のＳＡ部分内でＳＣＩ６２２−１を処理し送信するために十分な時間を与えるだけである。したがって、サブプール２のデータ部分の共有領域は、データＴＢ６２２−２，６２２−３を送信するために使用され、それは、そのような遅いメッセージパケットが、次のサブプール１サイクルを待つ必要なしに送信される、ことを可能にする。言い換えれば、本明細書で説明される柔軟なリソース共有は、また、次のサイクルを待つよりもむしろ共有リソースを使用して遅い到着パケット配信を可能にし、それを超低遅延サービスに特に適したものにするという点において、有利である。
【０１１２】
ＵＥ＿３については、メッセージパケットは、時間６２３において、つまり、サブプール２の後のサブプールＳＣ期間の間に受信され、その期間はもともと送信に使用することを許可されている。サブプール３のＳＡ部分およびデータ部分は完全に共有されるように設定されているので、ＵＥ＿３は、ＳＡ部分の間にそのＳＣＩ６２３−１を送信し、サブプール３のデータ部分の間にデータＴＢ６２３−２、６２３−３を送信する。このことは、上述のように、送信を次のサブプール２サイクルへ遅らせることなく、イベントトリガパケットの送信を可能にする。
【０１１３】
構成６３０が示され、ここでは、複数の共有領域が、時間領域多重化されたＳＡ部分およびデータ部分を有する複数のサブプールのために使用される。ＵＥ＿１およびＵＥ＿２は、サブプール１においてそれらのデータパケット群を送信することを許可されているサービス群に加入しており、ＵＥ＿３は、サブプール３において送信することを許可されている異なるサービス群に加入している。
【０１１４】
ＵＥ＿１について、データパケット群は、時間６３１で受信され、それは、サブプール１ＳＣ期間内の送信のためにＳＣＩ６３１−１およびデータＴＢを処理し準備するのに十分な時間を与える。サブプール１データ部分内のトラフィック輻輳のために、リソース群は１つのデータＴＢ６３１−２を送信するためにのみ利用可能である。したがって、サブプール２のデータ部分内の共有領域は、第２のデータＴＢ６３１−３を送信するために使用される。
【０１１５】
ＵＥ＿２については、遅い複数のデータパケットが、時間６３２で、つまり、ＳＡ部分の後のサブプール１のデータ部分の間に受信される。したがって、ＵＥ＿２は、サブプール１の間にＳＣＩおよびデータＴＢを送信することができない。この場合、ＵＥ＿２は、代わりに、そのＳＣＩ６３２−１および関連するデータＴＢ６３２を送信するために、サブプール２のＳＡ部分およびデータ部分の共有領域を利用する。これにより、ＵＥ＿２は、送信を次のサブプール１サイクルへ遅らせることなく、パケットのこの遅い到着に対処することが可能になる。
【０１１６】
ＵＥ＿３については、データパケットは、時間６３３で、つまり、送信のためにもともと割り当てられたサブプール３の前のサブプール期間中に受信される。サブプール２のＳＡ部分およびデータ部分の内の共有領域は、ＵＥ＿３によって利用され得るので、ＵＥ＿３は、受信した複数のパケットを処理して、サブプール２のＳＡ部分内のＳＡインデックス９を使用して直ちにＳＣＩ６３３−１を送信し、サブプール２のデータ部分の間に第１のデータＴＢ（６３３−２）を送信し、サブプール３のデータ部分の共有領域を用いて第２のデータＴＢ（６３３−３）を送信する。より早いサブプールに設定された複数の共有領域の、この即時送信および利用は、イベントトリガパケット群の突然の到着による送信遅延の最小化を効果的に可能にする。
【０１１７】
図６は、本発明の一実施形態によるデータ通信方法７００を示す。方法７００は、基地局７２０、および、参加しているモード１サイドリンク通信ＵＥ７２０，７３０（つまり、ＴＸ−ＵＥおよびＲＸ−ＵＥ）を参照して、説明される。方法７００は、クロスモードスケジューリングを可能にし、これは、基地局７２０が、必要に応じて、モード−１データ送信および受信をオフロードするための共有領域として設定される、十分に使われていないモード−２リソース群を使用する、ことを可能にする。
【０１１８】
基地局は、上記の複数のＩＥを使用して、そのＲＲＣ接続されたモード−１サイドリンク通信ＵＥ群に対して、設定された複数の共有領域を有するモード−２エンハンストリソースプール構造を示してもよい。モード−２通信リソース群の設定された複数の共有領域は、リソースプールレベルまたはリソースサブプールレベルであってもよい。モード−２リソースの設定された複数の共有領域は、要求に応じて、または、設定可能な間隔で定期的に、さらに監視および報告されてもよい。条件が許すとき、基地局は、さらに、モード−１ＴＸ−ＵＥに対して、モード−１のＳＡ部分でＳＡを送信し、共有されたモード−２のデータ部分で関連データＴＢを送信することを指示してもよく、これにより、そのモード−１のデータリソースプールでのデータ衝突を低減または除去する。
【０１１９】
サイドリンクメッセージ送信を実行するアドバンストＵＥ（Ｔｘ  ＵＥ）７２０および受信ＵＥ（ＲＸ  ＵＥ）７３０の両方のパワーアップ７０１において、モード１およびモード２の通信リソースプール／サブプールにおけるサイドリンクメッセージが、監視され復号される。特に、パワーアップ７０１の後、ＵＥ７２０，７３０は、参加を要求し、ネットワーク制御の下でサイドリンク通信を許可される。
【０１２０】
ステップ７１１で、ＴＸ  ＵＥ７２０およびＲＸ  ＵＥ７３０の両方が、サイドリンクリソースプールおよびサブプールの設定情報（sidelink resource pools and sub-pools configuration information）についてのブロードキャストシグナリングをローカルＢＳから受信して復号する。これに関しては、ＳＩＢ−１８が用いられてもよい。
【０１２１】
ステップ７１２で、ＵＥ７２０，７３０の両方は、複数のモード−２リソースサブプールのための複数の共有領域に関する設定情報についてのさらなる専用ブロードキャストシグナリング（dedicated broadcast signalling）を、やはりＳＩＢを介してＢＳ７１０から受信する。
【０１２２】
ＴＸ  ＵＥ７２０は、モード−１サイドリンク通信を介してメッセージを送信することを意図しているので、ステップ７１３および７２１において、ＴＸ  ＵＥ７２０は、ＲＲＣコネクションを確立し、ローカルＢＳ（７１０）への送信のための複数のサイドリンクリソースを要求する。このとき、ステップ７１４において、ＢＳ７１０は、モード−１送信リソースプールをＵＥ７２０へ割り当てる。
【０１２３】
ステップ７２２で、ＴＸ  ＵＥのメディアアクセス制御（ＭＡＣ）層は、その内部の上位層からの（例えば、アプリケーション層から発信された）メッセージパケットを受信し、ステップ７２３で、潜在的にバッファステータスレポートとともに送信要求を、サイドリンクスケジューリングのためにＢＳ７１０へ送信する。
【０１２４】
この時点で、他のセルラーＵＥ群によるＰＵＳＣＨ送信にも利用されるモード１データ部分のリソース群は、ローカルＢＳ７１０によって完全に管理および制御されているので、ローカルＢＳ７１０は、モード１データ／ＰＵＳＣＨゾーンの使用およびスケジューリング決定についての完全な知識を有している。
【０１２５】
ステップ７４０で、モード１データ／ＰＵＳＣＨゾーンの使用が、過去および既存のサイドリンクモード−１およびセルラーＵＬのスケジューリング要求に基づいて、完全に輻輳または輻輳すると予測される場合、サイドリンクチャネルメジャメントに関連する機能およびメッセージが、以下のステップ７４１、７４２、および７４３として、ＴＸ  ＵＥ７２０に関連して実行される。
【０１２６】
ステップ７４１で、ＢＳ７１０は、１つまたは複数の選択されたモード２リソースプールまたはサブプールにおけるサイドリンクリソースメジャメントをトリガする。
【０１２７】
ステップ７４２で、ＴＸ  ＵＥ７２０は、指示された１つまたは複数のモード２リソースプールおよび／またはサブプールにおけるサイドリンクリソース使用量を測定し、ここで、このメジャメントは、サイドリンクリソース利用率を決定するために、ＳＡおよびデータＴＢ群を復号することからのブロックエラーレート（ＢＬＥＲ）の計算、ＳＡ部分リソースおよびデータ部分リソースにおけるエネルギーレベルをセンシングすること、または、これらの組み合わせに基づいていてもよい。
【０１２８】
ステップ７４３で、ＴＸ  ＵＥ７２０は、セルラーＰＵＳＣＨチャネルを介して、サイドリンクチャネルメジャメントレポートをローカルＢＳ７１０へフィードバックする。
【０１２９】
次に、ステップ７１５で、報告されたサイドリンクチャネルメジャメント（リソース利用率）に基づいて、ＢＳ７１０は、モード２リソースプールまたはサブプールのどちらおよびどれがサイドリンクメッセージ送信のために使用されるべきかを決定し、この割り当てを、モード１のＳＡ部分でＳＣＩを送信するためのスケジューリング情報と共に、ＴＸ  ＵＥに示す。
【０１３０】
ステップ７２４で、ＢＳからのモード２の割り当てと、示されたモード２リソースプール／サブプールにおける過去のメジャメントとに基づいて、ＴＸ  ＵＥ７２０は、データ送信のためのリソースの選択を行う。
【０１３１】
ステップ７２５で、ＴＸ  ＵＥ７２０は、クロスモードスケジューリングのために、ＳＣＩおよびデータＴＢ群を準備し、ここで、ＳＣＩは、割り当てられたモード２リソースプールまたはサブプールのＩＤを含む。
【０１３２】
ステップ７２６および７２７で、ＴＸ  ＵＥ７２０は、モード１のＳＡ部分におけるスケジュールされたリソースを使用して、ＳＣＩを送信し、割り当てられたモード２のプール／サブプールにおいて選択されたリソースを使用して、データＴＢ群を送信する。
【０１３３】
ステップ７３１において、ＲＸ  ＵＥ７３０は、以下のステップ７３２，７３３，７３４として、サイドリンク受信に関連する機能７３１を実行する。
【０１３４】
ステップ７３２で、ＲＸ  ＵＥは、モード１ＳＡ部分の間に、ＳＡリソース群を継続的に監視して、ＳＣＩを復号する。
【０１３５】
ステップ７３３で、ＲＸ  ＵＥは、復号されたＳＣＩから、モード２リソースプール／サブプールのＩＤおよびその関連データリソース割り当て情報を取得する。次いで、これらに基づいて、ステップ７３４において、ＲＸ  ＵＥは、モード２プールサブプールデータ部分から、データＴＢを取り出して、復号する。
【０１３６】
次いで、７０２によって示されるように、ステップ７２２以降が繰り返され、反復プロセスを提供する。
【０１３７】
図７は、本発明の一実施形態による、クロスモード共有およびスケジューリングの方法８００を示す。方法８００は、クロスモードスケジューリングおよび送信を伴う、ＲＲＣ接続モード１ＵＥについて示されている。
【０１３８】
最初に、モード１リソースプール８１０およびモード２リソースプール８２０の形態の複数のサイドリンクリソースプールが、ブロードキャストを介して、セルラー基地局によって設定される。
【０１３９】
モード１リソースプール８１０は、ＳＣ期間８１１と、システム帯域幅の上部セクション８１２を占める周波数帯域幅サイズとを有する。それは、ＳＡ部分リソース群８１３と無線リソース部分８１４とを含み、ＳＡ部分リソース群８１３は、モード１サイドリンク制御／スケジューリング情報を送信するためのものであり、無線リソース部分８１４は、サイドリンクモード１データＴＢおよびセルラーアップリンクＰＵＳＣＨチャネルを送信するためのものであり、ＢＳスケジューリングに応じて柔軟に使用することができる。モード１リソースプール構造は、繰り返し８１５，８１６，８１７，８１８によって示されるように、モード１ＳＣ期間８１１を繰り返す。
【０１４０】
モード２リソースプール８２０は、ＳＣ期間８２１と、システム帯域幅の下部セクション８２２を占める周波数帯域幅サイズとを有する。それは、ＳＡ部分リソース群８２３とデータ部分リソース群８２４とを含み、ＳＡ部分リソース群８２３は、モード２サイドリンク制御／スケジューリング情報を送信するためのものであり、データ部分リソース群８２４は、サイドリンクデータＴＢのみを送信するために使用することができるものである。さらに、モード２リソースプールのデータ部分８２４の全体は、共有領域として設定されて、ブロードキャストされる。このモード２リソースプール構造８２１は、繰り返し８２５，８２６，８２７によって示されるように、モード２ＳＣ期間を繰り返す。
【０１４１】
モード１リソースプールをローカルＢＳによって割り当てられたアドバンストＵＥは、複数のサイドリンクメッセージを送信する必要があり、それは、８１１，８１６，８１８において２つのモード１ＳＣ期間毎に等しい周期で、８４０，８５０，８６０によって示されるように、ＳＣＩブロックおよび２つのデータＴＢを含んでいてもよい。
【０１４２】
第１のメッセージ送信８４０の間に、ＢＳは、サイドリンクモード１送信およびアップリンクセルラースケジューリング要求の両方の増加を検出し、将来必要とされるリソースの量が、モード１データおよびセルラーＰＵＳＣＨチャネル８１４についてのリソース部分において利用可能なリソース量を超えると予測する可能性がある。結果として、ＢＳは、時間８３０において、モード２リソースプール上でＳＬチャネルメジャメントを実行するように、アドバンストＵＥへ指示する。ＢＳは、ＳＣ期間（ｋ）８２５の間に、モード２プールの１つまたは複数の期間に等しい、設定可能なメジャメント長（configurable measurement length）８３１を提供する。
【０１４３】
その間、ＢＳは、８５０に示すように、サイドリンクメッセージ送信のために、モード１ＳＡ部分およびモード１データゾーン／ＰＵＳＣＨ部分から、リソースをアドバンストＵＥへ割り当てることを継続する。サイドリンクメッセージ送信８５０の間、サイドリンクＳＣＩおよびデータを送信するために用いられるサブフレーム／期間（subframes／time duration）８３２は、指示されたサイドリンクチャネルメジャメント期間８３１とオーバラップしており、このエリアは、サイドリンク送信のために使用されるがモード２リソースプールのメジャメントのためには使用されない。そのため、サイドリンクメッセージ送信は、常にサイドリンクチャネルメジャメントよりも高い優先順位を持つ。
【０１４４】
メジャメント期間の後、ＵＥは、時間８３３において、セルラアップリンクチャネルＰＵＳＣＨを介して、ＳＬチャネルメジャメントレポートを基地局へフィードバックする。
【０１４５】
アドバンストＵＥから報告されたＳＬチャネルメジャメントに基づいて、ＢＳは、モード２リソースプール、特に共有領域（全データ部分）が、軽負荷で輻輳していない、ことを識別し、アドバンストＵＥをモード２リソースプールにオフロードすることを決定する。サイドリンクメッセージ送信８６０について示されるように、ＢＳは、ＳＣＩを送信するために、モード１リソースプールのＳＡ部分から、アドバンストＵＥリソース８６１を割り当て、データＴＢを送信するために、モード２データ部分からの共有領域を利用するように、ＵＥへ指示する。
【０１４６】
次いで、アドバンスドＵＥは、ＳＡ復号およびモード２リソースプール使用量のエネルギーセンシングを含む過去のメジャメントに基づいて、メッセージデータＴＢを送信するためのモード２データ共有領域内でリソース８６２，８６３を決定する。制御／スケジューリング情報（ＳＣＩ）がモード１ＳＡプールを介して送信され且つその関連データＴＢがモード２データプール（共有領域）を介して送信される、クロスモードスケジューリングのこのような動作において、制御／スケジューリングが行われるリソースプールは、「ホスト」プール８７０と呼ばれ、共有領域が使用されるデータリソースプールは、「ゲスト」プール８８０と呼ばれる。したがって、制御シグナリングおよびその関連データＴＢの送信のための２つの異なるリソースプールの、ホストゲスト関係／関連（host-guest relationship/association）が、サイドリンクメッセージについて確立される。
【０１４７】
ＴＸ  ＵＥからのデータＴＢ送信およびそれに続くＲＸ  ＵＥでのデータＴＢ受信に適した適切なモード２ＳＣ期間（ゲストデータプール）を決定する際の原理は、８９１で示されるように、モード１ＳＡプールの最後からモード２データプールに残っている２つ以上の送信時間間隔（ＴＴＩｓ：Transmit Time Intervals）を有している、モード２データリソース部分であるべきである。このことは、ＴＸ  ＵＥとＲＸ  ＵＥとの間のホストＳＡプールおよびゲストデータプールの同じ理解を保証し、２つのデータＴＢについての十分な量の送信機会を可能とし、重複しているまたはより早い（ＳＡより前のデータ）ＴＴＩ群が許される場合、複数のＲＸ  ＵＥについての過度のバッファリングを回避する。
【０１４８】
ＲＸ  ＵＥでのデータ受信については、ＵＥが関連データＴＢの復号化を実行することができるようになる前に、一般に、制御シグナリング情報を処理するのに約１ＴＴＩかかる。適切なモード２ＳＣ期間を決定する際に上記の原理に従うことによって、３つのサイドリンクメッセージ受信シナリオがあり得て、これらのシナリオでは、データＴＢ復号化を開始することができる前に、ＲＸ  ＵＥが、モード２データ部分の開始時に、データの複数のサブフレームをバッファする必要がある可能性がある。
【０１４９】
モード１ＳＡ部分がモード２データ部分とオーバラップしている領域８９１を参照すると、ＲＸ  ＵＥは、ＳＣ期間（ｎ）８１６の間のモード１ＳＡ部分の後端からのＳＣ期間（ｋ）８２５の間のモード２データ部分において、１ＴＴＩのデータをバッファする必要がある。
【０１５０】
領域８９２を参照すると、ＳＣ期間（ｎ−２）８１１の間のモード１ＳＡ部分８１３の終わりと、ＳＣ期間（ｋ−１）８２１の間のモード２データ部分８２４の始まりとの間のギャップが、１ＴＴＩより大きい場合、ＲＸ  ＵＥは、モード２データ部分８２４の始まりの時点においてデータをバッファする必要がないであろう。
【０１５１】
時間８９３を参照すると、ＳＣ期間（ｎ＋２）８１８の間のモード１ＳＡ部分の終わりとＳＣ期間（ｋ＋２）８２７の間のモード２データ部分の始まりとの間にギャップがない場合、ＲＸ  ＵＥは、ＳＣ期間（ｋ＋２）８２７の間のモード２データ部分の始まりの時点において１ＴＴＩのデータをバッファする必要があるであろう。
【０１５２】
図８は、本発明の一実施形態によるデータ通信方法９００を示す。方法９００は、参加しているモード２サイドリンク通信ＵＥ（すなわち、ＴＸ  ＵＥおよびＲＸ  ＵＥ）において使用するためのものであり、ＴＸ  ＵＥが、他のサービスで使用されるように設定されてもよい、十分に使用されていない、設定されたセカンダリモード２リソースサブプールを使用する、ことを可能にする。このことは、必要に応じて、ＴＸ  ＵＥが、即時のデータ送信および受信のために、その設定されたプライマリモード２リソースサブプールから、トラフィックをオフロードする、ことを可能にする。
【０１５３】
基地局は、そのモード２サイドリンク通信のアドバンストＵＥに対して、上述のＩＥを使用して、設定された共有領域を有するモード２エンハンストリソースプール構造を示してもよい。モード２通信リソースの複数の共有領域は、リソースプールまたはリソースサブプールレベルで設定されてもよい。設定されたプライマリモード２リソースと共に設定されたセカンダリモード２リソースの設定された共有領域は、使用される仮想モード２リソースを形成し、この仮想モード２リソースは、要求に応じてまたは定期的に設定可能な間隔で、ＳＣＩおよびデータＴＢの送信におけるさらなる競合のために利用可能なチャネルリソースのために、モニタされる。
【０１５４】
観察からもたらされた、構築された仮想リソース内の利用可能なチャネルリソース内でのＳＣＩおよびデータＴＢの送信の競合の観点では、アドバンストＵＥは、さらに、その設定されたセカンダリリソースプール／サブプール領域内のチャネルインデックスよりも、選択優先度が高いプライマリリソースプール／サブプール内のチャネルインデックスを考慮してもよい。
【０１５５】
さらに、その設定されたセカンダリリソースプール／サブプール領域内のチャネルインデックスが選択のために考慮される場合、アドバンストＵＥは、構成された仮想リソースプールにおける設定されたセカンダリリソースプール／サブプール領域内のすべてのチャネルインデックスを、プール／サブプールの由来にかかわらず、等しい選択確率で扱うことができる。したがって、このことは、チャネル選択が物理的／論理的リソースプール／サブプールベースで考慮されるときに、その設定されたプライマリリソースプール／サブプールからの輻輳トラフィックが、最も輻輳の少ない設定されたセカンダリリソースプール／サブプールへ直接的にあふれる、ケースを排除し得る。条件が許すとき、モード−２のＴＸ  ＵＥは、そのもともと割り当てられたプライマリモード−２リソースプールにおいてまたは共有されたセカンダリモード−２リソースプールにおいて、ＳＡおよび関連データＴＢの一方または両方を送信してもよく、これにより、その指定されたプライマリモード−２リソースプール/サブプールにおいてトラフィックの増加に起因したデータ衝突を低減または排除する。
【０１５６】
方法９００は、セルラー基地局（ＢＳ）９１０、サイドリンクメッセージ送信を実行するアドバンストＵＥ（ＴＸ  ＵＥ）９２０、および、モード２通信リソースプール／サブプールにおいてサイドリンクメッセージを監視および復号する受信ＵＥ（ＲＸ  ＵＥ）９３０を参照して、説明される。
【０１５７】
ステップ８０１で、ＴＸ  ＵＥおよび複数のＲＸ  ＵＥの両方が起動し、ネットワーク制御下で、サイドリンク通信に参加しサイドリンク通信を許可されることを要求する。初期セットアップ段階では、ステップ９１１で、ＴＸ  ＵＥおよびＲＸ  ＵＥの両方が、ローカルＢＳから、サイドリンクリソースプールおよびサブプールの設定情報についてのブロードキャストシグナリングを受信して復号し、ここで、ＳＩＢ−１８が、使用のために拡張され得る。
【０１５８】
次に、ステップ９１２で、ＵＥ９２０，９３０の両方は、モード２リソースプール／サブプールの共有領域に関する設定情報についてのさらなる専用ブロードキャストシグナリングを、さらにＳＩＢを介して９１０ＢＳから受信する。ＴＸ  ＵＥ９２０は、サイドリンク通信を使用してメッセージを送信することを意図しているので、ＴＸ  ＵＥ９２０は、ステップ９１３および９２１において、それぞれ、ＲＲＣコネクションを確立し、ローカルＢＳ９１０への送信のために複数のサイドリンクリソースを要求する。ステップ９１４において、基地局９１０は、モード２送信リソースプール／サブプールを割り当てる。
【０１５９】
サイドリンクリソース選択はモード−２動作の間にＢＳの支援を必要としないので、ＴＸ  ＵＥ９２０は、ステップ９２２で、ＢＳ９１０とのＲＲＣコネクションを解放する。
【０１６０】
ステップ９２３で、ＴＸ  ＵＥ９２０のメディアアクセス制御（ＭＡＣ）層は、その内部の上位層から（例えば、アプリケーション層から発信される）メッセージパケットを受信し、トータルのデータＴＢサイズを計算し、サイドリンクリソースプールでメッセージを転送するために必要とされる、データリソースブロック（ＲＢ）の量を決定する。
【０１６１】
ステップ９２４で、ＴＸ  ＵＥ９２０は、ステップ９１４でＢＳによって指定されたＳＡ部分およびデータ部分の両方に渡って、モード２リソースプール／サブプールでのサイドリンクリソース使用量を測定する。そのメジャメントは、サイドリンクリソース利用率を決定するために、ＳＡおよびデータＴＢ群を復号することからのブロックエラーレート（ＢＬＥＲ）の計算、ＳＡ部分リソースおよびデータ部分リソースにおけるエネルギーレベルをセンシングすること、または、これらの組み合わせに基づいていてもよい。
【０１６２】
ＴＸ  ＵＥ９２０のＭＡＣ層は、その上位層からメッセージパケットを定期的に受信する可能性があるので、指定されたモード２リソースプール／サブプールにおけるサイドリンクチャネルメジャメントは、定期的に実行される。
【０１６３】
メジャメントの結果／成果に基づいて、ＴＸ  ＵＥ９２０は、その指定されたモード２リソースプール／サブプールが輻輳しているかどうかを判断し、そのＳＣＩの送信およびデータＴＢの送信に潜在的に使用され得る、空いているＳＡ部分リソースおよびデータ部分リソースを観察する。その指定されたプール／サブプールが高いトラフィック量を経験している場合、ステップ９２５において、ＵＥ９２０は、他のモード２リソースプール／サブプールに対してサイドリンクチャネルメジャメントを実行する。ＵＥ９２０は、適切な選択を行うために、設定された／事前設定された１つまたは複数の共有領域を有する、すべてのモード２プールおよびサブプールを監視する必要がある可能性がある。
【０１６４】
ステップ９２６で、ＴＸ  ＵＥ９２０は、設定された共有領域を有する（その指定されたもの以外の）モード２プール／サブプールの選択を行い、そして、メッセージＳＣＩが１つのプール／サブプールで搬送されるべきであり且つ関連するデータＴＢ群の一部または全部が選択されたプール／サブプールで搬送されるべきであると決定される場合に、仮想リソースプールを組み立てる。したがって、仮想リソースプールは、ＴＸ  ＵＥの指定されたプール（ホスト）に対して、選択されたモード２プール／サブプール（ゲスト）の１つまたは複数の共有データ領域をプラスした、組み合わせであり、このため、ホストゲスト関係／関連を形成する。この仮想リソースプール構成は、図９を参照して以下にさらに説明される。
【０１６５】
ステップ９２７で、メッセージ送信のための仮想リソースプールが構築されると、ＴＸ  ＵＥ９２０は、クロスサブプールスケジューリングのために、ＳＡリソースおよびデータリソースの選択を行い、ここで、ＳＡリソースは、ホストプールの仮想ＳＡ部分から選択され、データリソース群は、仮想データ部分から選択されることになる。
【０１６６】
ステップ９２８で、ＴＸ  ＵＥ９２０は、クロスモードスケジューリングのためにＳＣＩおよびデータＴＢ群を準備し、ここで、ＳＣＩは、ステップ９２６で選択されたモード２プール／サブプールのｐｏｏｌ＿ＩＤを含み、リソース割り当てパラメータ群は、構築された仮想データ部分に基づいて導出される。
【０１６７】
ステップ９２９−１および９２９−２で、ＴＸ  ＵＥ９２０は、構築された仮想リソースプールの、仮想ＳＡ部分から選択されたリソースを用いてメッセージＳＣＩを送信し、仮想データ部分から選択されたリソース群を用いて関連データＴＢ群を送信する。
【０１６８】
ＲＸ  ＵＥ９３０については、サイドリンク受信に関連する機能９３１が、ステップ９３２，９３３，９３４で提供される。
【０１６９】
ステップ９３２で、ＲＸ  ＵＥ９３０は、ＳＡリソース群を継続的に監視し、モード２プール／サブプールのＳＡ部分からのＳＣＩを復号する。
【０１７０】
ステップ９３３において、復号されたＳＣＩ（ホスト）および取得されたｐｏｏｌ＿ＩＤ（ゲスト）のリソースプール／サブプールに基づいて、ＲＸ  ＵＥ９３０は、仮想リソースプールを組み立てる。次に、ステップ９３４で、データリソース割り当てパラメータ群に基づき、ＵＥ９３０は、構築された仮想データ部分から関連データＴＢ群を取り出すことに進む。
【０１７１】
その後、９０２に示すように、ステップ９２３以降が繰り返され、反復プロセスが提供される。
【０１７２】
図９は、本発明の実施形態による、クロスサブプール共有およびスケジューリングの方法１０００を示す。方法１０００は、クロスサブプールスケジューリングおよび送信を伴う、モード２のＵＥについて示されている。
【０１７３】
セルラー基地局によって事前設定または設定されたサイドリンクモード２リソーススーパープール１００１は、設定可能な長さの持続時間、およびシステム帯域幅の設定可能な周波数サイズを有し、ＳＣ期間（ｊ＋１）について１００５によって示されるように、ＳＣ期間ごとにそれ自体を繰り返す。モード２スーパープール１００１は、３つの時分割多重化されたサブプール１００２，１００３，１００４を含み、それぞれがＳＣ期間および１つまたは複数の共有領域を有しており、個々に、設定／事前設定される。
【０１７４】
サブプール１  １００２については、ＳＡリソース部分およびデータリソース部分は、１つのローカライズされた共有領域がデータ部分の終わりに設定／事前設定された状態で、周波数多重化される。この構造は、モード２スーパープールＳＣ期間（ｊ＋１）内の１００６で繰り返される。
【０１７５】
サブプール２  １００３については、ＳＡリソース部分およびデータリソース部分は、２つの分散された共有領域がデータ部分に設定されている状態で、周波数多重化されている。この構造は、モード２スーパープールＳＣ期間（ｊ＋１）内の１００７で繰り返される。
【０１７６】
サブプール３（１００４）については、ＳＡリソース部分およびデータリソース部分は、両方の部分全体が共有領域として設定／事前設定されている状態で、周波数多重化される。この構造は、モード２スーパープールＳＣ期間（ｊ＋１）内の１００８で繰り返される。
【０１７７】
第１のＵＥ（ＵＥ＿１）は、上記のモード２スーパープール構造および複数の共有領域で設定されたアドバンストＵＥであり、サイドリンクメッセージ送信について指定されたモード−２リソースサブプールとしてサブプール１で割り当てられている。ＵＥ＿１は、複数のサイドリンクメッセージ１１０１，１１０６を送信し、各サイドリンクメッセージは、ＳＣＩブロックおよび２つのデータＴＢを含む。ＵＥ＿１は、モード２スーパープールＳＣ期間ごとに、複数のメッセージを送信することができる。
【０１７８】
サブプール１における第１のメッセージ送信１１０１の間に、第１のＵＥは、また、サブプール１ＳＣ期間（ｋ）のＳＡ部分１１０２およびデータ部分１１０３の両方において、サイドリンクチャネルメジャメントを実行する。第１のＵＥは、定期的にサイドリンクメッセージを送信する必要があるので、サブプール１の後続のＳＡ部分１１０８およびデータ部分１１０９において定期的にサイドリンクチャネルメジャメントを実行して、指定されたサブプールにおけるリソース利用を監視する。
【０１７９】
サブプール１  １１０３のデータ部分におけるサイドリンクチャネルメジャメントの間に、第１のＵＥは、リソース利用率の増加を観察し、高いトラフィック量を経験する可能性があり、このため、次のデータサブプールの複数の共有領域１１０５において、そのリソース利用率を決定するために、サイドリンクチャネルメジャメントをトリガする可能性がある。
【０１８０】
ＳＣ期間（ｊ）の間の１１０３および１１０５についてのサイドリンクメジャメント結果に基づいて、ＵＥ＿１は、後続のモード２スーパープールＳＣ期間（ｊ＋１）における第２のメッセージ送信のためにサブプール２データ部分の複数の共有領域を利用することを決定する。第２のメッセージ送信１１０６は、データサブプール２の複数の共有領域で送信された第２の複数のデータＴＢ１１０７を含む。
【０１８１】
第２のメッセージ送信１１０６のためにデータサブプール２の複数の共有領域を利用するために、ＵＥ＿１は、最初に、ＳＣ期間（ｋ＋１）からホストプール１００６としてもともと指定されているサブプール１と、ＳＣ期間（ｍ＋１）のゲストプール１３０６としてのデータサブプール２  １３０４および１３０５の複数の共有領域とを結合することによって、仮想リソースプールを組み立てる。したがって、その仮想リソースプールは、１３００で示されるように、ＳＣ期間（ｋ＋１）１３０１にＳＣ期間（ｍ＋１）１３０２の共有領域を加えた長さに等しい、仮想リソースプール長１３０３を有する。データリソース選択およびそのリソース割り当てパラメータ（例えば送信パターン）は、結合された仮想データ部分に基づくべきである。
【０１８２】
第２のＵＥ（ＵＥ＿２）も、上記のモード２スーパープール構造および複数の共有領域で設定／事前設定されているアドバンストＵＥであり、サイドリンクメッセージ送信のための指定されたモード−２リソースサブプールとしてサブプール２で割り当てられている。ＵＥ＿１と同様に、ＵＥ＿２は、複数のサイドリンクメッセージ１２０１，１２０６を送信し、各サイドリンクメッセージは、ＳＣＩブロックおよび２つのデータＴＢを含む。メッセージ１２０１，１２０６は、モード２スーパープールＳＣ期間ごとに送信される。
【０１８３】
サブプール２における第１のメッセージ送信１２０１の間に、第２のＵＥはまた、サブプール２ＳＣ期間（ｍ）のＳＡ部分１２０２およびデータ部分１２０３の両方において、サイドリンクチャネルメジャメントを実行する。第２のＵＥは、定期的にサイドリンクメッセージを送信する必要があるので、サブプール２の後続のＳＡ部分１２０８およびデータ部分１２０９において、定期的にサイドリンクチャネルメジャメントを実行して、指定されたサブプールにおけるリソース利用を監視する。ＵＥ＿２加入サービスの一部として、第２のＵＥは、（たとえば、処理電力消費が重要な関心事ではない車両ＵＥのための）モード２サブプール３で送信されているメッセージも監視および受信する。したがって、第２のＵＥは、サブプール３の共有領域１２０４，１２０５においても、サイドリンクチャネルメジャメントを定期的に実行してもよいが、メジャメント頻度は、サブプール２に比べて少なくてもよい。
【０１８４】
モード２スーパープールＳＣ期間（ｊ＋１）の間に、ＵＥ＿２は、その指定されたサブプール２期間の終わりに向かって複数のパケットの遅い到着を受信する。サブプール３における１２０４および１２０５のサイドリンクメジャメント結果に基づいて、１２０７によって示されるように、第２のＵＥは、第２のメッセージのデータＴＢ群を送信するために、サブプール３のデータ領域の共有領域を利用することを決定する。
【０１８５】
第２のメッセージ送信１２０６のためにデータサブプール３の複数の共有領域を利用するために、ＵＥ＿２は、最初に、ＳＣ期間（ｍ＋１）からホストプール１００７としてもともと指定されているサブプール２と、ＳＣ期間（ｎ＋１）のゲストプール１４０５としてのデータサブプール３  １４０４の共有領域とを結合することによって、仮想リソースプールを組み立てる。したがって、仮想リソースプールは、１４００によって示されるように、ＳＣ期間（ｍ＋１）１４０１に期間（ｎ＋１）１４０２の複数の共有領域を加えた長さに等しい、仮想リソースプール長１４０３を有する。データリソース選択およびそのリソース割り当てパラメータ（例えば送信パターン）は、結合された仮想データ部分に基づくべきである。
【０１８６】
有利には、本発明の実施形態は、既存のＬＴＥベースのサイドリンク通信リソースプール構造に基づいて、共有リソース群の設定可能な１つまたは複数の領域を提供し、これにより、アドバンストサイドリンク送信装置は、他の未指定または二次指定のリソースプール/サブプールから、十分に活用されていないサイドリンクリソースを柔軟に利用することができる。これは、共通リソースプールが複数のサービス間で共有するために割り当てられてサービス間送信衝突のリスクを最小にして、プライマリ指定サイドリンク通信リソースおよび／またはセルラー通信リソースにおける輻輳を軽減または防止し、（サイドリンクリソースを再設定する必要なしに）同じセル内の複数のサービスの、急速に変化するトラフィック要求または不均一な需要に対応するために、用いられてもよい。そのようにして、要求されるＱｏＳおよびサイドリンク通信性能は、保持され得る。
【０１８７】
本発明の実施形態は、後方互換性のあるエンハンストサイドリンクリソースプール構造を提供し、これにより、同じリソースプールまたはリソースサブプール内で同時に動作する、レガシー通信デバイスおよびアドバンストサイドリンク通信装置の共存を可能にする。この点に関して、複数のレガシーサイドリンク通信デバイスは、設定可能な「共有領域群」に関する追加の設定情報要素の知識を持たない可能性があり、したがって、レガシーシグナリングを介して示される、設定されたリソースプールまたはサブプールを、サイドリンク制御およびデータＴＢ送受信における競合のために利用可能なチャネルリソース群と見なしている。さらに、付加的な設定された情報要素群は、アドバンストサイドリンクデバイスにて復号可能であり、且つ、レガシーシグナリングを介して示される設定されたプライマリ指定リソースに加えて、必要に応じて使用するために設定可能なセカンダリ指定チャネルリソース群または競合のための利用可能なチャネルリソース群全体の一部を示すために、設計されている。
【０１８８】
サイドリンクの制御およびデータＴＢの送信のためのリソース競合が個別に行われる、モード−２または他の自律的なモードのサイドリンク通信の場合、アドバンストサイドリンク通信装置では、プライマリリンクプールまたはサブプール、および、１つまたは複数のセカンダリ指定リソースプールまたはサブプールの「共有領域群」から構築されている、仮想リソースプールまたはサブプールは、監視されるための、全体の周期的なチャネルリソースと見なされてもよい。観察からもたらされる利用可能なチャネルリソース群における１つまたは複数のチャネルは、サイドリンクおよび／またはデータＴＢの送信に使用されるためにさらにランダムに決定されてもよく、このアプローチの利点は、チャネル選択が論理リソースプールまたはサブプールベースで行われる場合、最も混雑したリソースプールから最も混雑の少ないリソースプール/サブプールへ流出する輻輳を除去することである。
【０１８９】
データメッセージの周期的送信により適している繰り返しサイドリンク制御期間を有する既存のサイドリンクリソースプール構造設計と比較して、設定可能な共有領域を有するエンハンスト構造および関連する方法は、時間に敏感なデータパケットを次の指定されたサイドリンク制御期間サイクルまで延期または遅延させる必要なしに、トリガされたイベントおよび遅延不耐性タイプの交通安全警告メッセージ（delay-intolerant type road safety warning messages）のタイムリな配信のための手段を提供する。
【０１９０】
同様に、２つの連続する指定されたリソースプールまたはサブプールの間の他のリソースプールまたはサブプールにおける共有領域群を有するエンハンストリソースプールは、遅れて到着したパケットが、他のプールまたはサブプールにおける共有領域を使用して直ちに送信される、ことを可能にし、これにより、遅延を減らしスケジューリングの複雑さを軽減する。
【０１９１】
本明細書および特許請求の範囲（もしあれば）において、「含む（comprising）」という語ならびに「含む（comprises）」および「含む（comprise）」を含むその派生語は、記載された整数のそれぞれを含むが、１つまたは複数のさらなる整数の包含を排除しない。
【０１９２】
本明細書全体を通して「一実施形態（one embodiment）」または「一実施形態（an embodiment）」への言及は、その実施形態に関連して説明された、特定の特徴（feature）、構造（structure）、または特性（characteristic）が、本発明の少なくとも１つの実施形態に含まれる、ことを意味する。したがって、本明細書を通して様々な箇所での「一実施形態では（in one embodiment）」または「一実施形態では（in an embodiment）」という句の出現は、必ずしもすべてが同じ実施形態を指すとは限らない。さらに、特定の特徴、構造、または特性は、１つまたは複数の組み合わせで任意の適切な方法で組み合わせることができる。
【０１９３】
法令に従って、本発明を構造的または方法的な特徴に多かれ少なかれ特有の言葉で説明した。
本明細書に記載された手段は本発明を実施する好ましい形態を含むので、本発明は、示されまたは記載された特定の特徴に限定されない、ことを理解すべきである。したがって、本発明は、当業者によって適切に解釈される（もしあれば）添付の特許請求の範囲の適切な範囲内のその形態または修正のいずれかで、請求される。
【０１９４】
この出願は、２０１６年９月２６日に出願されたオーストラリア仮特許出願第２０１６９０３８８９号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【図１】
2019532571.tif 000005
【図２】
2019532571.tif 000006
【図３Ａ】
2019532571.tif 000007
【図３Ｂ】
2019532571.tif 000008
【図４Ａ】
2019532571.tif 000009
【図４Ｂ】
2019532571.tif 000010
【図５】
2019532571.tif 000011
【図６】
2019532571.tif 000012
【図７】
2019532571.tif 000013
【図８】
2019532571.tif 000014
【図９】
2019532571.tif 000015
【手続補正書】
【提出日】平成31年3月13日(2019.3.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ダイレクト通信をサポートして柔軟なリソースプールの共有を提供するアドバンスト無線通信システムにて用いられる方法であって、
第１ＵＥが、設定された共有領域と関連づけられたダイレクト通信チャネルの少なくとも１つのリソースプールの利用率を測定し、
前記第１ＵＥが、少なくとも１つの第２ＵＥへ、前記少なくとも１つのリソースプールの選択されたリソースプールを識別するサイドリンク制御情報（ＳＣＩ）を送信し、
前記第１ＵＥが、前記少なくとも１つの第２ＵＥへ、前記ＳＣＩと関連づけられたデータを、前記選択されたリソースプールにおいて送信する、
方法。
【請求項２】
前記共有領域は、基地局によって設定される、
請求項１記載の方法。
【請求項３】
前記共有領域は、ブロードキャストシグナリングによって設定される、
請求項１または２に記載の方法。
【請求項４】
前記共有領域は、事前設定される、
請求項１記載の方法。
【請求項５】
前記ＳＣＩは、前記選択されたリソースプールを識別する、プール識別子（ｐｏｏｌ＿ＩＤ）を含む、
請求項１から４のいずれか１項に記載の方法。
【請求項６】
前記リソースプールは、サブプールを含む、
請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記第１ＵＥは、前記測定された利用率を基地局へ報告し、それに応じて、前記データの送信のためのリソースプールのインジケータを受信する、
請求項１記載の方法。
【請求項８】
前記第１ＵＥは、前記第１ＵＥへ指定されたリソースプールにおいて、前記ＳＣＩを送信する、
請求項１記載の方法。
【請求項９】
前記少なくとも１つのリソースプールは、時分割多重化または周波数分割多重化された、複数のリソースプールを含む、
請求項１から８のいずれか１項に記載の方法。
【請求項１０】
仮想リソースプールを形成すること、および、
前記仮想リソースプールのスケジューリング部分において前記ＳＣＩを送信し、前記仮想リソースプールのデータ部分において前記関連づけられたデータを送信すること、
を含む、
請求項１記載の方法。
【国際調査報告】
2019532571.tif 000016