JP2022543342A

JP2022543342A - サイドリンクの実装方法及び関連製品

Info

Publication number: JP2022543342A
Application number: JP2021576721A
Authority: JP
Inventors: ルー、チエンシー; チャオ、チェンシャン; リン、ホエイ－ミン
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2019-07-03
Filing date: 2019-07-03
Publication date: 2022-10-12
Anticipated expiration: 2039-07-03
Also published as: WO2021000306A1; CN113728711A; US20220124778A1; CN114364043A; EP3979743A1; EP3979743A4; JP7490005B2; EP3979743B1; KR20220030951A

Abstract

本発明の実施形態において、サイドリンクの実装方法及び関連製品が提供される。この方法は、アップリンクバッファー状態レポート（ＵＬＢＳＲ）よりサイドリンクバッファー状態レポート（ＳＬＢＳＲ）が優先的に報告されることを含む。本発明に係る技術方案は、ＳＬＢＳＲの優先的な送信の実現と、ＳＬデータの優先的な送信のサポートという利点を有する。

Description

本発明は端末技術の分野に関し、特にサイドリンクの実装方法及び関連製品に関する。

Ｄ２Ｄ通信（ＤｅｖｉｃｅｔｏＤｅｖｉｃｅＣｏｍｍｕｎｉｃａｔｉｏｎ、Ｄ２ＤＣｏｍｍｕｎｉｃａｔｉｏｎ）は、Ｄ２Ｄに基づいたサイドリンク（ＳｉｄｅＬｉｎｋ、ＳＬ）送信技術である。従来のセルラーシステムにおいて通信データが基地局を介して受信される又は送信されるという方式とは異なり、ＩｏＶ（ｉｎｔｅｒｎｅｔｏｆｖｅｈｉｃｌｅｓ）システムは端末－端末（ｔｅｒｍｉｎａｌ－ｔｏ－ｔｅｒｍｉｎａｌ）直接通信の方式を用いるため、より高いスペクトル効率及びより低い伝送遅延を有する。

既存のネットワークはサイドリンクバッファー状態レポート（ＳｉｄｅＬｉｎｋｂｕｆｆｅｒｓｔａｔｕｓｒｅｐｏｒｔ、ＳＬＢＳＲ）を適時に取得することができないため、ＳＬデータの送信に影響をもたらした。

本発明は、サイドリンクの実装方法及び関連製品を提供する。これによって、ＳＬＢＳＲの優先的な送信を実現し、ＳＬデータの優先的な送信をサポートすることができる。

第一様態において、本発明の実施形態はデバイス通信に基づいたサイドリンクの実装方法を提供する。この方法は、アップリンクバッファー状態レポート（ｕｐｌｉｎｋｂｕｆｆｅｒｓｔａｔｕｓｒｅｐｏｒｔ、ＵＬＢＳＲ）よりサイドリンクバッファー状態レポート（ＳＬＢＳＲ）を優先的に報告することを含む。

第二様態において、一つの装置が提供される。この装置は、ＵＬＢＳＲよりＳＬＢＳＲを優先的に報告するように構成されている報告ユニットを含む。

第三様態において、デバイス通信に基づいたサイドリンクの実装システムが提供される。このシステムは第一端末及び第二端末を含む。第一端末は、ＵＬＢＳＲよりＳＬＢＳＲを優先的に報告するように構成されている。

第四様態において、電子デバイスが提供される。この電子デバイスはプロセッサとメモリを含む。上記メモリは、上記プロセッサによって実行されるように構成された一つ又は複数のプログラムを格納するように構成されている。上記プログラムは、第一様態に記載の方法における操作を実行するために用いられる命令を含む。

第五様態において、コンピュータ可読記憶媒体が提供される。このコンピュータ可読記憶媒体は、電子データ交換のために用いられるコンピュータプログラムを格納する。上記コンピュータプログラムはコンピュータに、第一様態に提供された方法を実行させる。

第六様態において、コンピュータプログラム製品が提供される。このコンピュータプログラム製品は、コンピュータプログラムを格納する非一時的なコンピュータ可読記憶媒体を含む。上記コンピュータプログラムが実行されると、コンピュータに第一様態に提供された方法を実行させる。

本発明の実施形態の技術方案を明確に説明するために、以下、実施形態の説明に必要な図面を簡単に紹介する。明らかに、説明される図面は本発明のいくつかの実施形態にすぎず、当業者にとって、創造的な努力なしに、これらの図面によって他の図面を得ることができる。
図１ａは、本発明の実施形態に係るモードＡのネットワークの構造を示す概略図である。図１ｂは、本発明の実施形態に係るモードＢのネットワークの構造を示す概略図である。図２ａは、本発明の実施形態に係るサイドリンクの実装方法を示すフローチャートである。図２ｂは、本発明の実施形態に係るサイドリンクの実装方法を示すフローチャートである。図３は、本発明の実施形態に係るバッファー状態レポート（ＢＳＲ）タイマースキームを示すフローチャートである。図４は、本発明の実施形態に係るイベント処理スキームを示すフローチャートである。図５は、本発明の実施形態に係る装置の構造を示す概略図である。図６は、本発明の実施形態に係るサイドリンク実装システムの構造を示す概略図である。図７ａは、本発明の実施形態に係るサイドリンクの実装方法を示すフローチャートである。図７ｂは、本発明の実施形態に係る他のサイドリンクの実装方法を示すフローチャートである

以下、図面と実施形態を結びつけて本発明をさらに詳しく説明する。ここで説明される具体的な実施形態は本発明を解釈するだけに用いられ、本発明を限定するものではない。また、表現しやすさのため、図面は本発明と関連した全ての構造ではなく一部の構造だけを示した。

本発明の実施形態に係る電子デバイスは無線通信機能を有する各種類のハンドヘルド機器（例えば、スマートフォン）、車載機器、ウェアラブル機器、計算装置、又は無線モデムと接続する他のプロセスデバイス、及び各種類のユーザー機器（ＵｓｅｒＥｑｕｉｐｍｅｎｔ、ＵＥ）、移動ステーション（ＭｏｂｉｌｅＳｔａｔｉｏｎ、ＭＳ）、端末装置（ｔｅｒｍｉｎａｌｄｅｖｉｃｅ）、研究開発/テストプラットフォーム、サーバーなどを含むことができる。表現しやすさのため、上記デバイスを総称して電子デバイスと呼ぶ。

Ｄ２Ｄはデバイスツーデバイス通信である。３ＧＰＰ（３ｒｄｇｅｎｅｒａｔｉｏｎｐａｒｔｎｅｒｓｈｉｐｐｒｏｊｅｃｔ）において、Ｄ２Ｄは以下の３つの段階に分けられている。
ＰｒｏＳｅ（Ｐｒｏｘｉｍｉｔｙｂａｓｅｄｓｅｒｖｉｃｅ）：Ｒｅｌ-１２/１３では、Ｄ２Ｄ通信は、ＰｒｏＳｅシナリオに向けて研究され、主に公共安全サービスを対象とする。
Ｖ２Ｘ（Ｖｅｈｉｃｌｅｔｏｅｖｅｒｙｔｈｉｎｇ）：Ｒｅｌ-１４/１５では、Ｖ２ＸシステムはＶ２Ｖ（ＶｅｈｉｃｌｅｔｏＶｅｈｉｃｌｅ）通信のシナリオに向けて研究され、主に高速で移動するＶ２Ｖ（ＶｅｈｉｃｌｅｔｏＶｅｈｉｃｌｅ）通信、Ｖ２Ｐ（ＶｅｈｉｃｌｅｔｏＰｅｏｐｌｅ）通信のサービスを対象とする。
ウェアラブル機器向けのＦｅＤ２Ｄ（ＦｕｒｔｈｅｒｅｎｈａｎｃｅｍｅｎｔｓｔｏＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎＤ２Ｄ）：Ｒｅｌ-１４では、ＦｅＤ２Ｄはウェアラブル機器が携帯電話を介してネットワークにアクセスするシナリオに向けて研究され、主に低速で移動する且つ低電力でアクセスするシナリオを対象とする。

３ＧＰＰにおけるＤ２Ｄは、モードＡアーキテクチャ及びモードＢアーキテクチャという２種類のモードアーキテクチャ（ｍｏｄｅａｒｃｈｉｔｅｃｔｕｒｅ）に分けられることができる。

図１ａに示されたように、モードＡアーキテクチャは端末１、端末２及び基地局（ｅｖｏｌｖｅｄｎｏｄｅＢ、ｅＮＢ）を含む。当該端末１と端末２はそれぞれｅＮＢに接続されており、端末１と端末２は相互に接続されている。当該端末１と端末２の間の接続リンク（ｃｏｎｎｅｃｔｉｏｎｌｉｎｋ）はサイドリンク（ＳｉｄｅＬｉｎｋ、ＳＬ）であり、端末１とｅＮＢの間の接続リンクはダウンリンク（ｄｏｗｎｌｉｎｋ、ＤＬ）であり、端末２とｅＮＢの間の接続リンクはＤＬである。

図１ｂに示されたように、モードＢアーキテクチャは端末１、端末２及び基地局（ｅＮＢ）を含む。当該端末１と端末２は基地局に接続されず、端末１と端末２は相互に接続されている。当該端末１と端末２の間の接続リンクはＳＬである。

Ｄ２Ｄ通信では、バッファー状態レポート（ｂｕｆｆｅｒｓｔａｔｕｓｒｅｐｏｒｔ、ＢＳＲ）を報告する必要がある。ＵＥがＤ２Ｄ又はＶ２Ｘ通信を実行することはＢＳＲを介して報告される。異なるサービスに応え、ＢＳＲはアップリンクバッファー状態レポート（ｕｐｌｉｎｋｂｕｆｆｅｒｓｔａｔｕｓｒｅｐｏｒｔ、ＵＬＢＳＲ）とＳＬＢＳＲを含むことができる。

本発明の一つの実施形態はサイドリンクの実装方法を提供する。当該方法は端末によって実現される。当該端末は図１ａ又は図１ｂに示されたような端末１又は端末２であることができる。当該方法は図２ａに示されたように、以下のステップを含む。
ステップＳ２０１ａ、端末はＵＬＢＳＲよりＳＬＢＳＲを優先的に報告する。

上記ステップＳ２０１ａにおける報告対象が異なる可能性がある。例えば、一つの選択可能な実施形態において、当該ステップＳ２０１ａを実行する端末は、図１ａに示されたようなアーキテクチャに位置する。上記ステップＳ２０１ａの報告対象は端末２又はｅＮＢであることができる。もう一つの例を挙げると、別の選択可能な実施形態において、当該ステップＳ２０１ａを実行する端末は図１ｂに示されたようなアーキテクチャに位置する。上記ステップＳ２０１ａの報告対象は端末２であることができる。もちろん、具体的な実施形態は、上記具体的な報告方式に限定されていない。

本発明の一つの実施形態に係る技術方案において、ＵＬＢＳＲよりＳＬＢＳＲが優先的に報告されるように設定される。このようにして、実際のアプリケーションでは、ネットワーク側がＳＬＢＳＲを適時に取得することで、ＳＬデータの優先的な送信がサポートされる。

本発明の一つの実施形態において、ＵＬＢＳＲよりＳＬＢＳＲが優先的に報告されることは、以下のケースの任意の一つを含むことができる。

ケースＡでは、媒体アクセス制御（ｍｅｄｉａａｃｃｅｓｓｃｏｎｔｒｏｌ、ＭＡＣ）プロトコルデータユニット（ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ、ＰＤＵ）に、ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれる。

実際のアプリケーションでは、ＭＡＣＰＤＵにおけるＢＳＲを添加できるリソースに、ＳＬＢＳＲが優先的に添加され、次にＵＬＢＳＲが添加される。ＳＬＢＳＲが優先的にＭＡＣＰＤＵに含まれることは、ＳＬＢＳＲがＵＬＢＳＲより高い優先度を持つことを意味しており、ＭＡＣＰＤＵにおける他のデータとＢＳＲとの間の優先関係には影響しない。例えば、当該ＭＡＣＰＤＵはＢＳＲより高い優先度を持つデータαを有すると仮定すると、データαの優先度は依然としてＳＬＢＳＲ及びＵＬＢＳＲより高い。

ケースＢでは、ＭＡＣＰＤＵに第一の部分的なＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれる。

上記ケースＢにおける第一の部分的なＳＬＢＳＲはケースＡにおけるＳＬＢＳＲの部分的なデータである。

一つの選択可能な実施形態において、上記ケースＢにおける第一の部分的なＳＬＢＳＲは第一ＳＬＢＳＲを含んでもよい。もちろん、別の選択可能な実施形態において、上記ケースＢにおける第一の部分的なＳＬＢＳＲは、第一ＳＬＢＳＲ及び第二ＳＬＢＳＲの一部を含んでもよい。

上記第一ＳＬＢＳＲは設定された条件を満たすＳＬＢＳＲのデータであり、上記第二ＳＬＢＳＲは設定された条件を満たさないＳＬＢＳＲのデータである。上記第二ＳＬＢＳＲの一部は第二ＳＬＢＳＲの部分的なデータを含んでもよい。

ケースＣでは、ＭＡＣＰＤＵに第二の部分的なＳＬＢＳＲのみが含まれる。

上記ケースＣにおける第二の部分的なＳＬＢＳＲは、ケースＡにおけるＳＬＢＳＲの部分的なデータを含む。上記第一の部分的なＳＬＢＳＲは第二の部分的なＳＬＢＳＲと同じであってもよい。もちろん、異なるネットワークの状況において、上記第一の部分的なＳＬＢＳＲは第二の部分的なＳＬＢＳＲと異なってもよい。

上記ケースＣにおける第二の部分的なＳＬＢＳＲは第一ＳＬＢＳＲを含んでもよい。もちろん、ケースＣにおける第二の部分的なＳＬＢＳＲは第一ＳＬＢＳＲの一部を含んでもよい。上記ケースＣにおける第二の部分的なＳＬＢＳＲはさらに、第一ＳＬＢＳＲ、第二ＳＬＢＳＲの一部を含んでもよい。

ケースＤでは、ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲが含まれる。

実際のオペレーションでは、上記ケースＤは以下であることができる。ＭＡＣＰＤＵにおけるＢＳＲを添加できるリソースに、ＳＬＢＳＲが優先的に添加され、次にＵＬＢＳＲが添加され、最後に第二ＳＬＢＳＲが添加される。

ケースＥでは、ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲの一部が含まれる。

実際のオペレーションでは、上記ケースＥは以下であることができる。ＭＡＣＰＤＵにおけるＢＳＲを添加できるリソースに、ＳＬＢＳＲが優先的に添加され、次にＵＬＢＳＲが添加され、最後に第二ＳＬＢＳＲの一部が添加される。

別の実施形態において、本発明の実施形態はサイドリンクの実装方法を提供する。当該方法は端末によって実現される。当該端末は図１ａ又は図１ｂに示されたような端末１又は端末２であることができる。当該方法は図２ｂに示されたように、以下のステップを含む。
ステップＳ２０１ｂ、端末はリソースビット数を取得する。
ステップＳ２０２ｂ、端末は当該リソースビット数に基づいて、ＵＬＢＳＲよりＳＬＢＳＲが優先的に報告されると確定する。

本発明の別の実施形態に係る技術方案において、ＵＬＢＳＲよりＳＬＢＳＲが優先的に報告されるように設定される。このようにして、実際のアプリケーションでは、リソースビット数が限られている場合、ネットワーク側がＳＬＢＳＲを優先的に取得することで、ＳＬデータの優先的な送信がサポートされる。

別の実施形態の一つの選択可能な方案において、上記ステップＳ２０２ｂの実装方法は具体的に、以下のケースのうちの任意の一つであることができる。

ケースａ１、リソースビット数はＳＬＢＳＲとＵＬＢＳＲを携帯可能な条件を満たす。即ち、リソースビット数≧（ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）である。また、ＭＡＣＰＤＵに、ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれると確定する。

上記ケースａ１は、リソースビット数が比較的に多い場合のネットワークステータスを対象とする。この場合、リソースビット数は、ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たす。ケースａ１では、ＭＡＣＰＤＵにＳＬＢＳＲが優先的に携帯され、次にＵＬＢＳＲが携帯される。

ケースａ２では、リソースビット数は、ＳＬＢＳＲとＵＬＢＳＲを携帯可能な条件を満たす。即ち、リソースビット数≧（ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）である。また、ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲが含まれると確定する。

上記第一ＳＬＢＳＲ、第二ＳＬＢＳＲの定義については、ケースＢにおける記載を参照することができる。

上記ケースａ２は、リソースビット数が比較的に多い場合のネットワークステータスを対象とする。この場合、リソースビット数は、ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たす。ケースａ１では、ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に携帯され、次にＵＬＢＳＲが携帯され、最後に第二ＳＬＢＳＲが携帯される。ケースａ２では、主に、優先度の高い第一ＳＬＢＳＲをネットワーク側に報告することを保障し、次に、ＵＬＢＳＲをネットワーク側に報告することを保障し、最後に、優先度の低い第二ＳＬＢＳＲをネットワーク側に報告することを保障する。

ケースｂ１では、リソースビット数は、第一ＳＬＢＳＲとＵＬＢＳＲを携帯可能な条件を満たし、及び/又は、ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない。即ち、（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）≦リソースビット数＜（ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）、（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）≦リソースビット数、又は、リソースビット数＜（ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）である。また、ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲの一部が含まれると確定する。

上記ケースｂ１は、リソースビット数が比較的に多い（即ち、ｂ１におけるリソースビット数がケースａ１、ａ２におけるリソースビット数より少ない）場合のネットワークステータスを対象とする。この場合、リソースビット数は、ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさないが、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たす。ケースｂ１では、ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に携帯され、次にＵＬＢＳＲが携帯される。リソースビット数は、優先度が一番低い第二ＳＬＢＳＲを完全に携帯可能な条件を満たさないため、最後に、第二ＳＬＢＳＲの一部が携帯される。ケースｂ１では、主に、優先度の高い第一ＳＬＢＳＲをネットワーク側に報告することを保障し、次に、ＵＬＢＳＲをネットワーク側に報告することを保障し、最後に、優先度の低い第二ＳＬＢＳＲの一部をネットワーク側に報告することを保障する。

ケースｂ２では、リソースビット数は、第一ＳＬＢＳＲとＵＬＢＳＲを携帯可能な条件を満たし、及び/又は、ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない。即ち、（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）≦リソースビット数＜（ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）、（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）≦リソースビット数、又は、リソースビット数＜（ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）である。また、ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次に、ＵＬＢＳＲが含まれると確定する。

上記ケースｂ２におけるリソースビット数はケースｂ１におけるリソースビット数より少ない。この場合では、ｂ２におけるリソースビット数は、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たすが、第一ＳＬＢＳＲとＵＬＢＳＲを携帯するリソースビット以外に、ＭＡＣＰＤＵに残りのリソースビット数が少ない又はリソースビットが残されていないため、第二ＳＬＢＳＲを携帯することができない。

ケースｃ１では、リソースビット数は、第一ＳＬＢＳＲを携帯可能な条件を満たし、及び/又は、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない。即ち、第一ＳＬＢＳＲのビット数≦リソースビット数＜（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）、第一ＳＬＢＳＲのビット数≦リソースビット数、又は、リソースビット数＜（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）である。また、ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲの一部が含まれると確定する。

上記ケースｃ１におけるリソースビット数はケースｂ２におけるリソースビット数より少ない。この場合では、ケースｃ１におけるリソースビット数は第一ＳＬＢＳＲを完全に携帯可能な条件を満たすが、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない。このケースでは、ＭＡＣＰＤＵに優先度の高い第一ＳＬＢＳＲが優先的に携帯される。このケースでは、ＭＡＣＰＤＵにおける残りのリソースビットが全てのＵＬＢＳＲを携帯することができないため、ＭＡＣＰＤＵにＵＬＢＳＲの一部が携帯される。

ケースｃ２では、リソースビット数は、第一ＳＬＢＳＲを携帯可能な条件を満たし、及び/又は、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない。即ち、第一ＳＬＢＳＲのビット数≦リソースビット数＜（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）、第一ＳＬＢＳＲのビット数≦リソースビット数、又は、リソースビット数＜（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）である。また、ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次に第二ＳＬＢＳＲが含まれると確定する。

上記ケースｃ２におけるリソースビット数はケースｂ２におけるリソースビット数より少ない。この場合では、ケースｃ２におけるリソースビット数は第一ＳＬＢＳＲを完全に携帯可能な条件を満たすが、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない。このケースでは、ＭＡＣＰＤＵに優先度の高い第一ＳＬＢＳＲが優先的に携帯される。このケースでは、ＭＡＣＰＤＵに残りのビットが多い場合、ＭＡＣＰＤＵに第二ＳＬＢＳＲが携帯される。

ケースｃ３では、リソースビット数は、第一ＳＬＢＳＲを携帯可能な条件を満たし、及び/又は、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない。即ち、第一ＳＬＢＳＲのビット数≦リソースビット数＜（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）、第一ＳＬＢＳＲのビット数≦リソースビット数、又は、リソースビット数＜（第一ＳＬＢＳＲのビット数＋ＵＬＢＳＲのビット数）である。また、ＭＡＣＰＤＵに第一ＳＬＢＳＲのみが含まれると確定する。

上記ケースｃ３におけるリソースビット数は、ケースｃ１又はケースｃ２におけるリソースビット数より少ない。この場合では、ケースｃ３におけるリソースビット数は第一ＳＬＢＳＲを完全に携帯可能な条件を満たすが、ＵＬＢＳＲ又は第二ＳＬＢＳＲを完全に携帯可能な条件を満たさない。このケースでは、ＭＡＣＰＤＵに優先度の高い第一ＳＬＢＳＲが優先的に携帯される。ＭＡＣＰＤＵに残りのビットが少ない又はビットが残されず、残りのビットを埋めることができるため、当該ＭＡＣＰＤＵにＵＬＢＳＲ及び第二ＳＬＢＳＲがいずれも含まれることができない。

ケースｄでは、リソースビット数は、第一ＳＬＢＳＲを完全に携帯可能な条件を満たさない。即ち、リソースビット数＜第一ＳＬＢＳＲである。また、ＭＡＣＰＤＵに第一ＳＬＢＳＲの一部のみが含まれると確定する。

上記ケースｄにおけるリソースビット数は、上記ケースｃ３におけるリソースビット数より少ない。この場合では、ケースｄにおけるリソースビット数は第一ＳＬＢＳＲを完全に携帯可能な条件を満たさないため、ＭＡＣＰＤＵに第一ＳＬＢＳＲの一部のみが含まれると確定する。

上記第一ＳＬＢＳＲの一部は、第一ＳＬＢＳＲを切り取ることによって取得されることができる。もちろん、実際のアプリケーションでは、他の方式を用いることで第一ＳＬＢＳＲの一部を取得することができる。もちろん、上記第二ＳＬＢＳＲの一部は、上記第一ＳＬＢＳＲの一部を取得する方式によって取得されることができる。

上記図２ａ及び図２ｂに示された実施形態の設定された条件とは、ＳＬＢＳＲに関連する属性が属性要件を満たす場合、当該設定された条件が満たされると確定することを指す。上記ＳＬＢＳＲに関連する属性は、送信しようとするデータの属性、論理チャネルの属性、論理チャネルグループの属性、送信先アドレスの属性のうちの一つ又は任意の組み合わせであることができる。上記属性要件は、ネットワーク構成の属性要件、上層の表示（ｕｐｐｅｒｌａｙｅｒｉｎｄｉｃａｔｉｏｎ）の属性要件又は予めに構成された（ｐｒｅ－ｃｏｎｆｉｇｕｒｅｄ）属性要件であることができる。

ネットワーク構成の属性要件は具体的に、以下であることができる。図１ａに示されたようなネットワークシナリオに対して、当該ネットワーク構成の属性要件は、ｅＮＢが端末に送信するネットワーク構成の属性要件であることができる。上層の表示の属性要件は具体的に、以下であることができる。図１ｂに示されたようなネットワークシナリオに対して、当該上層の表示は、端末１又は端末２がリソースプールから選択したリソースビット数を含むことができる。次に、端末１が上層の表示を介して当該リソースビット数を確定する。予めに構成された属性要件は、工場出荷時の設定であることができる。もちろん、ユーザーによって予めに構成されてもよい。

図３を参照すると、本発明のもう一つの実施形態は、図２ａに示された実施形態及び図２ｂに示された実施形態を対象とするバッファー状態レポート（ＢＳＲ）タイマースキーム（ｔｉｍｅｒｓｃｈｅｍｅ）を提供する。プロトコルにおけるＳＬＢＳＲが、一つの実施形態と別の実施形態とでは異なるため、オリジナルのＢＳＲタイマースキームを変更する必要がある。従って、図２ａ及び図２ｂに示された実施形態に基づいて、本発明のもう一つの実施形態に、以下のステップが追加される。
ステップＳ３０１、第一ＳＬＢＳＲとマッチングするＢＳＲタイマースキームを実行する。

上記ステップＳ３０１の操作は、図２ａに示された実施形態におけるステップＳ２０１ａの操作の前に又は後に、実行されることができる。上記ステップＳ３０１の操作は、図２ｂに示された実施形態における任意のステップの操作の前に又は後に、実行されることができる。即ち、上記ステップＳ３０１の操作の実行は、図２ａ又は図２ｂに示された実施形態における任意のステップの操作の実行との間に論理的順序がない。

もう一つの実施形態における一つの選択可能な方案において、上記ステップＳ３０１は以下のように実現されることができる。
ＢＳＲタイマーは、第一ＢＳＲ又は第一ＢＳＲの一部が送信されたときに再起動し、当該ＢＳＲタイマーが時間制限を超えたときに第一ＢＳＲをトリガーし、当該ＢＳＲタイマーはサイドリンクグラント（ＳＬｇｒａｎｔ）を受信したときに再起動する。

上記第一ＢＳＲをトリガーすることは、第一ＢＳＲイベントをトリガーすることを含むが、それに限られていない。上記第一ＢＳＲイベントをトリガーすることは、
端末が第一ＢＳＲの関連データの準備をする又は開始することと、又は上記端末が第一ＢＳＲの一部の関連データの準備をする又は開始することと、
を含むが、それらに限られていない。

もう一つの実施形態における別の選択可能な方案において、上記ステップＳ３０１は以下のように実現されることができる。
ＢＳＲタイマーは、第一ＢＳＲ又は第一ＢＳＲの一部が送信されたときに再起動し、ＢＳＲタイマーが時間制限を超えたときにＳＬＢＳＲをトリガーする。

上記ＳＬＢＳＲをトリガーすることは、ＳＬＢＳＲイベントをトリガーすることを含むが、それに限られていない。上記ＳＬＢＳＲイベントをトリガーすることは、
端末がＳＬＢＳＲの関連データの準備をする又は開始することと、又は上記端末がＳＬＢＳＲの一部の関連データの準備をする又は開始することと、
を含むが、それらに限られていない。
当該ＳＬＢＳＲの一部は上記第一ＳＬＢＳＲであることができる。

図４を参照すると、本発明のもう一つの実施形態は、図２ａに示された実施形態及び図２ｂに示された実施形態を対象とするＳＬＢＳＲイベント処理スキームを提供する。プロトコルにおけるＳＬＢＳＲが、一つの実施形態と別の実施形態とでは異なるため、オリジナルのＢＳＲ処理スキームを変更する必要がある。従って、図２ａ及び図２ｂに示された実施形態に基づいて、本発明のもう一つの実施形態に、以下のステップが追加される。
ステップＳ４０１、第一ＳＬＢＳＲをトリガーする。
上記ステップＳ４０１における第一ＳＬＢＳＲをトリガーすることは、第一ＢＳＲの関連データの準備をする又は開始することと、又は第一ＢＳＲの一部の関連データの準備をする又は開始することとを含むが、それに限られていない。
ステップＳ４０２、第一ＳＬＢＳＲをトリガーした後、第一ＳＬＢＳＲに対応するＳＬＢＳＲイベントをキャンセルする。

上記ステップＳ４０１とステップＳ４０２の操作は、上記ステップＳ２０１ａの操作の前に実行されることができる。もちろん、上記ステップＳ４０１とステップＳ４０２の操作は、上記ステップＳ２０１ａの操作の後に実行されることができる。上記ステップＳ４０１とステップＳ４０２の操作は、上記ステップＳ２０２ｂの操作の前に実行されることができる。もちろん、上記ステップＳ４０１とステップＳ４０２の操作は、上記ステップＳ２０２ｂの操作の後に実行されることができる。

図５を参照すると、図５は一つの装置を提供する。当該装置は、ＵＬＢＳＲよりＳＬＢＳＲを優先的に報告するように構成されている報告ユニット５０１を含むことができる。

上記報告ユニット５０１がＵＬＢＳＲよりＳＬＢＳＲを優先的に報告する実現方式については、図２ａ又は図２ｂに示された実施形態の説明を参照することができる。ここでは繰り返さない。

一つの選択可能な実施形態において、上記装置は、第一ＳＬＢＳＲとマッチングするＢＳＲタイマースキームを実行するように構成されている実行ユニット５０２をさらに含むことができる。

上記ＢＳＲタイマースキームについては、図３に示された実施形態の説明を参照することができる。

図６を参照すると、図６はサイドリンク実装システムを提供する。システムは第一端末６０１及び第二端末６０２を含む。第一端末又は第二端末は、ＵＬＢＳＲよりＳＬＢＳＲを優先的に報告するように構成されている。

図７ａを参照すると、本発明の実施形態はサイドリンクの実装方法を提供する。当該方法は図１ａに示されたようなネットワークトポロジー構造のもとで実現される。図１ａに示されたように、上記端末１と端末２の間の通信のプロトコルは、ロングタームエボリューション（ｌｏｎｇｔｅｒｍｅｖｏｌｕｔｉｏｎ、ＬＴＥ）に基づくことができる。上記端末１と基地局との間の通信のプロトコル、又は端末２と基地局との間の通信のプロトコルは、ＬＴＥに基づくことができる。もちろん、実際のアプリケーションでは、上記端末１と端末２の間の通信のプロトコルは、ニューラジオ（ｎｅｗｒａｄｉｏ、ＮＲ）に基づくことができる。もちろん、上記端末１と基地局との間の通信のプロトコル、又は端末２と基地局との間の通信のプロトコルはＮＲに基づくことができる。図７ａに示されたように、当該方法は以下のステップを含むことができる。

ステップＳ７０１ａ、端末１は基地局にリソース要請メッセージを送信する。

ステップＳ７０２ａ、基地局は端末１にグラントリソース（ｇｒａｎｔｒｅｓｏｕｒｃｅ）を送信する。当該グラントリソースは端末が送信できるリソースビット数を表示するように構成されている。

ステップＳ７０３ａ、端末１はトリガーされたＢＳＲイベントに基づいて、第一ＳＬＢＳＲに必要な第一ビット量（ｂｉｔｑｕａｎｔｉｔｙ）ｘ１と、ＳＬＢＳＲに必要な第二ビット量ｘ２及びＵＬＢＳＲに必要な第三ビット量ｘ３のうちの少なくとも一つを確定する。

上記ＳＬＢＳＲのフォーマットは、異なるプロトコルフォーマットによって異なる。例えば、ＬＴＥプロトコルに基づく場合、当該ＳＬＢＳＲのフォーマットは表１に示されるようになる。

送信先インデックス_１（Ｄｅｓｔｉｎａｔｉｏｎｉｎｄｅｘ_１）は送信先アドレス１を示し、ＬＣＧＩＤ_１は論理チャネルグループ識別子（ｌｏｇｉｃａｌｃｈａｎｎｅｌｇｒｏｕｐｉｄｅｎｔｉｆｉｅｒ）を示し、バッファーサイズ_１（ＢｕｆｆｅｒＳｉｚｅ_１）はバッファー容量（Ｂｕｆｆｅｒｃａｐａｃｉｔｙ）１を示す。

例えば、ＮＲプロトコルに基づく場合、当該ＳＬＢＳＲのフォーマットは表２に示されるようになる。

上記表２における送信先インデックス（Ｄｅｓｔｉｎｄｅｘ）は送信先アドレスを示す。

ステップＳ７０４ａ、端末１は（ｘ２＋ｘ３）＞リソースビットにおけるＢＳＲを携帯可能なビットの数≧（ｘ１＋ｘ３）と確定し、ＭＡＣＰＤＵを生成する。また、当該ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれる。

ステップＳ７０５ａ、端末１は基地局に当該ＭＡＣＰＤＵを送信し、ＢＳＲタイマーを起動させる。

ステップＳ７０６ａ、基地局は端末１に当該ＭＡＣＰＤＵの応答を送信する。

ステップＳ７０７ａ、端末１は基地局が送信した当該ＭＡＣＰＤＵの応答を受信する。当該ＭＡＣＰＤＵの応答はＳＬグラントを含む場合、端末１は当該ＢＳＲタイマーを再起動させ、当該ＢＳＲイベントをキャンセルする。

本発明の別の実施形態に係る技術方案において、ＵＬＢＳＲよりＳＬＢＳＲが優先的に報告されるように設定される。このようにして、実際のアプリケーションでは、リソースビット数が限られている場合、ネットワーク側がＳＬＢＳＲを優先的に取得することで、ＳＬデータの送信がサポートされる。

図７ｂを参照すると、本発明の実施形態はデバイス通信に基づいたサイドリンクの実装方法を提供する。当該方法は図１ｂに示されたようなネットワークトポロジー構造のもとで実現される。図１ｂに示されたように、上記端末１と端末２の間の通信的プロトコはＬＴＥに基づくことができる。上記端末１と端末２の間の通信はＮＲに基づくことができる。図７ｂに示されたように、当該方法以下のステップを含むことができる。

ステップＳ７０１ｂ、端末１は端末２にリソース要請メッセージを送信する。

ステップＳ７０２ｂ、端末２は端末１にグラントリソースを送信する（当該グラントリソースはリソースプールから選択されたものであってもよい）。当該グラントリソースは、端末が送信できるリソースビット数を表示するように構成されている。

ステップＳ７０３ｂ、端末１はトリガーされたＢＳＲイベントに基づいて、第一ＳＬＢＳＲに必要な第一ビット量ｘ１と、ＳＬＢＳＲに必要な第二ビット量ｘ２及びＵＬＢＳＲに必要な第三ビット量ｘ３のうちの少なくとも一つを確定する。

ステップＳ７０４ｂ、端末１は、（ｘ１＋ｘ３）＞リソースビットにおけるＢＳＲを携帯可能なビットの数≧ｘ１と確定し、ＭＡＣＰＤＵを生成する。また、当該ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲの一部が含まれる。

ステップＳ７０５ｂ、端末１はＭＡＣＰＤＵを端末２に送信する。

ステップＳ７０６ｂ、端末１は端末２によって送信されるＳＬグラントを受信した後、当該ＢＳＲイベントをキャンセルする。

本発明の実施形態は、プロセッサとメモリを含む電子デバイスをさらに提供する。メモリは、プロセッサによって実行されるように構成された一つ又は複数のプログラムを格納するように構成されている。プログラムは、上記任意の一つの方法における操作を実行するために用いられる命令を含む。

本発明の実施形態は、コンピュータ可読記憶媒体をさらに提供する。当該コンピュータ可読記憶媒体は、電子データ交換（ｅｌｅｃｔｒｏｎｉｃｄａｔａｉｎｔｅｒｃｈａｎｇｅ、ＥＤＩ）のために用いられるコンピュータプログラムを格納する。コンピュータプログラムはコンピュータに、上記任意の一つの方法における操作を実行させる。

本発明の実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品は、コンピュータプログラムを格納する非一時的なコンピュータ可読記憶媒体を含む。コンピュータプログラムが実行されると、コンピュータに上記任意の一つの方法における操作を実行させる。

簡略化のために、前記した各実施形態は、一連の動作の組み合わせと表現されていることに留意されたい。しかしながら、本発明は説明された動作の順序に限定されず、本発明に基づいて、一部の操作が他の順序に従い、又は同時に実行されることができるということを当業者に理解されるべきである。また、明細書に記載された実施形態はいずれも代表的な実施形態であり、係わる動作とモジュールは必ずしも本発明に必要なものとは限らないということを当業者に理解されるべきである。

上記実施形態では、各実施形態の説明にはそれぞれ強調点がある。ある実施形態が詳しく説明されなかった場合は、他の実施形態の関連説明を参照できる。

本発明に係るいくつかの実施形態において、開示される装置は、他の形態により実現され得ると理解されるべきである。例えば、上記装置の実施形態は、例示的なものに過ぎない。例えば、ユニットの分割は、ロジック機能の分割に過ぎず、実際に実現される場合、別の分割形態を有してもよい。例えば、複数のユニット又はコンポーネントを組み合わせ、又は別のシステムに集積し、又は若干の特徴を無視し、又は実行しなくてもよい。さらに、示される又は検討される相互間の結合や直接結合や通信接続は、いくつかのインタフェース、装置、又はユニットによる間接結合や通信接続であってもよく、電気、又は他の形態であってもよい。

分離コンポーネントとして記載されたユニットは、物理的に分離してもよく、分離しなくてもよい。ユニットとして表示されるコンポーネントは、物理的なユニットであってもよく、物理的なユニットではなくてもよい。即ち、一つの場所に設置してもよく、複数のネットワークユニットに設置してもよい。実際のニーズに応じて一部又は全部のユニットを選択して本実施形態の技術方案の目的を実現することができる。

本実施形態に係る各機能ユニットは、１つの処理ユニットに集積されてもよいし、各ユニットが単独に物理的に存在してもよいし、２つ以上のユニットは１つのユニットに集積してもよい。上記の集積ユニットは、ハードウェア又はソフトウェア機能モジュールの形式で実現されることができる。

集積ユニットは、ソフトウェアのモジュールとして実現され、かつ、独立の製品として販売されたり使用されたりする場合、コンピュータ読み取り可能な記録媒体に記憶されてもよい。この理解によれば、本発明の技術方案について、本質的な部分、又は従来技術に貢献できた部分、又は当該技術方案の全部又は一部は、ソフトウェア製品として表現され得る。このコンピュータソフトウェア製品は、記憶媒体に記憶されており、１つのコンピュータ（パソコン、サーバー、又はネットワークデバイスなどであってもよい）に本発明の各実施形態に係る方法の全部又は一部のプロセスを実行させるための複数の命令を含む。上記記憶媒体は、ユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌｓｅｒｉａｌｂｕｓ、ＵＳＢ）フラッシュディスク、読み取り専用メモリ（Ｒｅａｄ－ＯｎｌｙＭｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ、ＲＡＭ）、モバイルハードディスク、磁気ディスク又は光ディスクなどの各種のプログラムコードを記憶可能な媒体を含む。

上記実施形態の各方法の一部又は全部の操作は、プログラムが関連ハードウェアを指示することによって完成され得るということを、当業者は理解できる。このプログラムはコンピュータ可読記憶媒体に格納されることができる。記憶媒体は、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク又は光ディスクなどを含むことができる。

以上は本発明の実施形態の詳しい説明である。明細書では、具体的な例を用いて本発明の原則と実施形態を説明した。上記実施形態の説明はただ本発明の方法とコアアイディアの理解を助けるために用いられる。同時に、当業者にとって、本発明のアイディアに基づいて、具体的な実施形態と応用範囲はいずれも変わるところがある。上記ように、本明細書は本発明を限定するものと理解されるべきではない。

図１ａに示されたように、モードＡアーキテクチャは端末１、端末２及び基地局（ｅｖｏｌｖｅｄｎｏｄｅＢ、ｅＮＢ）を含む。当該端末１と端末２はそれぞれｅＮＢに接続されており、端末１と端末２は相互に接続されている。当該端末１と端末２の間の接続リンク（ｃｏｎｎｅｃｔｉｏｎｌｉｎｋ）はサイドリンク（ＳｉｄｅＬｉｎｋ、ＳＬ）であり、端末１とｅＮＢの間の接続リンクはアップリンク（ｕｐｌｉｎｋ、ＵＬ）であり、端末２とｅＮＢの間の接続リンクはＵＬである。

上記ケースａ２は、リソースビット数が比較的に多い場合のネットワークステータスを対象とする。この場合、リソースビット数は、ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たす。ケースａ２では、ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に携帯され、次にＵＬＢＳＲが携帯され、最後に第二ＳＬＢＳＲが携帯される。ケースａ２では、主に、優先度の高い第一ＳＬＢＳＲをネットワーク側に報告することを保障し、次に、ＵＬＢＳＲをネットワーク側に報告することを保障し、最後に、優先度の低い第二ＳＬＢＳＲをネットワーク側に報告することを保障する。

ネットワーク構成の属性要件は具体的に、以下であることができる。図１ａに示されたようなネットワークシナリオに対して、当該ネットワーク構成の属性要件は、ｅＮＢが端末に送信するネットワーク構成の属性要件であることができる。上層の表示の属性要件は具体的に、以下であることができる。図１ｂに示されたようなネットワークシナリオに対して、当該上層の表示は、端末１又は端末２がリソースプールから選択したリソースビット数を含むことができる。次に、端末１が上層の表示を介して当該リソースビット数を確定する。予めに構成された属性要件は、工場出荷時の設定に含まれることができる。もちろん、ユーザーによって予めに構成されてもよい。

ステップＳ７０４ｂ、端末１は、（ｘ２＋ｘ３）＞リソースビットにおけるＢＳＲを携帯可能なビットの数≧ｘ１と確定し、ＭＡＣＰＤＵを生成する。また、当該ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲの一部が含まれる。

Claims

サイドリンクの実装方法であって、
アップリンクバッファー状態レポート（ＵＬＢＳＲ）よりサイドリンクバッファー状態レポート（ＳＬＢＳＲ）を優先的に報告することを含む、
ことを特徴とするサイドリンクの実装方法。
媒体アクセス制御（ＭＡＣ）プロトコルデータユニット（ＰＤＵ）に、ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、
又は、ＭＡＣＰＤＵに第一の部分的なＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、
又は、ＭＡＣＰＤＵに第二の部分的なＳＬＢＳＲのみが含まれる、
ことを特徴とする請求項１に記載の方法。
前記第一の部分的なＳＬＢＳＲとＵＬＢＳＲは第一ＳＬＢＳＲとＵＬＢＳＲを含み、
又は、前記第一の部分的なＳＬＢＳＲとＵＬＢＳＲは第一ＳＬＢＳＲ、第二ＳＬＢＳＲの一部とＵＬＢＳＲを含み、
前記第一ＳＬＢＳＲは設定された条件を満たすＳＬＢＳＲであり、前記第二ＳＬＢＳＲは設定された条件を満たさないＳＬＢＳＲである、
ことを特徴とする請求項２に記載の方法。
前記第二の部分的なＳＬＢＳＲは、
第一ＳＬＢＳＲ、
又は、第一ＳＬＢＳＲの一部、
又は、第一ＳＬＢＳＲと第二ＳＬＢＳＲの一部を含み、
前記第一ＳＬＢＳＲは設定された条件を満たすＳＬＢＳＲである、
ことを特徴とする請求項２に記載の方法。
ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲが含まれ、
又は、ＭＡＣＰＤＵに第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲの一部が含まれることを含み、
前記第一ＳＬＢＳＲは設定された条件を満たすＳＬＢＳＲであり、前記第二ＳＬＢＳＲは前記設定された条件を満たさないＳＬＢＳＲである、
ことを特徴とする請求項１に記載の方法。
リソースビット数はＳＬＢＳＲとＵＬＢＳＲを携帯可能な条件を満たす場合、
前記ＭＡＣＰＤＵに、ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれると確定し、
又は、前記ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲが含まれると確定することを含み、
前記第一ＳＬＢＳＲは前記設定された条件を満たすＳＬＢＳＲであり、前記第二ＳＬＢＳＲは前記設定された条件を満たさないＳＬＢＳＲである、
ことを特徴とする請求項１～５のいずれか一項に記載の方法。
リソースビット数は、第一ＳＬＢＳＲとＵＬＢＳＲを携帯可能な条件を満たし、及び/又は、ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない場合、
前記ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲが含まれ、その次に第二ＳＬＢＳＲの一部が含まれると確定し、
又は、前記ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次に、ＵＬＢＳＲが含まれると確定することを含み、
前記第一ＳＬＢＳＲは前記設定された条件を満たすＳＬＢＳＲであり、前記第二ＳＬＢＳＲは前記設定された条件を満たさないＳＬＢＳＲである、
ことを特徴とする請求項１～５のいずれか一項に記載の方法。
リソースビット数は、第一ＳＬＢＳＲを携帯可能な条件を満たし、及び/又は、第一ＳＬＢＳＲとＵＬＢＳＲを完全に携帯可能な条件を満たさない場合、
前記ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次にＵＬＢＳＲの一部が含まれると確定し、
又は、前記ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次に第二ＳＬＢＳＲが含まれると確定し、
又は、前記ＭＡＣＰＤＵに、第一ＳＬＢＳＲが優先的に含まれ、次に第二ＳＬＢＳＲの一部が含まれると確定し、
又は、前記ＭＡＣＰＤＵに第一ＳＬＢＳＲのみが含まれると確定することを含み、
前記第一ＳＬＢＳＲは前記設定された条件を満たすＳＬＢＳＲであり、前記第二ＳＬＢＳＲは前記設定された条件を満たさないＳＬＢＳＲである、
ことを特徴とする請求項１～５のいずれか一項に記載の方法。
リソースビット数は、第一ＳＬＢＳＲを完全に携帯可能な条件を満たさない場合、
前記ＭＡＣＰＤＵに第一ＳＬＢＳＲの一部のみが含まれると確定することを含み、
前記第一ＳＬＢＳＲは前記設定された条件を満たすＳＬＢＳＲである、
ことを特徴とする請求項１～５のいずれか一項に記載の方法。
前記設定された条件は、ＳＬＢＳＲに関連する属性が属性要件を満たすことを含み、
前記ＳＬＢＳＲに関連する属性は、
送信しようとするデータの属性、論理チャネルの属性、論理チャネルグループの属性、送信先アドレスの属性のうちの一つ又は任意の組み合わせを含む、
ことを特徴とする請求項３～９のいずれか一項に記載の方法。
前記属性要件は、ネットワーク構成の属性要件、上層の表示の属性要件又は予めに構成された属性要件を含む、
ことを特徴とする請求項１０に記載の方法。
第一ＳＬＢＳＲとマッチングするＢＳＲタイマースキームを実行することを含む、
ことを特徴とする請求項１～１１のいずれか一項に記載の方法。
前記ＢＳＲタイマースキームは、
前記ＢＳＲタイマーが、第一ＢＳＲ又は第一ＢＳＲの一部が送信されたときに再起動することと、前記ＢＳＲタイマーが時間制限を超えたときに前記第一ＢＳＲをトリガーすることと、前記ＢＳＲタイマーが、サイドリンクグラントを受信したときに再起動することとを含み、
前記第一ＳＬＢＳＲは前記設定された条件を満たすＳＬＢＳＲである、
ことを特徴とする請求項１２に記載の方法。
前記ＢＳＲタイマースキームは、
ＢＳＲタイマーが、第一ＢＳＲ又は第一ＢＳＲの一部が送信されたときに再起動することと、ＢＳＲタイマーが時間制限を超えたときにＳＬＢＳＲをトリガーすることとを含む、
ことを特徴とする請求項１２に記載の方法。
第一ＳＬＢＳＲをトリガーしたときに、第一ＳＬＢＳＲに対応するＳＬＢＳＲイベントをキャンセルすることを含む、
ことを特徴とする請求項１～９のいずれか一項に記載の方法。
装置であって、
アップリンクバッファー状態レポート（ＵＬＢＳＲ）よりサイドリンクバッファー状態レポート（ＳＬＢＳＲ）を優先的に報告するように構成されている報告ユニットを含む、
ことを特徴とする装置。
グラントリソースの数に基づいて、前記ＵＬＢＳＲより前記ＳＬＢＳＲを優先的に報告すると確定する、
ことを特徴とする請求項１６に記載の装置。
電子デバイスであって、
プロセッサとメモリを含み、
前記メモリは、前記プロセッサによって実行されるように構成された一つ又は複数のプログラムを格納するように構成されており、前記プログラムは、請求項１～１５のいずれか一項に記載の方法における操作を実行するために用いられる命令を含む、
ことを特徴とする電子デバイス。
コンピュータ可読記憶媒体であって、
電子データ交換のために用いられるコンピュータプログラムを格納しており、前記コンピュータプログラムはコンピュータに、請求項１～１５のいずれか一項に記載の方法を実行させる、
ことを特徴とするコンピュータ可読記憶媒体。
コンピュータプログラム製品であって、
コンピュータプログラムを格納する非一時的なコンピュータ可読記憶媒体を含み、前記コンピュータプログラムが実行されると、コンピュータに請求項１～１５のいずれか一項に記載の方法を実行させる、
ことを特徴とするコンピュータプログラム製品。