(57)【特許請求の範囲】
【請求項１】
ユーザ装置に適用される、バッファ状態報告の生成装置であって、
サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する第１決定手段と、
残りの構成されたサイドリンクグラントがあるか否かを判断する判断手段と、
前記判断手段の判断結果に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する第２決定手段と、
前記第２決定手段により決定された前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、前記バッファ状態報告を生成する生成手段と、を含む、装置。
【請求項２】
前記判断手段は、前記伝送時間間隔を含むサイドリンク制御期間及び／又はその後続のサイドリンク制御期間についての残りの構成されたサイドリンクグラントがあるか否かを判断する、請求項１に記載の装置。
【請求項３】
前記判断手段は、
前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔において前記構成されたサイドリンクグラントを使い切っていない場合、及び／又は
前記伝送時間間隔の所在するサイドリンク制御期間の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記ユーザ装置が前記次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、及び／又は
前記伝送時間間隔の所在するサイドリンク制御期間の次の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記ユーザ装置が前記次の次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、
残りの構成されたサイドリンクグラントがあると判断する、請求項１に記載の装置。
【請求項４】
前記判断手段は、
前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがなく、且つ前記伝送時間間隔の前に前記ユーザ装置が前記サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、及び／又は
前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記構成されたサイドリンクグラントを全て使い切っており、且つ前記伝送時間間隔の前に前記ユーザ装置が前記サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、
残りの構成されたサイドリンクグラントがないと判断する、請求項１に記載の装置。
【請求項５】
前記第２決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先を決定する、請求項１に記載の装置。
【請求項６】
前記第２決定手段は、まず、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先を決定し、そして、前記伝送時間間隔のアップリンクグラントについて前記サイドリンクのバッファ状態報告よりも高い優先順位を有するデータ若しくはＭＡＣ（媒体アクセス制御）要素を考慮した後の残りのビット数、又は前記伝送時間間隔における利用可能な付加ビットの数に基づいて、前記サイドリンクの前記バッファ状態報告に含める必要のあるサイドリンク先を決定する、請求項５に記載の装置。
【請求項７】
前記第２決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切ってサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）を全て構築した後のバッファ状態に基づいて、前記サイドリンクのバッファ状態報告に含める必要のあるサイドリンク先のバッファサイズを決定する、請求項１に記載の装置。
【請求項８】
前記第２決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先を決定し、残りの構成されたサイドリンクグラントを全て使い切ってサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）の全てを構築した後の、利用可能な伝送すべきデータを有するサイドリンク先のバッファ状態に基づいて、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズを決定する、請求項１に記載の装置。
【請求項９】
前記第２決定手段は、残りの構成されたサイドリンクグラントがないと前記判断手段により判断された場合、前記バッファ状態報告を伝送する伝送時間間隔内のバッファ状態に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する、請求項１に記載の装置。
【請求項１０】
前記第２決定手段は、
前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）の全てを生成する第１データユニット生成モジュールと、
前記伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第１決定モジュールと、をさらに含む、請求項５に記載の装置。
【請求項１１】
前記第２決定手段は、
前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）の全てを生成する第２データユニット生成モジュールと、
前記伝送時間間隔において、バッファにおけるデータ量のサイズを、前記バッファ状態報告に含める必要のあるサイドリンク先のバッファサイズとして計算する第１計算モジュールと、をさらに含む、請求項７に記載の装置。
【請求項１２】
前記第２決定手段は、
前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）の全てを生成する第３データユニット生成モジュールと、
前記伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第２決定モジュールと、
前記伝送時間間隔において、利用可能な伝送すべきデータを有するサイドリンク先のバッファにおけるデータ量のサイズを、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズとして計算する第２計算モジュールと、をさらに含む、請求項８に記載の装置。
【請求項１３】
前記第２決定手段は、
前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）の全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第３決定モジュール、をさらに含む、請求項５に記載の装置。
【請求項１４】
前記第２決定手段は、
前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）の全てを除いた、バッファにおけるデータ量のサイズを、前記バッファ状態報告に含める必要のあるサイドリンク先のバッファサイズとして計算する第３計算モジュール、をさらに含む、請求項７に記載の装置。
【請求項１５】
前記第２決定手段は、
前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣ（媒体アクセス制御）  ＰＤＵ（プロトコルデータユニット）の全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第４決定モジュールと、
前記伝送時間間隔において、前記残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のＭＡＣ  ＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先のバッファにおけるデータ量のサイズを、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズとして計算する第４計算モジュールと、をさらに含む、請求項８に記載の装置。
【請求項１６】
請求項１に記載のバッファ状態報告の生成装置を含む、ユーザ装置。
【請求項１７】
請求項１６に記載のユーザ装置を含む、通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信技術の分野に関し、特にバッファ状態報告の生成方法、装置及び通信システムに関する。
【背景技術】
【０００２】
現在のＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ：ロング・ターム・エボリューション）システムにおいて端末装置と端末装置との間の通信は無線アクセスネットワーク及びコアネットワークを介して行われる必要がある。新たなトラヒック要求の出現に伴い、ネットワークのロードを低減し、ネットワークのロードの移転を実現するために、端末装置と端末装置との間の通信は徐々に新たな研究の方向となっている。２つの端末装置の間の距離が十分に近い場合に、端末装置は相手の存在を互いに発見できるため、基地局の制御により装置と装置との間の直接通信を行うことができる。
【０００３】
装置と装置の通信を実現するために、ＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ：ロング・ターム・エボリューション・アドバンスト）システムでは２つのエアインタフェースのリソース割り当て方式、即ちモード１（Ｍｏｄｅ  １）及びモード２（Ｍｏｄｅ  ２）が定義されている。モード１では、従来のインフラ通信モードのトラヒックのバッファ状態報告（Ｂｕｆｆｅｒ  Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ：ＢＳＲ）の報告への影響を回避するために、装置間の通信のための特別なバッファ状態報告（ＰｒｏＳｅ−ＢＳＲと称されてもよい）メカニズムが導入され、該メカニズムは主に新たなバッファ状態報告のトリガ・メカニズム、並びにバッファ状態報告のＭＡＣシグナリング・フォーマット及び内容を含む。
【０００４】
Ｄ２Ｄ（Ｄｅｖｉｃｅ  ｔｏ  Ｄｅｖｉｃｅ：装置から装置）通信モードではサイドリンク制御期間（Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｐｅｒｉｏｄ。ＳＣ  ｐｅｒｉｏｄと略称される）の概念が定義され、該ＳＣ  ｐｅｒｉｏｄはスケジューリング制御（Ｓｃｈｅｄｕｌｉｎｇ  Ｃｏｎｔｒｏｌ）及びそれに対応するデータの伝送を含む時間周期を意味する。Ｍｏｄｅ  １について、Ｄ２Ｄ通信における送信側のデータ伝送の基本的な作動原理は以下の通りである。
【０００５】
基地局があるＤ２Ｄ  ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）のデータ伝送をスケジューリングすると決定した後に、基地局は、ＳＬ−ＲＮＴＩ（Ｓｉｄｅｌｉｎｋ−Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒｙ  Ｉｄｅｎｔｉｔｙ：サイドリンク無線ネットワーク一時識別子）によりスクランブルされたＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ：物理ダウンリンク制御チャネル）を介して該ＵＥにＳＬ  ｇｒａｎｔ（ｓ）（サイドリンクグラント）を送信し、該ＳＬ  ｇｒａｎｔ（ｓ）は、該ＵＥが伝送するＳＣ（スケジューリング制御）の時間周波数領域リソース位置及び伝送するデータの時間周波数領域リソース位置を含む。該ＳＬ  ｇｒａｎｔ（ｓ）の有効期間は１つのＳＣ  ｐｅｒｉｏｄであり、且つそれに対応するＳＣ  ｐｅｒｉｏｄは該ＳＬ  ｇｒａｎｔ（ｓ）を伝送するサブフレームの４ｍｓ後からの次のＳＣ  ｐｅｒｉｏｄである。ＳＬ  ｇｒａｎｔ（ｓ）を受信した後に、ＵＥは、該ＳＬ  ｇｒａｎｔ（ｓ）に対応するＳＣ  ｐｅｒｉｏｄ内で、まずＳＬ  ｇｒａｎｔ（ｓ）において指示されたＳＣのリソース位置においてＳＣを２回伝送し、そして、ＳＬ  ｇｒａｎｔ（ｓ）において指示されたｄａｔａのリソース位置においてＴＢ（Ｔｒａｎｓｐｏｒｔ  Ｂｌｏｃｋ）を伝送し、ここで、各ＴＢは４回伝送され、１つのＳＣ  ｐｅｒｉｏｄ内で伝送可能なＴＢの数はＳＬ  ｇｒａｎｔ（ｓ）において割り当てられたリソースの数に依存する。図１は該伝送処理を示す図である。
【０００６】
なお、背景技術に関する上記の説明は、単なる本発明の技術案をより明確、完全に説明するためのものであり、当業者を理解させるために説明するものであり。これら技術案が本発明の背景技術の部分に説明されているから当業者にとって周知の技術であると解釈してはならない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ユーザ装置。ユーザとも称される）がインフラの通信モード及びＤ２Ｄ（Ｄｅｖｉｃｅ−ｔｏ−Ｄｅｖｉｃｅ：装置から装置）の通信モード両方において作動する場合は、同一のサブフレームにおいて、ＵＥはアップリンクデータ伝送及びＤ２Ｄのデータ送信を同時に行うことができない。よって、あるＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ：伝送時間間隔）では、ＵＥがＵＬ  ｇｒａｎｔ（Ｕｐｌｉｎｋ  ｇｒａｎｔ：アップリンクグラント）を用いてＰｒｏＳｅ  ＢＳＲ（サイドリンクバッファ状態報告）を送信する場合、このＴＴＩにおいて、ＵＥは必ずＳｉｄｅｌｉｎｋ（ＳＬ：サイドリンク。即ち、Ｄ２Ｄ通信モードにおける装置間のリンク）上のＭＡＣ  ＰＤＵ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  −  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ：媒体アクセス制御−プロトコルデータユニット）を送信できない。従来のインフラ通信モードにおけるＢＳＲのｂｕｆｆｅｒ  ｓｉｚｅ（バッファサイズ）の決定方法に従ってＰｒｏＳｅ  ＢＳＲのｂｕｆｆｅｒ  ｓｉｚｅを決定すると、即ちあるＴＴＩにおいてＢＳＲを報告する必要がある場合に該ＢＳＲにおけるｂｕｆｆｅｒ  ｓｉｚｅはこのＴＴＩ内の全てのＭＡＣ  ＰＤＵが全て構築されたバッファ状態を反映すると、ＵＥはＰｒｏＳｅ  ＢＳＲを送信するＴＴＩ内でＳＬ  ＭＡＣ  ＰＤＵを構築できないため、現在のＵＥはｂｕｆｆｅｒ  ｓｉｚｅを決定できなくなる。具体的には、図２に示すように、アップリンク伝送がＴＴＩｎ＋４において発生するため、このＴＴＩｎ＋４においてＳＬ  ＭＡＣ  ＰＤＵ（サイドリンク上の媒体アクセス制御−プロトコルデータユニット）を構築できない。
【０００８】
また、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩでは、報告されたＰｒｏＳｅ  ＢＳＲに含まれるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ（サイドリンク先又はサイドリンクターゲット）の数を決定する際に、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩをタイミングとしてどのＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎが伝送すべきデータを有するかを判断すると、ＳＬ  ｇｒａｎｔ（ｓ）（サイドリンクグラント）が１つのＴＴＩについてのものではなく、１つのＳＣ  ｐｅｒｉｏｄ（Ｓｉｄｅｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｐｅｒｉｏｄ：サイドリンク制御期間）についてのものであるため、基地局に伝送すべきデータを本当に有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを報告できない。同様に、ＰｒｏＳｅ  ＢＳＲにおけるｂｕｆｆｅｒ  ｓｉｚｅを決定する際に、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩをタイミングとしてｂｕｆｆｅｒ  ｓｉｚｅを決定すると、ｂｕｆｆｅｒ  ｓｔａｔｕｓ（バッファ状態）を正確に反映できない。
【０００９】
上記問題を解決するために、本発明の実施例は、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決するバッファ状態報告の生成方法、装置及び通信システムを提供する。
【課題を解決するための手段】
【００１０】
本発明の実施例の第１態様では、ユーザ装置に適用される、バッファ状態報告の生成装置であって、サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する第１決定手段と、残りの構成されたサイドリンクグラントがあるか否かを判断する判断手段と、前記判断手段の判断結果に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する第２決定手段と、前記第２決定手段により決定された前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、前記バッファ状態報告を生成する生成手段と、を含む、装置を提供する。
【００１１】
本発明の実施例の第２態様では、ユーザ装置に適用される、バッファ状態報告の生成方法であって、サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定するステップと、残りの構成されたサイドリンクグラントがあるか否かを判断するステップと、判断結果に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定するステップと、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、前記バッファ状態報告を生成するステップと、を含む、方法を提供する。
【００１２】
本発明の実施例の第３態様では、上記のバッファ状態報告の生成装置を含む、ユーザ装置を提供する。
【００１３】
本発明の実施例の第４態様では、上記のユーザ装置を含む、通信システムを提供する。
【００１４】
本発明の実施例の他の態様では、バッファ状態報告の生成装置又はユーザ装置においてプログラムを実行する際に、コンピュータに、上記第２態様に記載のバッファ状態報告の生成方法を前記バッファ状態報告の生成装置又はユーザ装置において実行させる、コンピュータ読み取り可能なプログラムを提供する。
【００１５】
本発明の実施例の他の態様では、コンピュータに、上記第２態様に記載のバッファ状態報告の生成方法をバッファ状態報告の生成装置又はユーザ装置において実行させるためのコンピュータ読み取り可能なプログラムを記憶する、記憶媒体を提供する。
【００１６】
本発明の実施例の有益な効果としては、本発明の実施例の方法、装置及びシステムによれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅ  ＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅ  ＢＳＲに含まれている各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。
【００１７】
下記の説明及び図面に示すように、本発明の特定の実施形態が詳細に開示され、本発明の原理を採用できる方式が示される。なお、本発明の実施形態の範囲はこれらに限定されない。本発明の実施形態は、添付される特許請求の範囲の要旨及び項目の範囲内において、変更されたもの、修正されたもの及び均等的なものを含む。
【００１８】
１つの実施形態に記載された特徴及び／又は示された特徴は、同一又は類似の方式で１つ又はさらに多くの他の実施形態で用いられてもよいし、他の実施形態における特徴と組み合わせてもよいし、他の実施形態における特徴に代わってもよい。
【００１９】
なお、本文では、用語「包括／含む」は、特徴、部材、ステップ又はコンポーネントが存在することを指し、一つ又は複数の他の特徴、部材、ステップ又はコンポーネントの存在又は付加を排除しない。
【図面の簡単な説明】
【００２０】
ここで含まれる図面は、本発明の実施例を理解させるためのものであり、本明細書の一部を構成し、本発明の実施例を例示するためのものであり、文言の記載と合わせて本発明の原理を説明する。なお、ここに説明される図面は、単なる本発明の実施例を説明するためのものであり、当業者にとって、これらの図面に基づいて他の図面を容易に得ることができる。
【図１】サイドリンク上のデータ伝送を示す図である。
【図２】サイドリンク伝送とアップリンク伝送との衝突を示す図である。
【図３】本実施例のバッファ状態報告の生成方法のフローチャートである。
【図４】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図５】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図６】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図７】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図８】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図９】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図１０】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図１１】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図１２】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図１３】図４〜図１３は本実施例の方法の１０個の応用シナリオを示す図である。
【図１４】本実施例のバッファ状態報告の生成方法の全体的なフローチャートである。
【図１５】本実施例のバッファ状態報告の生成方法の１つの態様のフローチャートである。
【図１６】本実施例のバッファ状態報告の生成方法のもう１つの態様のフローチャートである。
【図１７】本実施例のバッファ状態報告の生成装置の構成を示す図である。
【図１８】図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。
【図１９】図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。
【図２０】図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。
【図２１】図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。
【図２２】図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。
【図２３】図１８〜図２３は本実施例のバッファ状態報告の生成装置の第２決定部の複数の態様の構成を示す図である。
【図２４】本実施例のユーザ装置の構成を示す図である。
【図２５】本実施例の通信システムのトポロジ構成を示す図である。
【発明を実施するための形態】
【００２１】
本発明の上記及びその他の特徴は、図面及び下記の説明により理解できるものである。明細書及び図面では、本発明の特定の実施形態、即ち本発明の原則に従う一部の実施形態を表すものを公開している。なお、本発明は説明される実施形態に限定されず、本発明は、特許請求の範囲内の全ての修正、変形されたもの、及び均等なものを含む。以下は、図面を参照しながら本発明の各実施例を説明する。これらの実施例は単なる例示的なものであり、本発明を限定するものではない。
【００２２】
＜実施例１＞
本発明の実施例はバッファ状態報告の生成方法を提供し、該方法はユーザ装置に適用される。図３は該方法のフローチャートであり、図３に示すように、該方法は以下のステップを含む。
【００２３】
ステップ３０１：サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する。
【００２４】
ステップ３０２：残りの構成されたサイドリンクグラントがあるか否かを判断する。
【００２５】
ステップ３０３：ステップ３０２の判断結果に基づいて、該サイドリンクのバッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する。
【００２６】
ステップ３０４：該サイドリンクのバッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、該サイドリンクのバッファ状態報告を生成する。
【００２７】
ステップ３０１において、ユーザ装置は、まずＰｒｏＳｅ  ＢＳＲ（サイドリンクのバッファ状態報告）を伝送するＴＴＩ（伝送時間間隔）を決定し、ユーザ装置は決定された該ＴＴＩにおいて該ＰｒｏＳｅ  ＢＳＲを伝送する。ここで、ユーザ装置は、基地局により送信されたＵＬ  ｇｒａｎｔを含むＰＤＣＣＨを受信した後に該ＴＴＩを決定してもよいし、他のポリシーを参照して該ＴＴＩを決定してもよい。本実施例では、ステップ３０１においてＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを決定した後に、該ユーザ装置は、ステップ３０２〜３０３において、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるサイドリンク先（ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ）及びそのバッファサイズ（ｂｕｆｆｅｒ  ｓｉｚｅ）を決定し、ステップ３０２において該ＰｒｏＳｅ  ＢＳＲを生成することで、ステップ３０１において決定されたＴＴＩにおいて該ＰｒｏＳｅ  ＢＳＲを伝送できる。
【００２８】
ステップ３０２において、ユーザ装置がＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを決定した後に、該ＴＴＩ又はその前に、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断してもよい。ここで、該ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄについて残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断してもよく、即ちＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを含むＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒｎａｔ（ｓ）があるか否かを判断してもよい。或いは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄの後続のＳＣ  ｐｅｒｉｏｄについて残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断してもよく、即ちＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを含むＳＣ  ｐｅｒｉｏｄの後続のＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒｎａｔ（ｓ）があるか否かを判断してもよい。或いは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ及びその後続のＳＣ  ｐｅｒｉｏｄ両方について残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断してもよく、即ちＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを含むＳＣ  ｐｅｒｉｏｄ及びその後続のＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒｎａｔ（ｓ）があるか否かを判断してもよい。
【００２９】
１つの態様では、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄに構成されたＳＬ  ｇｒａｎｔ（ｓ）があり、且つ該ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて該構成されたＳＬ  ｇｒａｎｔ（ｓ）を使い切っていない場合、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００３０】
図４〜図５はこの態様の２つの応用シナリオを示す図である。
【００３１】
図４に示すように、このシナリオでは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄはＳＣ  ｐｅｒｉｏｄ  １であり、図４から分かるように、該ＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて該ＳＬ  ｇｒａｎｔ（ｓ）を使い切っておらず、この場合は、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。さらに、図４に示すシナリオでは、ＳＣ  ｐｅｒｉｏｄ  １の後続のＳＣ  ｐｅｒｉｏｄ、例えば次のＳＣ  ｐｅｒｉｏｄ（ＳＣ  ｐｅｒｉｏｄ  ２）及び次の次のＳＣ  ｐｅｒｉｏｄ（ＳＣ  ｐｅｒｉｏｄ  ３）にはいずれも構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、即ち、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ又はその前に、ＳＣ  ｐｅｒｉｏｄ  ２及びＳＣ  ｐｅｒｉｏｄ  ３のＳＬ  ｇｒａｎｔ（ｓ）を復号して取得していない。
【００３２】
図５に示すように、このシナリオでは、図４のシナリオと異なって、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に、該ユーザ装置はＳＣ  ｐｅｒｉｏｄ  ２のＳＬ  ｇｒａｎｔ（ｓ）を既に復号して取得したが、ＳＣ  ｐｅｒｉｏｄ  ３のＳＬ  ｇｒａｎｔ（ｓ）を復号して取得していない。このシナリオでも、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００３３】
もう１つの態様では、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄの次のＳＣ  ｐｅｒｉｏｄに構成されたＳＬ  ｇｒａｎｔがあり、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該次のＳＣ  ｐｅｒｉｏｄのＳＬ  ｇｒａｎｔ（ｓ）を復号して取得した場合、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００３４】
図６〜図９は該態様の４つの応用シナリオを示す図である。
【００３５】
図６に示すように、このシナリオでは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄはＳＣ  ｐｅｒｉｏｄ  １であり、ＳＣ  ｐｅｒｉｏｄ  ２に構成されたＳＬ  ｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置がＳＣ  ｐｅｒｉｏｄ  ２のＳＬ  ｇｒａｎｔ（ｓ）を復号して取得しており、この場合は、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。さらに、図６に示すシナリオでは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、且つＳＣ  ｐｅｒｉｏｄ  ３にも構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、即ち、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置は、ＳＣ  ｐｅｒｉｏｄ  ３のＳＬ  ｇｒａｎｔ（ｓ）を復号して取得していない。
【００３６】
図７に示すように、このシナリオでは、図６のシナリオと異なって、ＳＣ  ｐｅｒｉｏｄ  ３にも構成されたＳＬ  ｇｒａｎｔ（ｓ）があり、即ちＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に、該ユーザ装置はＳＣ  ｐｅｒｉｏｄ  ３のＳＬ  ｇｒａｎｔ（ｓ）を既に復号して取得した。このシナリオでも、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００３７】
図８に示すように、このシナリオでは、図６のシナリオと異なって、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬ  ｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００３８】
図９に示すように、このシナリオでは、図７のシナリオと異なって、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬ  ｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００３９】
もう１つの態様では、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄの次の次のＳＣ  ｐｅｒｉｏｄに構成されたＳＬ  ｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該次の次のＳＣ  ｐｅｒｉｏｄのＳＬ  ｇｒａｎｔ（ｓ）を復号して取得した場合、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００４０】
図１０〜図１１はこの態様の２つの応用シナリオを示す図である。
【００４１】
図１０に示すように、このシナリオでは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄはＳＣ  ｐｅｒｉｏｄ  １であり、該ＳＣ  ｐｅｒｉｏｄ  １の次の次のＳＣ  ｐｅｒｉｏｄ（ＳＣ  ｐｅｒｉｏｄ  ３）に構成されたＳＬ  ｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置がＳＣ  ｐｅｒｉｏｄ  ３のＳＬ  ｇｒａｎｔ（ｓ）を復号して取得した場合、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。さらに、図１０に示すシナリオでは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、該ＳＣ  ｐｅｒｉｏｄ  １の次のＳＣ  ｐｅｒｉｏｄ（ＳＣ  ｐｅｒｉｏｄ  ２）にも構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、即ち、ユーザ装置がＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ又はその前にＳＣ  ｐｅｒｉｏｄ  ２のＳＬ  ｇｒａｎｔ（ｓ）を復号して取得していない。
【００４２】
図１１に示すように、このシナリオでは、図１０のシナリオと異なって、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬ  ｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があると判断する。
【００４３】
もう１つの態様では、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄに構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該ＳＣ  ｐｅｒｉｏｄの後続のＳＣ  ｐｅｒｉｏｄについての構成されたＳＬ  ｇｒａｎｔ（ｓ）を復号して取得していない場合、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がないと判断する。
【００４４】
図１２は該態様の応用シナリオを示す図である。図１２に示すように、このシナリオでは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄはＳＣ  ｐｅｒｉｏｄ  １であり、該ＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、該ＳＣ  ｐｅｒｉｏｄ  １の次のＳＣ  ｐｅｒｉｏｄ（ＳＣ  ｐｅｒｉｏｄ  ２）及び次の次のＳＣ  ｐｅｒｉｏｄ（ＳＣ  ｐｅｒｉｏｄ  ３）にいずれも構成されたＳＬ  ｇｒａｎｔ（ｓ）がなく、即ちＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置がＳＣ  ｐｅｒｉｏｄ  １の後続のＳＣ  ｐｅｒｉｏｄ  ２及びＳＣ  ｐｅｒｉｏｄ  ３についての構成されたＳＬ  ｇｒａｎｔ（ｓ）を復号して取得していない。このシナリオでは、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がないと判断する。
【００４５】
もう１つの態様では、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄに構成されたＳＬ  ｇｒａｎｔ（ｓ）があり、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切っており、且つＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの前に該ユーザ装置が該ＳＣ  ｐｅｒｉｏｄの後続のＳＣ  ｐｅｒｉｏｄについての構成されたＳＬ  ｇｒａｎｔ（ｓ）を復号して取得していない場合、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がないと判断する。
【００４６】
図１３は該態様の応用シナリオを示す図である。図１３に示すように、このシナリオでは、図１２のシナリオと異なって、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ  １に構成されたＳＬ  ｇｒａｎｔ（ｓ）があるが、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ又は該ＴＴＩの前に、該ＳＬ  ｇｒａｎｔ（ｓ）を使い切った。このシナリオでも、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がないと判断する。
【００４７】
ステップ３０３において、ユーザ装置は、ステップ３０２の判断結果に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定してもよい。
【００４８】
ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がない場合、即ち図１２及び図１３に示すシナリオでは、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ内のバッファ状態に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定してもよい。即ち、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの時点に利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのみを考慮し、この際に、該ＰｒｏＳｅ  ＢＳＲは、該ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ時点のバッファ状態を反映する。
【００４９】
具体的には、ＵＥがＴＴＩについてのトリガされたＰｒｏＳｅ  ＢＳＲを伝送可能なＵＬ  ｇｒａｎｔを有する場合、ＵＥは、現在のＴＴＩ時点においてどのＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに対応する論理チャネルが利用可能な伝送すべきデータを有するかを決定する。そして、通常のＰｒｏＳｅ  ＢＳＲ又は周期的なＰｒｏＳｅ  ＢＳＲについて、ＵＥは、ＵＬ  ｇｒａｎｔのサイズ及び前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅ  ＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄ  ＰｒｏＳｅ  ＢＳＲを報告するかを決定する。Ｐａｄｄｉｎｇ  ＰｒｏＳｅ  ＢＳＲについて、ＵＥは、利用可能なＰａｄｄｉｎｇ  ｂｉｔ（付加ビット）の数及び前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅ  ＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄ  ＰｒｏＳｅ  ＢＳＲを報告するかを決定する。
【００５０】
ここで、ＰｒｏＳｅ  ＢＳＲ又はＴｒｕｎｃａｔｅｄ  ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎについて、ＵＥは、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ時点に対応するバッファにおけるデータ量を決定し、該データ量及び参照文献［TS36.321, Medium Access Control (MAC) protocol specification, v
12.2.0］におけるバッファ状態報告テーブルに基づいて各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに対応するｂｕｆｆｅｒ  ｓｉｚｅを決定する。
【００５１】
これによって、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。
【００５２】
ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がある場合、即ち図４〜図１１に示すシナリオでは、ユーザ装置は、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のある、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定する。
【００５３】
例えば、ユーザ装置は、まず、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定し、そして、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩのＵＬ  ｇｒａｎｔ（アップリンクグラント）について該ＰｒｏＳｅ  ＢＳＲよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素（ＭＡＣ  ＣＥ：Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｃｏｎｔｒｏｌ  Ｅｌｅｍｅｎｔ）を考慮した後の残りのビット数、又はＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおける利用可能な付加ビットの数に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のある、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定する。ここで、ＭＡＣ  ＣＥは例えばＢＳＲ  ＭＡＣ  ＣＥである。
【００５４】
ここで、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの決定方法は以下の通りである。
【００５５】
態様１では、ユーザ装置がＳＬ  ｇｒａｎｔ（ｓ）を復号して取得した後、又は該ＳＬ  ｇｒａｎｔ（ｓ）に対応するＳＣ  ｐｅｒｉｏｄの開始時刻において、ユーザ装置は、該ＳＬ  ｇｒａｎｔ（ｓ）において割り当てられたデータを伝送するリソースに基づいて、該ＳＬ  ｇｒａｎｔ（ｓ）に対応するＳＣ  ｐｅｒｉｏｄ全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該ＳＬ  ｇｒａｎｔ（ｓ）に対応するＳＣ  ｐｅｒｉｏｄ内に伝送可能なＭＡＣ  ＰＤＵの全てを生成してもよい。これによって、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、どのＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに対応する論理チャネルが利用可能な伝送すべきデータを有するかを直接決定でき、即ちバッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定できる。
【００５６】
態様２では、ユーザ装置がＳＬ  ｇｒａｎｔ（ｓ）を復号して取得した後に、ユーザ装置は、該ＳＬ  ｇｒａｎｔ（ｓ）において割り当てられたデータを伝送する各ＴＴＩにおいて、該ＴＴＩ内で伝送可能な対応するＳＬ  ＭＡＣ  ＰＤＵを構築する。これによって、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、仮に全てのＳＬ  ｇｒａｎｔ（ｓ）において割り当てられた残りのデータ伝送用のリソースを全て使い切った後で構築可能な全てのＳＬ  ＭＡＣ  ＰＤＵの数及びサイズを計算し、これらのＳＬ  ＭＡＣ  ＰＤＵを除いた後に、どのＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに対応する論理チャネルが利用可能な伝送すべきデータを有するかを決定する。
【００５７】
ここで、該ＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの決定方法は以下の通りである。
【００５８】
具体的には、通常のＰｒｏＳｅ  ＢＳＲ又は周期的なＰｒｏＳｅ  ＢＳＲについて、ＵＥは、ＵＬ  ｇｒａｎｔにおいて該ＰｒｏＳｅよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素（ＭＡＣ  ＣＥ：Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｃｏｎｔｒｏｌ  Ｅｌｅｍｅｎｔ）を考慮した後の残りのビット数、又は前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅ  ＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄ  ＰｒｏＳｅ  ＢＳＲを報告するかを決定する。Ｐａｄｄｉｎｇ  ＰｒｏＳｅ  ＢＳＲについて、ＵＥは、利用可能なＰａｄｄｉｎｇ  ｂｉｔの数及び前に決定された利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの数に基づいて、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの全てを含むＰｒｏＳｅ  ＢＳＲを報告するか、それとも利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの一部のみを含むＴｒｕｎｃａｔｅｄ  ＰｒｏＳｅ  ＢＳＲを報告するかを決定する。
【００５９】
ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がある場合、即ち図４〜図１１に示すシナリオでは、ユーザ装置は、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切ってＳＬ  ＭＡＣ  ＰＤＵを全て構築した後のバッファ状態に基づいて、各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅを決定してもよい。即ち、ユーザ装置は、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切ってＳＬ  ＭＡＣ  ＰＤＵを全て構築した後のバッファ状態を、各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして決定する。
【００６０】
具体的には、ＰｒｏＳｅ  ＢＳＲ又はＴｒｕｎｃａｔｅｄ  ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎについて、ＵＥは、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切ってＳＬ  ＭＡＣ  ＰＤＵを全て構築した後のそれに対応するバッファにおけるデータ量を、該ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして決定する。
【００６１】
態様３では、態様１と同様に、ユーザ装置は、まずＳＬ  ＭＡＣ  ＰＤＵを構築し、そしてＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、バッファにおけるデータ量のサイズを該ｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【００６２】
態様４では、態様２と同様に、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、仮に残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切って構築可能なＳＬ  ＭＡＣ  ＰＤＵの全てを除いたバッファにおけるデータ量のサイズを該ｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【００６３】
ステップ３０３において、ステップ３０２の判断結果として残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がある場合、即ち図４〜図１１に示すシナリオでは、ユーザ装置は、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定してもよい。具体的には上述した通り、ここでその説明を省略する。そして、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切ってＳＬ  ＭＡＣ  ＰＤＵの全てを構築した後のバッファ状態に基づいて、各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅを決定してもよい。ここで、該ｂｕｆｆｅｒ  ｓｉｚｅは、前に決定されたＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに対応する。即ち、該態様では、ユーザ装置は、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切ってＳＬ  ＭＡＣ  ＰＤＵの全てを構築した後のバッファ状態を、ｂｕｆｆｅｒ  ｓｉｚｅとして決定してもよい。
【００６４】
態様５では、態様１と同様に、ユーザ装置は、まずＳＬ  ＭＡＣ  ＰＤＵを構築し、そして、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、バッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定し、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【００６５】
態様６では、態様２と同様に、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、仮に残りの構成されたサイドリンクグラントを全て使い切って構築可能な全てのＳＬ  ＭＡＣ  ＰＤＵを除いた利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定し、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの、該残りの構成されたサイドリンクグラントを使い切って構築可能な全てのＳＬ  ＭＡＣ  ＰＤＵを除いたバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【００６６】
図１４は本実施例の方法の全体的なフローチャートであり、図１４に示すように、該方法は以下のステップを含む。
【００６７】
ステップ１４０１：ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを決定する。
【００６８】
ここで、ステップ１４０１はステップ３０１に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。
【００６９】
ステップ１４０２：残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合、ステップ１４０３を実行し、そうでない場合、ステップ１４０５を実行する。
【００７０】
ここで、ステップ１４０２はステップ３０２に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。
【００７１】
ステップ１４０３：残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定する。
【００７２】
ここで、まず、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定し、そして、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩのアップリンクグラントについてのビット数又はＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおける利用可能な付加ビットの数に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のある、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの数を決定してもよい。
【００７３】
ここで、ステップ１４０３は、ステップ３０３におけるステップ３０２の判断結果が残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があることである場合にＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎの決定処理に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。
【００７４】
ステップ１４０４：残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切ってＳＬ  ＭＡＣ  ＰＤＵを全て構築した後のバッファ状態に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅを決定する。
【００７５】
ここで、ステップ１４０４は、ステップ３０３におけるステップ３０２の判断結果が残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があることである場合にＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅの決定処理に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。
【００７６】
ここで、本実施例ではステップ１４０３及びステップ１４０４の実行順序を限定せず、例えば、ステップ１４０３を実行した後にステップ１４０４を実行してもよいし、ステップ１４０４を実行した後にステップ１４０３を実行してもよいし、ステップ１４０３及びステップ１４０４を同時に実行してもよい。ここで、ステップ１４０３を実行した後にステップ１４０４を実行する場合は、ステップ１４０４は、ＰｒｏＳｅ  ＢＳＲに含めることができる利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅについてのものである。
【００７７】
ステップ１４０５：ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ内のバッファ状態に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及び各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファサイズを決定する。
【００７８】
ここで、ステップ１４０５は、ステップ３０３におけるステップ３０２の判断結果が残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）がないことである場合のユーザ装置の処理プロセスに対応し、具体的には上述した通りであり、ここでその説明を省略する。
【００７９】
ステップ１４０６：該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅに基づいて、該ＰｒｏＳｅ  ＢＳＲを生成する。
【００８０】
これによって、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩにおいて、サイドリンクのバッファ状態を反映したＰｒｏＳｅ  ＢＳＲを伝送でき、本願が解決しようとする課題を解決した。
【００８１】
本発明の実施例の方法によれば、ＰｒｏＳｅ  ＢＳＲを送信する際に、ＵＥはＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅ  ＢＳＲに含まれている各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。
【００８２】
図１５は本実施例のバッファ状態報告の生成方法の１つの態様のフローチャートであり、図１５に示すように、該方法は以下のステップを含む。
【００８３】
ステップ１５０１：ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを決定する。
【００８４】
ステップ１５０２：ユーザ装置は、該ＴＴＩ内のバッファ状態に基づいて、ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定する。
【００８５】
ステップ１５０３：ユーザ装置は、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅに基づいて、該ＰｒｏＳｅ  ＢＳＲを生成する。
【００８６】
ここで、ステップ１５０２の態様はステップ１４０５の態様に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。
【００８７】
この態様では、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの時点に利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのみを考慮し、この際に、該ＰｒｏＳｅ  ＢＳＲは、該ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩ時点のバッファ状態を反映する。これによって、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを報告する際に、ＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正しく反映でき、本願が解決しようとする課題を解決した。
【００８８】
また、この態様は上記の図４〜図１３の１０個のシナリオにも同様に適用できる。即ち、上記図４〜図１３の何れかのシナリオでも、図１５の方法を用いてＰｒｏＳｅ  ＢＳＲを生成してもよい。
【００８９】
図１６は本実施例のバッファ状態報告の生成方法のもう１つの態様のフローチャートであり、図１６に示すように、該方法は以下のステップを含む。
【００９０】
ステップ１６０１：ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩを決定する。
【００９１】
ステップ１６０２：該ＴＴＩの所在するＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断し、ない場合（図１２、図１０、図６、図７のシナリオに対応する）、ステップ１６０３を実行し、そうでない場合（図１３、図１１、図８、図９、図４、図５のシナリオに対応する）、ステップ１６０８を実行する。
【００９２】
ステップ１６０３：該ＴＴＩの所在するＳＣ  ｐｅｒｉｏｄの次のＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断し、ない場合（図１２及び図１０のシナリオに対応する）、ステップ１６０４を実行し、そうでない場合（図６及び図７のシナリオに対応する）、ステップ１６０５を実行する。
【００９３】
ステップ１６０４：該ＴＴＩの所在するＳＣ  ｐｅｒｉｏｄの次の次のＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合（図１０のシナリオに対応する）、ステップ１６０５を実行し、そうでない場合（図１２のシナリオに対応する）、ステップ１６０７を実行する。
【００９４】
ステップ１６０５：残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定する。
【００９５】
ステップ１６０６：残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）を全て使い切ってＳＬ  ＭＡＣ  ＰＤＵを全て構築した後のバッファ状態に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファサイズを決定する。
【００９６】
ステップ１６０７：該ＴＴＩ内のバッファ状態に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定する。
【００９７】
ステップ１６０８：該ＴＴＩの所在するＳＣ  ｐｅｒｉｏｄのＳＬ  ｇｒａｎｔ（ｓ）を使い切ったか否かを判断し、使い切った場合（図１３、図１１、図８、図９のシナリオに対応する）、ステップ１６０９を実行し、そうでない場合（図４、図５のシナリオに対応する）、ステップ１６０５を実行する。
【００９８】
ステップ１６０９：該ＴＴＩの所在するＳＣ  ｐｅｒｉｏｄの次のＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合（図８、図９のシナリオに対応する）、ステップ１６０５を実行し、そうでない場合（図１３、図１１のシナリオに対応する）、ステップ１６１０を実行する。
【００９９】
ステップ１６１０：該ＴＴＩの所在するＳＣ  ｐｅｒｉｏｄの次の次のＳＣ  ｐｅｒｉｏｄについてのＳＬ  ｇｒａｎｔ（ｓ）があるか否かを判断し、ある場合（図１１のシナリオに対応する）、ステップ１６０５を実行し、そうでない場合（図１３のシナリオに対応する）、ステップ１６０７を実行する。
【０１００】
ステップ１６１１：ユーザ装置は、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅに基づいて、該ＰｒｏＳｅ  ＢＳＲを生成する。
【０１０１】
ここで、ステップ１６０５〜１６０６及び１６０７の態様は上記ステップ１４０３〜１４０４及び１４０５の態様と同様であり、具体的には上述した通り、ここでその説明を省略する。
【０１０２】
この態様では、ユーザ装置は、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があるか否かのみを考慮し、残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）があれば、該残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）が、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩに対応するＳＣ  ｐｅｒｉｏｄ内に位置し、該ＳＣ  ｐｅｒｉｏｄの次のＳＣ  ｐｅｒｉｏｄ内に位置し、或いは該ＳＣ  ｐｅｒｉｏｄの次の次のＳＣ  ｐｅｒｉｏｄ内に位置するにも関わらず、ステップ１６０５〜１６０６の方法を用いて該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定してもよい。そうでない場合、ステップ１６０７の方法を用いて該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定してもよい。これによって、ユーザ装置は、ＰｒｏＳｅ  ＢＳＲを報告する際に、ＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正しく反映でき、本願が解決しようとする課題を解決した。
【０１０３】
本実施例では、上記残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）（Ｒｅｍａｉｎｉｎｇ  ｃｏｎｆｉｇｕｒｅｄ  ＳＬ  ｇｒａｎｔ（ｓ））は、利用可能なＳＬ  ｇｒａｎｔ（ｓ）（ａｖａｉｌａｂｌｅ  ＳＬ  ｇｒａｎｔ（ｓ））と定義されてもよいし、有効なＳＬ  ｇｒａｎｔ（ｓ）（Ｖａｌｉｄ  ＳＬ  ｇｒａｎｔ（ｓ））等と定義されてもよいが、本実施例はこれらに限定されない。また、上記残りの構成されたＳＬ  ｇｒａｎｔ（ｓ）は、ＰｒｏＳｅ  ＢＳＲを伝送するＴＴＩの所在するＳＣ  ｐｅｒｉｏｄ及び／又はその後続のＳＣ  ｐｅｒｉｏｄのＳＬ  ｇｒａｎｔ（ｓ）に限定されてもよい。
【０１０４】
本実施例の方法によれば、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。
【０１０５】
＜実施例２＞
本発明の実施例はバッファ状態報告の生成装置を提供し、該装置はユーザ装置に適用されてもよい。該装置の課題解決の原理は実施例１と同様であるため、その具体的な実施は実施例１の方法の実施を参照してもよく、同様な内容について説明を省略する。
【０１０６】
図１７は該装置の構成を示す図である。図１７に示すように、該バッファ状態報告の生成装置１７００は、第１決定部１７０１、判断部１７０２、第２決定部１７０３及び生成部１７０４を含む。
【０１０７】
本実施例では、第１決定部１７０１は、サイドリンクのバッファ状態報告を伝送する伝送時間間隔を決定する。
【０１０８】
本実施例では、判断部１７０２は、残りの構成されたサイドリンクグラントがあるか否かを判断する。
【０１０９】
本実施例では、第２決定部１７０３は、判断部１７０２の判断結果に基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定する。
【０１１０】
本実施例では、生成部１７０４は、第２決定部１７０３により決定された該バッファ状態報告に含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅに基づいて、該バッファ状態報告を生成する。
【０１１１】
１つの態様では、判断部１７０２は、該伝送時間間隔を含むサイドリンク制御期間及び／又はその後続のサイドリンク制御期間についての残りの構成されたサイドリンクグラントがあるか否かを判断する。
【０１１２】
１つの態様では、判断部１７０２は、該伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔において該構成されたサイドリンクグラントを使い切っていない場合、及び／又は該伝送時間間隔の所在するサイドリンク制御期間の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔の前に前記ユーザ装置が該次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、及び／又は該伝送時間間隔の所在するサイドリンク制御期間の次の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔の前に前記ユーザ装置が該次の次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、残りの構成されたサイドリンクグラントがあると判断する。
【０１１３】
１つの態様では、判断部１７０２は、該伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがなく、且つ該伝送時間間隔の前に該ユーザ装置が該サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、及び／又は該伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ該伝送時間間隔の前に該構成されたサイドリンクグラントを全て使い切っており、且つ該伝送時間間隔の前に該ユーザ装置が該サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、残りの構成されたサイドリンクグラントがないと判断する。
【０１１４】
１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがあると判断部１７０２により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定する。
【０１１５】
ここで、第２決定部１７０３は、まず、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定し、そして、該伝送時間間隔のアップリンクグラントについて該ＰｒｏＳｅ  ＢＳＲよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素を考慮した後の残りのビット数、又は該伝送時間間隔における利用可能な付加ビットの数に基づいて、該ＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定する。
【０１１６】
ここで、好ましくは、図１８に示すように、第２決定部１７０３は、第１データユニット生成モジュール１８０１及び第１決定モジュール１８０２を含んでもよい。第１データユニット生成モジュール１８０１は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なＳＬ  ＭＡＣ  ＰＤＵの全てを生成する。第１決定モジュール１８０２は、該伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎとして決定する。
【０１１７】
ここで、好ましくは、図１９に示すように、第２決定部１７０３は第３決定モジュール１９０１を含んでもよい。第３決定モジュール１９０１は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬ  ＭＡＣ  ＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎとして決定する。
【０１１８】
１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがあると判断部１７０２により判断された場合、残りの構成されたサイドリンクグラントを全て使い切ってＳＬ  ＭＡＣ  ＰＤＵを全て構築した後のバッファ状態を、該ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして決定する。
【０１１９】
ここで、好ましくは、図２０に示すように、第２決定部１７０３は、第２データユニット生成モジュール２００１及び第１決定モジュール２００２を含む。第２データユニット生成モジュール２００１は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なＳＬ  ＭＡＣ  ＰＤＵの全てを生成する。第１計算モジュール２００２は、該伝送時間間隔において、バッファにおけるデータ量のサイズを、ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【０１２０】
ここで、好ましくは、図２１に示すように、第２決定部１７０３は第３計算モジュール２１０１を含む。第３計算モジュール２１０１は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬ  ＭＡＣ  ＰＤＵの全てを除いた、バッファにおけるデータ量のサイズを、ＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【０１２１】
上記の態様では、図１８の第２決定部と図２０の第２決定部を併合してもよく、即ち第２決定部は、第１データユニット生成モジュール１８０１、第１決定モジュール１８０２、第２データユニット生成モジュール２００１及び第１計算モジュール２００２を同時に有してもよい。第１データユニット生成モジュール１８０１、第１決定モジュール１８０２によりＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定し、第２データユニット生成モジュール２００１及び第１計算モジュール２００２によりＰｒｏＳｅ  ＢＳＲに含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅを決定してもよい。ここで、第１データユニット生成モジュール１８０１と第２データユニット生成モジュール２００１の機能は同様であり、１つのモジュールに併合してもよい。同様に、図１９の第２決定部と図２１の第２決定部を併合してもよい。
【０１２２】
１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがあると判断部１７０２により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎに基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを決定し、残りの構成されたサイドリンクグラントを全て使い切ってＳＬ  ＭＡＣ  ＰＤＵの全てを構築した後の、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファ状態に基づいて、該利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅを決定する。
【０１２３】
ここで、好ましくは、図２２に示すように、第２決定部１７０３は、第３データユニット生成モジュール２２０１、第２決定モジュール２２０２及び第２計算モジュール２２０３を含む。第３データユニット生成モジュール２２０１は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なＳＬ  ＭＡＣ  ＰＤＵの全てを生成する。第２決定モジュール２２０２は、該伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎとして決定する。第２計算モジュール２２０３は、該伝送時間間隔において、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【０１２４】
ここで、好ましくは、図２３に示すように、第２決定部１７０３は、第４決定モジュール２３０１及び第４計算モジュール２３０２を含む。第４決定モジュール２３０１は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬ  ＭＡＣ  ＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎとして決定する。第４計算モジュール２３０２は、該伝送時間間隔において、該残りの構成されたサイドリンクグラントを全て使い切って構築されたＳＬ  ＭＡＣ  ＰＤＵの全てを除いた、利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのｂｕｆｆｅｒ  ｓｉｚｅとして計算する。
【０１２５】
１つの態様では、第２決定部１７０３は、残りの構成されたサイドリンクグラントがないと判断部１７０２により判断された場合、該バッファ状態報告を伝送する伝送時間間隔内のバッファ状態に基づいて、該バッファ状態報告に含める必要のあるＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎ及びそのｂｕｆｆｅｒ  ｓｉｚｅを決定する。
【０１２６】
本実施例の装置によれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅ  ＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅ  ＢＳＲに含まれている各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。
【０１２７】
＜実施例３＞
本発明の実施例は、実施例２のバッファ状態報告の生成装置を含むユーザ装置をさらに提供する。
【０１２８】
図２４は本発明の実施例のユーザ装置の構成を示す図である。図２４に示すように、ユーザ装置２４００は、中央処理装置２４０１及び記憶装置２４０２を含んでもよく、記憶装置２４０２は中央処理装置２４０１に接続される。なお、該図は単なる例示的なものであり、電気通信機能又は他の機能を実現するように、他の種類の構成を用いて、該構成を補充又は代替してもよい。
【０１２９】
１つの態様では、バッファ状態報告の生成装置の機能は中央処理装置２４０１に統合され、中央処理装置２４０１は、実施例２に記載されたバッファ状態報告の生成装置の機能を実現するように構成されてもよい。バッファ状態報告の生成装置の機能はここで援用し、ここでその説明を省略する。
【０１３０】
もう１つの態様では、バッファ状態報告の生成装置は中央処理装置２４０１とそれぞれ構成されてもよく、例えばバッファ状態報告の生成装置は中央処理装置２４０１に接続されたチップであり、中央処理装置２４０１の制御によりバッファ状態報告の生成装置の機能を実現してもよい。
【０１３１】
図２４に示すように、ユーザ装置２４００は、通信モジュール２４０３、入力部２４０４、音声処理装置２４０５、ディスプレイ２４０６、及び電源２４０７をさらに含んでもよい。なお、ユーザ装置２４００は図２４に示す全てのユニットを含む必要がない。また、ユーザ装置２４００は、図２４に示されていないユニットをさらに含んでもよく、従来技術を参照してもよい。
【０１３２】
図２４に示すように、中央処理装置２４０１は、コントローラ又は操作制御部とも称され、マイクロプロセッサ又は他の処理装置及び／又は論理装置を含んでもよく、中央処理装置２４０１は入力を受信し、ユーザ装置２４００の各部の操作を制御する。
【０１３３】
ここで、記憶装置２４０２は、例えばバッファ、フラッシュメモリ、ハードディスク、移動可能な媒体、発揮性メモリ、不発揮性メモリ、又は他の適切な装置の１つ又は複数であってもよい。上記障害に関する情報を記憶してもよいし、関連情報を実行するためのプログラムをさらに記憶してもよい。また、中央処理装置２４０１は、記憶装置２４０２に記憶されたプログラムを実行し、情報の記憶又は処理などを実現してもよい。他の部材は従来技術に類似するため、ここでその説明が省略される。端末装置２４００の各部は、本発明の範囲から逸脱することなく、特定のハードウェア、ファームウェア、ソフトウェア又はその組み合わせによって実現されてもよい。
【０１３４】
本実施例のユーザ装置によれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅ  ＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅ  ＢＳＲに含まれている各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。
【０１３５】
＜実施例４＞
本発明の実施例は通信システムをさらに提供し、図２５は該通信システムのトポロジ構成を示す図である。図２５に示すように、通信システム２５００はユーザ装置２５０１及び基地局２５０２を含む。
【０１３６】
ここで、基地局２５０２は、適切なタイミングでユーザ装置２５０１にＳＬ  ｇｒａｎｔ（ｓ）を含むＰＤＣＣＨ及びＵＬ  ｇｒａｎｔを含むＰＤＣＣＨを送信する。
【０１３７】
ここで、ユーザ装置２５０１は、基地局２５０１と従来のインフラに基づく通信を行うと共に、他のユーザ装置２５０１とＤ２Ｄに基づく通信を行うことができる。
【０１３８】
本実施例では、ユーザ装置２５０１は実施例１に記載されたバッファ状態報告の生成方法を適用してもよく、即ち実施例２に記載されたバッファ状態報告の生成装置の機能を実現するように構成されてもよい。実施例１及び実施例２の内容はここで援用し、ここでその説明を省略する。
【０１３９】
本実施例のシステムによれば、サイドリンクのバッファ状態報告（ＰｒｏＳｅ  ＢＳＲ）を送信する際に、ＵＥはＰｒｏＳｅ  ＢＳＲに含める必要のある利用可能な伝送すべきデータを有するＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎを合理的に決定できると共に、ＵＥはＰｒｏＳｅ  ＢＳＲに含まれている各ＰｒｏＳｅ  Ｄｅｓｔｉｎａｔｉｏｎのバッファのサイズを合理的に決定できるため、ＵＥがＰｒｏＳｅ  ＢＳＲを報告する際にＰｒｏＳｅ  ＢＳＲにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。
【０１４０】
本発明の実施例は、バッファ状態報告の生成装置又はユーザ装置においてプログラムを実行する際に、コンピュータに、上記実施例１に記載のバッファ状態報告の生成方法を該バッファ状態報告の生成装置又はユーザ装置において実行させる、コンピュータ読み取り可能なプログラムをさらに提供する。
【０１４１】
本発明の実施例は、コンピュータに、上記実施例１に記載のバッファ状態報告の生成方法をバッファ状態報告の生成装置又はユーザ装置において実行させるためのコンピュータ読み取り可能なプログラムを記憶する、記憶媒体をさらに提供する。
【０１４２】
本発明の以上の装置及び方法は、ハードウェアにより実現されてもよく、ハードウェアとソフトウェアを結合して実現されてもよい。本発明はコンピュータが読み取り可能なプログラムに関し、該プログラムは論理部により実行される時に、該ロジック部に上述した装置又は構成要件を実現させる、或いは該ロジック部に上述した各種の方法又はステップを実現させることができる。本発明は上記のプログラムを記憶するための記憶媒体、例えばハードディスク、磁気ディスク、光ディスク、ＤＶＤ、フラッシュメモリ等に関する。
【０１４３】
以上、具体的な実施形態を参照しながら本発明を説明しているが、上記の説明は、例示的なものに過ぎず、本発明の保護の範囲を限定するものではない。本発明の趣旨及び原理を離脱しない限り、本発明に対して各種の変形及び修正を行ってもよく、これらの変形及び修正も本発明の範囲に属する。
【図１】
0006369635.tif 000002
【図２】
0006369635.tif 000003
【図３】
0006369635.tif 000004
【図４】
0006369635.tif 000005
【図５】
0006369635.tif 000006
【図６】
0006369635.tif 000007
【図７】
0006369635.tif 000008
【図８】
0006369635.tif 000009
【図９】
0006369635.tif 000010
【図１０】
0006369635.tif 000011
【図１１】
0006369635.tif 000012
【図１２】
0006369635.tif 000013
【図１３】
0006369635.tif 000014
【図１４】
0006369635.tif 000015
【図１５】
0006369635.tif 000016
【図１６】
0006369635.tif 000017
【図１７】
0006369635.tif 000018
【図１８】
0006369635.tif 000019
【図１９】
0006369635.tif 000020
【図２０】
0006369635.tif 000021
【図２１】
0006369635.tif 000022
【図２２】
0006369635.tif 000023
【図２３】
0006369635.tif 000024
【図２４】
0006369635.tif 000025
【図２５】
0006369635.tif 000026