JP6369635B2

JP6369635B2 - バッファ状態報告の生成方法、装置及び通信システム

Info

Publication number: JP6369635B2
Application number: JP2017534835A
Authority: JP
Inventors: シュイ・ハイボ; ウ・リエヌハイ
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2014-12-31
Filing date: 2014-12-31
Publication date: 2018-08-08
Anticipated expiration: 2034-12-31
Also published as: KR20170095958A; EP3242526A1; JP2018504830A; EP3242526A4; CN107006028A; WO2016106729A1; US20170303307A1

Description

本発明は、通信技術の分野に関し、特にバッファ状態報告の生成方法、装置及び通信システムに関する。

現在のＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ：ロング・ターム・エボリューション）システムにおいて端末装置と端末装置との間の通信は無線アクセスネットワーク及びコアネットワークを介して行われる必要がある。新たなトラヒック要求の出現に伴い、ネットワークのロードを低減し、ネットワークのロードの移転を実現するために、端末装置と端末装置との間の通信は徐々に新たな研究の方向となっている。２つの端末装置の間の距離が十分に近い場合に、端末装置は相手の存在を互いに発見できるため、基地局の制御により装置と装置との間の直接通信を行うことができる。

装置と装置の通信を実現するために、ＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ：ロング・ターム・エボリューション・アドバンスト）システムでは２つのエアインタフェースのリソース割り当て方式、即ちモード１（Ｍｏｄｅ１）及びモード２（Ｍｏｄｅ２）が定義されている。モード１では、従来のインフラ通信モードのトラヒックのバッファ状態報告（ＢｕｆｆｅｒＳｔａｔｕｓＲｅｐｏｒｔ：ＢＳＲ）の報告への影響を回避するために、装置間の通信のための特別なバッファ状態報告（ＰｒｏＳｅ−ＢＳＲと称されてもよい）メカニズムが導入され、該メカニズムは主に新たなバッファ状態報告のトリガ・メカニズム、並びにバッファ状態報告のＭＡＣシグナリング・フォーマット及び内容を含む。

Ｄ２Ｄ（ＤｅｖｉｃｅｔｏＤｅｖｉｃｅ：装置から装置）通信モードではサイドリンク制御期間（ＳｉｄｅｌｉｎｋＣｏｎｔｒｏｌＰｅｒｉｏｄ。ＳＣｐｅｒｉｏｄと略称される）の概念が定義され、該ＳＣｐｅｒｉｏｄはスケジューリング制御（ＳｃｈｅｄｕｌｉｎｇＣｏｎｔｒｏｌ）及びそれに対応するデータの伝送を含む時間周期を意味する。Ｍｏｄｅ１について、Ｄ２Ｄ通信における送信側のデータ伝送の基本的な作動原理は以下の通りである。

基地局があるＤ２ＤＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置）のデータ伝送をスケジューリングすると決定した後に、基地局は、ＳＬ−ＲＮＴＩ（Ｓｉｄｅｌｉｎｋ−ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒｙＩｄｅｎｔｉｔｙ：サイドリンク無線ネットワーク一時識別子）によりスクランブルされたＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ：物理ダウンリンク制御チャネル）を介して該ＵＥにＳＬｇｒａｎｔ（ｓ）（サイドリンクグラント）を送信し、該ＳＬｇｒａｎｔ（ｓ）は、該ＵＥが伝送するＳＣ（スケジューリング制御）の時間周波数領域リソース位置及び伝送するデータの時間周波数領域リソース位置を含む。該ＳＬｇｒａｎｔ（ｓ）の有効期間は１つのＳＣｐｅｒｉｏｄであり、且つそれに対応するＳＣｐｅｒｉｏｄは該ＳＬｇｒａｎｔ（ｓ）を伝送するサブフレームの４ｍｓ後からの次のＳＣｐｅｒｉｏｄである。ＳＬｇｒａｎｔ（ｓ）を受信した後に、ＵＥは、該ＳＬｇｒａｎｔ（ｓ）に対応するＳＣｐｅｒｉｏｄ内で、まずＳＬｇｒａｎｔ（ｓ）において指示されたＳＣのリソース位置においてＳＣを２回伝送し、そして、ＳＬｇｒａｎｔ（ｓ）において指示されたｄａｔａのリソース位置においてＴＢ（ＴｒａｎｓｐｏｒｔＢｌｏｃｋ）を伝送し、ここで、各ＴＢは４回伝送され、１つのＳＣｐｅｒｉｏｄ内で伝送可能なＴＢの数はＳＬｇｒａｎｔ（ｓ）において割り当てられたリソースの数に依存する。図１は該伝送処理を示す図である。

なお、背景技術に関する上記の説明は、単なる本発明の技術案をより明確、完全に説明するためのものであり、当業者を理解させるために説明するものであり。これら技術案が本発明の背景技術の部分に説明されているから当業者にとって周知の技術であると解釈してはならない。

しかし、ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置。ユーザとも称される）がインフラの通信モード及びＤ２Ｄ（Ｄｅｖｉｃｅ−ｔｏ−Ｄｅｖｉｃｅ：装置から装置）の通信モード両方において作動する場合は、同一のサブフレームにおいて、ＵＥはアップリンクデータ伝送及びＤ２Ｄのデータ送信を同時に行うことができない。よって、あるＴＴＩ（ＴｒａｎｓｍｉｓｓｉｏｎＴｉｍｅＩｎｔｅｒｖａｌ：伝送時間間隔）では、ＵＥがＵＬｇｒａｎｔ（Ｕｐｌｉｎｋｇｒａｎｔ：アップリンクグラント）を用いてＰｒｏＳｅＢＳＲ（サイドリンクバッファ状態報告）を送信する場合、このＴＴＩにおいて、ＵＥは必ずＳｉｄｅｌｉｎｋ（ＳＬ：サイドリンク。即ち、Ｄ２Ｄ通信モードにおける装置間のリンク）上のＭＡＣＰＤＵ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ − ＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ：媒体アクセス制御−プロトコルデータユニット）を送信できない。従来のインフラ通信モードにおけるＢＳＲのｂｕｆｆｅｒｓｉｚｅ（バッファサイズ）の決定方法に従ってＰｒｏＳｅＢＳＲのｂｕｆｆｅｒｓｉｚｅを決定すると、即ちあるＴＴＩにおいてＢＳＲを報告する必要がある場合に該ＢＳＲにおけるｂｕｆｆｅｒｓｉｚｅはこのＴＴＩ内の全てのＭＡＣＰＤＵが全て構築されたバッファ状態を反映すると、ＵＥはＰｒｏＳｅＢＳＲを送信するＴＴＩ内でＳＬＭＡＣＰＤＵを構築できないため、現在のＵＥはｂｕｆｆｅｒｓｉｚｅを決定できなくなる。具体的には、図２に示すように、アップリンク伝送がＴＴＩ_ｎ＋４において発生するため、このＴＴＩ_ｎ＋４においてＳＬＭＡＣＰＤＵ（サイドリンク上の媒体アクセス制御−プロトコルデータユニット）を構築できない。

また、ＰｒｏＳｅＢＳＲを伝送するＴＴＩでは、報告されたＰｒｏＳｅＢＳＲに含まれるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ（サイドリンク先又はサイドリンクターゲット）の数を決定する際に、ＰｒｏＳｅＢＳＲを伝送するＴＴＩをタイミングとしてどのＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎが伝送すべきデータを有するかを判断すると、ＳＬｇｒａｎｔ（ｓ）（サイドリンクグラント）が１つのＴＴＩについてのものではなく、１つのＳＣｐｅｒｉｏｄ（ＳｉｄｅｌｉｎｋＣｏｎｔｒｏｌＰｅｒｉｏｄ：サイドリンク制御期間）についてのものであるため、基地局に伝送すべきデータを本当に有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを報告できない。同様に、ＰｒｏＳｅＢＳＲにおけるｂｕｆｆｅｒｓｉｚｅを決定する際に、ＰｒｏＳｅＢＳＲを伝送するＴＴＩをタイミングとしてｂｕｆｆｅｒｓｉｚｅを決定すると、ｂｕｆｆｅｒｓｔａｔｕｓ（バッファ状態）を正確に反映できない。

上記問題を解決するために、本発明の実施例は、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決するバッファ状態報告の生成方法、装置及び通信システムを提供する。

本発明の実施例の第１態様では、ユーザ装置に適用される、バッファ状態報告の生成装置であって、サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する第１決定手段と、残りの構成されたサイドリンクグラントがあるか否かを判断する判断手段と、前記判断手段の判断結果に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する第２決定手段と、前記第２決定手段により決定された前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、前記バッファ状態報告を生成する生成手段と、を含む、装置を提供する。

本発明の実施例の第２態様では、ユーザ装置に適用される、バッファ状態報告の生成方法であって、サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定するステップと、残りの構成されたサイドリンクグラントがあるか否かを判断するステップと、判断結果に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定するステップと、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、前記バッファ状態報告を生成するステップと、を含む、方法を提供する。

本発明の実施例の第３態様では、上記のバッファ状態報告の生成装置を含む、ユーザ装置を提供する。

本発明の実施例の第４態様では、上記のユーザ装置を含む、通信システムを提供する。

本発明の実施例の他の態様では、バッファ状態報告の生成装置又はユーザ装置においてプログラムを実行する際に、コンピュータに、上記第２態様に記載のバッファ状態報告の生成方法を前記バッファ状態報告の生成装置又はユーザ装置において実行させる、コンピュータ読み取り可能なプログラムを提供する。

本発明の実施例の他の態様では、コンピュータに、上記第２態様に記載のバッファ状態報告の生成方法をバッファ状態報告の生成装置又はユーザ装置において実行させるためのコンピュータ読み取り可能なプログラムを記憶する、記憶媒体を提供する。

本発明の実施例の有益な効果としては、本発明の実施例の方法、装置及びシステムによれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅＢＳＲに含まれている各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

下記の説明及び図面に示すように、本発明の特定の実施形態が詳細に開示され、本発明の原理を採用できる方式が示される。なお、本発明の実施形態の範囲はこれらに限定されない。本発明の実施形態は、添付される特許請求の範囲の要旨及び項目の範囲内において、変更されたもの、修正されたもの及び均等的なものを含む。

１つの実施形態に記載された特徴及び／又は示された特徴は、同一又は類似の方式で１つ又はさらに多くの他の実施形態で用いられてもよいし、他の実施形態における特徴と組み合わせてもよいし、他の実施形態における特徴に代わってもよい。

なお、本文では、用語「包括／含む」は、特徴、部材、ステップ又はコンポーネントが存在することを指し、一つ又は複数の他の特徴、部材、ステップ又はコンポーネントの存在又は付加を排除しない。

ここで含まれる図面は、本発明の実施例を理解させるためのものであり、本明細書の一部を構成し、本発明の実施例を例示するためのものであり、文言の記載と合わせて本発明の原理を説明する。なお、ここに説明される図面は、単なる本発明の実施例を説明するためのものであり、当業者にとって、これらの図面に基づいて他の図面を容易に得ることができる。
サイドリンク上のデータ伝送を示す図である。サイドリンク伝送とアップリンク伝送との衝突を示す図である。本実施例のバッファ状態報告の生成方法のフローチャートである。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。本実施例のバッファ状態報告の生成方法の全体的なフローチャートである。本実施例のバッファ状態報告の生成方法の１つの態様のフローチャートである。本実施例のバッファ状態報告の生成方法のもう１つの態様のフローチャートである。本実施例のバッファ状態報告の生成装置の構成を示す図である。図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。本実施例のユーザ装置の構成を示す図である。本実施例の通信システムのトポロジ構成を示す図である。

本発明の上記及びその他の特徴は、図面及び下記の説明により理解できるものである。明細書及び図面では、本発明の特定の実施形態、即ち本発明の原則に従う一部の実施形態を表すものを公開している。なお、本発明は説明される実施形態に限定されず、本発明は、特許請求の範囲内の全ての修正、変形されたもの、及び均等なものを含む。以下は、図面を参照しながら本発明の各実施例を説明する。これらの実施例は単なる例示的なものであり、本発明を限定するものではない。

＜実施例１＞
本発明の実施例はバッファ状態報告の生成方法を提供し、該方法はユーザ装置に適用される。図３は該方法のフローチャートであり、図３に示すように、該方法は以下のステップを含む。

ステップ３０１：サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する。

ステップ３０２：残りの構成されたサイドリンクグラントがあるか否かを判断する。

ステップ３０３：ステップ３０２の判断結果に基づいて、該サイドリンクのバッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する。

ステップ３０４：該サイドリンクのバッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、該サイドリンクのバッファ状態報告を生成する。

ステップ３０１において、ユーザ装置は、まずＰｒｏＳｅＢＳＲ（サイドリンクのバッファ状態報告）を伝送するＴＴＩ（伝送時間間隔）を決定し、ユーザ装置は決定された該ＴＴＩにおいて該ＰｒｏＳｅＢＳＲを伝送する。ここで、ユーザ装置は、基地局により送信されたＵＬｇｒａｎｔを含むＰＤＣＣＨを受信した後に該ＴＴＩを決定してもよいし、他のポリシーを参照して該ＴＴＩを決定してもよい。本実施例では、ステップ３０１においてＰｒｏＳｅＢＳＲを伝送するＴＴＩを決定した後に、該ユーザ装置は、ステップ３０２〜３０３において、該ＰｒｏＳｅＢＳＲに含める必要のあるサイドリンク先（ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ）及びそのバッファサイズ（ｂｕｆｆｅｒｓｉｚｅ）を決定し、ステップ３０２において該ＰｒｏＳｅＢＳＲを生成することで、ステップ３０１において決定されたＴＴＩにおいて該ＰｒｏＳｅＢＳＲを伝送できる。

ステップ３０２において、ユーザ装置がＰｒｏＳｅＢＳＲを伝送するＴＴＩを決定した後に、該ＴＴＩ又はその前に、残りの構成されたＳＬｇｒａｎｔ（ｓ）があるか否かを判断してもよい。ここで、該ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄについて残りの構成されたＳＬｇｒａｎｔ（ｓ）があるか否かを判断してもよく、即ちＰｒｏＳｅＢＳＲを伝送するＴＴＩを含むＳＣｐｅｒｉｏｄについてのＳＬｇｒｎａｔ（ｓ）があるか否かを判断してもよい。或いは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄの後続のＳＣｐｅｒｉｏｄについて残りの構成されたＳＬｇｒａｎｔ（ｓ）があるか否かを判断してもよく、即ちＰｒｏＳｅＢＳＲを伝送するＴＴＩを含むＳＣｐｅｒｉｏｄの後続のＳＣｐｅｒｉｏｄについてのＳＬｇｒｎａｔ（ｓ）があるか否かを判断してもよい。或いは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ及びその後続のＳＣｐｅｒｉｏｄ両方について残りの構成されたＳＬｇｒａｎｔ（ｓ）があるか否かを判断してもよく、即ちＰｒｏＳｅＢＳＲを伝送するＴＴＩを含むＳＣｐｅｒｉｏｄ及びその後続のＳＣｐｅｒｉｏｄについてのＳＬｇｒｎａｔ（ｓ）があるか否かを判断してもよい。

１つの態様では、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄに構成されたＳＬｇｒａｎｔ（ｓ）があり、且つ該ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて該構成されたＳＬｇｒａｎｔ（ｓ）を使い切っていない場合、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

図４〜図５はこの態様の２つの応用シナリオを示す図である。

図４に示すように、このシナリオでは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄはＳＣｐｅｒｉｏｄ１であり、図４から分かるように、該ＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて該ＳＬｇｒａｎｔ（ｓ）を使い切っておらず、この場合は、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。さらに、図４に示すシナリオでは、ＳＣｐｅｒｉｏｄ１の後続のＳＣｐｅｒｉｏｄ、例えば次のＳＣｐｅｒｉｏｄ（ＳＣｐｅｒｉｏｄ２）及び次の次のＳＣｐｅｒｉｏｄ（ＳＣｐｅｒｉｏｄ３）にはいずれも構成されたＳＬｇｒａｎｔ（ｓ）がなく、即ち、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩ又はその前に、ＳＣｐｅｒｉｏｄ２及びＳＣｐｅｒｉｏｄ３のＳＬｇｒａｎｔ（ｓ）を復号して取得していない。

図５に示すように、このシナリオでは、図４のシナリオと異なって、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に、該ユーザ装置はＳＣｐｅｒｉｏｄ２のＳＬｇｒａｎｔ（ｓ）を既に復号して取得したが、ＳＣｐｅｒｉｏｄ３のＳＬｇｒａｎｔ（ｓ）を復号して取得していない。このシナリオでも、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

もう１つの態様では、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄの次のＳＣｐｅｒｉｏｄに構成されたＳＬｇｒａｎｔがあり、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該次のＳＣｐｅｒｉｏｄのＳＬｇｒａｎｔ（ｓ）を復号して取得した場合、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

図６〜図９は該態様の４つの応用シナリオを示す図である。

図６に示すように、このシナリオでは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄはＳＣｐｅｒｉｏｄ１であり、ＳＣｐｅｒｉｏｄ２に構成されたＳＬｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置がＳＣｐｅｒｉｏｄ２のＳＬｇｒａｎｔ（ｓ）を復号して取得しており、この場合は、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。さらに、図６に示すシナリオでは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）がなく、且つＳＣｐｅｒｉｏｄ３にも構成されたＳＬｇｒａｎｔ（ｓ）がなく、即ち、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置は、ＳＣｐｅｒｉｏｄ３のＳＬｇｒａｎｔ（ｓ）を復号して取得していない。

図７に示すように、このシナリオでは、図６のシナリオと異なって、ＳＣｐｅｒｉｏｄ３にも構成されたＳＬｇｒａｎｔ（ｓ）があり、即ちＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に、該ユーザ装置はＳＣｐｅｒｉｏｄ３のＳＬｇｒａｎｔ（ｓ）を既に復号して取得した。このシナリオでも、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

図８に示すように、このシナリオでは、図６のシナリオと異なって、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

図９に示すように、このシナリオでは、図７のシナリオと異なって、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

もう１つの態様では、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄの次の次のＳＣｐｅｒｉｏｄに構成されたＳＬｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該次の次のＳＣｐｅｒｉｏｄのＳＬｇｒａｎｔ（ｓ）を復号して取得した場合、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

図１０〜図１１はこの態様の２つの応用シナリオを示す図である。

図１０に示すように、このシナリオでは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄはＳＣｐｅｒｉｏｄ１であり、該ＳＣｐｅｒｉｏｄ１の次の次のＳＣｐｅｒｉｏｄ（ＳＣｐｅｒｉｏｄ３）に構成されたＳＬｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置がＳＣｐｅｒｉｏｄ３のＳＬｇｒａｎｔ（ｓ）を復号して取得した場合、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。さらに、図１０に示すシナリオでは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）がなく、該ＳＣｐｅｒｉｏｄ１の次のＳＣｐｅｒｉｏｄ（ＳＣｐｅｒｉｏｄ２）にも構成されたＳＬｇｒａｎｔ（ｓ）がなく、即ち、ユーザ装置がＰｒｏＳｅＢＳＲを伝送するＴＴＩ又はその前にＳＣｐｅｒｉｏｄ２のＳＬｇｒａｎｔ（ｓ）を復号して取得していない。

図１１に示すように、このシナリオでは、図１０のシナリオと異なって、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬｇｒａｎｔ（ｓ）があると判断する。

もう１つの態様では、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄに構成されたＳＬｇｒａｎｔ（ｓ）がなく、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該ＳＣｐｅｒｉｏｄの後続のＳＣｐｅｒｉｏｄについての構成されたＳＬｇｒａｎｔ（ｓ）を復号して取得していない場合、残りの構成されたＳＬｇｒａｎｔ（ｓ）がないと判断する。

図１２は該態様の応用シナリオを示す図である。図１２に示すように、このシナリオでは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄはＳＣｐｅｒｉｏｄ１であり、該ＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）がなく、該ＳＣｐｅｒｉｏｄ１の次のＳＣｐｅｒｉｏｄ（ＳＣｐｅｒｉｏｄ２）及び次の次のＳＣｐｅｒｉｏｄ（ＳＣｐｅｒｉｏｄ３）にいずれも構成されたＳＬｇｒａｎｔ（ｓ）がなく、即ちＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置がＳＣｐｅｒｉｏｄ１の後続のＳＣｐｅｒｉｏｄ２及びＳＣｐｅｒｉｏｄ３についての構成されたＳＬｇｒａｎｔ（ｓ）を復号して取得していない。このシナリオでは、残りの構成されたＳＬｇｒａｎｔ（ｓ）がないと判断する。

もう１つの態様では、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄに構成されたＳＬｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切っており、且つＰｒｏＳｅＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該ＳＣｐｅｒｉｏｄの後続のＳＣｐｅｒｉｏｄについての構成されたＳＬｇｒａｎｔ（ｓ）を復号して取得していない場合、残りの構成されたＳＬｇｒａｎｔ（ｓ）がないと判断する。

図１３は該態様の応用シナリオを示す図である。図１３に示すように、このシナリオでは、図１２のシナリオと異なって、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ１に構成されたＳＬｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬｇｒａｎｔ（ｓ）がないと判断する。

ステップ３０３において、ユーザ装置は、ステップ３０２の判断結果に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定してもよい。

ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬｇｒａｎｔ（ｓ）がない場合、即ち図１２及び図１３に示すシナリオでは、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩ内のバッファ状態に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定してもよい。即ち、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの時点に利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのみを考慮し、この際に、該ＰｒｏＳｅＢＳＲは、該ＰｒｏＳｅＢＳＲを伝送するＴＴＩ時点のバッファ状態を反映する。

具体的には、ＵＥがＴＴＩについてのトリガされたＰｒｏＳｅＢＳＲを伝送可能なＵＬｇｒａｎｔを有する場合、ＵＥは、現在のＴＴＩ時点においてどのＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに対応する論理チャネルが利用可能な伝送すべきデータを有するかを決定する。そして、通常のＰｒｏＳｅＢＳＲ又は周期的なＰｒｏＳｅＢＳＲについて、ＵＥは、ＵＬｇｒａｎｔのサイズ及び前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄＰｒｏＳｅＢＳＲを報告するかを決定する。ＰａｄｄｉｎｇＰｒｏＳｅＢＳＲについて、ＵＥは、利用可能なＰａｄｄｉｎｇｂｉｔ（付加ビット）の数及び前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄＰｒｏＳｅＢＳＲを報告するかを決定する。

ここで、ＰｒｏＳｅＢＳＲ又はＴｒｕｎｃａｔｅｄＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎについて、ＵＥは、ＰｒｏＳｅＢＳＲを伝送するＴＴＩ時点に対応するバッファにおけるデータ量を決定し、該データ量及び参照文献［TS36.321, Medium Access Control (MAC) protocol specification, v
12.2.0］におけるバッファ状態報告テーブルに基づいて各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに対応するｂｕｆｆｅｒｓｉｚｅを決定する。

これによって、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬｇｒａｎｔ（ｓ）がある場合、即ち図４〜図１１に示すシナリオでは、ユーザ装置は、残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅＢＳＲに含める必要のある、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定する。

例えば、ユーザ装置は、まず、残りの構成されたＳＬｇｒａｎｔ（ｓ）を使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定し、そして、ＰｒｏＳｅＢＳＲを伝送するＴＴＩのＵＬｇｒａｎｔ（アップリンクグラント）について該ＰｒｏＳｅＢＳＲよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素（ＭＡＣＣＥ：ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｒｏｌＥｌｅｍｅｎｔ）を考慮した後の残りのビット数、又はＰｒｏＳｅＢＳＲを伝送するＴＴＩにおける利用可能な付加ビットの数に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のある、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定する。ここで、ＭＡＣＣＥは例えばＢＳＲＭＡＣＣＥである。

ここで、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの決定方法は以下の通りである。

態様１では、ユーザ装置がＳＬｇｒａｎｔ（ｓ）を復号して取得した後、又は該ＳＬｇｒａｎｔ（ｓ）に対応するＳＣｐｅｒｉｏｄの開始時刻において、ユーザ装置は、該ＳＬｇｒａｎｔ（ｓ）において割り当てられたデータを伝送するリソースに基づいて、該ＳＬｇｒａｎｔ（ｓ）に対応するＳＣｐｅｒｉｏｄ全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該ＳＬｇｒａｎｔ（ｓ）に対応するＳＣｐｅｒｉｏｄ内に伝送可能なＭＡＣＰＤＵの全てを生成してもよい。これによって、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、どのＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに対応する論理チャネルが利用可能な伝送すべきデータを有するかを直接決定でき、即ちバッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定できる。

態様２では、ユーザ装置がＳＬｇｒａｎｔ（ｓ）を復号して取得した後に、ユーザ装置は、該ＳＬｇｒａｎｔ（ｓ）において割り当てられたデータを伝送する各ＴＴＩにおいて、該ＴＴＩ内で伝送可能な対応するＳＬＭＡＣＰＤＵを構築する。これによって、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、仮に全てのＳＬｇｒａｎｔ（ｓ）において割り当てられた残りのデータ伝送用のリソースを全て使い切った後で構築可能な全てのＳＬＭＡＣＰＤＵの数及びサイズを計算し、これらのＳＬＭＡＣＰＤＵを除いた後に、どのＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに対応する論理チャネルが利用可能な伝送すべきデータを有するかを決定する。

ここで、該ＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの決定方法は以下の通りである。

具体的には、通常のＰｒｏＳｅＢＳＲ又は周期的なＰｒｏＳｅＢＳＲについて、ＵＥは、ＵＬｇｒａｎｔにおいて該ＰｒｏＳｅよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素（ＭＡＣＣＥ：ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌＣｏｎｔｒｏｌＥｌｅｍｅｎｔ）を考慮した後の残りのビット数、又は前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄＰｒｏＳｅＢＳＲを報告するかを決定する。ＰａｄｄｉｎｇＰｒｏＳｅＢＳＲについて、ＵＥは、利用可能なＰａｄｄｉｎｇｂｉｔの数及び前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄＰｒｏＳｅＢＳＲを報告するかを決定する。

ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬｇｒａｎｔ（ｓ）がある場合、即ち図４〜図１１に示すシナリオでは、ユーザ装置は、残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切ってＳＬＭＡＣＰＤＵを全て構築した後のバッファ状態に基づいて、各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅを決定してもよい。即ち、ユーザ装置は、残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切ってＳＬＭＡＣＰＤＵを全て構築した後のバッファ状態を、各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして決定する。

具体的には、ＰｒｏＳｅＢＳＲ又はＴｒｕｎｃａｔｅｄＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎについて、ＵＥは、残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切ってＳＬＭＡＣＰＤＵを全て構築した後のそれに対応するバッファにおけるデータ量を、該ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして決定する。

態様３では、態様１と同様に、ユーザ装置は、まずＳＬＭＡＣＰＤＵを構築し、そしてＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、バッファにおけるデータ量のサイズを該ｂｕｆｆｅｒｓｉｚｅとして計算する。

態様４では、態様２と同様に、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、仮に残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切って構築可能なＳＬＭＡＣＰＤＵの全てを除いたバッファにおけるデータ量のサイズを該ｂｕｆｆｅｒｓｉｚｅとして計算する。

ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬｇｒａｎｔ（ｓ）がある場合、即ち図４〜図１１に示すシナリオでは、ユーザ装置は、残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定してもよい。具体的には上述した通り、ここでその説明を省略する。そして、残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切ってＳＬＭＡＣＰＤＵの全てを構築した後のバッファ状態に基づいて、各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅを決定してもよい。ここで、該ｂｕｆｆｅｒｓｉｚｅは、前に決定されたＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに対応する。即ち、該態様では、ユーザ装置は、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの、残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切ってＳＬＭＡＣＰＤＵの全てを構築した後のバッファ状態を、ｂｕｆｆｅｒｓｉｚｅとして決定してもよい。

態様５では、態様１と同様に、ユーザ装置は、まずＳＬＭＡＣＰＤＵを構築し、そして、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、バッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定し、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして計算する。

態様６では、態様２と同様に、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、仮に残りの構成されたサイドリンクグラントを全て使い切って構築可能な全てのＳＬＭＡＣＰＤＵを除いた利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定し、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの、該残りの構成されたサイドリンクグラントを使い切って構築可能な全てのＳＬＭＡＣＰＤＵを除いたバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして計算する。

図１４は本実施例の方法の全体的なフローチャートであり、図１４に示すように、該方法は以下のステップを含む。

ステップ１４０１：ＰｒｏＳｅＢＳＲを伝送するＴＴＩを決定する。

ここで、ステップ１４０１はステップ３０１に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。

ステップ１４０２：残りの構成されたＳＬｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合、ステップ１４０３を実行し、そうでない場合、ステップ１４０５を実行する。

ここで、ステップ１４０２はステップ３０２に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。

ステップ１４０３：残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定する。

ここで、まず、残りの構成されたＳＬｇｒａｎｔ（ｓ）を使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定し、そして、ＰｒｏＳｅＢＳＲを伝送するＴＴＩのアップリンクグラントについてのビット数又はＰｒｏＳｅＢＳＲを伝送するＴＴＩにおける利用可能な付加ビットの数に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のある、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの数を決定してもよい。

ここで、ステップ１４０３は、ステップ３０３におけるステップ３０２の判断結果が残りの構成されたＳＬｇｒａｎｔ（ｓ）があることである場合にＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎの決定処理に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。

ステップ１４０４：残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切ってＳＬＭＡＣＰＤＵを全て構築した後のバッファ状態に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅを決定する。

ここで、ステップ１４０４は、ステップ３０３におけるステップ３０２の判断結果が残りの構成されたＳＬｇｒａｎｔ（ｓ）があることである場合にＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅの決定処理に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。

ここで、本実施例ではステップ１４０３及びステップ１４０４の実行順序を限定せず、例えば、ステップ１４０３を実行した後にステップ１４０４を実行してもよいし、ステップ１４０４を実行した後にステップ１４０３を実行してもよいし、ステップ１４０３及びステップ１４０４を同時に実行してもよい。ここで、ステップ１４０３を実行した後にステップ１４０４を実行する場合は、ステップ１４０４は、ＰｒｏＳｅＢＳＲに含めることができる利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅについてのものである。

ステップ１４０５：ＰｒｏＳｅＢＳＲを伝送するＴＴＩ内のバッファ状態に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及び各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファサイズを決定する。

ここで、ステップ１４０５は、ステップ３０３におけるステップ３０２の判断結果が残りの構成されたＳＬｇｒａｎｔ（ｓ）がないことである場合のユーザ装置の処理プロセスに対応し、具体的には上述した通りであり、ここでその説明を省略する。

ステップ１４０６：該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅに基づいて、該ＰｒｏＳｅＢＳＲを生成する。

これによって、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩにおいて、サイドリンクのバッファ状態を反映したＰｒｏＳｅＢＳＲを伝送でき、本願が解決しようとする課題を解決した。

本発明の実施例の方法によれば、ＰｒｏＳｅＢＳＲを送信する際に、ＵＥはＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅＢＳＲに含まれている各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

図１５は本実施例のバッファ状態報告の生成方法の１つの態様のフローチャートであり、図１５に示すように、該方法は以下のステップを含む。

ステップ１５０１：ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩを決定する。

ステップ１５０２：ユーザ装置は、該ＴＴＩ内のバッファ状態に基づいて、ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定する。

ステップ１５０３：ユーザ装置は、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅに基づいて、該ＰｒｏＳｅＢＳＲを生成する。

ここで、ステップ１５０２の態様はステップ１４０５の態様に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。

この態様では、ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの時点に利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのみを考慮し、この際に、該ＰｒｏＳｅＢＳＲは、該ＰｒｏＳｅＢＳＲを伝送するＴＴＩ時点のバッファ状態を反映する。これによって、ユーザ装置は、ＰｒｏＳｅＢＳＲを報告する際に、ＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正しく反映でき、本願が解決しようとする課題を解決した。

また、この態様は上記の図４〜図１３の１０個のシナリオにも同様に適用できる。即ち、上記図４〜図１３の何れかのシナリオでも、図１５の方法を用いてＰｒｏＳｅＢＳＲを生成してもよい。

図１６は本実施例のバッファ状態報告の生成方法のもう１つの態様のフローチャートであり、図１６に示すように、該方法は以下のステップを含む。

ステップ１６０１：ユーザ装置は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩを決定する。

ステップ１６０２：該ＴＴＩの所在するＳＣｐｅｒｉｏｄについてのＳＬｇｒａｎｔ（ｓ）があるか否かを判断し、ない場合（図１２、図１０、図６、図７のシナリオに対応する）、ステップ１６０３を実行し、そうでない場合（図１３、図１１、図８、図９、図４、図５のシナリオに対応する）、ステップ１６０８を実行する。

ステップ１６０３：該ＴＴＩの所在するＳＣｐｅｒｉｏｄの次のＳＣｐｅｒｉｏｄについてのＳＬｇｒａｎｔ（ｓ）があるか否かを判断し、ない場合（図１２及び図１０のシナリオに対応する）、ステップ１６０４を実行し、そうでない場合（図６及び図７のシナリオに対応する）、ステップ１６０５を実行する。

ステップ１６０４：該ＴＴＩの所在するＳＣｐｅｒｉｏｄの次の次のＳＣｐｅｒｉｏｄについてのＳＬｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合（図１０のシナリオに対応する）、ステップ１６０５を実行し、そうでない場合（図１２のシナリオに対応する）、ステップ１６０７を実行する。

ステップ１６０５：残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定する。

ステップ１６０６：残りの構成されたＳＬｇｒａｎｔ（ｓ）を全て使い切ってＳＬＭＡＣＰＤＵを全て構築した後のバッファ状態に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファサイズを決定する。

ステップ１６０７：該ＴＴＩ内のバッファ状態に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定する。

ステップ１６０８：該ＴＴＩの所在するＳＣｐｅｒｉｏｄのＳＬｇｒａｎｔ（ｓ）を使い切ったか否かを判断し、使い切った場合（図１３、図１１、図８、図９のシナリオに対応する）、ステップ１６０９を実行し、そうでない場合（図４、図５のシナリオに対応する）、ステップ１６０５を実行する。

ステップ１６０９：該ＴＴＩの所在するＳＣｐｅｒｉｏｄの次のＳＣｐｅｒｉｏｄについてのＳＬｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合（図８、図９のシナリオに対応する）、ステップ１６０５を実行し、そうでない場合（図１３、図１１のシナリオに対応する）、ステップ１６１０を実行する。

ステップ１６１０：該ＴＴＩの所在するＳＣｐｅｒｉｏｄの次の次のＳＣｐｅｒｉｏｄについてのＳＬｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合（図１１のシナリオに対応する）、ステップ１６０５を実行し、そうでない場合（図１３のシナリオに対応する）、ステップ１６０７を実行する。

ステップ１６１１：ユーザ装置は、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅに基づいて、該ＰｒｏＳｅＢＳＲを生成する。

ここで、ステップ１６０５〜１６０６及び１６０７の態様は上記ステップ１４０３〜１４０４及び１４０５の態様と同様であり、具体的には上述した通り、ここでその説明を省略する。

この態様では、ユーザ装置は、残りの構成されたＳＬｇｒａｎｔ（ｓ）があるか否かのみを考慮し、残りの構成されたＳＬｇｒａｎｔ（ｓ）があれば、該残りの構成されたＳＬｇｒａｎｔ（ｓ）が、ＰｒｏＳｅＢＳＲを伝送するＴＴＩに対応するＳＣｐｅｒｉｏｄ内に位置し、該ＳＣｐｅｒｉｏｄの次のＳＣｐｅｒｉｏｄ内に位置し、或いは該ＳＣｐｅｒｉｏｄの次の次のＳＣｐｅｒｉｏｄ内に位置するにも関わらず、ステップ１６０５〜１６０６の方法を用いて該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定してもよい。そうでない場合、ステップ１６０７の方法を用いて該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定してもよい。これによって、ユーザ装置は、ＰｒｏＳｅＢＳＲを報告する際に、ＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正しく反映でき、本願が解決しようとする課題を解決した。

本実施例では、上記残りの構成されたＳＬｇｒａｎｔ（ｓ）（ＲｅｍａｉｎｉｎｇｃｏｎｆｉｇｕｒｅｄＳＬｇｒａｎｔ（ｓ））は、利用可能なＳＬｇｒａｎｔ（ｓ）（ａｖａｉｌａｂｌｅＳＬｇｒａｎｔ（ｓ））と定義されてもよいし、有効なＳＬｇｒａｎｔ（ｓ）（ＶａｌｉｄＳＬｇｒａｎｔ（ｓ））等と定義されてもよいが、本実施例はこれらに限定されない。また、上記残りの構成されたＳＬｇｒａｎｔ（ｓ）は、ＰｒｏＳｅＢＳＲを伝送するＴＴＩの所在するＳＣｐｅｒｉｏｄ及び／又はその後続のＳＣｐｅｒｉｏｄのＳＬｇｒａｎｔ（ｓ）に限定されてもよい。

本実施例の方法によれば、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

＜実施例２＞
本発明の実施例はバッファ状態報告の生成装置を提供し、該装置はユーザ装置に適用されてもよい。該装置の課題解決の原理は実施例１と同様であるため、その具体的な実施は実施例１の方法の実施を参照してもよく、同様な内容について説明を省略する。

図１７は該装置の構成を示す図である。図１７に示すように、該バッファ状態報告の生成装置１７００は、第１決定部１７０１、判断部１７０２、第２決定部１７０３及び生成部１７０４を含む。

本実施例では、第１決定部１７０１は、サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する。

本実施例では、判断部１７０２は、残りの構成されたサイドリンクグラントがあるか否かを判断する。

本実施例では、第２決定部１７０３は、判断部１７０２の判断結果に基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定する。

本実施例では、生成部１７０４は、第２決定部１７０３により決定された該バッファ状態報告に含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅに基づいて、該バッファ状態報告を生成する。

１つの態様では、判断部１７０２は、該伝送時間間隔を含むサイドリンク制御期間及び／又はその後続のサイドリンク制御期間についての残りの構成されたサイドリンクグラントがあるか否かを判断する。

１つの態様では、判断部１７０２は、該伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔において該構成されたサイドリンクグラントを使い切っていない場合、及び／又は該伝送時間間隔の所在するサイドリンク制御期間の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔の前に前記ユーザ装置が該次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、及び／又は該伝送時間間隔の所在するサイドリンク制御期間の次の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔の前に前記ユーザ装置が該次の次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、残りの構成されたサイドリンクグラントがあると判断する。

１つの態様では、判断部１７０２は、該伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがなく、且つ該伝送時間間隔の前に該ユーザ装置が該サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、及び／又は該伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔の前に該構成されたサイドリンクグラントを全て使い切っており、且つ該伝送時間間隔の前に該ユーザ装置が該サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、残りの構成されたサイドリンクグラントがないと判断する。

１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがあると判断部１７０２により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定する。

ここで、第２決定部１７０３は、まず、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定し、そして、該伝送時間間隔のアップリンクグラントについて該ＰｒｏＳｅＢＳＲよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素を考慮した後の残りのビット数、又は該伝送時間間隔における利用可能な付加ビットの数に基づいて、該ＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定する。

ここで、好ましくは、図１８に示すように、第２決定部１７０３は、第１データユニット生成モジュール１８０１及び第１決定モジュール１８０２を含んでもよい。第１データユニット生成モジュール１８０１は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なＳＬＭＡＣＰＤＵの全てを生成する。第１決定モジュール１８０２は、該伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎとして決定する。

ここで、好ましくは、図１９に示すように、第２決定部１７０３は第３決定モジュール１９０１を含んでもよい。第３決定モジュール１９０１は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬＭＡＣＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎとして決定する。

１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがあると判断部１７０２により判断された場合、残りの構成されたサイドリンクグラントを全て使い切ってＳＬＭＡＣＰＤＵを全て構築した後のバッファ状態を、該ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして決定する。

ここで、好ましくは、図２０に示すように、第２決定部１７０３は、第２データユニット生成モジュール２００１及び第１決定モジュール２００２を含む。第２データユニット生成モジュール２００１は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なＳＬＭＡＣＰＤＵの全てを生成する。第１計算モジュール２００２は、該伝送時間間隔において、バッファにおけるデータ量のサイズを、ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして計算する。

ここで、好ましくは、図２１に示すように、第２決定部１７０３は第３計算モジュール２１０１を含む。第３計算モジュール２１０１は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬＭＡＣＰＤＵの全てを除いた、バッファにおけるデータ量のサイズを、ＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして計算する。

上記の態様では、図１８の第２決定部と図２０の第２決定部を併合してもよく、即ち第２決定部は、第１データユニット生成モジュール１８０１、第１決定モジュール１８０２、第２データユニット生成モジュール２００１及び第１計算モジュール２００２を同時に有してもよい。第１データユニット生成モジュール１８０１、第１決定モジュール１８０２によりＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定し、第２データユニット生成モジュール２００１及び第１計算モジュール２００２によりＰｒｏＳｅＢＳＲに含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅを決定してもよい。ここで、第１データユニット生成モジュール１８０１と第２データユニット生成モジュール２００１の機能は同様であり、１つのモジュールに併合してもよい。同様に、図１９の第２決定部と図２１の第２決定部を併合してもよい。

１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがあると判断部１７０２により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを決定し、残りの構成されたサイドリンクグラントを全て使い切ってＳＬＭＡＣＰＤＵの全てを構築した後の、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファ状態に基づいて、該利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅを決定する。

ここで、好ましくは、図２２に示すように、第２決定部１７０３は、第３データユニット生成モジュール２２０１、第２決定モジュール２２０２及び第２計算モジュール２２０３を含む。第３データユニット生成モジュール２２０１は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なＳＬＭＡＣＰＤＵの全てを生成する。第２決定モジュール２２０２は、該伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎとして決定する。第２計算モジュール２２０３は、該伝送時間間隔において、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして計算する。

ここで、好ましくは、図２３に示すように、第２決定部１７０３は、第４決定モジュール２３０１及び第４計算モジュール２３０２を含む。第４決定モジュール２３０１は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬＭＡＣＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎとして決定する。第４計算モジュール２３０２は、該伝送時間間隔において、該残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬＭＡＣＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒｓｉｚｅとして計算する。

１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがないと判断部１７０２により判断された場合、該バッファ状態報告を伝送する伝送時間間隔内のバッファ状態に基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒｓｉｚｅを決定する。

本実施例の装置によれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅＢＳＲに含まれている各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

＜実施例３＞
本発明の実施例は、実施例２のバッファ状態報告の生成装置を含むユーザ装置をさらに提供する。

図２４は本発明の実施例のユーザ装置の構成を示す図である。図２４に示すように、ユーザ装置２４００は、中央処理装置２４０１及び記憶装置２４０２を含んでもよく、記憶装置２４０２は中央処理装置２４０１に接続される。なお、該図は単なる例示的なものであり、電気通信機能又は他の機能を実現するように、他の種類の構成を用いて、該構成を補充又は代替してもよい。

１つの態様では、バッファ状態報告の生成装置の機能は中央処理装置２４０１に統合され、中央処理装置２４０１は、実施例２に記載されたバッファ状態報告の生成装置の機能を実現するように構成されてもよい。バッファ状態報告の生成装置の機能はここで援用し、ここでその説明を省略する。

もう１つの態様では、バッファ状態報告の生成装置は中央処理装置２４０１とそれぞれ構成されてもよく、例えばバッファ状態報告の生成装置は中央処理装置２４０１に接続されたチップであり、中央処理装置２４０１の制御によりバッファ状態報告の生成装置の機能を実現してもよい。

図２４に示すように、ユーザ装置２４００は、通信モジュール２４０３、入力部２４０４、音声処理装置２４０５、ディスプレイ２４０６、及び電源２４０７をさらに含んでもよい。なお、ユーザ装置２４００は図２４に示す全てのユニットを含む必要がない。また、ユーザ装置２４００は、図２４に示されていないユニットをさらに含んでもよく、従来技術を参照してもよい。

図２４に示すように、中央処理装置２４０１は、コントローラ又は操作制御部とも称され、マイクロプロセッサ又は他の処理装置及び／又は論理装置を含んでもよく、中央処理装置２４０１は入力を受信し、ユーザ装置２４００の各部の操作を制御する。

ここで、記憶装置２４０２は、例えばバッファ、フラッシュメモリ、ハードディスク、移動可能な媒体、発揮性メモリ、不発揮性メモリ、又は他の適切な装置の１つ又は複数であってもよい。上記障害に関する情報を記憶してもよいし、関連情報を実行するためのプログラムをさらに記憶してもよい。また、中央処理装置２４０１は、記憶装置２４０２に記憶されたプログラムを実行し、情報の記憶又は処理などを実現してもよい。他の部材は従来技術に類似するため、ここでその説明が省略される。端末装置２４００の各部は、本発明の範囲から逸脱することなく、特定のハードウェア、ファームウェア、ソフトウェア又はその組み合わせによって実現されてもよい。

本実施例のユーザ装置によれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅＢＳＲに含まれている各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

＜実施例４＞
本発明の実施例は通信システムをさらに提供し、図２５は該通信システムのトポロジ構成を示す図である。図２５に示すように、通信システム２５００はユーザ装置２５０１及び基地局２５０２を含む。

ここで、基地局２５０２は、適切なタイミングでユーザ装置２５０１にＳＬｇｒａｎｔ（ｓ）を含むＰＤＣＣＨ及びＵＬｇｒａｎｔを含むＰＤＣＣＨを送信する。

ここで、ユーザ装置２５０１は、基地局２５０１と従来のインフラに基づく通信を行うと共に、他のユーザ装置２５０１とＤ２Ｄに基づく通信を行うことができる。

本実施例では、ユーザ装置２５０１は実施例１に記載されたバッファ状態報告の生成方法を適用してもよく、即ち実施例２に記載されたバッファ状態報告の生成装置の機能を実現するように構成されてもよい。実施例１及び実施例２の内容はここで援用し、ここでその説明を省略する。

本実施例のシステムによれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅＢＳＲに含まれている各ＰｒｏＳｅＤｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅＢＳＲを報告する際にＰｒｏＳｅＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

本発明の実施例は、バッファ状態報告の生成装置又はユーザ装置においてプログラムを実行する際に、コンピュータに、上記実施例１に記載のバッファ状態報告の生成方法を該バッファ状態報告の生成装置又はユーザ装置において実行させる、コンピュータ読み取り可能なプログラムをさらに提供する。

本発明の実施例は、コンピュータに、上記実施例１に記載のバッファ状態報告の生成方法をバッファ状態報告の生成装置又はユーザ装置において実行させるためのコンピュータ読み取り可能なプログラムを記憶する、記憶媒体をさらに提供する。

本発明の以上の装置及び方法は、ハードウェアにより実現されてもよく、ハードウェアとソフトウェアを結合して実現されてもよい。本発明はコンピュータが読み取り可能なプログラムに関し、該プログラムは論理部により実行される時に、該ロジック部に上述した装置又は構成要件を実現させる、或いは該ロジック部に上述した各種の方法又はステップを実現させることができる。本発明は上記のプログラムを記憶するための記憶媒体、例えばハードディスク、磁気ディスク、光ディスク、ＤＶＤ、フラッシュメモリ等に関する。

以上、具体的な実施形態を参照しながら本発明を説明しているが、上記の説明は、例示的なものに過ぎず、本発明の保護の範囲を限定するものではない。本発明の趣旨及び原理を離脱しない限り、本発明に対して各種の変形及び修正を行ってもよく、これらの変形及び修正も本発明の範囲に属する。

Claims

ユーザ装置に適用される、バッファ状態報告の生成装置であって、
サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する第１決定手段と、
残りの構成されたサイドリンクグラントがあるか否かを判断する判断手段と、
前記判断手段の判断結果に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する第２決定手段と、
前記第２決定手段により決定された前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、前記バッファ状態報告を生成する生成手段と、を含む、装置。
前記判断手段は、前記伝送時間間隔を含むサイドリンク制御期間及び／又はその後続のサイドリンク制御期間についての残りの構成されたサイドリンクグラントがあるか否かを判断する、請求項１に記載の装置。
前記判断手段は、
前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔において前記構成されたサイドリンクグラントを使い切っていない場合、及び／又は
前記伝送時間間隔の所在するサイドリンク制御期間の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記ユーザ装置が前記次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、及び／又は
前記伝送時間間隔の所在するサイドリンク制御期間の次の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記ユーザ装置が前記次の次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、
残りの構成されたサイドリンクグラントがあると判断する、請求項１に記載の装置。
前記判断手段は、
前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがなく、且つ前記伝送時間間隔の前に前記ユーザ装置が前記サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、及び／又は
前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記構成されたサイドリンクグラントを全て使い切っており、且つ前記伝送時間間隔の前に前記ユーザ装置が前記サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、
残りの構成されたサイドリンクグラントがないと判断する、請求項１に記載の装置。
前記第２決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先を決定する、請求項１に記載の装置。
前記第２決定手段は、まず、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先を決定し、そして、前記伝送時間間隔のアップリンクグラントについて前記サイドリンクのバッファ状態報告よりも高い優先順位を有するデータ若しくはＭＡＣ（媒体アクセス制御）要素を考慮した後の残りのビット数、又は前記伝送時間間隔における利用可能な付加ビットの数に基づいて、前記サイドリンクの前記バッファ状態報告に含める必要のあるサイドリンク先を決定する、請求項５に記載の装置。
前記第２決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切ってサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）を全て構築した後のバッファ状態に基づいて、前記サイドリンクのバッファ状態報告に含める必要のあるサイドリンク先のバッファサイズを決定する、請求項１に記載の装置。
前記第２決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先を決定し、残りの構成されたサイドリンクグラントを全て使い切ってサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）の全てを構築した後の、利用可能な伝送すべきデータを有するサイドリンク先のバッファ状態に基づいて、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズを決定する、請求項１に記載の装置。
前記第２決定手段は、残りの構成されたサイドリンクグラントがないと前記判断手段により判断された場合、前記バッファ状態報告を伝送する伝送時間間隔内のバッファ状態に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する、請求項１に記載の装置。
前記第２決定手段は、
前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）の全てを生成する第１データユニット生成モジュールと、
前記伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第１決定モジュールと、をさらに含む、請求項５に記載の装置。
前記第２決定手段は、
前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）の全てを生成する第２データユニット生成モジュールと、
前記伝送時間間隔において、バッファにおけるデータ量のサイズを、前記バッファ状態報告に含める必要のあるサイドリンク先のバッファサイズとして計算する第１計算モジュールと、をさらに含む、請求項７に記載の装置。
前記第２決定手段は、
前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）の全てを生成する第３データユニット生成モジュールと、
前記伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第２決定モジュールと、
前記伝送時間間隔において、利用可能な伝送すべきデータを有するサイドリンク先のバッファにおけるデータ量のサイズを、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズとして計算する第２計算モジュールと、をさらに含む、請求項８に記載の装置。
前記第２決定手段は、
前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）の全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第３決定モジュール、をさらに含む、請求項５に記載の装置。
前記第２決定手段は、
前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）の全てを除いた、バッファにおけるデータ量のサイズを、前記バッファ状態報告に含める必要のあるサイドリンク先のバッファサイズとして計算する第３計算モジュール、をさらに含む、請求項７に記載の装置。
前記第２決定手段は、
前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣ（媒体アクセス制御）ＰＤＵ（プロトコルデータユニット）の全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第４決定モジュールと、
前記伝送時間間隔において、前記残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先のバッファにおけるデータ量のサイズを、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズとして計算する第４計算モジュールと、をさらに含む、請求項８に記載の装置。
請求項１に記載のバッファ状態報告の生成装置を含む、ユーザ装置。
請求項１６に記載のユーザ装置を含む、通信システム。