図面 (/)

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

出願人 富士通株式会社
発明者 シュイ・ハイボウ・リエヌハイ
出願日 2014年12月31日 (4年6ヶ月経過) 出願番号 2017-534835
公開日 2018年2月15日 (1年5ヶ月経過) 公開番号 2018-504830
状態 特許登録済
技術分野 移動無線通信システム
主要キーワード 不発揮性メモリ 発揮性メモリ サイドリンク 参照文 スケジューリング制御 インフラ通信 時間周波数領域 計算モジュール
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年2月15日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題・解決手段

バッファ状態報告生成方法、装置及び通信ステムを提供する。該装置は、ユーザ装置(UE)に適用され、サイドリンクのバッファ状態報告(ProSeBSR)を伝送する伝送時間間隔を決定する第1決定部と、残りの構成されたサイドリンクグラントがあるか否かを判断する判断部と、該判断部の判断結果に基づいて、該バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する第2決定部と、該第2決定部により決定された該バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、該バッファ状態報告を生成する生成部とを含む。本発明によれば、UEがProSe BSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

概要

背景

現在のLTE(Long Term Evolution:ロングタームエボリューション)システムにおいて端末装置と端末装置との間の通信無線アクセスネットワーク及びコアネットワークを介して行われる必要がある。新たなトラヒック要求の出現に伴い、ネットワークのロードを低減し、ネットワークのロードの移転を実現するために、端末装置と端末装置との間の通信は徐々に新たな研究の方向となっている。2つの端末装置の間の距離が十分に近い場合に、端末装置は相手の存在を互いに発見できるため、基地局の制御により装置と装置との間の直接通信を行うことができる。

装置と装置の通信を実現するために、LTE−A(LTE−Advanced:ロング・ターム・エボリューション・アドバンスト)システムでは2つのエアインタフェースリソース割り当て方式、即ちモード1(Mode 1)及びモード2(Mode 2)が定義されている。モード1では、従来のインフラ通信モードのトラヒックのバッファ状態報告(Buffer Status Report:BSR)の報告への影響を回避するために、装置間の通信のための特別なバッファ状態報告(ProSe−BSRと称されてもよい)メカニズムが導入され、該メカニズムは主に新たなバッファ状態報告のトリガ・メカニズム、並びにバッファ状態報告のMACシグナリングフォーマット及び内容を含む。

D2D(Device to Device:装置から装置)通信モードではサイドリンク制御期間(Sidelink Control Period。SC periodと略称される)の概念が定義され、該SC periodはスケジューリング制御(Scheduling Control)及びそれに対応するデータの伝送を含む時間周期を意味する。Mode 1について、D2D通信における送信側のデータ伝送の基本的な作動原理は以下の通りである。

基地局があるD2DUE(User Equipment:ユーザ装置)のデータ伝送をスケジューリングすると決定した後に、基地局は、SL−RNTI(Sidelink−Radio Network Tempory Identity:サイドリンク無線ネットワーク一時識別子)によりスクランブルされたPDCCH(Physical Downlink Control Channel:物理ダウンリンク制御チャネル)を介して該UEにSL grant(s)(サイドリンクグラント)を送信し、該SL grant(s)は、該UEが伝送するSC(スケジューリング制御)の時間周波数領域リソース位置及び伝送するデータの時間周波数領域リソース位置を含む。該SL grant(s)の有効期間は1つのSC periodであり、且つそれに対応するSC periodは該SL grant(s)を伝送するサブフレームの4ms後からの次のSC periodである。SL grant(s)を受信した後に、UEは、該SL grant(s)に対応するSC period内で、まずSL grant(s)において指示されたSCのリソース位置においてSCを2回伝送し、そして、SL grant(s)において指示されたdataのリソース位置においてTB(Transport Block)を伝送し、ここで、各TBは4回伝送され、1つのSC period内で伝送可能なTBの数はSL grant(s)において割り当てられたリソースの数に依存する。図1は該伝送処理を示す図である。

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

概要

バッファ状態報告の生成方法、装置及び通信システムを提供する。該装置は、ユーザ装置(UE)に適用され、サイドリンクのバッファ状態報告(ProSeBSR)を伝送する伝送時間間隔を決定する第1決定部と、残りの構成されたサイドリンクグラントがあるか否かを判断する判断部と、該判断部の判断結果に基づいて、該バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する第2決定部と、該第2決定部により決定された該バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズに基づいて、該バッファ状態報告を生成する生成部とを含む。本発明によれば、UEがProSe BSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

目的

本発明の実施例は、UEがProSeBSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決するバッファ状態報告の生成方法、装置及び通信システムを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記判断手段は、前記伝送時間間隔を含むサイドリンク制御期間及び/又はその後続のサイドリンク制御期間についての残りの構成されたサイドリンクグラントがあるか否かを判断する、請求項1に記載の装置。

請求項3

前記判断手段は、前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔において前記構成されたサイドリンクグラントを使い切っていない場合、及び/又は前記伝送時間間隔の所在するサイドリンク制御期間の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記ユーザ装置が前記次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、及び/又は前記伝送時間間隔の所在するサイドリンク制御期間の次の次のサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記ユーザ装置が前記次の次のサイドリンク制御期間のサイドリンクグラントを復号して取得した場合、残りの構成されたサイドリンクグラントがあると判断する、請求項1に記載の装置。

請求項4

前記判断手段は、前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがなく、且つ前記伝送時間間隔の前に前記ユーザ装置が前記サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、及び/又は前記伝送時間間隔の所在するサイドリンク制御期間に構成されたサイドリンクグラントがあり、且つ前記伝送時間間隔の前に前記構成されたサイドリンクグラントを全て使い切っており、且つ前記伝送時間間隔の前に前記ユーザ装置が前記サイドリンク制御期間の後続のサイドリンク制御期間についての構成されたサイドリンクグラントを復号して取得していない場合、残りの構成されたサイドリンクグラントがないと判断する、請求項1に記載の装置。

請求項5

前記第2決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先を決定する、請求項1に記載の装置。

請求項6

前記第2決定手段は、まず、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先を決定し、そして、前記伝送時間間隔のアップリンクグラントについて前記サイドリンクのバッファ状態報告よりも高い優先順位を有するデータ若しくはMAC(媒体アクセス制御)要素を考慮した後の残りのビット数、又は前記伝送時間間隔における利用可能な付加ビットの数に基づいて、前記サイドリンクの前記バッファ状態報告に含める必要のあるサイドリンク先を決定する、請求項5に記載の装置。

請求項7

前記第2決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切ってサイドリンク上のMAC(媒体アクセス制御)PDUプロトコルデータユニット)を全て構築した後のバッファ状態に基づいて、前記サイドリンクのバッファ状態報告に含める必要のあるサイドリンク先のバッファサイズを決定する、請求項1に記載の装置。

請求項8

前記第2決定手段は、残りの構成されたサイドリンクグラントがあると前記判断手段により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するサイドリンク先に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先を決定し、残りの構成されたサイドリンクグラントを全て使い切ってサイドリンク上のMAC(媒体アクセス制御)PDU(プロトコルデータユニット)の全てを構築した後の、利用可能な伝送すべきデータを有するサイドリンク先のバッファ状態に基づいて、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズを決定する、請求項1に記載の装置。

請求項9

前記第2決定手段は、残りの構成されたサイドリンクグラントがないと前記判断手段により判断された場合、前記バッファ状態報告を伝送する伝送時間間隔内のバッファ状態に基づいて、前記バッファ状態報告に含める必要のあるサイドリンク先及びそのバッファサイズを決定する、請求項1に記載の装置。

請求項10

前記第2決定手段は、前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のMAC(媒体アクセス制御)PDU(プロトコルデータユニット)の全てを生成する第1データユニット生成モジュールと、前記伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第1決定モジュールと、をさらに含む、請求項5に記載の装置。

請求項11

前記第2決定手段は、前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のMAC(媒体アクセス制御)PDU(プロトコルデータユニット)の全てを生成する第2データユニット生成モジュールと、前記伝送時間間隔において、バッファにおけるデータ量のサイズを、前記バッファ状態報告に含める必要のあるサイドリンク先のバッファサイズとして計算する第1計算モジュールと、をさらに含む、請求項7に記載の装置。

請求項12

前記第2決定手段は、前記ユーザ装置がサイドリンクグラントを復号して取得した後、又は前記サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、前記サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、前記サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なサイドリンク上のMAC(媒体アクセス制御)PDU(プロトコルデータユニット)の全てを生成する第3データユニット生成モジュールと、前記伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第2決定モジュールと、前記伝送時間間隔において、利用可能な伝送すべきデータを有するサイドリンク先のバッファにおけるデータ量のサイズを、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズとして計算する第2計算モジュールと、をさらに含む、請求項8に記載の装置。

請求項13

前記第2決定手段は、前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のMAC(媒体アクセス制御)PDU(プロトコルデータユニット)の全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第3決定モジュール、をさらに含む、請求項5に記載の装置。

請求項14

前記第2決定手段は、前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のMAC(媒体アクセス制御)PDU(プロトコルデータユニット)の全てを除いた、バッファにおけるデータ量のサイズを、前記バッファ状態報告に含める必要のあるサイドリンク先のバッファサイズとして計算する第3計算モジュール、をさらに含む、請求項7に記載の装置。

請求項15

前記第2決定手段は、前記伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のMAC(媒体アクセス制御)PDU(プロトコルデータユニット)の全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先を、利用可能な伝送すべきデータを依然として有するサイドリンク先として決定する第4決定モジュールと、前記伝送時間間隔において、前記残りの構成されたサイドリンクグラントを全て使い切って構築されたサイドリンク上のMACPDUの全てを除いた、利用可能な伝送すべきデータを有するサイドリンク先のバッファにおけるデータ量のサイズを、前記利用可能な伝送すべきデータを有するサイドリンク先のバッファサイズとして計算する第4計算モジュールと、をさらに含む、請求項8に記載の装置。

請求項16

請求項1に記載のバッファ状態報告の生成装置を含む、ユーザ装置。

請求項17

請求項16に記載のユーザ装置を含む、通信ステム

技術分野

0001

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

背景技術

0002

現在のLTE(Long Term Evolution:ロングタームエボリューション)システムにおいて端末装置と端末装置との間の通信は無線アクセスネットワーク及びコアネットワークを介して行われる必要がある。新たなトラヒック要求の出現に伴い、ネットワークのロードを低減し、ネットワークのロードの移転を実現するために、端末装置と端末装置との間の通信は徐々に新たな研究の方向となっている。2つの端末装置の間の距離が十分に近い場合に、端末装置は相手の存在を互いに発見できるため、基地局の制御により装置と装置との間の直接通信を行うことができる。

0003

装置と装置の通信を実現するために、LTE−A(LTE−Advanced:ロング・ターム・エボリューション・アドバンスト)システムでは2つのエアインタフェースリソース割り当て方式、即ちモード1(Mode 1)及びモード2(Mode 2)が定義されている。モード1では、従来のインフラ通信モードのトラヒックのバッファ状態報告(Buffer Status Report:BSR)の報告への影響を回避するために、装置間の通信のための特別なバッファ状態報告(ProSe−BSRと称されてもよい)メカニズムが導入され、該メカニズムは主に新たなバッファ状態報告のトリガ・メカニズム、並びにバッファ状態報告のMACシグナリングフォーマット及び内容を含む。

0004

D2D(Device to Device:装置から装置)通信モードではサイドリンク制御期間(Sidelink Control Period。SC periodと略称される)の概念が定義され、該SC periodはスケジューリング制御(Scheduling Control)及びそれに対応するデータの伝送を含む時間周期を意味する。Mode 1について、D2D通信における送信側のデータ伝送の基本的な作動原理は以下の通りである。

0005

基地局があるD2DUE(User Equipment:ユーザ装置)のデータ伝送をスケジューリングすると決定した後に、基地局は、SL−RNTI(Sidelink−Radio Network Tempory Identity:サイドリンク無線ネットワーク一時識別子)によりスクランブルされたPDCCH(Physical Downlink Control Channel:物理ダウンリンク制御チャネル)を介して該UEにSL grant(s)(サイドリンクグラント)を送信し、該SL grant(s)は、該UEが伝送するSC(スケジューリング制御)の時間周波数領域リソース位置及び伝送するデータの時間周波数領域リソース位置を含む。該SL grant(s)の有効期間は1つのSC periodであり、且つそれに対応するSC periodは該SL grant(s)を伝送するサブフレームの4ms後からの次のSC periodである。SL grant(s)を受信した後に、UEは、該SL grant(s)に対応するSC period内で、まずSL grant(s)において指示されたSCのリソース位置においてSCを2回伝送し、そして、SL grant(s)において指示されたdataのリソース位置においてTB(Transport Block)を伝送し、ここで、各TBは4回伝送され、1つのSC period内で伝送可能なTBの数はSL grant(s)において割り当てられたリソースの数に依存する。図1は該伝送処理を示す図である。

0006

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

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

0007

しかし、UE(User Equipment:ユーザ装置。ユーザとも称される)がインフラの通信モード及びD2D(Device−to−Device:装置から装置)の通信モード両方において作動する場合は、同一のサブフレームにおいて、UEはアップリンクデータ伝送及びD2Dのデータ送信を同時に行うことができない。よって、あるTTI(Transmission Time Interval:伝送時間間隔)では、UEがUL grant(Uplink grant:アップリンクグラント)を用いてProSeBSR(サイドリンクバッファ状態報告)を送信する場合、このTTIにおいて、UEは必ずSidelink(SL:サイドリンク。即ち、D2D通信モードにおける装置間のリンク)上のMACPDU(Media Access Control − Protocol Data Unit:媒体アクセス制御プロトコルデータユニット)を送信できない。従来のインフラ通信モードにおけるBSRのbuffer size(バッファサイズ)の決定方法に従ってProSe BSRのbuffer sizeを決定すると、即ちあるTTIにおいてBSRを報告する必要がある場合に該BSRにおけるbuffer sizeはこのTTI内の全てのMAC PDUが全て構築されたバッファ状態を反映すると、UEはProSe BSRを送信するTTI内でSL MAC PDUを構築できないため、現在のUEはbuffer sizeを決定できなくなる。具体的には、図2に示すように、アップリンク伝送がTTIn+4において発生するため、このTTIn+4においてSL MAC PDU(サイドリンク上の媒体アクセス制御−プロトコルデータユニット)を構築できない。

0008

また、ProSeBSRを伝送するTTIでは、報告されたProSe BSRに含まれるProSe Destination(サイドリンク先又はサイドリンクターゲット)の数を決定する際に、ProSe BSRを伝送するTTIをタイミングとしてどのProSe Destinationが伝送すべきデータを有するかを判断すると、SL grant(s)(サイドリンクグラント)が1つのTTIについてのものではなく、1つのSC period(Sidelink Control Period:サイドリンク制御期間)についてのものであるため、基地局に伝送すべきデータを本当に有するProSe Destinationを報告できない。同様に、ProSe BSRにおけるbuffer sizeを決定する際に、ProSe BSRを伝送するTTIをタイミングとしてbuffer sizeを決定すると、buffer status(バッファ状態)を正確に反映できない。

0009

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

課題を解決するための手段

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

本発明の実施例の有益な効果としては、本発明の実施例の方法、装置及びシステムによれば、サイドリンクのバッファ状態報告(ProSeBSR)を送信する際に、UEはProSe BSRに含める必要のある利用可能な伝送すべきデータを有するProSe Destinationを合理的に決定できると共に、UEはProSe BSRに含まれている各ProSe Destinationのバッファのサイズを合理的に決定できるため、UEがProSe BSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

0017

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

0018

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

0019

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

図面の簡単な説明

0020

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

実施例

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

ステップ301において、ユーザ装置は、まずProSeBSR(サイドリンクのバッファ状態報告)を伝送するTTI(伝送時間間隔)を決定し、ユーザ装置は決定された該TTIにおいて該ProSe BSRを伝送する。ここで、ユーザ装置は、基地局により送信されたUL grantを含むPDCCHを受信した後に該TTIを決定してもよいし、他のポリシーを参照して該TTIを決定してもよい。本実施例では、ステップ301においてProSe BSRを伝送するTTIを決定した後に、該ユーザ装置は、ステップ302〜303において、該ProSe BSRに含める必要のあるサイドリンク先(ProSe Destination)及びそのバッファサイズ(buffer size)を決定し、ステップ302において該ProSe BSRを生成することで、ステップ301において決定されたTTIにおいて該ProSe BSRを伝送できる。

0028

ステップ302において、ユーザ装置がProSeBSRを伝送するTTIを決定した後に、該TTI又はその前に、残りの構成されたSL grant(s)があるか否かを判断してもよい。ここで、該ユーザ装置は、ProSe BSRを伝送するTTIの所在するSC periodについて残りの構成されたSL grant(s)があるか否かを判断してもよく、即ちProSe BSRを伝送するTTIを含むSC periodについてのSL grnat(s)があるか否かを判断してもよい。或いは、ProSe BSRを伝送するTTIの所在するSC periodの後続のSC periodについて残りの構成されたSL grant(s)があるか否かを判断してもよく、即ちProSe BSRを伝送するTTIを含むSC periodの後続のSC periodについてのSL grnat(s)があるか否かを判断してもよい。或いは、ProSe BSRを伝送するTTIの所在するSC period及びその後続のSC period両方について残りの構成されたSL grant(s)があるか否かを判断してもよく、即ちProSe BSRを伝送するTTIを含むSC period及びその後続のSC periodについてのSL grnat(s)があるか否かを判断してもよい。

0029

1つの態様では、ProSeBSRを伝送するTTIの所在するSC periodに構成されたSL grant(s)があり、且つ該ProSe BSRを伝送するTTIにおいて該構成されたSL grant(s)を使い切っていない場合、残りの構成されたSL grant(s)があると判断する。

0030

図4図5はこの態様の2つの応用シナリオを示す図である。

0031

図4に示すように、このシナリオでは、ProSeBSRを伝送するTTIの所在するSC periodはSC period 1であり、図4から分かるように、該SC period 1に構成されたSL grant(s)があり、且つProSe BSRを伝送するTTIにおいて該SL grant(s)を使い切っておらず、この場合は、残りの構成されたSL grant(s)があると判断する。さらに、図4に示すシナリオでは、SC period 1の後続のSC period、例えば次のSC period(SC period 2)及び次の次のSC period(SC period 3)にはいずれも構成されたSL grant(s)がなく、即ち、ユーザ装置は、ProSe BSRを伝送するTTI又はその前に、SC period 2及びSC period 3のSL grant(s)を復号して取得していない。

0032

図5に示すように、このシナリオでは、図4のシナリオと異なって、ProSeBSRを伝送するTTIの前に、該ユーザ装置はSC period 2のSL grant(s)を既に復号して取得したが、SC period 3のSL grant(s)を復号して取得していない。このシナリオでも、残りの構成されたSL grant(s)があると判断する。

0033

もう1つの態様では、ProSeBSRを伝送するTTIの所在するSC periodの次のSC periodに構成されたSL grantがあり、且つProSe BSRを伝送するTTIの前に該ユーザ装置が該次のSC periodのSL grant(s)を復号して取得した場合、残りの構成されたSL grant(s)があると判断する。

0034

図6図9は該態様の4つの応用シナリオを示す図である。

0035

図6に示すように、このシナリオでは、ProSeBSRを伝送するTTIの所在するSC periodはSC period 1であり、SC period 2に構成されたSL grant(s)があり、且つProSe BSRを伝送するTTIの前に該ユーザ装置がSC period 2のSL grant(s)を復号して取得しており、この場合は、残りの構成されたSL grant(s)があると判断する。さらに、図6に示すシナリオでは、ProSe BSRを伝送するTTIの所在するSC period 1に構成されたSL grant(s)がなく、且つSC period 3にも構成されたSL grant(s)がなく、即ち、ProSe BSRを伝送するTTIの前に該ユーザ装置は、SC period 3のSL grant(s)を復号して取得していない。

0036

図7に示すように、このシナリオでは、図6のシナリオと異なって、SC period 3にも構成されたSL grant(s)があり、即ちProSeBSRを伝送するTTIの前に、該ユーザ装置はSC period 3のSL grant(s)を既に復号して取得した。このシナリオでも、残りの構成されたSL grant(s)があると判断する。

0037

図8に示すように、このシナリオでは、図6のシナリオと異なって、ProSeBSRを伝送するTTIの所在するSC period 1に構成されたSL grant(s)があるが、ProSe BSRを伝送するTTI又は該TTIの前に、該SL grant(s)を使い切った。このシナリオでも、残りの構成されたSL grant(s)があると判断する。

0038

図9に示すように、このシナリオでは、図7のシナリオと異なって、ProSeBSRを伝送するTTIの所在するSC period 1に構成されたSL grant(s)があるが、ProSe BSRを伝送するTTI又は該TTIの前に、該SL grant(s)を使い切った。このシナリオでも、残りの構成されたSL grant(s)があると判断する。

0039

もう1つの態様では、ProSeBSRを伝送するTTIの所在するSC periodの次の次のSC periodに構成されたSL grant(s)があり、且つProSe BSRを伝送するTTIの前に該ユーザ装置が該次の次のSC periodのSL grant(s)を復号して取得した場合、残りの構成されたSL grant(s)があると判断する。

0040

図10図11はこの態様の2つの応用シナリオを示す図である。

0041

図10に示すように、このシナリオでは、ProSeBSRを伝送するTTIの所在するSC periodはSC period 1であり、該SC period 1の次の次のSC period(SC period 3)に構成されたSL grant(s)があり、且つProSe BSRを伝送するTTIの前に該ユーザ装置がSC period 3のSL grant(s)を復号して取得した場合、残りの構成されたSL grant(s)があると判断する。さらに、図10に示すシナリオでは、ProSe BSRを伝送するTTIの所在するSC period 1に構成されたSL grant(s)がなく、該SC period 1の次のSC period(SC period 2)にも構成されたSL grant(s)がなく、即ち、ユーザ装置がProSe BSRを伝送するTTI又はその前にSC period 2のSL grant(s)を復号して取得していない。

0042

図11に示すように、このシナリオでは、図10のシナリオと異なって、ProSeBSRを伝送するTTIの所在するSC period 1に構成されたSL grant(s)があるが、ProSe BSRを伝送するTTI又は該TTIの前に、該SL grant(s)を使い切った。このシナリオでも、残りの構成されたSL grant(s)があると判断する。

0043

もう1つの態様では、ProSeBSRを伝送するTTIの所在するSC periodに構成されたSL grant(s)がなく、且つProSe BSRを伝送するTTIの前に該ユーザ装置が該SC periodの後続のSC periodについての構成されたSL grant(s)を復号して取得していない場合、残りの構成されたSL grant(s)がないと判断する。

0044

図12は該態様の応用シナリオを示す図である。図12に示すように、このシナリオでは、ProSeBSRを伝送するTTIの所在するSC periodはSC period 1であり、該SC period 1に構成されたSL grant(s)がなく、該SC period 1の次のSC period(SC period 2)及び次の次のSC period(SC period 3)にいずれも構成されたSL grant(s)がなく、即ちProSe BSRを伝送するTTIの前に該ユーザ装置がSC period 1の後続のSC period 2及びSC period 3についての構成されたSL grant(s)を復号して取得していない。このシナリオでは、残りの構成されたSL grant(s)がないと判断する。

0045

もう1つの態様では、ProSeBSRを伝送するTTIの所在するSC periodに構成されたSL grant(s)があり、且つProSe BSRを伝送するTTIの前に該構成されたSL grant(s)を全て使い切っており、且つProSe BSRを伝送するTTIの前に該ユーザ装置が該SC periodの後続のSC periodについての構成されたSL grant(s)を復号して取得していない場合、残りの構成されたSL grant(s)がないと判断する。

0046

図13は該態様の応用シナリオを示す図である。図13に示すように、このシナリオでは、図12のシナリオと異なって、ProSeBSRを伝送するTTIの所在するSC period 1に構成されたSL grant(s)があるが、ProSe BSRを伝送するTTI又は該TTIの前に、該SL grant(s)を使い切った。このシナリオでも、残りの構成されたSL grant(s)がないと判断する。

0047

ステップ303において、ユーザ装置は、ステップ302の判断結果に基づいて、該ProSeBSRに含める必要のあるProSe Destination及びそのbuffer sizeを決定してもよい。

0048

ステップ303において、ステップ302の判断結果として残りの構成されたSL grant(s)がない場合、即ち図12及び図13に示すシナリオでは、ユーザ装置は、ProSeBSRを伝送するTTI内のバッファ状態に基づいて、該ProSe BSRに含める必要のあるProSe Destination及びそのbuffer sizeを決定してもよい。即ち、ユーザ装置は、ProSe BSRを伝送するTTIの時点に利用可能な伝送すべきデータを有するProSe Destinationのみを考慮し、この際に、該ProSe BSRは、該ProSe BSRを伝送するTTI時点のバッファ状態を反映する。

0049

具体的には、UEがTTIについてのトリガされたProSeBSRを伝送可能なUL grantを有する場合、UEは、現在のTTI時点においてどのProSe Destinationに対応する論理チャネルが利用可能な伝送すべきデータを有するかを決定する。そして、通常のProSe BSR又は周期的なProSe BSRについて、UEは、UL grantのサイズ及び前に決定された利用可能な伝送すべきデータを有するProSe Destinationの数に基づいて、利用可能な伝送すべきデータを有するProSe Destinationの全てを含むProSe BSRを報告するか、それとも利用可能な伝送すべきデータを有するProSe Destinationの一部のみを含むTruncated ProSe BSRを報告するかを決定する。Padding ProSe BSRについて、UEは、利用可能なPadding bit(付加ビット)の数及び前に決定された利用可能な伝送すべきデータを有するProSe Destinationの数に基づいて、利用可能な伝送すべきデータを有するProSe Destinationの全てを含むProSe BSRを報告するか、それとも利用可能な伝送すべきデータを有するProSe Destinationの一部のみを含むTruncated ProSe BSRを報告するかを決定する。

0050

ここで、ProSeBSR又はTruncated ProSe BSRに含める必要のあるProSe Destinationについて、UEは、ProSe BSRを伝送するTTI時点に対応するバッファにおけるデータ量を決定し、該データ量及び参照文献[TS36.321, Medium Access Control (MAC) protocol specification, v
12.2.0]におけるバッファ状態報告テーブルに基づいて各ProSe Destinationに対応するbuffer sizeを決定する。

0051

これによって、UEがProSeBSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

0052

ステップ303において、ステップ302の判断結果として残りの構成されたSL grant(s)がある場合、即ち図4図11に示すシナリオでは、ユーザ装置は、残りの構成されたSL grant(s)を全て使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationに基づいて、該ProSeBSRに含める必要のある、利用可能な伝送すべきデータを有するProSe Destinationを決定する。

0053

例えば、ユーザ装置は、まず、残りの構成されたSL grant(s)を使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationを決定し、そして、ProSeBSRを伝送するTTIのUL grant(アップリンクグラント)について該ProSe BSRよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素(MAC CE:Medium Access Control Control Element)を考慮した後の残りのビット数、又はProSe BSRを伝送するTTIにおける利用可能な付加ビットの数に基づいて、該ProSe BSRに含める必要のある、利用可能な伝送すべきデータを有するProSe Destinationを決定する。ここで、MAC CEは例えばBSR MAC CEである。

0054

ここで、利用可能な伝送すべきデータを有するProSe Destinationの決定方法は以下の通りである。

0055

態様1では、ユーザ装置がSL grant(s)を復号して取得した後、又は該SL grant(s)に対応するSC periodの開始時刻において、ユーザ装置は、該SL grant(s)において割り当てられたデータを伝送するリソースに基づいて、該SL grant(s)に対応するSC period全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該SL grant(s)に対応するSC period内に伝送可能なMACPDUの全てを生成してもよい。これによって、ユーザ装置は、ProSeBSRを伝送するTTIにおいて、どのProSe Destinationに対応する論理チャネルが利用可能な伝送すべきデータを有するかを直接決定でき、即ちバッファにおける利用可能な伝送すべきデータを依然として有するProSe Destinationを決定できる。

0056

態様2では、ユーザ装置がSL grant(s)を復号して取得した後に、ユーザ装置は、該SL grant(s)において割り当てられたデータを伝送する各TTIにおいて、該TTI内で伝送可能な対応するSL MACPDUを構築する。これによって、ユーザ装置は、ProSeBSRを伝送するTTIにおいて、仮に全てのSL grant(s)において割り当てられた残りのデータ伝送用のリソースを全て使い切った後で構築可能な全てのSL MAC PDUの数及びサイズを計算し、これらのSL MAC PDUを除いた後に、どのProSe Destinationに対応する論理チャネルが利用可能な伝送すべきデータを有するかを決定する。

0057

ここで、該ProSeBSRに含める必要のある利用可能な伝送すべきデータを有するProSe Destinationの決定方法は以下の通りである。

0058

具体的には、通常のProSeBSR又は周期的なProSe BSRについて、UEは、UL grantにおいて該ProSeよりも高い優先順位を有するデータ若しくは媒体アクセス制御要素(MAC CE:Medium Access Control Control Element)を考慮した後の残りのビット数、又は前に決定された利用可能な伝送すべきデータを有するProSe Destinationの数に基づいて、利用可能な伝送すべきデータを有するProSe Destinationの全てを含むProSe BSRを報告するか、それとも利用可能な伝送すべきデータを有するProSe Destinationの一部のみを含むTruncated ProSe BSRを報告するかを決定する。Padding ProSe BSRについて、UEは、利用可能なPadding bitの数及び前に決定された利用可能な伝送すべきデータを有するProSe Destinationの数に基づいて、利用可能な伝送すべきデータを有するProSe Destinationの全てを含むProSe BSRを報告するか、それとも利用可能な伝送すべきデータを有するProSe Destinationの一部のみを含むTruncated ProSe BSRを報告するかを決定する。

0059

ステップ303において、ステップ302の判断結果として残りの構成されたSL grant(s)がある場合、即ち図4図11に示すシナリオでは、ユーザ装置は、残りの構成されたSL grant(s)を全て使い切ってSL MACPDUを全て構築した後のバッファ状態に基づいて、各ProSe Destinationのbuffer sizeを決定してもよい。即ち、ユーザ装置は、残りの構成されたSL grant(s)を全て使い切ってSL MAC PDUを全て構築した後のバッファ状態を、各ProSe Destinationのbuffer sizeとして決定する。

0060

具体的には、ProSeBSR又はTruncated ProSe BSRに含める必要のあるProSe Destinationについて、UEは、残りの構成されたSL grant(s)を全て使い切ってSL MACPDUを全て構築した後のそれに対応するバッファにおけるデータ量を、該ProSe Destinationのbuffer sizeとして決定する。

0061

態様3では、態様1と同様に、ユーザ装置は、まずSL MACPDUを構築し、そしてProSeBSRを伝送するTTIにおいて、バッファにおけるデータ量のサイズを該buffer sizeとして計算する。

0062

態様4では、態様2と同様に、ユーザ装置は、ProSeBSRを伝送するTTIにおいて、仮に残りの構成されたSL grant(s)を全て使い切って構築可能なSL MACPDUの全てを除いたバッファにおけるデータ量のサイズを該buffer sizeとして計算する。

0063

ステップ303において、ステップ302の判断結果として残りの構成されたSL grant(s)がある場合、即ち図4図11に示すシナリオでは、ユーザ装置は、残りの構成されたSL grant(s)を全て使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationに基づいて、該ProSeBSRに含める必要のあるProSe Destinationを決定してもよい。具体的には上述した通り、ここでその説明を省略する。そして、残りの構成されたSL grant(s)を全て使い切ってSL MACPDUの全てを構築した後のバッファ状態に基づいて、各ProSe Destinationのbuffer sizeを決定してもよい。ここで、該buffer sizeは、前に決定されたProSe BSRに含める必要のある利用可能な伝送すべきデータを有するProSe Destinationに対応する。即ち、該態様では、ユーザ装置は、利用可能な伝送すべきデータを有するProSe Destinationの、残りの構成されたSL grant(s)を全て使い切ってSL MAC PDUの全てを構築した後のバッファ状態を、buffer sizeとして決定してもよい。

0064

態様5では、態様1と同様に、ユーザ装置は、まずSL MACPDUを構築し、そして、ProSeBSRを伝送するTTIにおいて、バッファにおける利用可能な伝送すべきデータを依然として有するProSe Destinationに基づいて、該バッファ状態報告に含める必要のある利用可能な伝送すべきデータを有するProSe Destinationを決定し、ProSe BSRを伝送するTTIにおいて、利用可能な伝送すべきデータを有するProSe Destinationのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するProSe Destinationのbuffer sizeとして計算する。

0065

態様6では、態様2と同様に、ユーザ装置は、ProSeBSRを伝送するTTIにおいて、仮に残りの構成されたサイドリンクグラントを全て使い切って構築可能な全てのSL MACPDUを除いた利用可能な伝送すべきデータを有するProSe Destinationに基づいて、該バッファ状態報告に含める必要のあるProSe Destinationを決定し、ProSe BSRを伝送するTTIにおいて、利用可能な伝送すべきデータを有するProSe Destinationの、該残りの構成されたサイドリンクグラントを使い切って構築可能な全てのSL MAC PDUを除いたバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するProSe Destinationのbuffer sizeとして計算する。

0066

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

0067

ステップ1401:ProSeBSRを伝送するTTIを決定する。

0068

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

0069

ステップ1402:残りの構成されたSL grant(s)があるか否かを判断し、ある場合、ステップ1403を実行し、そうでない場合、ステップ1405を実行する。

0070

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

0071

ステップ1403:残りの構成されたSL grant(s)を全て使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationに基づいて、該ProSeBSRに含める必要のあるProSe Destinationを決定する。

0072

ここで、まず、残りの構成されたSL grant(s)を使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationを決定し、そして、ProSeBSRを伝送するTTIのアップリンクグラントについてのビット数又はProSe BSRを伝送するTTIにおける利用可能な付加ビットの数に基づいて、該ProSe BSRに含める必要のある、利用可能な伝送すべきデータを有するProSe Destinationの数を決定してもよい。

0073

ここで、ステップ1403は、ステップ303におけるステップ302の判断結果が残りの構成されたSL grant(s)があることである場合にProSeBSRに含める必要のあるProSe Destinationの決定処理に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。

0074

ステップ1404:残りの構成されたSL grant(s)を全て使い切ってSL MACPDUを全て構築した後のバッファ状態に基づいて、該ProSeBSRに含める必要のあるProSe Destinationのbuffer sizeを決定する。

0075

ここで、ステップ1404は、ステップ303におけるステップ302の判断結果が残りの構成されたSL grant(s)があることである場合にProSeBSRに含める必要のあるProSe Destinationのbuffer sizeの決定処理に対応し、具体的な処理プロセスは上述した通りであり、ここでその説明を省略する。

0076

ここで、本実施例ではステップ1403及びステップ1404の実行順序を限定せず、例えば、ステップ1403を実行した後にステップ1404を実行してもよいし、ステップ1404を実行した後にステップ1403を実行してもよいし、ステップ1403及びステップ1404を同時に実行してもよい。ここで、ステップ1403を実行した後にステップ1404を実行する場合は、ステップ1404は、ProSeBSRに含めることができる利用可能な伝送すべきデータを有するProSe Destinationのbuffer sizeについてのものである。

0077

ステップ1405:ProSeBSRを伝送するTTI内のバッファ状態に基づいて、該ProSe BSRに含める必要のあるProSe Destination及び各ProSe Destinationのバッファサイズを決定する。

0078

ここで、ステップ1405は、ステップ303におけるステップ302の判断結果が残りの構成されたSL grant(s)がないことである場合のユーザ装置の処理プロセスに対応し、具体的には上述した通りであり、ここでその説明を省略する。

0079

ステップ1406:該ProSeBSRに含める必要のあるProSe Destination及びそのbuffer sizeに基づいて、該ProSe BSRを生成する。

0080

これによって、ユーザ装置は、ProSeBSRを伝送するTTIにおいて、サイドリンクのバッファ状態を反映したProSe BSRを伝送でき、本願が解決しようとする課題を解決した。

0081

本発明の実施例の方法によれば、ProSeBSRを送信する際に、UEはProSe BSRに含める必要のある利用可能な伝送すべきデータを有するProSe Destinationを合理的に決定できると共に、UEはProSe BSRに含まれている各ProSe Destinationのバッファのサイズを合理的に決定できるため、UEがProSe BSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

0082

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

0083

ステップ1501:ユーザ装置は、ProSeBSRを伝送するTTIを決定する。

0084

ステップ1502:ユーザ装置は、該TTI内のバッファ状態に基づいて、ProSeBSRに含める必要のあるProSe Destination及びそのbuffer sizeを決定する。

0085

ステップ1503:ユーザ装置は、該ProSeBSRに含める必要のあるProSe Destination及びそのbuffer sizeに基づいて、該ProSe BSRを生成する。

0086

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

0087

この態様では、ユーザ装置は、ProSeBSRを伝送するTTIの時点に利用可能な伝送すべきデータを有するProSe Destinationのみを考慮し、この際に、該ProSe BSRは、該ProSe BSRを伝送するTTI時点のバッファ状態を反映する。これによって、ユーザ装置は、ProSe BSRを報告する際に、ProSe BSRにおいてサイドリンクのバッファ状態を正しく反映でき、本願が解決しようとする課題を解決した。

0088

また、この態様は上記の図4図13の10個のシナリオにも同様に適用できる。即ち、上記図4図13の何れかのシナリオでも、図15の方法を用いてProSeBSRを生成してもよい。

0089

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

0090

ステップ1601:ユーザ装置は、ProSeBSRを伝送するTTIを決定する。

0091

ステップ1602:該TTIの所在するSC periodについてのSL grant(s)があるか否かを判断し、ない場合(図12図10図6図7のシナリオに対応する)、ステップ1603を実行し、そうでない場合(図13図11図8図9図4図5のシナリオに対応する)、ステップ1608を実行する。

0092

ステップ1603:該TTIの所在するSC periodの次のSC periodについてのSL grant(s)があるか否かを判断し、ない場合(図12及び図10のシナリオに対応する)、ステップ1604を実行し、そうでない場合(図6及び図7のシナリオに対応する)、ステップ1605を実行する。

0093

ステップ1604:該TTIの所在するSC periodの次の次のSC periodについてのSL grant(s)があるか否かを判断し、ある場合(図10のシナリオに対応する)、ステップ1605を実行し、そうでない場合(図12のシナリオに対応する)、ステップ1607を実行する。

0094

ステップ1605:残りの構成されたSL grant(s)を全て使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationに基づいて、該ProSeBSRに含める必要のあるProSe Destinationを決定する。

0095

ステップ1606:残りの構成されたSL grant(s)を全て使い切ってSL MACPDUを全て構築した後のバッファ状態に基づいて、該ProSeBSRに含める必要のあるProSe Destinationのバッファサイズを決定する。

0096

ステップ1607:該TTI内のバッファ状態に基づいて、該ProSeBSRに含める必要のあるProSe Destination及びそのbuffer sizeを決定する。

0097

ステップ1608:該TTIの所在するSC periodのSL grant(s)を使い切ったか否かを判断し、使い切った場合(図13図11図8図9のシナリオに対応する)、ステップ1609を実行し、そうでない場合(図4図5のシナリオに対応する)、ステップ1605を実行する。

0098

ステップ1609:該TTIの所在するSC periodの次のSC periodについてのSL grant(s)があるか否かを判断し、ある場合(図8図9のシナリオに対応する)、ステップ1605を実行し、そうでない場合(図13図11のシナリオに対応する)、ステップ1610を実行する。

0099

ステップ1610:該TTIの所在するSC periodの次の次のSC periodについてのSL grant(s)があるか否かを判断し、ある場合(図11のシナリオに対応する)、ステップ1605を実行し、そうでない場合(図13のシナリオに対応する)、ステップ1607を実行する。

0100

ステップ1611:ユーザ装置は、該ProSeBSRに含める必要のあるProSe Destination及びそのbuffer sizeに基づいて、該ProSe BSRを生成する。

0101

ここで、ステップ1605〜1606及び1607の態様は上記ステップ1403〜1404及び1405の態様と同様であり、具体的には上述した通り、ここでその説明を省略する。

0102

この態様では、ユーザ装置は、残りの構成されたSL grant(s)があるか否かのみを考慮し、残りの構成されたSL grant(s)があれば、該残りの構成されたSL grant(s)が、ProSeBSRを伝送するTTIに対応するSC period内に位置し、該SC periodの次のSC period内に位置し、或いは該SC periodの次の次のSC period内に位置するにも関わらず、ステップ1605〜1606の方法を用いて該ProSe BSRに含める必要のあるProSe Destination及びそのbuffer sizeを決定してもよい。そうでない場合、ステップ1607の方法を用いて該ProSe BSRに含める必要のあるProSe Destination及びそのbuffer sizeを決定してもよい。これによって、ユーザ装置は、ProSe BSRを報告する際に、ProSe BSRにおいてサイドリンクのバッファ状態を正しく反映でき、本願が解決しようとする課題を解決した。

0103

本実施例では、上記残りの構成されたSL grant(s)(Remaining configured SL grant(s))は、利用可能なSL grant(s)(available SL grant(s))と定義されてもよいし、有効なSL grant(s)(Valid SL grant(s))等と定義されてもよいが、本実施例はこれらに限定されない。また、上記残りの構成されたSL grant(s)は、ProSeBSRを伝送するTTIの所在するSC period及び/又はその後続のSC periodのSL grant(s)に限定されてもよい。

0104

本実施例の方法によれば、UEがProSeBSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

0105

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

0106

図17は該装置の構成を示す図である。図17に示すように、該バッファ状態報告の生成装置1700は、第1決定部1701、判断部1702、第2決定部1703及び生成部1704を含む。

0107

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

0108

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

0109

本実施例では、第2決定部1703は、判断部1702の判断結果に基づいて、該バッファ状態報告に含める必要のあるProSe Destination及びそのbuffer sizeを決定する。

0110

本実施例では、生成部1704は、第2決定部1703により決定された該バッファ状態報告に含める必要のあるProSe Destination及びそのbuffer sizeに基づいて、該バッファ状態報告を生成する。

0111

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

0112

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

0113

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

0114

1つの態様では、第2決定部1703は、残りの構成されたサイドリンクグラントがあると判断部1702により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationに基づいて、該バッファ状態報告に含める必要のあるProSe Destinationを決定する。

0115

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

0116

ここで、好ましくは、図18に示すように、第2決定部1703は、第1データユニット生成モジュール1801及び第1決定モジュール1802を含んでもよい。第1データユニット生成モジュール1801は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なSL MACPDUの全てを生成する。第1決定モジュール1802は、該伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するProSe Destinationを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationとして決定する。

0117

ここで、好ましくは、図19に示すように、第2決定部1703は第3決定モジュール1901を含んでもよい。第3決定モジュール1901は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたSL MACPDUの全てを除いた、利用可能な伝送すべきデータを有するProSe Destinationを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationとして決定する。

0118

1つの態様では、第2決定部1703は、残りの構成されたサイドリンクグラントがあると判断部1702により判断された場合、残りの構成されたサイドリンクグラントを全て使い切ってSL MACPDUを全て構築した後のバッファ状態を、該ProSeBSRに含める必要のあるProSe Destinationのbuffer sizeとして決定する。

0119

ここで、好ましくは、図20に示すように、第2決定部1703は、第2データユニット生成モジュール2001及び第1決定モジュール2002を含む。第2データユニット生成モジュール2001は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なSL MACPDUの全てを生成する。第1計算モジュール2002は、該伝送時間間隔において、バッファにおけるデータ量のサイズを、ProSeBSRに含める必要のあるProSe Destinationのbuffer sizeとして計算する。

0120

ここで、好ましくは、図21に示すように、第2決定部1703は第3計算モジュール2101を含む。第3計算モジュール2101は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたSL MACPDUの全てを除いた、バッファにおけるデータ量のサイズを、ProSeBSRに含める必要のあるProSe Destinationのbuffer sizeとして計算する。

0121

上記の態様では、図18の第2決定部と図20の第2決定部を併合してもよく、即ち第2決定部は、第1データユニット生成モジュール1801、第1決定モジュール1802、第2データユニット生成モジュール2001及び第1計算モジュール2002を同時に有してもよい。第1データユニット生成モジュール1801、第1決定モジュール1802によりProSeBSRに含める必要のあるProSe Destinationを決定し、第2データユニット生成モジュール2001及び第1計算モジュール2002によりProSe BSRに含める必要のあるProSe Destinationのbuffer sizeを決定してもよい。ここで、第1データユニット生成モジュール1801と第2データユニット生成モジュール2001の機能は同様であり、1つのモジュールに併合してもよい。同様に、図19の第2決定部と図21の第2決定部を併合してもよい。

0122

1つの態様では、第2決定部1703は、残りの構成されたサイドリンクグラントがあると判断部1702により判断された場合、残りの構成されたサイドリンクグラントを全て使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationに基づいて、該バッファ状態報告に含める必要のあるProSe Destinationを決定し、残りの構成されたサイドリンクグラントを全て使い切ってSL MACPDUの全てを構築した後の、利用可能な伝送すべきデータを有するProSe Destinationのバッファ状態に基づいて、該利用可能な伝送すべきデータを有するProSe Destinationのbuffer sizeを決定する。

0123

ここで、好ましくは、図22に示すように、第2決定部1703は、第3データユニット生成モジュール2201、第2決定モジュール2202及び第2計算モジュール2203を含む。第3データユニット生成モジュール2201は、該ユーザ装置がサイドリンクグラントを復号して取得した後、又は該サイドリンクグラントに対応するサイドリンク制御期間の開始時刻において、該サイドリンクグラントにおいて割り当てられたデータを伝送するリソースに基づいて、サイドリンクグラントに対応するサイドリンク制御期間全体内に伝送可能なデータのサイズを決定し、伝送可能なデータのサイズに基づいて、該サイドリンクグラントに対応するサイドリンク制御期間内に伝送可能なSL MACPDUの全てを生成する。第2決定モジュール2202は、該伝送時間間隔において、バッファにおける利用可能な伝送すべきデータを依然として有するProSe Destinationを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationとして決定する。第2計算モジュール2203は、該伝送時間間隔において、利用可能な伝送すべきデータを有するProSe Destinationのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するProSe Destinationのbuffer sizeとして計算する。

0124

ここで、好ましくは、図23に示すように、第2決定部1703は、第4決定モジュール2301及び第4計算モジュール2302を含む。第4決定モジュール2301は、該伝送時間間隔において、仮に残りの構成されたサイドリンクグラントを全て使い切って構築されたSL MACPDUの全てを除いた、利用可能な伝送すべきデータを有するProSe Destinationを、残りの構成されたサイドリンクグラントを使い切った後に利用可能な伝送すべきデータを依然として有するProSe Destinationとして決定する。第4計算モジュール2302は、該伝送時間間隔において、該残りの構成されたサイドリンクグラントを全て使い切って構築されたSL MAC PDUの全てを除いた、利用可能な伝送すべきデータを有するProSe Destinationのバッファにおけるデータ量のサイズを、該利用可能な伝送すべきデータを有するProSe Destinationのbuffer sizeとして計算する。

0125

1つの態様では、第2決定部1703は、残りの構成されたサイドリンクグラントがないと判断部1702により判断された場合、該バッファ状態報告を伝送する伝送時間間隔内のバッファ状態に基づいて、該バッファ状態報告に含める必要のあるProSe Destination及びそのbuffer sizeを決定する。

0126

本実施例の装置によれば、サイドリンクのバッファ状態報告(ProSeBSR)を送信する際に、UEはProSe BSRに含める必要のある利用可能な伝送すべきデータを有するProSe Destinationを合理的に決定できると共に、UEはProSe BSRに含まれている各ProSe Destinationのバッファのサイズを合理的に決定できるため、UEがProSe BSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

0127

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

0128

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

0129

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

0130

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

0131

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

0132

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

0133

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

0134

本実施例のユーザ装置によれば、サイドリンクのバッファ状態報告(ProSeBSR)を送信する際に、UEはProSe BSRに含める必要のある利用可能な伝送すべきデータを有するProSe Destinationを合理的に決定できると共に、UEはProSe BSRに含まれている各ProSe Destinationのバッファのサイズを合理的に決定できるため、UEがProSe BSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

0135

<実施例4>
本発明の実施例は通信システムをさらに提供し、図25は該通信システムのトポロジ構成を示す図である。図25に示すように、通信システム2500はユーザ装置2501及び基地局2502を含む。

0136

ここで、基地局2502は、適切なタイミングでユーザ装置2501にSL grant(s)を含むPDCCH及びUL grantを含むPDCCHを送信する。

0137

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

0138

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

0139

本実施例のシステムによれば、サイドリンクのバッファ状態報告(ProSeBSR)を送信する際に、UEはProSe BSRに含める必要のある利用可能な伝送すべきデータを有するProSe Destinationを合理的に決定できると共に、UEはProSe BSRに含まれている各ProSe Destinationのバッファのサイズを合理的に決定できるため、UEがProSe BSRを報告する際にProSe BSRにおいてサイドリンクのバッファ状態を正確に反映できないという問題を解決した。

0140

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

0141

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

0142

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

0143

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ