IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士通株式会社の特許一覧

特許7310959バッファ状態報告の処理方法、装置及び通信システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-10
(45)【発行日】2023-07-19
(54)【発明の名称】バッファ状態報告の処理方法、装置及び通信システム
(51)【国際特許分類】
   H04W 72/121 20230101AFI20230711BHJP
   H04W 72/25 20230101ALI20230711BHJP
【FI】
H04W72/121
H04W72/25
【請求項の数】 3
(21)【出願番号】P 2022049434
(22)【出願日】2022-03-25
(62)【分割の表示】P 2019019559の分割
【原出願日】2015-01-26
(65)【公開番号】P2022075975
(43)【公開日】2022-05-18
【審査請求日】2022-03-25
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(72)【発明者】
【氏名】シュイ・ハイボ
(72)【発明者】
【氏名】ウ・リエヌハイ
【審査官】桑江 晃
(56)【参考文献】
【文献】LG Electronics Inc.,BSR cancellation for ProSe communication[online], 3GPP TSG-RAN WG2#88 R2-145039,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_88/Docs/R2-145039.zip>,2014年11月21日,1-2頁
【文献】ASUSTeK,Discussion on ProSe BSR and SR cancellation[online], 3GPP TSG-RAN WG2#88 R2-145066,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_88/Docs/R2-145066.zip>,2014年11月21日,1-3頁
【文献】Huawei, HiSilicon,ProSe-BSR Triggering and Cancelling Mechanisms and Text Proposals[online], 3GPP TSG-RAN WG2#87bis R2-144407,インターネット<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_87bis/Docs/R2-144407.zip>,2014年10月10日,1-6頁
(58)【調査した分野】(Int.Cl.,DB名)
H04W 4/00 - 99/00
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1,4
(57)【特許請求の範囲】
【請求項1】
ユーザ装置であって、
割り当てられている上りリソースが、少なくとも1つのサイドリンク目標に対するバッファ状態を含む1つのサイドリンクバッファ状態報告MAC CE及びその対応するMAC subheaderを収容できる場合に、バッファ状態報告をトリガーする制御装置と、
前記バッファ状態報告を送信する送信装置と、を含み、
前記制御装置は、前記割り当てられている上りリソースの残りが全ての使用可能なサイドリンク伝送データを収容できる場合に、すべてのサイドリンクバッファ状態報告のトリガーを取り消す、ユーザ装置。
【請求項2】
通信方法であって、
割り当てられている上りリソースが、少なくとも1つのサイドリンク目標に対するバッファ状態を含む1つのサイドリンクバッファ状態報告MAC CE及びその対応するMAC subheaderを収容できる場合に、バッファ状態報告をトリガーする制御ステップと、
前記バッファ状態報告を送信する送信ステップと、を含み、
前記制御ステップは、前記割り当てられている上りリソースの残りが全ての使用可能なサイドリンク伝送データを収容できる場合に、すべてのサイドリンクバッファ状態報告のトリガーを取り消す取り消しステップを含む、通信方法。
【請求項3】
ユーザ装置を含む通信システムであって、
前記ユーザ装置は、
割り当てられている上りリソースが、少なくとも1つのサイドリンク目標に対するバッファ状態を含む1つのサイドリンクバッファ状態報告MAC CE及びその対応するMAC subheaderを収容できる場合に、バッファ状態報告をトリガーし、前記バッファ状態報告を送信するよう構成され、
前記ユーザ装置は、前記割り当てられている上りリソースの残りが全ての使用可能なサイドリンク伝送データを収容できる場合に、すべてのサイドリンクバッファ状態報告のトリガーを取り消す、通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信分野に関し、特に、バッファ状態報告の処理方法、装置及び通信システムに関する。
【背景技術】
【0002】
従来のLTE(Long Term Evolution)システム中の端末装置と端末装置との間の通信は、無線アクセスネットワーク及びコアネットワークにより完成される必要がある。新しいトラフィックのニーズが現れているにつれて、また、ネットワークのロードを減少させ、ネットワークロードのトランスファーを実現し得るために、端末装置と端末装置との間の通信は、1つの新しい研究方向になっている。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、装置対装置)通信について、2種類のProSe BSRのフォーマットが、それぞれ、図1及び図2に示すように定義されている。この2種類のフォーマットは、全て、ProSe Destination(サイドリンク目的地又はサイドリンク目標)に使用可能な伝送待ちデータがある場合に使用する、ProSe BSRを報告するフォーマットである。言い換えると、ProSe BSRを伝送するTTI内で、全てのProSe Destinationに伝送要のデータが無い時に、UEは、報告するProSe BSRがどのフォーマットを使用すべきかを確定できない。
【0005】
D2D通信モードには、サイドリンク制御周期(Sidelink Control Period;SC periodと略称される)の概念が定義されており、該SC periodとは、スケジューリング制御(Scheduling Control)及びその対応するデータの伝送を含む時間周期を指す。Mode 1について、D2D通信中の送信端のデータ伝送の基本ワーキング原理は、次の通りである。
【0006】
基地局が、あるD2D UE(User Equipment、ユーザ装置)のデータ伝送についてのスケジューリングを決定した後に、基地局は、SL-RNTI(Sidelink-Radio Network Temporary Identity)によってスクランブル(scramble)されたPDCCH(Physical Downlink Control Channel)により、SL grant(サイドリンクグラント)を該UEに送信し、該SL grantには、該UEが伝送しようとするSC(スケジューリング制御)の時間周波数領域リソース位置及び伝送しようとするデータの時間周波数領域リソース位置を含む。該SL grantの有効期間は、1つのSC periodであり、且つその対応するSC periodは、該SL grantを伝送するsubframeの後の4msからの次の1つのSC periodである。SL grantを受信した後に、UEは、該SL grantに対応するSC period内で、まず、SL grant中で指示されているSCのリソース位置上でSCを2回伝送し、その後、SL grant中で指示されているdataのリソース位置上でTB(Transport Block)を伝送し、そのうち、各TBが4回伝送されるが、1つのSC period内で伝送し得るTBの個数は、SL grant中で割り当てられているリソース数に依存する。図3は、該伝送プロセスを示す図である。
【0007】
なお、上述の背景技術の紹介は、本発明の技術案を明確且つ完全に説明し、当業者がそれを理解し得るためだけのものである。これらの案は、本発明の背景技術の部分に記述されているため、当業者に周知であると解釈されてはいけない。
【発明の概要】
【発明が解決しようとする課題】
【0008】
幾つかの場合、UEがトリガーされているProSe BSRを伝送し得る十分に多くの上りグラントを有するTTI(Transmission Time Interval)において、UEの全てのProSe Destinationには、使用可能な伝送データが無い。このような場合、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEは、伝送要のProSe BSR MAC CEの内容を確定できないので、現在のバッファ状態を報告できない。
【0009】
上述の問題を解決するために、本発明の実施例は、バッファ状態報告の処理方法、装置及び通信システムを提供する。
【課題を解決するための手段】
【0010】
本実施例の第一側面によれば、バッファ状態報告の処理方法が提供され、該方法は、ユーザ装置(UE)に応用され、そのうち、前記方法は、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断し、「はい」の場合、前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断し、「ない」の場合、トリガーされている全てのProSe BSRを取り消すことを含む。
【0011】
本実施例の第二側面によれば、バッファ状態報告の処理方法が提供され、該方法は、ユーザ装置(UE)に応用され、そのうち、前記方法は、1つのTTIにおいて、割り当てられている該TTIに対しの上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断し、「はい」の場合、前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断し、「ない」の場合、Nが1の1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのbuffer size域のみを有る1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのMAC subheaderのみを報告することを含む。
【0012】
本実施例の第三側面によれば、バッファ状態報告の処理装置が提供され、該装置は、ユーザ装置(UE)に応用され、そのうち、前記装置は、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断するための第一判断ユニット;前記第一判断ユニットの判断結果が「はい」の時に、前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断するための第二判断ユニット;及び、前記第二判断ユニットの判断結果が「ない」の時に、トリガーされている全てのProSe BSRを取り消すための取消ユニットを含む。
【0013】
本実施例の第四側面によれば、バッファ状態報告の処理装置が提供され、該装置は、ユーザ装置(UE)に応用され、そのうち、前記装置は、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断するための第一判断ユニット;前記第一判断ユニットの判断結果が「はい」の時に、前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断するための第二判断ユニット;及び、前記第二判断ユニットの判断結果が「ない」の時に、Nが1である1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのbuffer size域のみを有する1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのMAC subheaderのみを報告するための報告ユニットを含む。
【0014】
本実施例の第五側面によれば、ユーザ装置が提供され、そのうち、前記ユーザ装置は、前述の第三側面又は第四側面に記載のバッファ状態報告の処理装置を含む。
【0015】
本実施例の第六側面によれば、通信システムが提供され、前記通信システムは、ユーザ装置を含み、そのうち、前記ユーザ装置は、次のように構成され、即ち、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる場合、前記TTIにおいて使用可能なサイドリンク伝送データが無ければ、トリガーされている全てのProSe BSRを取り消し、又は、Nが1である1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのbuffer size域のみを有する1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのMAC subheaderのみを報告する。
【0016】
本実施例の他の側面によれば、コンピュータ可読プログラムが提供され、そのうち、バッファ状態報告の処理装置又はユーザ装置中で前記プログラムを実行する時に、前記プログラムは、コンピュータに、前記バッファ状態報告の処理装置又はユーザ装置中で前述の第一側面又は第二側面に記載のバッファ状態報告の処理方法を実行させる。
【0017】
本実施例の他の側面によれば、コンピュータ可読プログラムを記憶した記憶媒体が提供され、そのうち、前記コンピュータ可読プログラムは、コンピュータに、バッファ状態報告の処理装置又はユーザ装置中で前述の第一側面又は第二側面に記載のバッファ状態報告の処理方法を実行させる。
【0018】
本発明の実施例の有益な効果は、本発明の実施例により、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決できる。
【0019】
後述の説明及び図面に基づいて、本発明の特定の実施形態を詳細に開示し、本発明の原理が採用され得る方式を明確にする。なお、本発明の実施形態は、範囲上でそれによって限定されない。添付した特許請求の範囲の精神及び技術的範囲内では、本発明の実施形態は、あらゆる変形、変更に及び代替によるものも含む。
【0020】
1つの実施形態について説明した及び/又は示した特徴は、同じ又は類似した方式で、1つ又は複数の他の実施形態に使用し、他の実施形態における特徴と組み合わせ、又は、他の実施形態における特徴を置換することができる。
【0021】
なお、「包括/含む」のような用語は、本文に使用する時に、特徴、装置全体、ステップ又はアセンブリの存在を指すが、1つ又は複数の他の特徴、装置全体、ステップ又はアセンブリの存在又は付加を排除しないことをも指す。
【図面の簡単な説明】
【0022】
含まれている図面は、本発明の実施例への更なる理解を提供するために用いられ、これらの図面は、本明細書の一部を構成しており、本発明の実施形態を例示し、また、文字記載とともに本発明の原理を説明するために用いられる。また、明らかのように、以下に記載されている図面は、本発明の幾つかの実施例を示すためのものに過ぎず、当業者は、創造性のある労働をせずに、これらの図面に基づいて他の図面を得ることもできる。
図1】Nが偶数の時のProSe BSR MAC CEのフォーマットを示す図である。
図2】Nが奇数の時のProSe BSR MAC CEのフォーマットを示す図である。
図3】D2D通信における送信端のデータ伝送の基本ワーキング原理を示す図である。
図4】本実施例の5つの応用シナリオのうちの1つを示す図である。
図5】本実施例の5つの応用シナリオのうちの1つを示す図である。
図6】本実施例の5つの応用シナリオのうちの1つを示す図である。
図7】本実施例の5つの応用シナリオのうちの1つを示す図である。
図8】本実施例の5つの応用シナリオのうちの1つを示す図である。
図9】実施例1によるバッファ状態報告の処理方法の1つの実施方式のフローチャートである。
図10】実施例2によるバッファ状態報告の処理方法の1つの実施方式のフローチャートである。
図11】実施例3によるバッファ状態報告の処理方法の1つの実施方式のフローチャートである。
図12】実施例3中のProSe BSR MAC CEの1つの実施方式のフォーマットを示す図である。
図13】実施例3中のMAC subheaderの1つの実施方式のフォーマットを示す図である。
図14】実施例3中のMAC subheaderのもう1つの実施方式のフォーマットを示す図である。
図15】実施例3中のProSe BSR MAC CEのもう1つの実施方式のフォーマットを示す図である。
図16】実施例4によるバッファ状態報告の処理方法の1つの実施方式のフローチャートである。
図17】実施例5によるバッファ状態報告の処理方法の1つの実施方式のフローチャートである。
図18】実施例6によるバッファ状態報告の処理装置の1つの実施方式の構成を示す図である。
図19】実施例7によるバッファ状態報告の処理装置の1つの実施方式の構成を示す図である。
図20】実施例8によるバッファ状態報告の処理装置の1つの実施方式の構成を示す図である。
図21】実施例8によるバッファ状態報告の処理装置のもう1つの実施方式の構成を示す図である。
図22】本実施例のユーザ装置の構成を示す図である。
図23】本実施例の通信システムのトポロジー構造を示す図である。
【発明を実施するための形態】
【0023】
添付した図面及び本明細書により、本発明の実施例の前述及び他の特徴は、より明確になる。なお、明細書及び図面では、本発明の特定の実施形態が具体的に開示されているが、それらは、本発明の原理を採用し得る一部のみの実施形態である。また、理解すべきは、本発明は、記載されている実施形態に限定されず、添付した特許請求の範囲に属する全ての変更、変形及び代替によるものも含む。以下、図面を参照しながら、本発明の各種の実施方式について説明する。なお、これらの実施方式は、例示に過ぎず、本発明を限定するものでない。
【0024】
図4図8は、本発明の実施例の5つの応用シナリオを示す図である。これらのシナリオにおいて、“UEが十分に多くの上りグラント(UL grant)を有して、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEの全てのProSe Destinationに使用可能な伝送待ちデータがない”という状況が出現する。
【0025】
図4に示すように、該シナリオでは、あるTTI(例えば、図4に示すTTI-1)においてPeriodic ProSe BSR-Timerがタイムオーバーになり、この時に、1つのPeriodic ProSe BSRがトリガーされる。しかし、該TTIにおいて、UEのサイドリンクバッファに使用可能な伝送データ(data available for transmission)がない。UEがトリガーされているProSe BSRを伝送し得る十分に多くの上りグラントを有するTTI(例えば、図4に示すTTI-2)において、UEのサイドリンクバッファに依然として使用可能な伝送データが存在しない。
【0026】
図5に示すように、該シナリオでは、あるTTI(例えば、図5に示すTTI-1)において1つのProSe BSRがトリガーされる。該TTIにおいて、UEは、使用可能な伝送データを有する少なくとも1つのProSe Destinationを有する。このProSe BSRがトリガーされる前に、UEは、既にデコードによりSL grantをキャリー(carry)する1つのPDCCHを得ている。UEがトリガーされているProSe BSRを伝送し得る十分に多くの上りグラントを有するTTI(例えば、図5に示すTTI-2)において又はその前に、全ての使用可能な伝送データは、既に、前述のSL grantにより伝送されている。
【0027】
図6に示すように、該シナリオでは、あるTTI(例えば、図6に示すTTI-1)において、1つのProSe BSRがトリガーされる。該TTIにおいて、UEは、使用可能な伝送データを持つ少なくとも1つのProSe Destinationを有する。このProSe BSRがトリガーされる前に、UEは、既に、デコードによりSL grantをキャリーする1つのPDCCHを得ており、且つ該SL grantは、ProSe BSRを伝送し得るTTI(例えば、図6に示すTTI-2)を含むSC periodに対してのものである。UEがトリガーされているProSe BSRを伝送し得る十分に多くの上りグラントを有するTTI(例えば、図6に示すTTI-2)において、上述のSL grantのうちの残りのSL grantは、全ての使用可能な伝送データを収容できる。
【0028】
図7に示すように、該シナリオでは、あるTTI(例えば、図7に示すTTI-1)において、1つのProSe BSRがトリガーされる。該TTIにおいて、UEは、使用可能な伝送データを有る少なくとも1つのProSe Destinationがある。このProSe BSRがトリガーされる前に、UEは、既にデコードによりSL grantをキャリーする1つのPDCCHを得ており、且つ該SL grantは、ProSe BSRを伝送し得るTTIを含むSC periodの次の1つのSC periodに対してのものである。UEがトリガーされているProSe BSRを伝送し得る十分に多くの上りグラントを有するTTI(例えば、図7に示すTTI-2)において、上述のSL grantのうちの残りのSL grantは、全ての使用可能な伝送データを収容できる。
【0029】
図8に示すように、該シナリオでは、あるTTI(例えば、図8に示すTTI-1)において、1つのProSe BSRがトリガーされる。該TTIにおいて、UEは、使用可能な伝送データがある少なくとも1つのProSe Destinationを有する。このProSe BSRがトリガーされる前に、UEは、既に、デコードによりSL grantをキャリーする1つのPDCCHを得ており、且つ該SL grantは、ProSe BSRを伝送し得るTTIを含むSC periodの次の第2個目のSC periodに対してのものである。UEがトリガーされているProSe BSRを伝送し得る十分に多くの上りグラントを有するTTI(例えば、図8に示すTTI-2)において、上述のSL grantのうちの残りのSL grantは、全ての使用可能な伝送データを収容できる。
【0030】
なお、上述のシナリオは、例示に過ぎず、本発明の実施例は、上述のシナリオだけでなく、他の実施可能なシナリオに応用することもできる。以下、図面を参照しながら、本発明の実施例について説明する。
【実施例1】
【0031】
本発明の実施例は、バッファ状態報告の処理方法を提供し、該方法は、ユーザ装置(UE)に応用される。図9は、該方法のフローチャートである。図9に示すように、該方法は、次のようなステップを含む。
【0032】
ステップ901:1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断し、「はい」の場合、ステップ902を実行し、そうでない場合、エンドし;
ステップ902:前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断し、「ない」の場合、ステップ903を実行し、そうでない場合、ステップ904を実行し;
そのうち、ここで、サイドリンクバッファに実際に存在するデータに基づいて判断することができ、バッファに実際に存在するデータが有れば、「はい」と判断し、ステップ904を実行し、バッファに実際に存在するデータが無ければ、「いいえ」と判断し、ステップ903を実行し;
ステップ903:トリガーされている全てのProSe BSRを取り消し;
ステップ904:前記使用可能なサイドリンク伝送データに基づいて、ProSe BSRの内容、即ち、ProSe BSR MAC CEの内容を確定し、その後、前記TTIにおいて該ProSe BSRを報告する。
【0033】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時に(ステップ901の判断結果が「はい」の場合)、このTTIにおいて使用可能なサイドリンク伝送データが無い(ステップ902の判断結果が「いいえ」のとき)の場合、トリガーされている全てのProSe BSRを取り消し(ステップ903)、これにより、シナリオ1及びシナリオ2において伝送要のProSe BSR MAC CEの内容を確定できない問題を解決できる。
【0034】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時(ステップ901の判断結果が「はい」のとき)に、このTTI内に使用可能なサイドリンク伝送データがある場合(ステップ902の判断結果が「はい」の場合)、従来の方法又は他の実施可能な方法に従って、前記使用可能なサイドリンク伝送データに基づいて、ProSe BSRの内容、即ち、ProSe BSR MAC CEの内容を確定し、その後、ProSe BSRを報告するTTIにおいて該ProSe BSRを報告する(ステップ904)。
【0035】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できない時(ステップ901判断結果が「いいえ」のとき)に、ProSe BSRを報告する必要がないため、ProSe BSR MAC CEの内容を確定する必要がなく、即ち、シナリオ1及びシナリオ2での問題が存在しないため、この時に処理を行う必要がない。
【0036】
本実施例の1つの実施方式では、ステップ902の前に、例えば、ステップ901の前又は後に、本実施例の方法は、更に、次のようなステップを含んでも良い。
【0037】
ステップ900(図示せず):デコードによりSL grantをキャリーするPDCCHを得た後に、又は、該SL grantが対応するSC periodの開始時刻に、前記SL grant中の割り当てられている伝送データのリソースに基づいて、前記SL grantに対応するSC period全体の中の伝送可能なデータの大小(size)を確定し、また、伝送可能なデータの大小に基づいて、前記SL grantに対応するSC period内で伝送可能な全てのSL MAC PDUを生成する。
【0038】
そのうち、デコードにより得られたSL grantを考慮して、全ての、デコードにより得られたSL grantに対応するSC period内で伝送可能なSL MAC PDUを生成してから、ProSe BSRを報告するTTIにおいて使用可能なサイドリンク伝送データがあるかを判断し、このようにして、送信しようとするデータがあっても、この部分のデータのSL MAC PDUが既に生成されているため、該データを考慮しなくても良いため、使用可能なサイドリンク伝送データがないと判断する。これにより、シナリオ1、2において伝送要のProSe BSR MAC CEの内容を確定できない問題を解決できるのみならず、更にシナリオ3、4、5において伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することもできる。
【0039】
本実施例の1つの実施方式では、ステップ902の後に、ProSe BSRを報告するTTI内に使用可能なサイドリンク伝送データが有れば、該方法は、更に、以下のようなステップを含んでも良い。
【0040】
S1:残りの構成されているSL grantがあるかを判断し、判断結果が「はい」の場合、ステップS2を実行し、判断結果が「いいえ」の場合、ステップ904を実行し;
S2:該残りの構成されているSL grantが全ての使用可能なサイドリンク伝送データを収容できるかを判断し、判断結果が「はい」の場合、ステップ903を実行し、判断結果が「いいえ」の場合、ステップ904を実行する。
【0041】
そのうち、該構成されているSL grantは、該TTIを含むSC periodの次の1つのSC periodに対して構成されているSL grantであっても良く、該TTIを含むSC periodの次の1つのSC periodに対して構成されているSL grantが、全ての使用可能なサイドリンク伝送データを収容できる場合、例えば、シナリオ4に示す場合、該TTIを含むSC periodの次の1つのSC periodにおいて使用可能なサイドリンク伝送データが有っても、該使用可能なサイドリンク伝送データが既にSL grantを有し、且つ該SL grantが全ての使用可能なサイドリンク伝送データを収容できるため、実際には使用可能なサイドリンク伝送データが無く、この場合、トリガーされている全てのProSe BSRを取り消す。
【0042】
そのうち、該構成されているSL grantは、該TTIを含むSC periodの後の第2個目のSC periodに対して構成されているSL grantであっても良い。該TTIを含むSC periodの後の第2個目のSC periodに対して構成されているSL grantが、全ての使用可能なサイドリンク伝送データを収容できる場合、例えば、シナリオ5に示す場合、該TTIを含むSC periodの後の第2個目のSC periodにおいて使用可能なサイドリンク伝送データが有っても、該使用可能なサイドリンク伝送データが既にSL grantを有し、且つ該SL grantが全ての使用可能なサイドリンク伝送データを収容できるので、実際には使用可能なサイドリンク伝送データが無く、この場合、トリガーされている全てのProSe BSRを取り消す。
【0043】
そのうち、ステップS1又はS2の判断結果が「いいえ」の場合、前記SL grantが収容できる使用可能なサイドリンク伝送データを除いた後の使用可能なサイドリンク伝送データに基づいて、ProSe BSRの内容、即ち、ProSe BSR MAC CEの内容を確定し、その後、前記TTIにおいて該ProSe BSRを報告しても良い。
【0044】
本実施例の方法により、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することができる。
【実施例2】
【0045】
本発明の実施例は、バッファ状態報告の処理方法を提供し、該方法は、ユーザ装置(UE)に応用される。図10は、該方法のフローチャートである。図10に示すように、該方法は、次のようなステップを含む。
【0046】
ステップ1001:1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断し、「はい」の場合、ステップ1002を行い、そうでない場合、エンドし;
ステップ1002:前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断し、「ない」の場合、ステップ1003を実行し、そうでない場合、ステップ1004を行い;
そのうち、サイドリンクバッファに実際に存在するデータに基づいて判断しても良く、バッファに実際に存在するデータ及びデコードにより得られたSL grantに基づいて判断しても良く、具体的には、後述し;
ステップ1003:トリガーされている全てのProSe BSRを取り消し;
ステップ1004:前記使用可能なサイドリンク伝送データに基づいて、ProSe BSRの内容、即ち、ProSe BSR MAC CEの内容を確定し、その後、前記TTIにおいて該ProSe BSRを報告する。
【0047】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時に(ステップ1001の判断結果が「はい」のとき)、このTTI内に使用可能なサイドリンク伝送データが無い場合(ステップ1002の判断結果が「いいえ」の場合)、トリガーされている全てのProSe BSRを取り消す(ステップ1003)。
【0048】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時に(ステップ1001の判断結果が「はい」のとき)、このTTI内に使用可能なサイドリンク伝送データがある場合(ステップ1002の判断結果が「はい」の場合)、従来の方法又は他の実施可能な方法に従って、前記使用可能なサイドリンク伝送データに基づいて、ProSe BSRの内容、即ち、ProSe BSR MAC CEの内容を確定し、その後、ProSe BSRを報告するTTIにおいて該ProSe BSRを報告する(ステップ1004)。
【0049】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できない時に(ステップ1001判断結果が「いいえ」のとき)、ProSe BSRを報告する必要がないため、ProSe BSR MAC CEの内容を確定する必要がなく、この時に処理を行う必要がない。
【0050】
ステップ1002の1つの実施方式では、使用可能なサイドリンク伝送データがあるかの判断は、サイドリンクバッファに実際に存在するデータがあるかに基づいて判断できる。即ち、サイドリンクバッファに実際に存在するデータが有れば、ステップ1002の判断結果が「はい」であり、そうでない場合、「いいえ」である。
【0051】
該実施方式では、UEが、PDCCHをデコードすることにより、構成されているSL grantを得た場合、デコードにより、SL grantをキャリーするPDCCHを得た後に、又は、該SL grantが対応するSC periodの開始時刻に、UEは、前記SL grant中で割り当てられている伝送データのリソースに基づいて、前記SL grantが対応するSC period全体の中の伝送可能なデータの大小を確定し、また、伝送可能なデータの大小に基づいて、全ての、前記SL grantが対応するSC period内で伝送可能なSL MAC PDUを生成することができる。
【0052】
このように、デコードにより得られたSL grantを考慮して、全ての、デコードにより得られたSL grantが対応するSC period内で伝送可能なSL MAC PDUを生成してから、ProSe BSRを報告するTTIにおいて伝送待ちの使用可能な伝送データがあるかを判断する。
【0053】
該実施方式では、構成されているSL grantは、該TTIを含むSC periodの次の1つのSC periodに対して構成されているSL grant、及び/又は、該TTIを含SC periodの後の第2個目のSC periodに対して構成されているSL grantであっても良い。
【0054】
ステップ1002のもう1つの実施方式では、使用可能なサイドリンク伝送データがあるかの判断は、サイドリンクバッファに実際に存在するデータがあるか、及び、構成されているSL grantがあるかに基づいて判断しても良い。即ち、サイドリンクバッファに実際に存在するデータがあるかを判断する。「ない」の場合、S1002の判断結果が「いいえ」であり、「ある」の場合、さらに残りの構成されているSL grantがあるかを判断する。「ない」の場合、S1002の判断結果が「はい」であり、「ある」の場合、さらに前記残りの構成されているSL grantが、サイドリンクバッファ中の全ての使用可能なサイドリンク伝送データを収容できるかを判断する。「はい」の場合、S1002の判断結果が「いいえ」であり、そうでない場合、S1002の判断結果が「はい」である。
【0055】
該実施方式では、UEが、PDCCHへのデコードにより、構成されているSL grantを得た場合、UEは、該SL grantが対応する各TTI(s)において、前記SL grant中で割り当てられている伝送データのリソースに基づいて、前記各TTI内で伝送可能なデータの大小を確定し、また、伝送可能なデータの大小に基づいて、前記各TTI内で伝送可能なSL MAC PDUを生成する。
【0056】
該実施方式では、構成されているSL grantは、該TTIを含むSC periodの次の1つのSC periodに対して構成されているSL grant、及び/又は、該TTIを含むSC periodの後の第2個目のSC periodに対して構成されているSL grantであっても良い。
【0057】
本実施例の方法により、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することができる。
【実施例3】
【0058】
本発明の実施例は、更に、バッファ状態報告の処理方法を提供し、該方法は、同様に、ユーザ装置(UE)に応用される。図11は、該方法のフローチャートである。図11に示すように、該方法は、次のようなステップを含む。
【0059】
ステップ1101:1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断し、「はい」の場合、ステップ1102を実行し、そうでない場合、エンドし;
ステップ1102:前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断し、「ない」の場合、判断結果が「いいえ」であり、ステップ1103を行い、そうでない場合、ステップ1104を実行し;
ステップ1103:Nが1である1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのbuffer size域のみを有する1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのMAC subheaderのみを報告し;
ステップ1104:前記使用可能なサイドリンク伝送データに基づいて、ProSe BSRの内容、即ち、ProSe BSR MAC CEの内容を確定し、その後、前記TTIにおいて該ProSe BSRを報告する。
【0060】
ステップ1102の1つの実施方式では、使用可能なサイドリンク伝送データがあるかの判断は、サイドリンクバッファに実際に存在するデータがあるかに基づいて判断できる。即ち、サイドリンクバッファに実際に存在するデータが有れば、S1102の判断結果が「はい」であり、そうでない場合、「いいえ」である。
【0061】
ステップ1102のもう1つの実施方式では、使用可能なサイドリンク伝送データがあるかの判断は、サイドリンクバッファに実際に存在するデータがあるか、及び、構成されているSL grantがあるかに基づいて判断できる。即ち、サイドリンクバッファに実際に存在するデータがあるかを判断する。「ない」の場合、S1102の判断結果が「いいえ」であり、「ある」の場合、さらに残りの構成されているSL grantがあるかを判断する。「ない」の場合、S1102の判断結果が「はい」であり、「ある」の場合、さらに前記残りの構成されているSL grantが、サイドリンクバッファ中の全ての使用可能なサイドリンク伝送データを収容できるかを判断する。「はい」の場合、S1102の判断結果が「いいえ」であり、そうでない場合、S1102の判断結果が「はい」である。
【0062】
本実施例では、構成されているSL grantは、該TTIを含むSC periodの次の1つのSC periodに対して構成されているSL grant、及び/又は、該TTIを含むSC periodの後の第2個目のSC periodに対して構成されているSL grantであっても良い。
【0063】
本実施例の方法は、実施例1及び2の方法に類似したが、異なるのは、実施例1及び2の方法では、ProSe BSRを報告するTTIにおいて使用可能なサイドリンク伝送データがないと判断した時に、トリガーされている全てのProSe BSRを取り消すが、本実施例では、ProSe BSRを報告するTTIにおいて使用可能なサイドリンク伝送データが無いと判断した時に、1つの特殊フォーマットのProSe BSRを報告する。
【0064】
1つの実施方式では、該特殊フォーマットのProSe BSRは、Nが1であるProSe BSR MAC CE及びその対応するMAC subheaderであっても良く、そのうち、Nは、ProSe BSR MAC CEに含まれるProSe Destinationの個数である。
【0065】
図12は、該実施方式のProSe BSR MAC CEのフォーマットを示す図である。そのうち、Group indexは、組インデックスであり、LCG IDは、論理チャネル組の標識であり、buffer sizeは、バッファの大小であり、本実施方式では、その値は、0であり、Rは、予備ビットである。
【0066】
本実施方式では、図12に示すProSe BSR MAC CEに対応するMAC subheaderのフォーマットは、図13又は図14に示すようであるが、本実施例は、これに限定されない。そのうち、図13及び図14に示すMAC subheaderのフォーマットのうち、LCIDは、新定義の値であっても良く、本実施例では、所定値と称され、その対応するProSe BSR MAC CEのフォーマット及び/又は長さを示すために用いられ、本実施方式では、その値は、11000、10110などであっても良い。図13に示すように、Eは、拡張ビットであり、該MAC subheaderの後が、もう1つのMAC subheaderか、それとも、MAC SDU又はMAC CEであるかを示すために用いられる。図14に示すように、Fビットは、Lビットが占めるバイト数を示すために用いられ、Lは、該MAC subheaderが対応するMAC CE又はMAC SDUの長さを示すために用いられる。
【0067】
もう1つの実施方式では、該特殊フォーマットのProSe BSRは、1つのbuffer size域のみを有するProSe BSR MAC CE及びその対応するMAC subheaderであっても良い。
【0068】
図15は、該実施方式のProSe BSR MAC CEのフォーマットを示す図である。そのうち、Rは、予備ビットであり、buffer sizeは、バッファの大小であり、本実施方式では、その値は、0である。本実施方式では、該ProSe BSR MAC CEには、組インデックス(Group index)及び論理チャネル組の標識(LCG ID)が含まれない。
【0069】
本実施方式では、図15に示すProSe BSR MAC CEに対応するMAC subheaderのフォーマットは、図13に示すようであるが、本実施例は、これに限定されず、そのうち、LCIDの意味は、前述のようであり、それは、1つの新定義の値であっても良い。ここでは、その詳しい説明を省略する。
【0070】
もう1つの実施方式では、該特殊フォーマットのProSe BSRは、1つのMAC subheaderのみであっても良く、例えば、図13に示すMAC subheaderである。本実施方式では、該MAC subheader中のLCIDの意味は、前述と同様であり、それは、1つの新定義の値であっても良く、ここでは、その詳しい説明を省略する。
【0071】
本実施例では、実施例1又は実施例2と同じである内容、例えば、ステップ1001、1002、1004については、その詳しい説明を省略する。
【0072】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時に、このTTI内で使用可能なサイドリンク伝送データがない場合、Nが1である1つのProSe BSR MAC CE(図12)及びその対応するMAC subheader(図13又は図14)を報告し、又は、1つのbuffer size域のみを有する1つのProSe BSR MAC CE(図15)及びその対応するMAC subheader(図13)を報告し、又は、1つのMAC subheaderのみを報告し(図13)、これにより、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することができる。
【実施例4】
【0073】
本発明の実施例は、更に、バッファ状態報告の処理方法を提供し、該方法は、同様に、ユーザ装置(UE)に応用され、図16は、該方法のフローチャートである。図16に示すように、該方法は、次のようなステップを含む。
【0074】
ステップ1601:Padding ProSe BSR又はPeriodic ProSe BSRに対しての第一トリガー条件を満足しているかを判断し、「満足している」の場合、ステップ1602を実行し、そうでない場合、ステップ1604を実行し;
ステップ1602:任意の1つのサイドリンクトラフィック論理チャネルに対して、UEが使用可能なサイドリンク伝送データを有するかを判断し、「ある」の場合、ステップ1603を実行し、そうでない場合、ステップ1604を行い;
ステップ1603:前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーし;
ステップ1604:前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーしない。
【0075】
本実施例では、第一トリガー条件は、従来規格に定義のPadding ProSe BSR又はPeriodic ProSe BSRのトリガー条件、例えば、文献http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_88/Docs/R2-145307に定義の条件であっても良く、他の所定のトリガー条件であっても良い。
【0076】
本実施例では、第一トリガー条件を満足した時に、先ず、前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーせず、任意の1つのサイドリンクトラフィック論理チャネル(即ち、STCH:Sidelink Traffic logical Channel)に対して、UEが使用可能なサイドリンク伝送データを有するかを判断し、「ある」の場合、該Padding ProSe BSR又はPeriodic ProSe BSRをトリガーし、そうでない場合、トリガーしない。これにより、任意のサイドリンクトラフィック論理チャネルに対して、UEが使用可能なサイドリンク伝送データを有しない時に、Padding ProSe BSR又はPeriodic ProSe BSRをトリガーしない。これにより、トリガーされているProSe BSRを伝送できるTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することができる。
【実施例5】
【0077】
本発明の実施例は、更に、バッファ状態報告の処理方法を提供し、該方法は、同様に、ユーザ装置(UE)に応用される。図17は、該方法のフローチャートである。図17に示すように、該方法は、次のようなステップを含む。
【0078】
ステップ1701:ProSe BSR(Padding ProSe BSR又はPeriodic ProSe BSR又はRegular ProSe BSR)に対しての第一トリガー条件を満足しているかを判断し、満足しており、且つ該ProSe BSRがPadding ProSe BSR又はPeriodic ProSe BSRである場合、ステップ1702を実行し、満足しており、且つ該ProSe BSRがRegular ProSe BSRである場合、ステップ1703を実行し;そうでない場合、ステップ1706を実行し;
ステップ1702:任意の1つのサイドリンクトラフィック論理チャネルに対して、UEが使用可能なサイドリンク伝送データを有するかを判断し、「ある」の場合、ステップ1703を行い、そうでない場合、ステップ1706を実行し;
ステップ1703:残りの構成されているSL grantがあるかを判断し、「ある」の場合、ステップ1704を実行し、そうでない場合、ステップ1705を実行し;
ステップ1704:残りの構成されているSL grantが、全ての使用可能なサイドリンク伝送データを収容できるかを判断し、「はい」の場合、ステップ1706を行い、「いいえ」の場合、ステップ1705を行い;
ステップ1705:前記Padding ProSe BSR又はPeriodic ProSe BSR又はRegular BSRをトリガーし;
ステップ1706:前記Padding ProSe BSR又はPeriodic ProSe BSR又はRegular BSRをトリガーしない。
【0079】
本実施例では、Padding ProSe BSR、Periodic ProSe BSR及びRegular ProSe BSRについて、ステップ1701に記載の第一トリガー条件は、従来規格に定義のPadding ProSe BSR、Periodic ProSe BSR及びRegular ProSe BSRのトリガー条件、例えば、文献http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_88/Docs/R2-145307に定義の条件であっても良く、他の所定のトリガー条件であっても良い。
【0080】
本実施例では、Padding ProSe BSR又はPeriodic ProSe BSRの第一トリガー条件を満足した時に、先ず、前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーせず、任意の1つのサイドリンクトラフィック論理チャネル(即ち、STCH:Sidelink Traffic logical Channel)に対して、UEが使用可能な伝送データを有するかを判断し、「ない」の場合、UEが前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーせず、「ある」の場合、さらに残りの構成されているSL grantがあるかを判断する。残りの構成されているSL grantがない場合、UEは、前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーする。残りの構成されているSL grantがある場合、UEは、前記構成されているSL grantが全てのサイドリンクトラフィック論理チャネルの可用伝送データを収容できるかを判断する。判断結果が「いいえ」の場合、UEは、前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーする。判断結果が「はい」の場合、UEは、前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーしない。
【0081】
本実施例では、Regular ProSe BSRの第一トリガー条件を満足した時に、先ず、前記Regular ProSe BSRをトリガーせず、残りの構成されているSL grantがあるかを判断する。「ない」の場合、UEは、前記Regular ProSe BSRをトリガーする。残りの構成されているSL grantがある場合、UEは、前記SL grantが全てのサイドリンクトラフィック論理チャネルの可用伝送データを収容できるかを判断する。判断結果が「いいえ」の場合、UEは、前記Regular BSRをトリガーする。判断結果が「はい」の場合、UEは、前記Regular ProSe BSRをトリガーしない。
【0082】
これにより、任意のサイドリンクトラフィック論理チャネルに対して、UEが使用可能な伝送データを有しない時に、UEは、Padding ProSe BSR又はPeriodic ProSe BSRをトリガーせず;UEが使用可能なサイドリンク伝送データを有するが、残りの構成されているSL grantが全てのこれらのデータを収容できる時に、UEは、Padding ProSe BSR又はPeriodic ProSe BSR又はRegular ProSe BSRをトリガーしない。これにより、トリガーされているProSe BSRを伝送できるTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することができる。
【0083】
本実施例では、構成されているSL grantは、該TTIを含むSC periodの次の1つのSC periodに対して構成されたSL grant及び/又は該TTIを含むSC periodの後の第2個目のSC periodに対して構成されたSL grantであっても良い。
【0084】
以上、5つの実施例をもとに本実施例の方法を説明したが、具体的な実施プロセスでは、上述の5つの実施例は、合併されても良く、独立して使用されても良く、例えば、実施例1、2及び実施例4、5は、合併されても良く、実施例3及び実施例4、5は、合併されても良く、また、実施例1、2、3、4、5は、別々で実施されても良い。
【実施例6】
【0085】
本発明の実施例は、バッファ状態報告の処理装置を提供し、該装置は、ユーザ装置に応用され得る。該装置が問題を解決する原理は、実施例1、2の方法に類似したので、その具体的な実施は、実施例1、2の方法の実施を参照でき、内容が同じである重複説明は、省略される。
【0086】
図18は、該装置の構成を示す図である。図18に示すように、該バッファ状態報告の処理装置1800は、第一判断ユニット181、第二判断ユニット182及び取消ユニット183を含む。
【0087】
そのうち、第一判断ユニット181は、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できるかを判断する。
【0088】
そのうち、第二判断ユニット182は、第一判断ユニット181の判断結果が「はい」の時に、前記TTIにおいて使用可能なサイドリンク伝送データがあるかを判断する。そのうち、実施例1及び実施例2に対応する第二判断ユニット182の判断方式は若干違いがあるが、詳しくは、実施例1及び実施例2を参照できる。
【0089】
そのうち、取消ユニット183は、第二判断ユニット182の判断結果が「ない」の時に、トリガーされている全てのProSe BSRを取り消す。
【0090】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソーが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時に、該TTI内で使用可能なサイドリンク伝送データが無ければ、トリガーされている全てのProSe BSRを取り消し、これにより、トリガーされているProSe BSRを伝送できるTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することができる。
【0091】
1つの実施方式では、該バッファ状態報告の処理装置1800は、更に、確定ユニット184及び生成ユニット185を含む。
【0092】
そのうち、確定ユニット184は、前記ユーザ装置がデコードによりSL grantをキャリーするPDCCHを得た後に、又は、該SL grantに対応するSC periodの開始時刻に、前記SL grantにおいて割り当てられた伝送データのリソースに基づいて、前記SL grantに対応するSC period全体のうちの伝送可能なデータの大小を確定する。
【0093】
そのうち、生成ユニット185は、確定ユニット184が確定した伝送可能なデータの大小に基づいて、全ての、前記SL grantに対応するSC period内で伝送可能なSL MAC PDUを生成する。
【0094】
該実施方式では、まず、全ての、SL grantに対応するSC period内で伝送可能なSL MAC PDUを生成してから、ProSe BSRを伝送するTTI内で伝送待ちの使用可能な伝送データがあるかを判断し、これにより、シナリオ1、2での問題だけでなく、シナリオ3、4、5での問題を解決することもできる。
【0095】
1つの実施方式では、該バッファ状態報告の処理装置1800は、更に、第三判断ユニット186及び第四判断ユニット187を含み、そのうち、第三判断ユニット186は、第二判断ユニット182が、ProSe BSRを伝送するTTI内で伝送待ちの使用可能な伝送データがあると判断した時に、残りの構成されているSL grantがあるかを判断する。第四判断ユニット187は、第三判断ユニット186の判断結果が「はい」の時に、該残りの構成されているSL grantが全ての伝送待ちの使用可能な伝送データを収容できるかを判断する。取消ユニット183は、該第四判断ユニット187の判断結果が「はい」時、トリガーされている全てのProSe BSRを取り消す。
【0096】
そのうち、該構成されているSL grantは、該TTIを含むSC periodの次の1つのSC periodに対して構成されているSL grantであっても良い。これにより、シナリオ3での問題を解決することができる。
【0097】
そのうち、該構成されているSL grantは、該TTIを含むSC periodの後の第2個目のSC periodに対して構成されているSL grantであっても良い。これにより、シナリオ5での問題を解決できる。
【0098】
本実施例では、第二判断ユニット182は、サイドリンクバッファに実際に存在するデータに基づいて、使用可能なサイドリンク伝送データがあるかを判断でき、サイドリンクバッファに実際に存在するデータがある場合、第二判断ユニットは、使用可能なサイドリンク伝送データがあると判断し、そうでない場合、第二判断ユニットは、使用可能なサイドリンク伝送データがないと判断する。具体的には、実施例2に記載のようであり、ここでは、詳しい説明を省略する。
【0099】
本実施例では、第二判断ユニット182は、サイドリンクバッファに実際に存在するデータ及び構成されているSL grantに基づいて、使用可能なサイドリンク伝送データがあるかを判断することもでき、サイドリンクバッファに実際に存在するデータがあり、且つ前記構成されているSL grantがサイドリンクバッファ中の全てのデータを収容できない場合、第二判断ユニットは、使用可能なサイドリンク伝送データがあると判断し、そうでない場合、第二判断ユニットは、使用可能なサイドリンク伝送データがないと判断する。具体的には、実施例2に記載のようであり、ここでは、詳しい説明を省略する。
【実施例7】
【0100】
本発明の実施例は、バッファ状態報告の処理装置を提供し、該装置は、ユーザ装置に応用され得る。該装置が問題を解決する原理は、実施例3の方法に類似したため、その具体的な実施は、実施例3の方法の実施を参照でき、内容が同じである重複説明は、省略される。
【0101】
図19は、該装置の構成を示す図である。図19に示すように、該バッファ状態報告の処理装置1900は、第一判断ユニット191、第二判断ユニット192及び報告ユニット193を含む。
【0102】
そのうち、第一判断ユニット191及び第二判断ユニット192の原理及び実施プロセスは、実施例6の装置の第一判断ユニット181及び第二判断ユニット182と同じであるため、その内容は、ここに合併され、ここでは、その詳しい説明を省略する。
【0103】
そのうち、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時に(第一判断ユニット191の判断結果が「はい」のとき)、且つ、該TTI内で伝送待ちの使用可能な伝送データがない時に(第二判断ユニット192の判断結果が「いいえ」のとき)、報告ユニット193は、Nが1である1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのbuffer size域のみを有する1つのProSe BSR MAC CE及びその対応するMAC subheaderを報告し、又は、1つのMAC subheaderのみを報告する。
【0104】
本実施例では、MAC subheader内のLCIDは、その対応するProSe BSR MAC CEの所定値を示すために用いられる。
【0105】
本実施例では、1つのTTIにおいて、割り当てられている該TTIに対しての上りリソースが、少なくとも1つのProSe Destinationのバッファ状態を含む1つのProSe BSR MAC CE及びその対応するMAC subheaderを収容できる時に、該TTI内で伝送待ちの使用可能な伝送データが無い場合、1つの特殊フォーマットのProSe BSRを報告し、これにより、トリガーされているProSe BSRを伝送できるTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決することができる。
【0106】
本実施例では、実施例6と同様に、第二判断ユニット182は、サイドリンクバッファに実際に存在するデータに基づいて使用可能なサイドリンク伝送データがあるかを判断しても良く、サイドリンクバッファに実際に存在するデータ及び構成されているSL grantに基づいて使用可能なサイドリンク伝送データが有るかを判断しても良い。
【実施例8】
【0107】
本発明の実施例は、バッファ状態報告の処理装置を提供し、該装置は、ユーザ装置に応用され得る。該装置が問題を解決する原理は、実施例4、5の方法に類似したので、その具体的な実施は、実施例4、5の方法の実施を参照でき、内容が同じである重複説明は、省略される。
【0108】
図20は、該装置の1つの実施方式の構成を示す図である。図20に示すように、該バッファ状態報告の処理装置2000は、第一判断ユニット201、第二判断ユニット202及び処理ユニット203を含む。
【0109】
そのうち、第一判断ユニット201は、Padding ProSe BSR又はPeriodic ProSe BSRに対しての第一トリガー条件が満足されているかを判断する。
【0110】
そのうち、第二判断ユニット202は、第一判断ユニット201が、満足されていると判断した時に、任意の1つのサイドリンクトラフィック論理チャネルに対して、UEが使用可能なサイドリンク伝送データを有するかを判断する。
【0111】
そのうち、処理ユニット203は、第二判断ユニット202の判断結果が「ある」の時に、前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーする。また、処理ユニット203は、更に、第二判断ユニット202の判断結果が「いいえ」の時に、前記Padding ProSe BSR又はPeriodic ProSe BSRをトリガーしない。
【0112】
本実施例では、任意のサイドリンクトラフィック論理チャネルに対して、UEが使用可能なサイドリンク伝送データを有しない時に、Padding ProSe BSR又はPeriodic ProSe BSRの元のトリガー条件が既に満足されていても、Padding ProSe BSR又はPeriodic ProSe BSRをトリガーしない。これにより、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決できる。
【0113】
図21は、該装置のもう1つの実施方式の構成を示す図である。図21に示すように、該バッファ状態報告の処理装置2100は、第一判断ユニット211、第二判断ユニット212、第三判断ユニット213、第四判断ユニット214、処理ユニット215を含む。
【0114】
第一判断ユニット211は、ProSe BSRの対しての第一トリガー条件が満足されているかを判断する。
【0115】
第二判断ユニット212は、第一判断ユニット211の判断結果が「はい」のとき、且つ該ProSe BSRがPadding ProSe BSR又はPeriodic ProSe BSRであるときに、任意の1つのサイドリンクトラフィック論理チャネルに対して、UEが使用可能なサイドリンク伝送データを有するかを判断する。
【0116】
第三判断ユニット213は、第二判断ユニットの判断結果が「はい」のとき、又は、第一判断ユニットの判断結果が「はい」のとき、且つ該ProSe BSRがRegular ProSe BSRであるときに、残りの構成されているSL grantがあるかを判断する。
【0117】
第四判断ユニット214は、第三判断ユニット213の判断結果が「はい」の時に、残りの構成されているSL grantが全ての使用可能なサイドリンク伝送データを収容できるかを判断する。
【0118】
処理ユニット215は、第一判断ユニット211の判断結果が「いいえ」であり、又は、第二判断ユニット212の判断結果が「いいえ」であり、又は、第四判断ユニット214の判断結果が「はい」の場合、前記Padding ProSe BSR又はPeriodic ProSe BSR又はRegular BSRをトリガーせず、また、第三判断ユニット213の判断結果が「いいえ」であり、又は、第四判断ユニットの判断結果が「いいえ」の場合、前記Padding ProSe BSR又はPeriodic ProSe BSR又はRegular BSRをトリガーする。
【0119】
本実施例の装置により、トリガーされているProSe BSRを伝送できるTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決できる。
【実施例9】
【0120】
本発明の実施例は、更に、ユーザ装置を提供し、そのうち、該ユーザ装置は、実施例6~8に記載のバッファ状態報告の処理装置を含む。
【0121】
図22は、本発明の実施例のユーザ装置の構成を示す図である。図22に示すように、該ユーザ装置2200は、中央処理装置2201及び記憶器2202を含んでも良く、記憶器2202は、中央処理装置2201に接続される。なお、該図は、例示に過ぎず、更に他の類型の構造を以て該構造に対して補充又は代替を行うことで、電気通信機能又は他の機能を実現しても良い。
【0122】
1つの実施方式では、バッファ状態報告の処理装置の機能は、中央処理装置2201に統合しても良く、中央処理装置2201により、実施例6~8に記載のバッファ状態報告の処理装置の機能を実現しても良く、そのうち、バッファ状態報告の処理装置の機能は、ここに合併され、ここではその詳しい説明を省略する。
【0123】
もう1つの実施方式では、バッファ状態報告の処理装置は、中央処理装置2201と別々で構成されても良く、例えば、バッファ状態報告の処理装置を、中央処理装置2201に接続されるチップとして構成し、中央処理装置2201の制御でバッファ状態報告の処理装置の機能を実現しても良い。
【0124】
図22に示すように、該ユーザ装置2200は、更に、通信モジュール2203、入力ユニット2204、音声処理ユニット2205、表示器2206、電源2207を含んでも良い。なお、ユーザ装置2200は、必ずしも図22中の全ての部品を含む必要がなく、また、ユーザ装置2200は、更に、図22に示されていない部品を含んでも良く、これについては、従来技術を参照できる。
【0125】
図22に示すように、中央処理装置2201は、制御器又は操作コントローラと称される場合があり、マイクロプロセッサ又は他の処理器及び/又は論理装置を含んでも良く、該中央処理装置2201は、入力を受信し、また、ユーザ装置2200の各部品の操作を制御できる。
【0126】
そのうち、記憶器2202は、例えば、バッファ、フレッシュメモリ、HDD、移動可能な媒体、揮発性記憶器、不揮発性記憶器、又は他の適切な装置のうちの一つ又は複数であっても良い。上述の構成に関する情報を記憶することができ、また、更に情報処理に関するプログラムを記憶することもできる。中央処理装置2201は、該記憶器2202に記憶された該プログラムを、情報の記憶又は処理などを実現するために実行することができる。なお、他の部品の機能は、従来に類似したので、ここでは詳しい説明を省略する。また、ユーザ装置2200の各部品は、専用ハードウェア、ファームウェア、ソフトウェア又はその組み合わせにより実現することもでき、これらは、全て、本発明の範囲に属する。
【0127】
本実施例のユーザ装置により、トリガーされているProSe BSRを伝送可能なTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決できる。
【実施例10】
【0128】
本発明の実施例は、更に、通信システムを提供する。図23は、該通信システムのトポロジー構造を示す図である。図23に示すように、該通信システム2300は、ユーザ装置2301及び基地局2302を含む。
【0129】
そのうち、該基地局2302は、適切なタイミングでユーザ装置2301にSL grantを搬送するPDCCH及びUL grantを搬送するPDCCHを送信するように構成される。それは、従来の基地局により実現することができるため、具体的な説明は省略される。
【0130】
そのうち、ユーザ装置2301は、基地局2301と、従来のインフラに基づく通信を行うと共に、他のユーザ装置2301とD2Dに基づく通信を行うように構成される。
【0131】
本実施例では、該ユーザ装置2301は、実施例1~5に記載のバッファ状態報告の処理方法を用いることができ、即ち、実施例6~8に記載のバッファ状態報告の処理装置の機能を実現でき、実施例1~8の内容は、ここに合併され、ここでは、その詳しい説明を省略する。
【0132】
本実施例の通信システムにより、トリガーされているProSe BSRを伝送し得るTTIにおいて、UEが伝送要のProSe BSR MAC CEの内容を確定できない問題を解決できる。
【0133】
本発明の実施例は、更に、コンピュータ可読プログラムを提供し、そのうち、バッファ状態報告の処理装置又はユーザ装置中で前記プログラムを実行する時に、前記プログラムは、コンピュータに、前記バッファ状態報告の処理装置又はユーザ装置中で実施例1~5に記載のバッファ状態報告の処理方法を実行させる。
【0134】
本発明の実施例は、更に、コンピュータ可読プログラムを記憶した記憶媒体を提供し、そのうち、前記コンピュータ可読プログラムは、コンピュータに、バッファ状態報告の処理装置又はユーザ装置中で実施例1~5に記載のバッファ状態報告の処理方法を実行させる。
【0135】
本発明の上述の装置及び方法はドウェアにより実現されても良く、ハードウェアとソフトウェアとの組み合わせにより実現されても良い。本発明は、このようなコンピュータ可読プログラムに関し、該プログラムは、論理部品により実行される時に、該論理部品に、上述の装置又は構成部品を実現させることができ、又は、該論理部品に、上述の各種の方法又はステップを実現させることができる。本発明は、さらに、上述のプログラムを記憶した記憶媒体、例えば、ハードディスク、磁気ディスク、光ディスク、DVD、flashメモリなどにも関する。
【0136】
以上、本発明の好ましい実施形態を説明したが、本発明はこの実施形態に限定されず、本発明の趣旨を離脱しない限り、本発明に対するあらゆる変更は本発明の技術的範囲に属する。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23