▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-11-07
(45)【発行日】2022-11-15
(54)【発明の名称】ユーザ機器及び方法
(51)【国際特許分類】
H04W 72/10 20090101AFI20221108BHJP
H04W 92/18 20090101ALI20221108BHJP
【ＦＩ】
H04W72/10
H04W92/18
【請求項の数】
14
(21)【出願番号】P 2021087562
(22)【出願日】2021-05-25
(62)【分割の表示】P 2020013593の分割
【原出願日】2015-12-21
(65)【公開番号】P2021122154
(43)【公開日】2021-08-26
【審査請求日】2021-05-25
(31)【優先権主張番号】15153298.3
(32)【優先日】2015-01-30
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】15167898.4
(32)【優先日】2015-05-15
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】ローア ヨアキム
(72)【発明者】
【氏名】バス マリック プラティーク
(72)【発明者】
【氏名】堀 貴子
(72)【発明者】
【氏名】鈴木 秀俊
【審査官】三枝 保裕
(56)【参考文献】
【文献】ZTE，Some considerations for D2D communication[online]，3GPP TSG-RAN WG2#85 R2-140695，2014年02月14日
【文献】Ericsson，ProSe communication and Group priority[online]，3GPP TSG-RAN WG2#88 R2-145137，2014年11月21日
【文献】ZTE Corporation，Contents of D2D BSR[online]，3GPP TSG-RAN WG2#87 R2-143603，2014年08月22日
【文献】Vice-Chair (InterDigital)，Report of the LTE break-out session (ProSe and eDRX)[online]，3GPP TSG-RAN WG2#91 R2-153885，2015年08月28日
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－ ７／２６
Ｈ０４Ｗ ４／００－９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
ユーザ機器であって、サイドリンク宛先グループに設定される複数のサイドリンク論理チャネルに含まれる各サイドリンク論理チャネルに対する論理チャネル優先度を取得する処理と、
送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最も高い前記論理チャネル優先度を有するサイドリンク論理チャネルが帰属するサイドリンク宛先グループを複数のサイドリンク宛先グループから選択し、
前記選択したサイドリンク宛先グループに帰属する前記各サイドリンク論理チャネルに対して前記論理チャネル優先度の降順に無線リソースを割り当てるスケジューリング処理と、を制御する制御部と、
前記割り当てられた無線リソースを用いてサイドリンクデータを送信する送信部と、
を有する、ユーザ機器。
【請求項2】
前記論理チャネル優先度は、データ宛先の前記サイドリンク宛先グループと関連づけられる宛先グループ優先度、
搬送されるデータの種類に従ってグループ化される一群の論理チャネルと関連づけられる論理チャネルグループ優先度、
前記ユーザ機器の地理的位置、
前記ユーザ機器が動作している緊急レベル、および、
ユーザ機器識別子、
の少なくとも１つに依存する、
請求項１に記載のユーザ機器。
【請求項3】
前記制御部は、前記無線通信システムの近接サービス（ＰｒｏＳｅ）エンティティにおけるＰｒｏＳｅ機能によって決定される前記各サイドリンク論理チャネルに対する前記論理チャネル優先度のインジケーションを受信し、前記論理チャネル優先度を記憶する受信処理をさらに制御する、請求項１に記載のユーザ機器。
【請求項4】
前記スケジューリング処理は、前記サイドリンク論理チャネルに対する前記論理チャネル優先度を決定する、請求項１に記載のユーザ機器。
【請求項5】
前記制御部は、前記サイドリンク論理チャネルに対して送信されるべきデータを記憶するバッファを有し、
前記論理チャネル優先度の自身の再計算に基づいて、または、ＰｒｏＳｅ機能から受信される指令に基づいて、前記サイドリンク論理チャネルに対する現在の論理チャネル優先度を修正された論理チャネル優先度に修正する優先度設定処理を、をさらに制御する、
請求項１から４のいずれか一項に記載のユーザ機器。
【請求項6】
前記制御部は、修正前に前記バッファに記憶された前記データを、前記現在の論理チャネル優先度が前記修正された論理チャネル優先度より高いか否か、前記修正された論理チャネル優先度のレベル、および、修正の原因、の少なくとも１つに応じて、フラッシュするか、または、前記現在の論理チャネル優先度で送信するかのいずれかの処理を制御する、請求項５に記載のユーザ機器。
【請求項7】
前記制御部は、前記ユーザ機器が前記無線通信システムのユーザ機器の中でデータを送信するように選択されるか否かを判定し、
前記ユーザ機器が選択されない場合、前記サイドリンク論理チャネルを停止し、
データ発信ユーザ機器が選択された場合、前記先だって停止されたサイドリンク論理チャネルを再開する、フロア制御処理をさらに制御し、
前記スケジューリング処理は、選択し、リソースを割り当てるためには前記停止された論理チャネルを考慮しない、
請求項１から６のいずれか一項に記載のユーザ機器。
【請求項8】
前記フロア制御処理は、前記ユーザ機器間、および／または、ＭＡＣより上のレイヤにおける近接サービス（ＰｒｏＳｅ）エンティティ間の前記無線通信システムで交換されるメッセージに従って、前記ユーザ機器がデータを送信するべきか否かを決定し、前記ユーザ機器がデータを送信するべきでないと決定した上で、前記ユーザ機器は、スケジューリング割当ておよび対応するデータの１回の送信に対応する期間であるサイドリンク制御期間内で自身のデータおよび／またはサイドリンク制御情報の送信を停止する、
請求項７に記載のユーザ機器。
【請求項9】
前記フロア制御処理は、別のユーザ機器から受信される、物理レイヤ上のサイドリンク制御情報またはメディアアクセス制御（ＭＡＣ）プロトコルデータユニット（ＰＤＵ）から、ユーザ機器優先度インジケータを抽出し、前記ユーザ機器優先度インジケータは、前記ユーザ機器または前記ユーザ機器によって送信されるべき前記データの優先度を示し、前記抽出したユーザ機器優先度インジケータを、前記ユーザ機器に記憶される自身のユーザ機器優先度または送信されるべき前記データの優先度と比較し、
前記自身のユーザ機器優先度が前記抽出したユーザ機器優先度より低い場合、前記ユーザ機器が前記送信のために選択されないと判定する、
請求項７または８に記載のユーザ機器。
【請求項10】
前記ユーザ機器がフロアを有し、同時に、より高いユーザ機器優先度を持つ別のユーザ機器からのサイドリンク制御情報を受信した場合、前記フロア制御処理は、前記送信を停止し、前記別のユーザ機器にフロアを委譲する、請求項９に記載のユーザ機器。
【請求項11】
前記ユーザ機器優先度は、前記ＭＡＣ ＰＤＵのＭＡＣヘッダ内で通知され、前記無線通信システムの近接サービス（ＰｒｏＳｅ）エンティティによって設定される、請求項９または１０に記載のユーザ機器。
【請求項12】
前記制御部は、前記論理チャネル優先度と関連づけられるバッファの状況を前記無線通信システムのネットワークノードに報告するためのバッファ状況報告処理をさらに制御する、請求項１から１１のいずれか一項に記載のユーザ機器。
【請求項13】
前記スケジューリング処理は、リソースプールから前記データの前記送信のために割り当てられるべき前記リソースを選択するように、および前記宛先グループ優先度または前記データが送信されるべきサイドリンク論理チャネルと関連づけられる論理チャネル優先度に従って複数のリソースプールの中の前記リソースプールを選択する、請求項２に記載のユーザ機器。
【請求項14】
ユーザ機器によって実行される方法であって、前記方法は、サイドリンク宛先グループに設定される複数のサイドリンク論理チャネルに含まれる各サイドリンク論理チャネルに対する論理チャネル優先度を取得し、
送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最も高い前記論理チャネル優先度を有するサイドリンク論理チャネルが帰属するサイドリンク宛先グループを複数のサイドリンク宛先グループから選択し、
前記選択したサイドリンク宛先グループに帰属する前記各サイドリンク論理チャネルに対して前記論理チャネル優先度の降順に無線リソースを割り当てるスケジューリング処理を制御し、
前記割り当てられた無線リソースを用いてサイドリンクデータを送信する、
を含む、方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、論理チャネル優先順位付け手順（logical channel prioritization procedure）を行う場合にサイドリンク論理チャネル（sidelink logical channels）に無線リソースを割り当てるためのユーザ機器及び方法に関する。
【背景技術】
【0002】
＜ロングタームエボリューション（ＬＴＥ：Long Term Evolution）＞
ロングタームエボリューションの仕様が、第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）ユニバーサル移動体地上ネットワーク（Universal Mobile Terrestrial Network）に続くシステムとしてのＲｅｌｅａｓｅ８（ＬＴＥ Ｒｅｌ．８）として完成された。ＬＴＥシステムは、低遅延および低コストでフルＩＰベースの機能性を提供する効率的なパケットベースの無線アクセスを提供する。ＬＴＥでは、所与のスペクトルを用いて柔軟なシステム展開を達成するために、１．４、３．０、５．０、１０．０、１５．０および２０．０ＭＨｚなどのスケーラブルな複数の送信帯域幅が設定される。ダウンリンクでは、直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）ベースの無線アクセスが、低シンボルレートによるマルチパス干渉（ＭＰＩ）に対するその固有の耐性、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）の使用、および異なる送信帯域幅の配置に対するその親和性のために採用された。ユーザ機器（ＵＥ：User Equipment）の制限される送信電力を考慮すると、ピークデータレートの向上よりも広域カバレージを備えることが優先されるため、アップリンクではシングルキャリア周波数分割多元接続（ＳＣ－ＦＤＭＡ：Single-Carrier Frequency Division Multiple Access）ベースの無線アクセスが採用された。ＬＴＥ Ｒｅｌ．８／９では、多くの主要なパケット無線アクセス技法が、ＭＩＭＯ（Multiple Input Multiple Output）チャネル送信技術を含めて利用され、高効率の制御シグナリング構造が達成される。
ロングタームエボリューションの仕様が、第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）ユニバーサル移動体地上ネットワーク（Universal Mobile Terrestrial Network）に続くシステムとしてのＲｅｌｅａｓｅ８（ＬＴＥ Ｒｅｌ．８）として完成された。ＬＴＥシステムは、低遅延および低コストでフルＩＰベースの機能性を提供する効率的なパケットベースの無線アクセスを提供する。ＬＴＥでは、所与のスペクトルを用いて柔軟なシステム展開を達成するために、１．４、３．０、５．０、１０．０、１５．０および２０．０ＭＨｚなどのスケーラブルな複数の送信帯域幅が設定される。ダウンリンクでは、直交周波数分割多重（ＯＦＤＭ：Orthogonal Frequency Division Multiplexing）ベースの無線アクセスが、低シンボルレートによるマルチパス干渉（ＭＰＩ）に対するその固有の耐性、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）の使用、および異なる送信帯域幅の配置に対するその親和性のために採用された。ユーザ機器（ＵＥ：User Equipment）の制限される送信電力を考慮すると、ピークデータレートの向上よりも広域カバレージを備えることが優先されるため、アップリンクではシングルキャリア周波数分割多元接続（ＳＣ－ＦＤＭＡ：Single-Carrier Frequency Division Multiple Access）ベースの無線アクセスが採用された。ＬＴＥ Ｒｅｌ．８／９では、多くの主要なパケット無線アクセス技法が、ＭＩＭＯ（Multiple Input Multiple Output）チャネル送信技術を含めて利用され、高効率の制御シグナリング構造が達成される。
【0003】
＜ＬＴＥアーキテクチャ＞
全体的なアーキテクチャを図１に示し、Ｅ－ＵＴＲＡＮアーキテクチャのより詳細な表現を図２に示す。Ｅ－ＵＴＲＡＮはｅＮｏｄｅＢから構成され、ユーザ機器（ＵＥ）に向けたＥ－ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルの終端および制御プレーン（ＲＲＣ）プロトコルの終端を提供する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）および、ユーザプレーンヘッダ圧縮および暗号化の機能を含むパケットデータ制御プロトコル（ＰＤＣＰ）レイヤをホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッションコントロール、スケジューリング、ネゴシエートされたアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／解読、ならびにダウンリンク／アップリンクユーザプレーンパケットヘッダの圧縮／解凍を含む多くの機能を行う。ｅＮｏｄｅＢは、Ｘ２インタフェースを用いて相互接続される。
全体的なアーキテクチャを図１に示し、Ｅ－ＵＴＲＡＮアーキテクチャのより詳細な表現を図２に示す。Ｅ－ＵＴＲＡＮはｅＮｏｄｅＢから構成され、ユーザ機器（ＵＥ）に向けたＥ－ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルの終端および制御プレーン（ＲＲＣ）プロトコルの終端を提供する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）、メディアアクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）および、ユーザプレーンヘッダ圧縮および暗号化の機能を含むパケットデータ制御プロトコル（ＰＤＣＰ）レイヤをホストする。ｅＮｏｄｅＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮｏｄｅＢは、無線リソース管理、アドミッションコントロール、スケジューリング、ネゴシエートされたアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報ブロードキャスト、ユーザおよび制御プレーンデータの暗号化／解読、ならびにダウンリンク／アップリンクユーザプレーンパケットヘッダの圧縮／解凍を含む多くの機能を行う。ｅＮｏｄｅＢは、Ｘ２インタフェースを用いて相互接続される。
【0004】
ｅＮｏｄｅＢはまた、Ｓ１インタフェースを用いてＥＰＣ（Evolved Packet Core）に、より詳細には、Ｓ１－ＭＭＥを用いてＭＭＥ（Mobility Management Entity）に接続され、Ｓ１－Ｕを用いてサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続される。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多の関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングおよび転送する一方で、ｅＮｏｄｅＢ間でのハンドオーバ中にユーザプレーンのためのモビリティアンカとして、および、（Ｓ４インタフェースを終端し、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間のトラヒックを中継する）ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカとして機能する。アイドル（Idle）状態のユーザ機器に対しては、ＳＧＷはダウンリンクデータを終端し、ユーザ機器に対してダウンリンクデータが到着するとページングをトリガする。ＳＧＷはユーザ機器コンテキスト、例えば、ＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報を管理および記憶する。ＳＧＷは、合法的傍受の場合にはユーザトラヒックの複製も行う。
【0005】
ＭＭＥは、ＬＴＥアクセスネットワークにとって主要な制御ノードである。ＭＭＥは、再送を含むアイドルモードのユーザ機器のトラッキングおよびページング手順に対する役割を担う。ＭＭＥはベアラアクティブ化／非アクティブ化プロセスに関与し、かつ初期アタッチ時およびコアネットワーク（ＣＮ：Core Network）ノード再配置を伴うＬＴＥ内ハンドオーバ時にユーザ機器に対するＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥで終端し、ＭＭＥは一時的な識別子の生成およびユーザ機器への割当ての役割も担う。ＭＭＥは、サービスプロバイダのＰＬＭＮ（Public Land Mobile Network）にキャンプするためにユーザ機器の認証を確認し、ユーザ機器のローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングに対する暗号化／整合性保護のためのネットワークにおける終端点であり、セキュリティキー管理を扱う。シグナリングの合法的傍受もＭＭＥによってサポートされる。ＭＭＥは、Ｓ３インタフェースがＳＧＳＮからＭＭＥで終端して、ＬＴＥおよび２Ｇ／３Ｇアクセスネットワーク間のモビリティのための制御プレーン機能も提供する。ＭＭＥは、ローミングユーザ機器に対してホームＨＳＳに向けたＳ６ａインタフェースも終端する。
【0006】
＜ＬＴＥにおけるコンポーネントキャリア構造＞
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間－周波数領域で、いわゆるサブフレームに分割される。３ＧＰＰ ＬＴＥでは、各サブフレームは２つのダウンリンクスロットに分割され、ここでは第１のダウンリンクスロットは第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは時間領域で所与の数のＯＦＤＭシンボル（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では１２または１４個のＯＦＤＭシンボル）から成り、ここでは各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に渡る。ＯＦＤＭシンボルは、したがって各々、図３にも図示するように、それぞれのサブキャリアで送信されるいくつかの変調シンボルから成る。
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、時間－周波数領域で、いわゆるサブフレームに分割される。３ＧＰＰ ＬＴＥでは、各サブフレームは２つのダウンリンクスロットに分割され、ここでは第１のダウンリンクスロットは第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは時間領域で所与の数のＯＦＤＭシンボル（３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では１２または１４個のＯＦＤＭシンボル）から成り、ここでは各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に渡る。ＯＦＤＭシンボルは、したがって各々、図３にも図示するように、それぞれのサブキャリアで送信されるいくつかの変調シンボルから成る。
【0007】
例えば、３ＧＰＰ ＬＴＥに使用されるような、ＯＦＤＭを利用するマルチキャリア通信システムを前提とすると、スケジューラによって割り当てられることができるリソースの最小単位は１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Physical Resource Block）は、時間領域では連続するＯＦＤＭシンボル（例えば７つのＯＦＤＭシンボル）、および、周波数領域では図３に例示するように連続するサブキャリア（例えばコンポーネントキャリアにとして１２個のサブキャリア）として定義される。３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８）では、物理リソースブロックはリソースエレメントから成り、時間領域では１つのスロットに、かつ周波数領域では１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細については、例えばｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献１の６．２節を参照のこと）。
【0008】
１つのサブフレームは２つのスロットから成り、その結果、いわゆる「通常（normal）」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレームに１４個のＯＦＤＭシンボルがあり、いわゆる「拡張（extended）」ＣＰが使用されるときにはサブフレームに１２個のＯＦＤＭシンボルがある。専門用語のために、以下では、サブフレーム全体に渡る同じ連続するサブキャリアに相当する時間－周波数リソースを、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ぶ。
【0009】
「コンポーネントキャリア」という用語は、周波数領域でのいくつかのリソースブロックの組合せを指す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、代わりに専門用語は、ダウンリンクおよび任意選択でアップリンクリソースの組合せを指す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間の関連づけ（リンキング）は、ダウンリンクリソースで送信されるシステム情報に示される。
【0010】
コンポーネントキャリア構造に対する同様の前提が、後のリリースにも当てはまる。
【0011】
＜より広帯域幅のサポートのためのＬＴＥ－Ａでのキャリアアグリゲーション＞
Ｒｅｌｅａｓｅ１０以降のＬＴＥで利用可能なキャリアアグリゲーションでは、１００ＭＨｚまでのより広い送信帯域幅をサポートするために、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥシステムでのいくつかのセルがアグリゲートされて、たとえＬＴＥでのこれらのセルが異なる周波数帯にあるとしても、１００ＭＨｚに対して十分に広いＬＴＥ－Ａｄｖａｎｃｅｄシステムでの１つのより広いチャネルになる。
Ｒｅｌｅａｓｅ１０以降のＬＴＥで利用可能なキャリアアグリゲーションでは、１００ＭＨｚまでのより広い送信帯域幅をサポートするために、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥシステムでのいくつかのセルがアグリゲートされて、たとえＬＴＥでのこれらのセルが異なる周波数帯にあるとしても、１００ＭＨｚに対して十分に広いＬＴＥ－Ａｄｖａｎｃｅｄシステムでの１つのより広いチャネルになる。
【0012】
すべてのコンポーネントキャリアは、少なくともコンポーネントキャリアの帯域幅がＬＴＥ Ｒｅｌ．８／９セルのサポートされる帯域幅を超えない場合、ＬＴＥ Ｒｅｌ．８／９互換性があるように構成されることができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＲｅｌ．８／９互換性があるわけではなくてもよい。現存のメカニズム（例えば禁止（ｂａｒｒｉｎｇ））を使用して、Ｒｅｌ－８／９ユーザ機器がコンポーネントキャリアにキャンプすることを回避してもよい。
【0013】
ユーザ機器は、その能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信してもよい。キャリアアグリゲーションのための受信および／または送信能力を持つＬＴＥ－Ａ Ｒｅｌ．１０ユーザ機器は、複数のサービングセルで同時に受信および／または送信することができる一方で、ＬＴＥ Ｒｅｌ．８／９ユーザ機器は、コンポーネントキャリアの構造がＲｅｌ．８／９仕様に従うとの条件で、単一のサービングセルのみで受信および送信することができる。
【0014】
キャリアアグリゲーションは連続および非連続コンポーネントキャリア両方に対してサポートされるが、各コンポーネントキャリアは３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）のニューメロロジー（numerology）を用いて周波数領域で最大で１１０個のリソースブロックに制限される。３ＧＰＰ ＬＴＥ－Ａ（Ｒｅｌｅａｓｅ１０）互換のユーザ機器を、同じｅＮｏｄｅＢ（基地局）から発信し、かつ場合によりアップリンクおよびダウンリンクで異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように構成することが可能である。構成することができるダウンリンクコンポーネントキャリアの数はＵＥのダウンリンクアグリゲーション能力に依存する。反対に、構成することができるアップリンクコンポーネントキャリアの数はＵＥのアップリンクアグリゲーション能力に依存する。移動端末をダウンリンクコンポーネントキャリアよりアップリンクコンポーネントキャリアが多くなるように構成することは、現在、可能でなくてもよい。
【0015】
連続してアグリゲートされるコンポーネントキャリアの中心周波数間の間隔は３００ｋＨｚの倍数であるものとする。これは、３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）の１００ｋＨｚ周波数ラスタ（raster）と互換性があり、かつ同時に１５ｋＨｚ間隔を持つサブキャリアの直交性を保持するためである。アグリゲーションシナリオに応じて、ｎ＊３００ｋＨｚ間隔は、連続したコンポーネントキャリア間への少数の未使用サブキャリアの挿入によって容易にされることができる。
【0016】
複数のキャリアのアグリゲーションの性質は、ＭＡＣレイヤまでしか明らかにされていない。アップリンクおよびダウンリンク両方に関して、各アグリゲートされるコンポーネントキャリアごとにＭＡＣで１つのＨＡＲＱエンティティが必要とされる。（アップリンクに対するＳＵ－ＭＩＭＯの不在下では）コンポーネントキャリア当たり多くとも１つのトランスポートブロックがある。トランスポートブロックおよびその潜在的なＨＡＲＱ再送信は同じコンポーネントキャリアにマッピングされる必要がある。
【0017】
＜ＬＴＥレイヤ２－ユーザプレーンおよび制御プレーンプロトコルスタック＞
ＬＴＥレイヤ２ユーザプレーン／制御プレーンプロトコルスタックは、図４に図示するような３つのサブレイヤ（ＰＤＣＰ、ＲＬＣおよびＭＡＣ）を備える。送信側では、各レイヤは、レイヤがサービスを提供する上位レイヤからサービスデータユニット（ＳＤＵ）を受け取り、下位のレイヤにＰＤＵを出力する。ＲＬＣレイヤはＰＤＣＰレイヤからパケットを受け取る。これらのパケットは、ＰＤＣＰの観点からはＰＤＣＰ ＰＤＵと呼ばれ、ＲＬＣの観点からはＲＬＣ ＳＤＵを表す。ＲＬＣレイヤは、下位のレイヤ、すなわちＭＡＣレイヤに提供されるパケットを作成する。ＲＬＣによってＭＡＣレイヤに提供されるパケットは、ＲＬＣの観点からはＲＬＣ ＰＤＵ、ＭＡＣの観点からはＭＡＣ ＳＤＵである。
ＬＴＥレイヤ２ユーザプレーン／制御プレーンプロトコルスタックは、図４に図示するような３つのサブレイヤ（ＰＤＣＰ、ＲＬＣおよびＭＡＣ）を備える。送信側では、各レイヤは、レイヤがサービスを提供する上位レイヤからサービスデータユニット（ＳＤＵ）を受け取り、下位のレイヤにＰＤＵを出力する。ＲＬＣレイヤはＰＤＣＰレイヤからパケットを受け取る。これらのパケットは、ＰＤＣＰの観点からはＰＤＣＰ ＰＤＵと呼ばれ、ＲＬＣの観点からはＲＬＣ ＳＤＵを表す。ＲＬＣレイヤは、下位のレイヤ、すなわちＭＡＣレイヤに提供されるパケットを作成する。ＲＬＣによってＭＡＣレイヤに提供されるパケットは、ＲＬＣの観点からはＲＬＣ ＰＤＵ、ＭＡＣの観点からはＭＡＣ ＳＤＵである。
【0018】
受信側では、プロセスは反転され、各レイヤが上位のレイヤにＳＤＵを渡し、上位のレイヤでＳＤＵはＰＤＵとして受け取られる。
【0019】
物理レイヤが本質的に、ターボ符号化および巡回冗長検査（ＣＲＣ：Cyclic Redundancy Check）によって保護されるビットパイプ（bitpipe）を提供する一方で、リンクレイヤプロトコルは上昇した信頼性、安全性および整合性によって上位のレイヤに対するサービスを強化する。加えて、リンクレイヤは、マルチユーザのメディアアクセスおよびスケジューリングの役割を担う。ＬＴＥリンクレイヤ設計に対する主な課題の１つは、広範囲の異なるサービスおよびデータレートを持つインターネットプロトコル（ＩＰ：Internet Protocol）データフローに、必要とされる信頼性レベルおよび遅延を提供することである。特に、プロトコルオーバーヘッドが比例しなければならない。例えば、ボイスオーバーＩＰ（ＶｏＩＰ：Voice over IP）フローが１００ｍｓ程度の遅延および１パーセントまでのパケットロスを許容することができると広く思われている。他方では、ＴＣＰファイルダウンロードが低帯域幅遅延積を持つリンクを通じてよりよく作動することが周知である。結果的に、超高データレート（例えば、１００Ｍｂ／ｓ）でのダウンロードは一層低い遅延を必要とし、加えて、ＶｏＩＰトラヒックよりＩＰパケットロスに影響される。
【0020】
全体として、この課題は、部分的に結び付けられるＬＴＥリンクレイヤの３つのサブレイヤによって達成される。
【0021】
パケットデータ収束プロトコル（ＰＤＣＰ：Packet Data Convergence Protocol）サブレイヤは主に、ＩＰヘッダ圧縮および暗号化の役割を担う。加えて、ＰＤＣＰサブレイヤは、ｅＮＢ間ハンドオーバの場合には無損失のモビリティをサポートし、上位レイヤ制御プロトコルに整合性保護を提供する。
【0022】
無線リンク制御（ＲＬＣ：Radio Link Control）サブレイヤは、主にＡＲＱ機能を備え、データセグメンテーションおよび連結をサポートする。後者の２つは、データレートから独立したプロトコルオーバーヘッドを最小化する。
【0023】
最後に、メディアアクセス制御（ＭＡＣ：Medium Access Control）サブレイヤはＨＡＲＱを提供し、スケジューリング動作およびランダムアクセスなどのメディアアクセスのために必要とされる機能の役割を担う。図５は、物理レイヤまでのリンクレイヤプロトコルを通してのＩＰパケットのデータフローを例示的に描く。図は、各プロトコルサブレイヤがデータユニットにそれ自体のプロトコルヘッダを追加することを示す。
【0024】
＜ＬＴＥのためのアップリンクアクセス方式＞
アップリンク送信について、カバレージ（coverage）を最大化するのに電力効率の良いユーザ端末送信が必要である。動的帯域幅割当てを伴うＦＤＭＡと組み合わされるシングルキャリア送信が、進化型ＵＴＲＡアップリンク送信方式として選択されている。各時間間隔中に、ＮｏｄｅＢが、ユーザデータを送信するための固有の時間／周波数リソースをユーザに割り当て、それによってセル内直交性を保証する。アップリンクでの直交アクセスは、セル内干渉を排除することによって上昇したスペクトル効率を約束する。マルチパス伝搬による干渉は、送信信号へのサイクリックプレフィックスの挿入によって補助されて基地局（ＮｏｄｅＢ）で処理される。
アップリンク送信について、カバレージ（coverage）を最大化するのに電力効率の良いユーザ端末送信が必要である。動的帯域幅割当てを伴うＦＤＭＡと組み合わされるシングルキャリア送信が、進化型ＵＴＲＡアップリンク送信方式として選択されている。各時間間隔中に、ＮｏｄｅＢが、ユーザデータを送信するための固有の時間／周波数リソースをユーザに割り当て、それによってセル内直交性を保証する。アップリンクでの直交アクセスは、セル内干渉を排除することによって上昇したスペクトル効率を約束する。マルチパス伝搬による干渉は、送信信号へのサイクリックプレフィックスの挿入によって補助されて基地局（ＮｏｄｅＢ）で処理される。
【0025】
データ送信のために使用される基本的な物理リソースは１つの時間間隔、例えば０．５ｍｓのサブフレームの間のサイズＢＷｇｒａｎｔの周波数リソースから成り、その上に符号化情報ビットがマッピングされる。送信時間間隔（ＴＴＩ：Transmission Time Interval）とも称されるサブフレームがユーザデータ送信のための最小時間間隔であることに留意するべきである。しかしながら、サブフレームの連結によってユーザに１つのＴＴＩより長い時限に渡って周波数リソースＢＷｇｒａｎｔを割り当てることが可能である。
【0026】
＜ＬＴＥのためのＵＬスケジューリング方式＞
アップリンク方式は、スケジュールされる、すなわちｅＮＢによって制御されるアクセスおよび競合ベースのアクセスの両方を許容する。
アップリンク方式は、スケジュールされる、すなわちｅＮＢによって制御されるアクセスおよび競合ベースのアクセスの両方を許容する。
【0027】
スケジュールされるアクセスの場合には、ＵＥは、アップリンクデータ送信のために一定の時間に渡る一定の周波数リソース（すなわち時間／周波数リソース）を割り当てられる。しかしながら、いくらかの時間／周波数リソースは競合ベースのアクセスのために割り当てられることができる。これらの時間／周波数リソース内で、ＵＥは、最初にスケジュールされることなく送信することができる。ＵＥが競合ベースのアクセスをしている１つのシナリオは、例えばランダムアクセス、すなわちＵＥがセルへのまたはアップリンクリソースを要求するための初期アクセスを行っているときである。
【0028】
スケジュールされるアクセスに関して、ＮｏｄｅＢスケジューラは、ユーザにアップリンクデータ送信のための固有の周波数／時間リソースを割り当てる。より詳細には、スケジューラは、どのＵＥが送信するのを許容されるか、送信のために移動端末によって使用されるべき物理チャネルリソース（周波数）およびトランスポート形式（変調符号化方式（ＭＣＳ：Modulation Coding Scheme））を決定する。
【0029】
割当て情報は、Ｌ１／Ｌ２制御チャネル（以下で「アップリンクグラントチャネル」と呼ばれる）で送信されるスケジューリンググラントを介してＵＥにシグナリングされる。スケジューリンググラントメッセージは、ＵＥが周波数帯域のどの部分を使用するのを許容されるかという情報、グラントの有効期間、およびＵＥが来るべきアップリンク送信のために使用しなければならないトランスポート形式を含む。最短有効期間は１つのサブフレームである。選択される方式に応じて、ＵＥに対するグラントメッセージに付加情報も含まれてもよい。ＵＥは次いで、割り当てられたリソースをなんらかの規則に従ってその無線ベアラに分配する。ｅＮＢはなんらかの情報、例えば報告されるスケジューリング情報およびＱｏＳ情報に基づいてトランスポート形式を決定し、ＵＥは選択されたトランスポート形式に従わなければならない。サービス品質を決定するためには、無線リソースのスケジューリングが共用チャネルアクセスネットワークで最も重要な機能であるので、効率的なＱｏＳ管理を許容するために、ＬＴＥのためのＵＬスケジューリング方式によって果たされるべきであるいくつかの要件がある。
【0030】
－ 低優先度サービスの枯渇が回避されるべきである。枯渇は、高優先度論理チャネルからのデータがすべてのＭＡＣ ＰＤＵスペースを占めるため、低優先度論理チャネルからのデータが送信されることができないことを意味する。
－ 無線ベアラ／サービスに対する明白なＱｏＳ区別がスケジューリング方式によってサポートされるべきである。
－ ｅＮＢスケジューラがどの無線ベアラ／サービスについてデータが送信されるべきかを識別するのを許容するために、ＵＬ報告は微粒（fine granular）のバッファ報告（例えば無線ベアラごとまたは無線ベアラグループごと）を許容するべきである。
－ 異なるユーザのサービス間の明白なＱｏＳ区別をすることが可能であるべきである。
－ 無線ベアラごとに最小ビットレートを提供することが可能であるべきである。
－ 無線ベアラ／サービスに対する明白なＱｏＳ区別がスケジューリング方式によってサポートされるべきである。
－ ｅＮＢスケジューラがどの無線ベアラ／サービスについてデータが送信されるべきかを識別するのを許容するために、ＵＬ報告は微粒（fine granular）のバッファ報告（例えば無線ベアラごとまたは無線ベアラグループごと）を許容するべきである。
－ 異なるユーザのサービス間の明白なＱｏＳ区別をすることが可能であるべきである。
－ 無線ベアラごとに最小ビットレートを提供することが可能であるべきである。
【0031】
上記の列記から分かるように、ＬＴＥスケジューリング方式の１つの本質的な態様は、事業者が異なるＱｏＳクラスの無線ベアラ間でそのアグリゲートされたセル容量の分割を制御することができるメカニズムを提供することである。
【0032】
＜論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順＞
アップリンクについて、ＵＥが割り当てられた無線リソースを使用して送信するＭＡＣ ＰＤＵを作成するプロセスは完全に標準化され、これは最適でかつ異なるＵＥ実装間で一貫した方途でＵＥが各構成された無線ベアラのＱｏＳを充足することを保証するように構成される。ＰＤＣＣＨでシグナリングされるアップリンク送信リソースグラントメッセージに基づいて、ＵＥは、新たなＭＡＣに含まれるべき各論理チャネルに対するデータ量を決定しなければならず、必要ならば、ＭＡＣ制御要素のためにスペースも割り当てなければならない。
アップリンクについて、ＵＥが割り当てられた無線リソースを使用して送信するＭＡＣ ＰＤＵを作成するプロセスは完全に標準化され、これは最適でかつ異なるＵＥ実装間で一貫した方途でＵＥが各構成された無線ベアラのＱｏＳを充足することを保証するように構成される。ＰＤＣＣＨでシグナリングされるアップリンク送信リソースグラントメッセージに基づいて、ＵＥは、新たなＭＡＣに含まれるべき各論理チャネルに対するデータ量を決定しなければならず、必要ならば、ＭＡＣ制御要素のためにスペースも割り当てなければならない。
【0033】
複数の論理チャネルからのデータでＭＡＣ ＰＤＵを構築する際、最も単純かつ最も直観的な方法は絶対優先度ベースの方法であり、この方法ではＭＡＣ ＰＤＵスペースは論理チャネル優先度の降順に論理チャネルに割り当てられる。つまり、最高優先度の論理チャネルからのデータがＭＡＣ ＰＤＵで最初に扱われ、次の最高優先度の論理チャネルからのデータが後続し、ＭＡＣ ＰＤＵスペースが尽きるまで続く。絶対優先度ベースの方法はＵＥ実装の点で非常に単純であるとは言え、その方法は時には低優先度の論理チャネルからのデータの枯渇につながる。
【0034】
ＬＴＥでは、重要性の順にデータを送信するが、しかしより低い優先度を持つデータの枯渇を回避もするために、優先ビットレート（ＰＢＲ：Prioritized Bit Rate）が各論理チャネルに対して規定される。ＰＢＲは、論理チャネルに対して保証される最小データレートである。たとえ論理チャネルが低優先度を有するとしても、ＰＢＲを保証するために、少なくとも小量のＭＡＣ ＰＤＵスペースが割り当てられる。したがって、ＰＢＲを使用することによって、枯渇の問題は回避されることができる。
【0035】
ＰＢＲを持つＭＡＣ ＰＤＵを構築することは、２つのラウンドから成る。第１のラウンドでは、各論理チャネルは論理チャネル優先度の降順に扱われるが、ＭＡＣ ＰＤＵに含まれる各論理チャネルからのデータ量は、最初、論理チャネルの設定されたＰＢＲ値に対応する量に制限される。すべての論理チャネルがそれらのＰＢＲ値まで扱われた後、ＭＡＣ ＰＤＵに残された余地があれば、第２のラウンドが行われる。第２のラウンドでは、各論理チャネルは優先度の降順に再び扱われる。第１のラウンドと比較した第２のラウンドについての大きな違いは、より高い優先度のすべての論理チャネルがもはや送信するデータを有しない場合だけ、より低い優先度の各論理チャネルがＭＡＣ ＰＤＵスペースを割り当てられることができることである。
【0036】
ＭＡＣ ＰＤＵは、各設定された論理チャネルからのＭＡＣ ＳＤＵだけでなくＭＡＣ ＣＥ（制御要素）も含んでもよい。パディングＢＳＲ（バッファ状況報告）を除いて、ＭＡＣ ＣＥは、それがＭＡＣレイヤの動作を制御するので、論理チャネルからのＭＡＣ ＳＤＵより高い優先度を有する。したがって、ＭＡＣ ＰＤＵが構成されるとき、ＭＡＣ ＣＥが存在すれば、それが含まれるべき最初のものであり、残りのスペースが論理チャネルからのＭＡＣ ＳＤＵのために使用される。次いで、追加のスペースが残され、それがＢＳＲを含むのに十分大きければ、パディングＢＳＲがトリガされてＭＡＣ ＰＤＵに含められる。
【0037】
アップリンクのための論理チャネル優先順位付けは、例えばｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ本明細書に援用される非特許文献２（最新バージョンｖ１２．４．０）の５．４．３．１節に標準化される。
【0038】
論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）手順は、トランスポートブロックの新たな送信が行われるときに（すなわち同じデータの再送信時にではなく）適用される。
【0039】
ＲＲＣは、各論理チャネルに対するシグナリングによって、アップリンクデータのスケジューリングを制御する：
－ 大きい優先度値ほど低い優先度レベルを示すpriority、
－ 優先ビットレート（ＰＢＲ：Prioritized Bit Rate）を設定するprioritisedBitRate、
－ バケットサイズ継続時間（ＢＳＤ：Bucket Size Duration）を設定するbucketSizeDuration。
－ 大きい優先度値ほど低い優先度レベルを示すpriority、
－ 優先ビットレート（ＰＢＲ：Prioritized Bit Rate）を設定するprioritisedBitRate、
－ バケットサイズ継続時間（ＢＳＤ：Bucket Size Duration）を設定するbucketSizeDuration。
【0040】
ＵＥは、各論理チャネルｊのための変数Ｂｊを維持するものとする。Ｂｊは、関連した論理チャネルが確立されるときにゼロに初期化され、各ＴＴＩごとに積ＰＢＲ×ＴＴＩ継続時間だけインクリメントされるものとし、ここでＰＢＲは論理チャネルｊの優先ビットレートである。しかしながら、Ｂｊの値は決してバケットサイズを超えることができず、Ｂｊの値が論理チャネルｊのバケットサイズより大きければ、Ｂｊの値はバケットサイズに設定されるものとする。論理チャネルのバケットサイズはＰＢＲ＊ＢＳＤに等しく、ここでＰＢＲおよびＢＳＤは上位のレイヤによって設定される。
【0041】
ＵＥ（ＭＡＣエンティティ）は、新たな送信が行われるときに以下の論理チャネル優先順位付け手順を行うものとする：
－ ＵＥ（ＭＡＣエンティティ）は、以下のステップで論理チャネルにリソースを割り当てるものとする：
－－ ステップ１：Ｂｊ＞０のすべての論理チャネルが優先度降順にリソースを割り当てられる。無線ベアラのＰＢＲが「無限大」に設定されれば、ＵＥは、より低い優先度無線ベアラのＰＢＲを満たす前に、無線ベアラでの送信のために利用可能であるすべてのデータのためにリソースを割り当てるものとする。
－－ ステップ２：ＵＥ（ＭＡＣエンティティ）は、ステップ１で論理チャネルｊに分配されるＭＡＣ ＳＤＵの総サイズだけＢｊをデクリメントするものとする。
注：Ｂｊの値は負でありえる。
－－ ステップ３：任意のリソースが残れば、どちらが先にせよその論理チャネルのためのデータかまたはＵＬグラントかいずれかが尽きるまで、すべての論理チャネルが（Ｂｊの値に関係なく）厳密な優先度降順に扱われる。等しい優先度が設定される論理チャネルは等しく扱われるべきである。
－ ＵＥ（ＭＡＣエンティティ）は、以下のステップで論理チャネルにリソースを割り当てるものとする：
－－ ステップ１：Ｂｊ＞０のすべての論理チャネルが優先度降順にリソースを割り当てられる。無線ベアラのＰＢＲが「無限大」に設定されれば、ＵＥは、より低い優先度無線ベアラのＰＢＲを満たす前に、無線ベアラでの送信のために利用可能であるすべてのデータのためにリソースを割り当てるものとする。
－－ ステップ２：ＵＥ（ＭＡＣエンティティ）は、ステップ１で論理チャネルｊに分配されるＭＡＣ ＳＤＵの総サイズだけＢｊをデクリメントするものとする。
注：Ｂｊの値は負でありえる。
－－ ステップ３：任意のリソースが残れば、どちらが先にせよその論理チャネルのためのデータかまたはＵＬグラントかいずれかが尽きるまで、すべての論理チャネルが（Ｂｊの値に関係なく）厳密な優先度降順に扱われる。等しい優先度が設定される論理チャネルは等しく扱われるべきである。
【0042】
－ ＵＥ（ＭＡＣエンティティ）は、以上のスケジューリング手順の間、以下の規則にも従うものとする：
－－ ＵＥ（ＭＡＣエンティティ）は、全体のＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）をセグメント化するべきでない。
－－ ＵＥ（ＭＡＣエンティティ）が論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする。
－－ ＵＥ（ＭＡＣエンティティ）はデータの送信を最大化するべきである。
－－ ＵＥ（ＭＡＣエンティティ）が、送信のために利用可能なデータを有しつつ、４バイト以上であるＵＬグラントサイズを与えられれば、ＵＥ（ＭＡＣエンティティ）は、パディングＢＳＲおよび／またはパディングのみを送信することはしないものとする（ＵＬグラントサイズが７バイト未満であり、かつＡＭＤ ＰＤＵセグメントが送信される必要がある場合を除く）。
－－ ＵＥ（ＭＡＣエンティティ）は、全体のＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵもしくは再送信されるＲＬＣ ＰＤＵ）をセグメント化するべきでない。
－－ ＵＥ（ＭＡＣエンティティ）が論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする。
－－ ＵＥ（ＭＡＣエンティティ）はデータの送信を最大化するべきである。
－－ ＵＥ（ＭＡＣエンティティ）が、送信のために利用可能なデータを有しつつ、４バイト以上であるＵＬグラントサイズを与えられれば、ＵＥ（ＭＡＣエンティティ）は、パディングＢＳＲおよび／またはパディングのみを送信することはしないものとする（ＵＬグラントサイズが７バイト未満であり、かつＡＭＤ ＰＤＵセグメントが送信される必要がある場合を除く）。
【0043】
ＵＥは、停止されている無線ベアラに対応する論理チャネルのためのデータを送信しないものとする（無線ベアラが停止されていると考えられるときの条件は、ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能である非特許文献３に規定される）。
【0044】
論理チャネル優先順位付け手順に関して、ＵＥは以下の相対的優先度を降順に考慮するものとする：
－ Ｃ－ＲＮＴＩに関するＭＡＣ制御要素またはＵＬ－ＣＣＣＨからのデータ；
－ パディングのために含まれるＢＳＲを除くＢＳＲに関するＭＡＣ制御要素；
－ ＰＨＲもしくは拡張ＰＨＲまたは二重接続ＰＨＲに関するＭＡＣ制御要素；
－ ＵＬ－ＣＣＣＨからのデータを除く、任意の論理チャネルからのデータ；
－ パディングのために含まれるＢＳＲに関するＭＡＣ制御要素。
－ Ｃ－ＲＮＴＩに関するＭＡＣ制御要素またはＵＬ－ＣＣＣＨからのデータ；
－ パディングのために含まれるＢＳＲを除くＢＳＲに関するＭＡＣ制御要素；
－ ＰＨＲもしくは拡張ＰＨＲまたは二重接続ＰＨＲに関するＭＡＣ制御要素；
－ ＵＬ－ＣＣＣＨからのデータを除く、任意の論理チャネルからのデータ；
－ パディングのために含まれるＢＳＲに関するＭＡＣ制御要素。
【0045】
ＵＥが１つのＴＴＩに複数のＭＡＣ ＰＤＵを送信するように要求されるとき、ステップ１～３および関連する規則が各グラントに独立してか、またはグラントの容量の和にかいずれかで適用されてもよい。また、グラントが処理される順序は、ＵＥ実装次第である。ＵＥが１つのＴＴＩに複数のＭＡＣ ＰＤＵを送信するように要求されるとき、どのＭＡＣ ＰＤＵにＭＡＣ制御要素が含まれるか決定することはＵＥ実装次第である。
【0046】
＜バッファ状況報告＞
スケジューリングの通例のモードは、ダウンリンク送信リソースの割当てのためのダウンリンク割当てメッセージおよびアップリンク送信リソースの割当てのためのアップリンクグラントメッセージを用いた、動的スケジューリングであり、これらのメッセージは通例、特定の単一のサブフレームに対して有効である。それらのメッセージは、ＵＥのＣ－ＲＮＴＩを使用してＰＤＣＣＨで送信される。動的スケジューリングは、ＴＣＰなど、トラヒックのレートがバースト的かつ動的であるサービス種類に対して効率的である。
スケジューリングの通例のモードは、ダウンリンク送信リソースの割当てのためのダウンリンク割当てメッセージおよびアップリンク送信リソースの割当てのためのアップリンクグラントメッセージを用いた、動的スケジューリングであり、これらのメッセージは通例、特定の単一のサブフレームに対して有効である。それらのメッセージは、ＵＥのＣ－ＲＮＴＩを使用してＰＤＣＣＨで送信される。動的スケジューリングは、ＴＣＰなど、トラヒックのレートがバースト的かつ動的であるサービス種類に対して効率的である。
【0047】
動的スケジューリングに加えて、永続スケジューリング（persistent scheduling）が規定され、これは無線リソースが半静的に設定されて１つのサブフレームより長い時限の間ＵＥに割り当てられることを可能にし、したがって各サブフレームに対するＰＤＣＣＨ上での特定のダウンリンク割当てメッセージまたはアップリンクグラントメッセージの必要性を回避する。永続スケジューリングは、データパケットのサイズが小さく、周期的でかつ半静的であるＶｏＩＰなどのサービスに対して有用である。したがって、ＰＤＣＣＨのオーバーヘッドは、動的スケジューリングの場合と比較して著しく低減される。
【0048】
ｅＮｏｄｅＢがアップリンクリソースを割り当てること、すなわちアップリンクスケジューリングを支援するために、ＵＥからｅＮｏｄｅＢへのバッファ状況報告（ＢＳＲ：Buffer Status Reports）が使用される。ダウンリンクの場合に関して、ｅＮＢスケジューラは各ＵＥに配信されるべきデータ量を明らかに認識しているが、しかしながら、アップリンク方向に関しては、スケジューリング決定がｅＮＢで行われ、データのためのバッファがＵＥにあるので、ＵＬ－ＳＣＨを通じて送信される必要があるデータ量を示すために、ＵＥからｅＮＢにＢＳＲが送信されなければならない。
【0049】
ＬＴＥのためのバッファ状況報告ＭＡＣ制御要素は、長いＢＳＲ（ＬＣＧ ＩＤ＃０～３に対応する４つのバッファサイズフィールドを持つ）か、または、短いＢＳＲ（１つのＬＣＧ ＩＤフィールドおよび１つの対応するバッファサイズフィールドを持つ）かいずれかから成る。バッファサイズフィールドは、論理チャネルグループのすべての論理チャネルに渡って利用可能な総データ量を示し、異なるバッファサイズレベルの指標として符合化されるバイト数で示される（ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献２のバージョン１２．４．０の６．１．３．１節も参照のこと）。
【0050】
短いまたは長いＢＳＲいずれかのどちらのＢＳＲがＵＥによって送信されるかは、トランスポートブロックでの利用可能な送信リソース、どれくらいの論理チャネルのグループが空でないバッファを有するか、および、特定のイベントがＵＥでトリガされるかどうか、に依存する。長いＢＳＲが４つの論理チャネルグループのためのデータ量を報告する一方で、短いＢＳＲは最高の論理チャネルグループのみのためにバッファされるデータ量を示す。
【0051】
論理チャネルグループ概念を導入する理由は、たとえＵＥが５つ以上の論理チャネルを設定されてもよいとしても、各個々の論理チャネルに対するバッファ状況を報告することが、あまりに多くのシグナリングオーバーヘッドを引き起こすだろうということである。したがって、ｅＮＢは各論理チャネルを論理チャネルグループに割り当て、好ましくは同じ／同様のＱｏＳ要件を持つ論理チャネルが同じ論理チャネルグループ内に割り当てられるべきである。
【0052】
送信失敗に対してロバストであるために、ＬＴＥにＢＳＲ再送信メカニズムが規定されており、アップリンクグラントが再開されるたびに再送信ＢＳＲタイマが始動または再始動され、再送信ＢＳＲタイマが満了する前にアップリンクグラントが受信されなければ、別のＢＳＲがＵＥによってトリガされる。
【0053】
ＢＳＲは、以下のイベントなどについてトリガされる。
－ バッファが空でない（すなわちバッファが先だってデータを含んだ）論理チャネルより高い優先度を有する論理チャネルに対してデータが到着するたびに、
－ 送信のために利用可能なデータが先だってない（すなわちすべてのバッファが先だって空になる）ときに任意の論理チャネルのためにデータが利用可能になるたびに、
－ 再送信ＢＳＲタイマが満了するたびに、
－ 定期的なＢＳＲ報告が予定される、すなわちｐｅｒｉｏｄｉｃＢＳＲタイマが満了するたびに、
－ ＢＳＲを収容することができる予備のスペースがトランスポートブロックにあるたびに。
－ バッファが空でない（すなわちバッファが先だってデータを含んだ）論理チャネルより高い優先度を有する論理チャネルに対してデータが到着するたびに、
－ 送信のために利用可能なデータが先だってない（すなわちすべてのバッファが先だって空になる）ときに任意の論理チャネルのためにデータが利用可能になるたびに、
－ 再送信ＢＳＲタイマが満了するたびに、
－ 定期的なＢＳＲ報告が予定される、すなわちｐｅｒｉｏｄｉｃＢＳＲタイマが満了するたびに、
－ ＢＳＲを収容することができる予備のスペースがトランスポートブロックにあるたびに。
【0054】
ＢＳＲおよび特にそれをトリガすることに関するより詳細な情報が、ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献２のバージョン１２．４．０の５．４．５節に説明される。
【0055】
ＢＳＲがトリガされるときに、ＵＥがトランスポートブロックにＢＳＲを含むために割り当てられるアップリンクリソースを有しなければ、ＵＥは、ＢＳＲを送信するアップリンクリソースを割り当てられるように、ｅＮｏｄｅＢにスケジューリング要求（ＳＲ：Scheduling Request）を送信する。単一ビットスケジューリング要求がＰＵＣＣＨを通じて送信される（個別スケジューリング要求、Ｄ－ＳＲ：Dedicated Scheduling Request）か、またはランダムアクセス手順（ＲＡＣＨ：Random Access Procedure）が行われるかいずれかで、ＢＳＲを送信するためのアップリンク無線リソースの割当てを要求する。
【0056】
＜ＬＴＥデバイスツーデバイス（Ｄ２Ｄ：Device to Device）近接サービス（ＰｒｏＳｅ：Proximity Services）＞
事業者およびユーザにとって関心があろう商用サービスおよび公安（Public Safety）に関連したサービスを含む領域で、近接ベースのアプリケーションが使用されてもよい。デバイスツーデバイス（Ｄ２Ｄ：Device to Device）通信は、任意の基地局を通るトラヒックのないユーザ端末間の直接通信を可能にするＬＴＥ－Ｒｅｌ．１２のための技術要素である。デバイスツーデバイス（Ｄ２Ｄ：Device to Device）通信技術は、セルラネットワークに対するアンダーレイとしてのＤ２Ｄがスペクトル効率を上昇させるのを許容する。例えば、セルラネットワークがＬＴＥであれば、すべてのデータ通知用物理チャネルはＤ２ＤシグナリングのためにＳＣ－ＦＤＭＡを使用する。
事業者およびユーザにとって関心があろう商用サービスおよび公安（Public Safety）に関連したサービスを含む領域で、近接ベースのアプリケーションが使用されてもよい。デバイスツーデバイス（Ｄ２Ｄ：Device to Device）通信は、任意の基地局を通るトラヒックのないユーザ端末間の直接通信を可能にするＬＴＥ－Ｒｅｌ．１２のための技術要素である。デバイスツーデバイス（Ｄ２Ｄ：Device to Device）通信技術は、セルラネットワークに対するアンダーレイとしてのＤ２Ｄがスペクトル効率を上昇させるのを許容する。例えば、セルラネットワークがＬＴＥであれば、すべてのデータ通知用物理チャネルはＤ２ＤシグナリングのためにＳＣ－ＦＤＭＡを使用する。
【0057】
＜ＬＴＥでのＤ２Ｄ通信＞
ＬＴＥでのＤ２Ｄ通信は２つの領域：発見および通信に重点を置いている。
ＰｒｏＳｅ（近接ベースのサービス）直接発見（Direct Discovery）は、ＰｒｏＳｅ対応ＵＥによって、ＰＣ５インタフェースを介してＥ－ＵＴＲＡ直接無線信号を使用してその近接の他のＰｒｏＳｅ対応ＵＥを発見するために使用される手順として規定される。図６は、ＵＥ ＡとＵＥ Ｂとの間のデバイスツーデバイス直接発見のためのＰＣ５インタフェースを概略的に例示する。図６は、物理レイヤ、Ｌ２無線プロトコル（ＭＡＣであることができる）および「上位レイヤ」のＰｒｏＳｅプロトコルを含むＰｒｏＳｅ直接発見のための無線プロトコルスタック（ＡＳ）も概略的に例示する。
ＬＴＥでのＤ２Ｄ通信は２つの領域：発見および通信に重点を置いている。
ＰｒｏＳｅ（近接ベースのサービス）直接発見（Direct Discovery）は、ＰｒｏＳｅ対応ＵＥによって、ＰＣ５インタフェースを介してＥ－ＵＴＲＡ直接無線信号を使用してその近接の他のＰｒｏＳｅ対応ＵＥを発見するために使用される手順として規定される。図６は、ＵＥ ＡとＵＥ Ｂとの間のデバイスツーデバイス直接発見のためのＰＣ５インタフェースを概略的に例示する。図６は、物理レイヤ、Ｌ２無線プロトコル（ＭＡＣであることができる）および「上位レイヤ」のＰｒｏＳｅプロトコルを含むＰｒｏＳｅ直接発見のための無線プロトコルスタック（ＡＳ）も概略的に例示する。
【0058】
Ｄ２Ｄ通信では、ＵＥは、基地局（ＢＳ：Base Station）を通しての代わりにセルラリソースを使用する直接リンクを通じて互いにデータ信号を送信する。Ｄ２Ｄユーザは、ＢＳ下で制御されたまま、すなわち少なくともｅＮＢのカバレージにいるときに直接通信する。したがって、Ｄ２Ｄは、セルラリソースを再使用することによってシステム性能を向上させることができる。
【0059】
Ｄ２Ｄは、（ＦＤＤの場合）アップリンクＬＴＥスペクトル、または、（カバレージ外の場合を除き、ＴＤＤの場合）カバレージを与えるセルのアップリンクサブフレームで動作することを前提とする。さらには、Ｄ２Ｄ送信／受信は所与のキャリアで全二重を使用しない。個々のＵＥの観点から、所与のキャリアで、Ｄ２Ｄ信号受信およびＬＴＥアップリンク送信は全二重を使用しない、すなわちＤ２Ｄ信号受信およびＬＴＥ ＵＬ送信の同時は不可能である。
【0060】
Ｄ２Ｄ通信では、１つの特定のＵＥ１が送信の役割を有するとき（送信ユーザ機器または送信端末）、ＵＥ１はデータを送信し、別のＵＥ２（受信ユーザ機器）がそのデータを受信する。ＵＥ１およびＵＥ２はそれらの送信および受信役割を交換することができる。ＵＥ１からの送信は、ＵＥ２のような１つまたは複数のＵＥによって受信されることができる。
【0061】
ユーザプレーンプロトコルに関して、以下にＤ２Ｄ通信の観点からの取り決めの一部を挙げる（参照により本明細書に援用される、ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能な3GPP TR 36.843、current version 12.0.1、「Study on LTE device to device proximity services; Radio aspects」、Section 9.2.2も参照のこと）。
【0062】
ＰＤＣＰ：
－ １：Ｍ（１つのデバイスがＭ個のデバイスに送信し、Ｍが整数である）Ｄ２Ｄブロードキャスト通信データ（すなわちＩＰパケット）は、通常のユーザプレーンデータとして取り扱われるべきである。
－ ＰＤＣＰでのヘッダ圧縮／伸長は、１：ＭのＤ２Ｄブロードキャスト通信に適用可能である。
－－ Ｕ―モードは、公安のためのＤ２Ｄブロードキャスト動作のためのＰＤＣＰでのヘッダ圧縮のために使用される。
－ １：Ｍ（１つのデバイスがＭ個のデバイスに送信し、Ｍが整数である）Ｄ２Ｄブロードキャスト通信データ（すなわちＩＰパケット）は、通常のユーザプレーンデータとして取り扱われるべきである。
－ ＰＤＣＰでのヘッダ圧縮／伸長は、１：ＭのＤ２Ｄブロードキャスト通信に適用可能である。
－－ Ｕ―モードは、公安のためのＤ２Ｄブロードキャスト動作のためのＰＤＣＰでのヘッダ圧縮のために使用される。
【0063】
ＲＬＣ：
－ ＲＬＣ ＵＭは、１：Ｍ Ｄ２Ｄブロードキャスト通信のために使用される。
－ セグメンテーションおよび再構築（Re-assmebly）は、ＲＬＣ ＵＭによってＬ２でサポートされる。
－ 受信ＵＥは、送信ピアＵＥごとに少なくとも１つのＲＬＣ ＵＭエンティティを維持する必要がある。
－ ＲＬＣ ＵＭ受信側エンティティは、第１のＲＬＣ ＵＭデータユニットの受信前に設定される必要はない。
－ ここまで、ユーザプレーンデータ送信のためのＤ２Ｄ通信のためのＲＬＣ ＡＭまたはＲＬＣ ＴＭに対して必要が確認されていない。
－ ＲＬＣ ＵＭは、１：Ｍ Ｄ２Ｄブロードキャスト通信のために使用される。
－ セグメンテーションおよび再構築（Re-assmebly）は、ＲＬＣ ＵＭによってＬ２でサポートされる。
－ 受信ＵＥは、送信ピアＵＥごとに少なくとも１つのＲＬＣ ＵＭエンティティを維持する必要がある。
－ ＲＬＣ ＵＭ受信側エンティティは、第１のＲＬＣ ＵＭデータユニットの受信前に設定される必要はない。
－ ここまで、ユーザプレーンデータ送信のためのＤ２Ｄ通信のためのＲＬＣ ＡＭまたはＲＬＣ ＴＭに対して必要が確認されていない。
【0064】
ＭＡＣ：
－ １：Ｍ Ｄ２Ｄブロードキャスト通信に対して、ＨＡＲＱフィードバックは前提とされない。
－ 受信ＵＥは、受信側ＲＬＣ ＵＭエンティティを識別するためにソースＩＤを知る必要がある。
－ ＭＡＣヘッダは、ＭＡＣレイヤでパケットをフィルタリングすることを許容するＬ２ターゲットＩＤを備える。
－ Ｌ２ターゲットＩＤはブロードキャスト、グループキャストまたはユニキャストアドレスでもよい。
－－ Ｌ２グループキャスト／ユニキャスト：ＭＡＣヘッダで通知されるＬ２ターゲットＩＤは、受信ＲＬＣ ＵＭ ＰＤＵをＲＬＣ受信側エンティティに送る前にさえそれを破棄することを許容するであろう。
－－ Ｌ２ブロードキャスト：受信ＵＥは、すべての送信機からのすべての受信ＲＬＣ ＰＤＵを処理し、ＩＰパケットを再構築して上位のレイヤに送ろうとするであろう。
－ ＭＡＣサブヘッダは、複数の論理チャネルを区別するＬＣＩＤを含む。
－ 少なくとも多重化／逆多重化、優先度処理およびパディングはＤ２Ｄに対して有用である。
－ １：Ｍ Ｄ２Ｄブロードキャスト通信に対して、ＨＡＲＱフィードバックは前提とされない。
－ 受信ＵＥは、受信側ＲＬＣ ＵＭエンティティを識別するためにソースＩＤを知る必要がある。
－ ＭＡＣヘッダは、ＭＡＣレイヤでパケットをフィルタリングすることを許容するＬ２ターゲットＩＤを備える。
－ Ｌ２ターゲットＩＤはブロードキャスト、グループキャストまたはユニキャストアドレスでもよい。
－－ Ｌ２グループキャスト／ユニキャスト：ＭＡＣヘッダで通知されるＬ２ターゲットＩＤは、受信ＲＬＣ ＵＭ ＰＤＵをＲＬＣ受信側エンティティに送る前にさえそれを破棄することを許容するであろう。
－－ Ｌ２ブロードキャスト：受信ＵＥは、すべての送信機からのすべての受信ＲＬＣ ＰＤＵを処理し、ＩＰパケットを再構築して上位のレイヤに送ろうとするであろう。
－ ＭＡＣサブヘッダは、複数の論理チャネルを区別するＬＣＩＤを含む。
－ 少なくとも多重化／逆多重化、優先度処理およびパディングはＤ２Ｄに対して有用である。
【0065】
＜ＰｒｏＳｅ直接通信関連識別情報＞
ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能である非特許文献４の現行バージョン１２．４．０が、ＰｒｏＳｅ直接通信のために使用する以下の識別情報を８．３節に規定する：
－ ＳＬ－ＲＮＴＩ：ＰｒｏＳｅ直接通信スケジューリングのために使用される固有の識別；
－ ソースレイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータの送信側を識別する。ソースレイヤ２ＩＤは長さ２４ビットであり、受信側でのＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティの識別のためのＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと共に使用される；
－ 宛先レイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータのターゲットを識別する。宛先レイヤ２ＩＤは長さ２４ビットであり、ＭＡＣレイヤで２つのビット列に分割される：
－－ １つのビット列は宛先レイヤ２ＩＤのＬＳＢ部（８ビット）であり、サイドリンク制御レイヤ１ＩＤとして物理レイヤに転送される。これはサイドリンク制御の意図されたデータのターゲットを識別し、物理レイヤでパケットのフィルタリングのために使用される。
－－ 第２のビット列は宛先レイヤ２ＩＤのＭＳＢ部（１６ビット）であり、ＭＡＣヘッダ内で通知される。これはＭＡＣレイヤでパケットのフィルタリングのために使用される。
ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能である非特許文献４の現行バージョン１２．４．０が、ＰｒｏＳｅ直接通信のために使用する以下の識別情報を８．３節に規定する：
－ ＳＬ－ＲＮＴＩ：ＰｒｏＳｅ直接通信スケジューリングのために使用される固有の識別；
－ ソースレイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータの送信側を識別する。ソースレイヤ２ＩＤは長さ２４ビットであり、受信側でのＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティの識別のためのＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと共に使用される；
－ 宛先レイヤ２ＩＤ：サイドリンクＰｒｏＳｅ直接通信でデータのターゲットを識別する。宛先レイヤ２ＩＤは長さ２４ビットであり、ＭＡＣレイヤで２つのビット列に分割される：
－－ １つのビット列は宛先レイヤ２ＩＤのＬＳＢ部（８ビット）であり、サイドリンク制御レイヤ１ＩＤとして物理レイヤに転送される。これはサイドリンク制御の意図されたデータのターゲットを識別し、物理レイヤでパケットのフィルタリングのために使用される。
－－ 第２のビット列は宛先レイヤ２ＩＤのＭＳＢ部（１６ビット）であり、ＭＡＣヘッダ内で通知される。これはＭＡＣレイヤでパケットのフィルタリングのために使用される。
【0066】
アクセス層シグナリングは、グループ形成のために、ならびにＵＥでソースレイヤ２ＩＤ、宛先レイヤ２ＩＤおよびサイドリンク制御Ｌ１ＩＤを設定するために必要とされない。これらの識別情報は上位レイヤによって提供されるか、または上位レイヤによって提供される識別情報から導出されるかいずれかである。グループキャストおよびブロードキャストの場合には、上位レイヤによって提供されるＰｒｏＳｅ ＵＥ ＩＤはソースレイヤ２ＩＤとして直接使用され、上位レイヤによって提供されるＰｒｏＳｅレイヤ２グループＩＤはＭＡＣレイヤで宛先レイヤ２ＩＤとして直接使用される。
【0067】
＜近接サービスのための無線リソース割当て＞
送信ＵＥの観点から、近接サービス対応ＵＥ（ＰｒｏＳｅ対応ＵＥ）は、リソース割当てのための２つのモードで動作することができる。
送信ＵＥの観点から、近接サービス対応ＵＥ（ＰｒｏＳｅ対応ＵＥ）は、リソース割当てのための２つのモードで動作することができる。
【0068】
モード１はｅＮＢスケジュールリソース割当てを指し、ここでＵＥがｅＮＢ（またはリリース１０中継ノード）に送信リソースを要求し、ｅＮｏｄｅＢ（またはリリース１０中継ノード）は次いで直接データおよび直接制御情報を送信するためにＵＥによって使用される正確なリソースをスケジュールする（例えばスケジューリング割当て）。ＵＥは、データを送信するためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤである必要がある。特に、ＵＥはｅＮＢにスケジューリング要求（Ｄ－ＳＲまたはランダムアクセス）を送信し、通例のようにバッファ状況報告（ＢＳＲ：Buffer Status Report）が後続する（以下の章「Ｄ２Ｄ通信のための送信手順」も参照のこと）。ＢＳＲに基づいて、ｅＮＢは、ＵＥがＰｒｏＳｅ直接通信送信のためのデータを有すると判定することができ、送信のために必要とされるリソースを推定することができる。
【0069】
他方では、モード２はＵＥ自律リソース選択を指し、ここでＵＥが、直接データおよびサイドリンク制御情報を送信するためにリソースプールからリソース（時間および周波数）を単独で選択する（すなわちＳＡ）。１つのリソースプールが、例えばＳＩＢ１８の内容によって、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎによって規定され、この特定のリソースプールはセルでブロードキャストされ、次いでなおＲＲＣ＿Ｉｄｌｅ状態のセルにおけるすべてのＵＥに共通に利用可能である。実際上、ｅＮＢは、上記プールの４つまでの異なるインスタンス、それぞれＳＡメッセージおよび直接データの送信のための４つのリソースプールを規定してもよい。しかしながら、たとえ列記がＲｅｌｅａｓｅ１２ＬＴＥのための複数のリソースプールを設定されたとしても、ＵＥは列記に規定される第１のリソースプールを常に使用するものとする。規格の以後のバージョンは取扱いが異なってもよい。
【0070】
代替策として、別のリソースプールがｅＮＢによって規定され、ＳＩＢ１８で、すなわちフィールドｃｏｍｍＴｘＰｏｏｌＥｘｃｅｐｔｉｏｎａｌを使用することによってシグナリングされることができ、そのリソースプールは例外的な場合にＵＥによって使用されることができる。
【0071】
ＵＥがどのリソース割当てモードを使用する予定かは、ｅＮＢによって設定可能である。さらには、ＵＥがＤ２Ｄデータ通信のためにどのリソース割当てモードを使用する予定かは、また、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ、およびＵＥのカバレージ状態、すなわちカバレージ内、カバレージ外に依存してもよい。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレージ内と考えられる。
－ リソース割当てモードに関する以下の規則がＵＥに当てはまる：
－ ＵＥがカバレージ外であれば、ＵＥはモード２を使用することができるのみである；
－ ＵＥがカバレージ内であれば、ｅＮＢがＵＥを相応に設定すれば、それはモード１を使用してもよい；
－ ＵＥがカバレージ内であれば、ｅＮＢがＵＥを相応に設定すれば、ＵＥはモード２を使用してもよい。
－ リソース割当てモードに関する以下の規則がＵＥに当てはまる：
－ ＵＥがカバレージ外であれば、ＵＥはモード２を使用することができるのみである；
－ ＵＥがカバレージ内であれば、ｅＮＢがＵＥを相応に設定すれば、それはモード１を使用してもよい；
－ ＵＥがカバレージ内であれば、ｅＮＢがＵＥを相応に設定すれば、ＵＥはモード２を使用してもよい。
【0072】
例外条件がないとき、ＵＥは、そうするようにｅＮＢによって設定される場合のみ、モード１からモード２にまたはその逆に変更してもよい。ＵＥがカバレージ内であれば、例外的な場合の１つが発生しない限り、ＵＥはｅＮＢ構成によって示されるモードのみを使用するものとする；
－－ ＵＥは、例えばＴ３１１またはＴ３０１が動作している間、ＵＥ自体を例外条件にあると考える；
－－ 例外的な場合が発生すると、ＵＥは、たとえＵＥがモード１を使用するように設定されたとしても、一時的にモード２を使用するようにされる。
Ｅ－ＵＴＲＡセルのカバレージ範囲にある間、たとえＵＬキャリアのリソースが、例えばＵＩＣＣ（ユニバーサル集積回路カード）に予め設定されているとしても、ＵＥはそのセルによって割り当てられるリソースのみでのそのキャリアでＰｒｏＳｅ直接通信送信を行うものとする。
－－ ＵＥは、例えばＴ３１１またはＴ３０１が動作している間、ＵＥ自体を例外条件にあると考える；
－－ 例外的な場合が発生すると、ＵＥは、たとえＵＥがモード１を使用するように設定されたとしても、一時的にモード２を使用するようにされる。
Ｅ－ＵＴＲＡセルのカバレージ範囲にある間、たとえＵＬキャリアのリソースが、例えばＵＩＣＣ（ユニバーサル集積回路カード）に予め設定されているとしても、ＵＥはそのセルによって割り当てられるリソースのみでのそのキャリアでＰｒｏＳｅ直接通信送信を行うものとする。
【0073】
ＲＲＣ＿ＩＤＬＥのＵＥに対して、ｅＮＢは、以下のオプションの１つを選択してもよい：
－ ｅＮＢは、ＳＩＢでモード２送信リソースプールを提供してもよい。ＰｒｏＳｅ直接通信に許可されているＵＥは、ＲＲＣ＿ＩＤＬＥのＰｒｏＳｅ直接通信のためにこれらのリソースを使用する；
－ ｅＮＢは、それがＤ２Ｄをサポートするが、しかしＰｒｏＳｅ直接通信のためのリソースは提供しないことをＳＩＢで示してもよい。ＵＥは、ＰｒｏＳｅ直接通信送信を行うためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤに入る必要がある。
－ ｅＮＢは、ＳＩＢでモード２送信リソースプールを提供してもよい。ＰｒｏＳｅ直接通信に許可されているＵＥは、ＲＲＣ＿ＩＤＬＥのＰｒｏＳｅ直接通信のためにこれらのリソースを使用する；
－ ｅＮＢは、それがＤ２Ｄをサポートするが、しかしＰｒｏＳｅ直接通信のためのリソースは提供しないことをＳＩＢで示してもよい。ＵＥは、ＰｒｏＳｅ直接通信送信を行うためにＲＲＣ＿ＣＯＮＮＥＣＴＥＤに入る必要がある。
【0074】
ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに対して：
－ ＰｒｏＳｅ直接通信送信を行う許可を与えられているＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥは、ＵＥがＰｒｏＳｅ直接通信送信を行う必要があるときに、ＵＥがＰｒｏＳｅ直接通信送信を行いたいことをｅＮＢに示す；
－ ｅＮＢは、ＭＭＥから受信されるＵＥコンテキストを使用して、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥがＰｒｏＳｅ直接通信送信に許可されているかどうかを確認する；
－ ｅＮＢはＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤである間、制約なく使用してもよいモード２リソース割当て送信リソースプールを個別シグナリングによって設定してもよい。代替的に、ｅＮＢはＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに、ＵＥが例外的な場合にのみ使用し、そうでなければモード１に依存するようにされるモード２リソース割当て送信リソースプールを個別シグナリングによって設定してもよい。
－ ＰｒｏＳｅ直接通信送信を行う許可を与えられているＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥは、ＵＥがＰｒｏＳｅ直接通信送信を行う必要があるときに、ＵＥがＰｒｏＳｅ直接通信送信を行いたいことをｅＮＢに示す；
－ ｅＮＢは、ＭＭＥから受信されるＵＥコンテキストを使用して、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥがＰｒｏＳｅ直接通信送信に許可されているかどうかを確認する；
－ ｅＮＢはＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤである間、制約なく使用してもよいモード２リソース割当て送信リソースプールを個別シグナリングによって設定してもよい。代替的に、ｅＮＢはＲＲＣ＿ＣＯＮＮＥＣＴＥＤのＵＥに、ＵＥが例外的な場合にのみ使用し、そうでなければモード１に依存するようにされるモード２リソース割当て送信リソースプールを個別シグナリングによって設定してもよい。
【0075】
ＵＥがカバレージ外であるときのスケジューリング割当てのためのリソースプールは、以下のように設定されることができる：
－ 受信のために使用されるリソースプールが予め設定される。
－ 送信のために使用されるリソースプールが予め設定される。
ＵＥがカバレージ内であるときのスケジューリング割当てのためのリソースプールは、以下のように設定されることができる：
－ 受信のために使用されるリソースプールが、個別またはブロードキャストシグナリングで、ＲＲＣを介してｅＮＢによって設定される。
－ モード２リソース割当てが使用されれば、送信のために使用されるリソースプールがＲＲＣを介してｅＮＢによって設定される。
－ モード１リソース割当てが使用されれば、送信のために使用されるＳＡリソースプールはＵＥには知られない。
－ モード１リソース割当てが使用されれば、ｅＮＢは、スケジューリング割当て送信のために使用する特定のリソースをスケジュールする。ｅＮＢによって割り当てられる特定のリソースは、ＵＥに提供されるスケジューリング割当ての受信のためのリソースプール内にある。
－ 受信のために使用されるリソースプールが予め設定される。
－ 送信のために使用されるリソースプールが予め設定される。
ＵＥがカバレージ内であるときのスケジューリング割当てのためのリソースプールは、以下のように設定されることができる：
－ 受信のために使用されるリソースプールが、個別またはブロードキャストシグナリングで、ＲＲＣを介してｅＮＢによって設定される。
－ モード２リソース割当てが使用されれば、送信のために使用されるリソースプールがＲＲＣを介してｅＮＢによって設定される。
－ モード１リソース割当てが使用されれば、送信のために使用されるＳＡリソースプールはＵＥには知られない。
－ モード１リソース割当てが使用されれば、ｅＮＢは、スケジューリング割当て送信のために使用する特定のリソースをスケジュールする。ｅＮＢによって割り当てられる特定のリソースは、ＵＥに提供されるスケジューリング割当ての受信のためのリソースプール内にある。
【0076】
図７は、オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を例示する。
【0077】
基本的に、ｅＮｏｄｅＢは、ＵＥがモード１またはモード２送信を適用してもよいかどうかを制御する。一旦ＵＥが、それがＤ２Ｄ通信を送信（または受信）することができるそのリソースを知ると、ＵＥは対応する送信／受信のための対応するリソースのみを使用する。例えば、図７で、Ｄ２Ｄサブフレームは、Ｄ２Ｄ信号を受信または送信するためにのみ使用されることになる。Ｄ２ＤデバイスとしてのＵＥは半二重モードで動作するであろうから、ＵＥは任意の時点でＤ２Ｄ信号を受信かまたは送信かいずれかすることができる。同様に、図７に例示するその他のサブフレームは、ＬＴＥ（オーバーレイ）送信および／または受信のために使用することができる。
【0078】
＜Ｄ２Ｄ通信のための送信手順＞
Ｄ２Ｄデータ送信手順は、リソース割当てモードに応じて異なる。モード１について上記したように、ｅＮＢは、ＵＥからの対応する要求後、スケジューリング割当ておよびＤ２Ｄデータ通信のためのリソースを明示的にスケジュールする。特に、ＵＥは、Ｄ２Ｄ通信が通常許容されるが、しかしモード２リソース（すなわちリソースプール）は提供されないことをｅＮＢによって通知されてもよく；これは、例えばＵＥによるＤ２Ｄ通信関心インジケーションおよび対応する応答（Ｄ２Ｄ通信応答）の交換で行われてもよく、ここで、上述した対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇ情報要素はｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎを含まないであろうから、送信を伴う直接通信を開始したいＵＥがＥ－ＵＴＲＡＮに各個々の送信のためのリソースを割り当てるように要求しなければならないことを意味する。したがって、そのような場合に、ＵＥは各個々の送信のためのリソースを要求しなければならず、以下に要求／グラント手順の異なるステップがこのモード１リソース割当てに関して例示的に列記される：
－ ステップ１：ＵＥがＰＵＣＣＨを介してｅＮＢにＳＲ（スケジューリング要求）を送信する；
－ ステップ２：ｅＮＢがＰＤＣＣＨを介して（ＵＥがＢＳＲを送信するための）ＵＬリソースを、Ｃ－ＲＮＴＩによってスクランブルして許可する；
－ ステップ３：ＵＥがＰＵＳＣＨを介してバッファ状況を示すＤ２Ｄ ＢＳＲを送信する；
－ ステップ４：ｅＮＢがＰＤＣＣＨを介して（ＵＥがデータを送信するための）Ｄ２Ｄリソースを、Ｄ２Ｄ－ＲＮＴＩによってスクランブルして許可する。
－ ステップ５：Ｄ２Ｄ Ｔｘ ＵＥがステップ４で受信したグラントに従ってＳＡ／Ｄ２Ｄデータを送信する。
Ｄ２Ｄデータ送信手順は、リソース割当てモードに応じて異なる。モード１について上記したように、ｅＮＢは、ＵＥからの対応する要求後、スケジューリング割当ておよびＤ２Ｄデータ通信のためのリソースを明示的にスケジュールする。特に、ＵＥは、Ｄ２Ｄ通信が通常許容されるが、しかしモード２リソース（すなわちリソースプール）は提供されないことをｅＮＢによって通知されてもよく；これは、例えばＵＥによるＤ２Ｄ通信関心インジケーションおよび対応する応答（Ｄ２Ｄ通信応答）の交換で行われてもよく、ここで、上述した対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇ情報要素はｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎを含まないであろうから、送信を伴う直接通信を開始したいＵＥがＥ－ＵＴＲＡＮに各個々の送信のためのリソースを割り当てるように要求しなければならないことを意味する。したがって、そのような場合に、ＵＥは各個々の送信のためのリソースを要求しなければならず、以下に要求／グラント手順の異なるステップがこのモード１リソース割当てに関して例示的に列記される：
－ ステップ１：ＵＥがＰＵＣＣＨを介してｅＮＢにＳＲ（スケジューリング要求）を送信する；
－ ステップ２：ｅＮＢがＰＤＣＣＨを介して（ＵＥがＢＳＲを送信するための）ＵＬリソースを、Ｃ－ＲＮＴＩによってスクランブルして許可する；
－ ステップ３：ＵＥがＰＵＳＣＨを介してバッファ状況を示すＤ２Ｄ ＢＳＲを送信する；
－ ステップ４：ｅＮＢがＰＤＣＣＨを介して（ＵＥがデータを送信するための）Ｄ２Ｄリソースを、Ｄ２Ｄ－ＲＮＴＩによってスクランブルして許可する。
－ ステップ５：Ｄ２Ｄ Ｔｘ ＵＥがステップ４で受信したグラントに従ってＳＡ／Ｄ２Ｄデータを送信する。
【0079】
スケジューリング割当て（ＳＡ：Scheduling Assignment）は、制御情報、例えば対応するＤ２Ｄデータ送信のための時間／周波数リソースへのポインタを含むコンパクトな（低ペイロード）メッセージである。ＳＡの内容は基本的に、上記ステップ４で受信したグラントに従う。Ｄ２ＤグラントおよびＳＡ内容の正確な詳細は今なお確定されていないが、しかしＳＡ内容に対する作業前提として、以下の取り決めが達せられた：
－ 周波数リソースは、Ｒｅｌ－８ＵＬタイプ０リソース割当て（システムＢＷに応じて５～１３ビット）によって示される。
－ １ビット周波数ホッピングインジケータ（Ｒｅｌ－８の通り）
－－ モード２で設定されたリソースプール外のＰＲＢをホッピングが使用しないように、インデクシングのなんらかの再解釈が規定されるべきであることに留意されたい。
－ 単一クラスタリソース割当てのみが有効である。
－－ このことは、周波数領域でリソースプールにギャップがあれば、リソース割当てはギャップをまたがないものとすることを暗示する。
－ ＳＡにはＲＶインジケータがない。
－ データに対するＲＶパターン：｛０，２，３，１｝
－ 周波数リソースは、Ｒｅｌ－８ＵＬタイプ０リソース割当て（システムＢＷに応じて５～１３ビット）によって示される。
－ １ビット周波数ホッピングインジケータ（Ｒｅｌ－８の通り）
－－ モード２で設定されたリソースプール外のＰＲＢをホッピングが使用しないように、インデクシングのなんらかの再解釈が規定されるべきであることに留意されたい。
－ 単一クラスタリソース割当てのみが有効である。
－－ このことは、周波数領域でリソースプールにギャップがあれば、リソース割当てはギャップをまたがないものとすることを暗示する。
－ ＳＡにはＲＶインジケータがない。
－ データに対するＲＶパターン：｛０，２，３，１｝
【0080】
他方では、モード２リソース割当てに関して、上記ステップ１～４は基本的に必要でなく、ＵＥは、ｅＮＢによって設定および提供される送信リソースプールからＳＡおよびＤ２Ｄデータ送信のためのリソースを自律的に選択する。
【0081】
図８は、２つのＵＥ（ＵＥ－ＡおよびＵＥ－Ｂ）に対するスケジューリング割当ておよびＤ２Ｄデータの送信を例示的に示し、ここでスケジューリング割当てを送信するためのリソースは周期的であり、Ｄ２Ｄデータ送信のために使用されるリソースは対応するスケジューリング割当てによって示される。
【0082】
図９は、ＳＣ期間（サイドリンク制御期間）としても知られている１つのＳＡ／データ期間のモード２、自律スケジューリングのＤ２Ｄ通信タイミングを例示する。
【0083】
図１０は、１つのＳＡ／データ期間のモード１、ｅＮＢスケジュール割当てのＤ２Ｄ通信タイミングを例示する。ＳＣ期間は、スケジューリング割当ておよびそれらの対応するデータの送信から成る期間である。図９から分かるように、ＵＥはＳＡオフセット時間後に、モード２のスケジューリング割当てのための送信プールリソース（ＳＡ＿Ｍｏｄｅ２＿Ｔｘ＿ｐｏｏｌ）を使用して、スケジューリング割当てを送信する。ＳＡの１回目の送信の後に、例えば同じＳＡメッセージの３回の再送信が続く。次いで、ＵＥは、ＳＡリソースプールの第１のサブフレーム（ＳＡ＿ｏｆｆｓｅｔによって与えられる）後いくらかの設定したオフセット（Ｍｏｄｅ２ｄａｔａ＿ｏｆｆｓｅｔ）で、Ｄ２Ｄデータ送信、より詳しくはＴ－ＲＰＴビットマップ／パターンを開始する。ＭＡＣ ＰＤＵの１つのＤ２Ｄデータ送信は、その１回目の送信および数回の再送信から成る。図９の（および図１０の）例について、３回の再送信が行われる（すなわち同じＭＡＣ ＰＤＵの２回目、３回目および４回目の送信）ことを前提とする。Ｍｏｄｅ２Ｔ－ＲＰＴビットマップ（送信（Ｔ－ＲＰＴ）の時間リソースパターン）は基本的に、ＭＡＣ ＰＤＵ送信（１回目の送信）およびその再送信（２回目、３回目および４回目の送信）のタイミングを規定する。
【0084】
１つのＳＡ／データ期間の間、ＵＥは、１つのＰｒｏＳｅ宛先グループのみにではあるが、複数のトランスポートブロックを（サブフレーム（ＴＴＩ）ごとに１つのみ、すなわち順々に）送信することができる。また、１つのトランスポートブロックの再送信は、次のトランスポートブロックの第１の送信が開始する前に終わらなければならず、すなわち１つのＨＡＲＱプロセスのみが複数のトランスポートブロックの送信のために使用される。
【0085】
図１０から明らかなように、ｅＮＢスケジュールリソース割当てモード（モード１）に関して、Ｄ２Ｄデータ送信、より詳しくはＴ－ＲＰＴパターン／ビットマップは、ＳＡリソースプールでの最後のＳＡ送信繰り返し後、次のＵＬサブフレームで開始する。図９に関して既に説明したように、Ｍｏｄｅ１Ｔ－ＲＰＴビットマップ（送信（Ｔ－ＲＰＴ）の時間リソースパターン）は基本的に、ＭＡＣ ＰＤＵ送信（１回目の送信）およびその再送信（２回目、３回目および４回目の送信）のタイミングを規定する。
【0086】
＜ＰｒｏＳｅネットワークアーキテクチャおよびＰｒｏＳｅエンティティ＞
図１１は、それぞれのＵＥ ＡおよびＢにおける異なるＰｒｏＳｅアプリケーションの他に、ネットワークにおけるＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む、非ローミングケースについての高レベルの例示的なアーキテクチャを例示する。図１１のアーキテクチャ例は、ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献５のバージョン１２．３．０の「Architectural Reference Model」というタイトルの４．２節から取られている。
図１１は、それぞれのＵＥ ＡおよびＢにおける異なるＰｒｏＳｅアプリケーションの他に、ネットワークにおけるＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む、非ローミングケースについての高レベルの例示的なアーキテクチャを例示する。図１１のアーキテクチャ例は、ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能であり、かつ参照により本明細書に援用される非特許文献５のバージョン１２．３．０の「Architectural Reference Model」というタイトルの４．２節から取られている。
【0087】
機能エンティティは、参照により本明細書に援用される、上記引用した非特許文献５の「Functional Entities」というタイトルの４．４節に詳細に提示および説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅのために必要とされるネットワーク関連行動のために使用される論理機能であり、ＰｒｏＳｅの特徴の各々のための異なる役割を果たす。ＰｒｏＳｅ機能は３ＧＰＰのＥＰＣの一部であり、近接サービスに関連した、許可、認証、データ操作などのようなすべての関連するネットワークサービスを提供する。ＰｒｏＳｅ直接発見および通信に関して、ＵＥは、ＰＣ３基準点を通じてＰｒｏＳｅ機能から、特定のＰｒｏＳｅ ＵＥ識別情報、他の構成情報の他に許可を得てもよい。ネットワークには複数のＰｒｏＳｅ機能を展開することができるが、例解の容易さのために、単一のＰｒｏＳｅ機能を提示する。ＰｒｏＳｅ機能は、ＰｒｏＳｅ特徴に応じて異なる役割を行う３つの主な副機能：直接供給機能（ＤＰＦ：Direct Provision Function）、直接発見名管理機能およびＥＰＣレベル発見機能から成る。ＤＰＦは、ＰｒｏＳｅ直接発見およびＰｒｏＳｅ直接通信を使用するために、ＵＥに必要なパラメータを供給するために使用される。
【0088】
上記関連で使用される用語「ＵＥ」は、以下などのＰｒｏＳｅ機能性をサポートするＰｒｏＳｅ対応ＵＥを指す：
－ ＰＣ３基準点を通じるＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換。
－ ＰＣ５基準点を通じる他のＰｒｏＳｅ対応ＵＥの公開ＰｒｏＳｅ直接発見のための手順。
－ ＰＣ５基準点を通じる一対多ＰｒｏＳｅ直接通信のための手順。
－ ＰｒｏＳｅ ＵＥ対ネットワークリレーとして作用する手順。リモートＵＥは、ＰＣ５基準点を通じてＰｒｏＳｅ ＵＥ対ネットワークリレーと通信する。ＰｒｏＳｅ ＵＥ対ネットワークリレーはレイヤ３パケット転送を使用する。
－ 例えばＵＥ対ネットワークリレー検出およびＰｒｏＳｅ直接発見のための、ＰＣ５基準点を通じるＰｒｏＳｅ ＵＥ間の制御情報の交換。
－ ＰＣ３基準点を通じる別のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換。ＰｒｏＳｅ ＵＥ対ネットワークリレーの場合には、リモートＵＥはＰＣ５ユーザプレーンを通じてこの制御情報を送信し、ＰｒｏＳｅ機能に向けてＬＴＥ－Ｕｕインタフェースを通じて中継されることになる。
－ パラメータ（例えば、ＩＰアドレス、ＰｒｏＳｅレイヤ２グループＩＤ、グループセキュリティ事柄、無線リソースパラメータを含む）の構成。これらのパラメータは、ＵＥに予め設定されるか、またはカバレージ内であれば、ネットワークにおけるＰｒｏＳｅ機能にＰＣ３基準点を通じてシグナリングによって供給されることができる。
－ ＰＣ３基準点を通じるＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換。
－ ＰＣ５基準点を通じる他のＰｒｏＳｅ対応ＵＥの公開ＰｒｏＳｅ直接発見のための手順。
－ ＰＣ５基準点を通じる一対多ＰｒｏＳｅ直接通信のための手順。
－ ＰｒｏＳｅ ＵＥ対ネットワークリレーとして作用する手順。リモートＵＥは、ＰＣ５基準点を通じてＰｒｏＳｅ ＵＥ対ネットワークリレーと通信する。ＰｒｏＳｅ ＵＥ対ネットワークリレーはレイヤ３パケット転送を使用する。
－ 例えばＵＥ対ネットワークリレー検出およびＰｒｏＳｅ直接発見のための、ＰＣ５基準点を通じるＰｒｏＳｅ ＵＥ間の制御情報の交換。
－ ＰＣ３基準点を通じる別のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間のＰｒｏＳｅ制御情報の交換。ＰｒｏＳｅ ＵＥ対ネットワークリレーの場合には、リモートＵＥはＰＣ５ユーザプレーンを通じてこの制御情報を送信し、ＰｒｏＳｅ機能に向けてＬＴＥ－Ｕｕインタフェースを通じて中継されることになる。
－ パラメータ（例えば、ＩＰアドレス、ＰｒｏＳｅレイヤ２グループＩＤ、グループセキュリティ事柄、無線リソースパラメータを含む）の構成。これらのパラメータは、ＵＥに予め設定されるか、またはカバレージ内であれば、ネットワークにおけるＰｒｏＳｅ機能にＰＣ３基準点を通じてシグナリングによって供給されることができる。
【0089】
ＰｒｏＳｅアプリケーションサーバは、ＥＰＣ ＰｒｏＳｅユーザＩＤおよびＰｒｏＳｅ機能ＩＤの記憶、ならびにアプリケーションレイヤユーザＩＤおよびＥＰＣ ＰｒｏＳｅユーザＩＤのマッピングをサポートする。ＰｒｏＳｅアプリケーションサーバ（ＡＳ：Application Server）は３ＧＰＰの範囲外のエンティティである。ＵＥにおけるＰｒｏＳｅアプリケーションは、アプリケーションレイヤ基準点ＰＣ１を介してＰｒｏＳｅ ＡＳと通信する。ＰｒｏＳｅ ＡＳはＰＣ２基準点を介して３ＧＰＰネットワークに接続される。
【0090】
＜Ｄ２ＤのためのＵＥカバレージ状態＞
既に前述したように、Ｄ２Ｄ通信のためのリソース割当て方法は、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤとは別に、ＵＥのカバレージ状態、すなわちカバレージ内、カバレージ外にも依存する。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレージ内と考えられる。
既に前述したように、Ｄ２Ｄ通信のためのリソース割当て方法は、ＲＲＣ状態、すなわちＲＲＣ＿ＩＤＬＥおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤとは別に、ＵＥのカバレージ状態、すなわちカバレージ内、カバレージ外にも依存する。ＵＥは、それがサービングセルを有する（すなわちＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであるかまたはＲＲＣ＿ＩＤＬＥのセルにキャンプしている）とすれば、カバレージ内と考えられる。
【0091】
ここまで述べた２つのカバレージ状態、すなわちカバレージ内（ＩＣ：in-coverage）およびカバレージ外（ＯＯＣ：out-of-coverage）は、Ｄ２Ｄに関して下位状態にさらに区別される。図１２は、Ｄ２Ｄ ＵＥが関連づけられることができる４つの異なる状態を示し、それらは以下の通りに要約されることができる：
－ 状態１：ＵＥ１はアップリンクおよびダウンリンクカバレージを有する。この状態では、ネットワークは各Ｄ２Ｄ通信セッションを制御する。さらには、ネットワークは、ＵＥ１がリソース割当てモード１かまたはモード２かどちらを使用するべきかを設定する。
－ 状態２：ＵＥ２はアップリンクを除いたダウンリンクカバレージ、すなわちＤＬカバレージのみを有する。ネットワークは（競合ベースの）リソースプールをブロードキャストする。この状態では、送信ＵＥは、ネットワークによって設定されるリソースプールからＳＡおよびデータのために使用されるリソースを選択するが、リソース割当ては、そのような状態のＤ２Ｄ通信のためのモード２に従って可能であるのみである。
－ 状態３：ＵＥ３はアップリンクおよびダウンリンクカバレージを有しないので、ＵＥ３は厳密に言えば、既にカバレージ外（ＯＯＣ：out-of-coverage）として考えられる。しかしながら、ＵＥ３は、それら自体（例えばＵＥ１）セルのカバレージ内であるいくつかのＵＥのカバレージ内であり、すなわちそれらのＵＥはＣＰ中継ＵＥとも称されることができる。したがって、図１２における状態３ＵＥの領域は、ＣＰ ＵＥ中継カバレージ範囲として示されることができる。この状態３のＵＥはＯＯＣ状態３ＵＥとも称される。この状態では、ＵＥは、ｅＮＢ（ＳＩＢ）によって送信され、セルのカバレージ内のＣＰ ＵＥ中継ＵＥによってＰＤ２ＤＳＣＨを介してＯＯＣ状態３ＵＥに転送されるなんらかのセル固有情報を受信する。（競合ベースの）ネットワーク制御リソースプールがＰＤ２ＤＳＣＨによってシグナリングされる。
－ 状態４：ＵＥ４はカバレージ外であり、セルのカバレージ内である他のＵＥからＰＤ２ＤＳＣＨを受信しない。状態４ＯＯＣとも称されるこの状態では、送信ＵＥは、リソースの予め設定されたプールからデータ送信のために使用されるリソースを選択する。
－ 状態１：ＵＥ１はアップリンクおよびダウンリンクカバレージを有する。この状態では、ネットワークは各Ｄ２Ｄ通信セッションを制御する。さらには、ネットワークは、ＵＥ１がリソース割当てモード１かまたはモード２かどちらを使用するべきかを設定する。
－ 状態２：ＵＥ２はアップリンクを除いたダウンリンクカバレージ、すなわちＤＬカバレージのみを有する。ネットワークは（競合ベースの）リソースプールをブロードキャストする。この状態では、送信ＵＥは、ネットワークによって設定されるリソースプールからＳＡおよびデータのために使用されるリソースを選択するが、リソース割当ては、そのような状態のＤ２Ｄ通信のためのモード２に従って可能であるのみである。
－ 状態３：ＵＥ３はアップリンクおよびダウンリンクカバレージを有しないので、ＵＥ３は厳密に言えば、既にカバレージ外（ＯＯＣ：out-of-coverage）として考えられる。しかしながら、ＵＥ３は、それら自体（例えばＵＥ１）セルのカバレージ内であるいくつかのＵＥのカバレージ内であり、すなわちそれらのＵＥはＣＰ中継ＵＥとも称されることができる。したがって、図１２における状態３ＵＥの領域は、ＣＰ ＵＥ中継カバレージ範囲として示されることができる。この状態３のＵＥはＯＯＣ状態３ＵＥとも称される。この状態では、ＵＥは、ｅＮＢ（ＳＩＢ）によって送信され、セルのカバレージ内のＣＰ ＵＥ中継ＵＥによってＰＤ２ＤＳＣＨを介してＯＯＣ状態３ＵＥに転送されるなんらかのセル固有情報を受信する。（競合ベースの）ネットワーク制御リソースプールがＰＤ２ＤＳＣＨによってシグナリングされる。
－ 状態４：ＵＥ４はカバレージ外であり、セルのカバレージ内である他のＵＥからＰＤ２ＤＳＣＨを受信しない。状態４ＯＯＣとも称されるこの状態では、送信ＵＥは、リソースの予め設定されたプールからデータ送信のために使用されるリソースを選択する。
【0092】
状態３ＯＯＣと状態４ＯＯＣとの間で区別する理由は、主にカバレージ外デバイスからのＤ２Ｄ送信とレガシーＥ－ＵＴＲＡ送信との間の潜在的に強い干渉を回避するためである。概して、Ｄ２Ｄ可能ＵＥは、カバレージ外の間に使用するためにＤ２Ｄ ＳＡおよびデータの送信のためのリソースプールを予め設定しているだろう。これらのカバレージ外ＵＥがセル境界付近でこれらの予め設定されたリソースプールで送信する場合、Ｄ２Ｄ送信とカバレージ内レガシー送信との間の干渉がセル内の通信に悪影響を及ぼすはずである。カバレージ内のＤ２Ｄ対応ＵＥがセル境界付近でそれらのカバレージ外デバイスにＤ２Ｄリソースプール設定を転送するとすれば、カバレージ外ＵＥはｅＮｏｄｅ Ｂによって特定されるリソースにそれらカバレージ外ＵＥの送信を限定し、したがってカバレージ内のレガシー送信との干渉を最小化することができるだろう。したがって、ＲＡＮ１は、カバレージ内ＵＥがカバレージ範囲すぐ外のそれらのデバイス（状態３ＵＥ）にリソースプール情報および他のＤ２Ｄ関連設定を転送するメカニズムを導入した。
【0093】
物理Ｄ２Ｄ同期チャネル（ＰＤ２ＤＳＣＨ：Physical D2D synchronization channel）を使用してネットワーク近接のＵＥにカバレージ内Ｄ２Ｄリソースプールについてのこの情報を通知し、その結果ネットワーク近接内のリソースプールは同調される。ＰＤ２ＤＳＣＨの詳細な内容は今なお完成されていない。
【0094】
＜Ｄ２Ｄ（サイドリンク）論理チャネルのためのＬＣＰ手順＞
Ｄ２ＤのためのＬＣＰ手順は、「通常の」ＬＴＥデータのための以上提示したＬＣＰ手順とは異なることになる。以下の情報は、ＰｒｏＳｅおよびその機能性の導入に向けられる、非特許文献２のバージョン１２．３．０に対するＲ２－１４５４３５（変更要求０７４４）から取られており、その書類は参照によりその全体が本明細書に援用される。
論理チャネル優先順位付け手順は新たな送信が行われるときに適用される。
Ｄ２ＤのためのＬＣＰ手順は、「通常の」ＬＴＥデータのための以上提示したＬＣＰ手順とは異なることになる。以下の情報は、ＰｒｏＳｅおよびその機能性の導入に向けられる、非特許文献２のバージョン１２．３．０に対するＲ２－１４５４３５（変更要求０７４４）から取られており、その書類は参照によりその全体が本明細書に援用される。
論理チャネル優先順位付け手順は新たな送信が行われるときに適用される。
【0095】
ＵＥは、新たな送信が行われるときに以下の論理チャネル優先順位付け手順を行うものとする。ＵＥは、以下の規則に従ってサイドリンク論理チャネルにリソースを割り当てるものとする：
－ ＵＥは、全体のＳＤＵ（または部分的に送信されるＳＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵ）をセグメント化するべきでない；
－ ＵＥがサイドリンク論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする；
－ ＵＥはデータの送信を最大化するべきである。
－ ＵＥが、送信のために利用可能なデータを有しつつ、１０バイト以上であるサイドリンクグラントサイズを与えられれば、ＵＥは、パディングのみを送信することはしないものとする。
－ ＵＥは、全体のＳＤＵ（または部分的に送信されるＳＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵ）をセグメント化するべきでない；
－ ＵＥがサイドリンク論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする；
－ ＵＥはデータの送信を最大化するべきである。
－ ＵＥが、送信のために利用可能なデータを有しつつ、１０バイト以上であるサイドリンクグラントサイズを与えられれば、ＵＥは、パディングのみを送信することはしないものとする。
【0096】
注：上記規則は、サイドリンク論理チャネルが扱われる順序はＵＥ実装次第であることを暗示する。概して、１つのＰＤＵのために、ＭＡＣは同じソースレイヤ２ＩＤ－宛先レイヤ２ＩＤ対を持つ論理チャネルのみを考えるものとし、すなわち１つのＰＤＵのために、ＵＥにおけるＭＡＣエンティティは同じＰｒｏＳｅ宛先グループの論理チャネルのみを考えるものとする。さらには、Ｒｅｌ－１２では、１つのＳＡ／データ期間の間、Ｄ２Ｄ送信ＵＥは１つのＰｒｏＳｅ宛先グループにデータを送信することができるのみである。
【0097】
すべてのＤ２Ｄ（サイドリンク）論理チャネル、例えばＳＴＣＨ（サイドリンクトラヒックチャネル）は、ＬＣＧＩＤが「１１」に設定される同じ論理チャネルグループ（ＬＣＧ：Logical Channel Group）に割り当てられる。Ｒｅｌ－１２では、Ｄ２Ｄ（サイドリンク）論理チャネル／グループのための優先順位付けメカニズムはない。本質的に、すべてのサイドリンク論理チャネルはＵＥの観点から同じ優先度を有し、すなわちサイドリンク論理チャネルが扱われる順序はＵＥ実装次第である。
【0098】
＜ＰｒｏＳｅのためのバッファ状況報告＞
（Ｄ２Ｄ）サイドリンクバッファ状況報告手順は、サービングｅＮＢにＵＥのサイドリンクバッファで送信のために利用可能なサイドリンクデータ量についての情報を提供するために使用される。ＲＲＣは、２つのタイマＰｅｒｉｏｄｉｃ－ＰｒｏｓｅＢＳＲ－ＴｉｍｅｒおよびＲｅｔｘＰｒｏｓｅＢＳＲ－Ｔｉｍｅｒを設定することによってサイドリンクＢＳＲ報告を制御する。各サイドリンク論理チャネル（ＳＴＣＨ）は、ＬＣＧＩＤが「１１」に設定されるＬＣＧに割り当てられ、ＰｒｏＳｅ宛先グループに帰属する。
（Ｄ２Ｄ）サイドリンクバッファ状況報告手順は、サービングｅＮＢにＵＥのサイドリンクバッファで送信のために利用可能なサイドリンクデータ量についての情報を提供するために使用される。ＲＲＣは、２つのタイマＰｅｒｉｏｄｉｃ－ＰｒｏｓｅＢＳＲ－ＴｉｍｅｒおよびＲｅｔｘＰｒｏｓｅＢＳＲ－Ｔｉｍｅｒを設定することによってサイドリンクＢＳＲ報告を制御する。各サイドリンク論理チャネル（ＳＴＣＨ）は、ＬＣＧＩＤが「１１」に設定されるＬＣＧに割り当てられ、ＰｒｏＳｅ宛先グループに帰属する。
【0099】
サイドリンクバッファ状況報告（ＢＳＲ：Buffer Status Report）は、非特許文献２のバージョン１２．５．０の５．１４．１．４節に挙げられるように、なんらかの特定のイベントが発生する場合にトリガされるものとする。非特許文献２のバージョン１２．５．０の６．１．３．１．ａ節は、ＰｒｏＳｅ ＢＳＲ ＭＡＣ制御要素およびそれらの対応する内容を以下の通りに特定する。
【0100】
ＰｒｏＳｅバッファ状況報告（ＢＳＲ：Buffer Status Report）ＭＡＣ制御要素は、報告されるＤ２Ｄ宛先グループごとに１つのグループインデックスフィールド、１つのＬＣＧ ＩＤフィールドおよび１つの対応するバッファサイズフィールドから成る。より詳細には、各含まれるＰｒｏＳｅ宛先グループに対して、以下のフィールドが規定される：
－ グループインデックス：グループインデックスフィールドはＰｒｏＳｅ宛先グループを識別する。このフィールドの長さは４ビットである。値は、ＰｒｏｓｅＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔで報告される宛先識別情報のインデックスに設定される；
－ ＬＣＧ ＩＤ：論理チャネルグループＩＤフィールドは、バッファ状況が報告されている論理チャネルのグループを識別する。フィールドの長さは２ビットであり、それは「１１」に設定される；
－ バッファサイズ：バッファサイズフィールドは、ＴＴＩに対するすべてのＭＡＣ ＰＤＵが構築された後にＰｒｏＳｅ宛先グループのすべての論理チャネルに渡って利用可能な総データ量を識別する。データ量は、バイト数で示される。
－ Ｒ：予約ビット、「０」に設定される。
図１３は、以上引用した非特許文献２のバージョン１２．５．０から取られる、Ｎ（ＰｒｏＳｅ宛先グループの数）にも対するＰｒｏＳｅ ＢＳＲ ＭＡＣ制御要素を示す。
－ グループインデックス：グループインデックスフィールドはＰｒｏＳｅ宛先グループを識別する。このフィールドの長さは４ビットである。値は、ＰｒｏｓｅＤｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔで報告される宛先識別情報のインデックスに設定される；
－ ＬＣＧ ＩＤ：論理チャネルグループＩＤフィールドは、バッファ状況が報告されている論理チャネルのグループを識別する。フィールドの長さは２ビットであり、それは「１１」に設定される；
－ バッファサイズ：バッファサイズフィールドは、ＴＴＩに対するすべてのＭＡＣ ＰＤＵが構築された後にＰｒｏＳｅ宛先グループのすべての論理チャネルに渡って利用可能な総データ量を識別する。データ量は、バイト数で示される。
－ Ｒ：予約ビット、「０」に設定される。
図１３は、以上引用した非特許文献２のバージョン１２．５．０から取られる、Ｎ（ＰｒｏＳｅ宛先グループの数）にも対するＰｒｏＳｅ ＢＳＲ ＭＡＣ制御要素を示す。
【0101】
＜ミッションクリティカルプッシュツートーク＞
近年、ミッションクリティカルプッシュツートーク（ＭＣＰＴＴ：Mission Critical Push To Talk）サービスと呼ばれるサービスが３ＧＰＰで検討されており、それはｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能である非特許文献６にも取り込まれている。プッシュツートーク（ＰＴＴ：Push To Talk）サービスは、２人以上のユーザが通信に係わってもよい調停された方法を提供する。ユーザは、（例えば、伝統的にボタンの押下によって）送信する許可を要求してもよい。ＬＴＥを通じたミッションクリティカルプッシュツートークサービスは、３ＧＰＰ進化型パケットシステム（ＥＰＳ：Evolved Packet System）サービスに基づいて、ミッションクリティカルシナリオに適する拡張ＰＴＴサービスをサポートする。ここで規定されるＭＣＰＴＴサービスの要件は、非ミッションクリティカルプッシュツートーク（ＰＴＴ：Push To Talk）サービスのための基盤を形成することもできる。ＭＣＰＴＴサービスは数人のユーザ間の通信（グループコール（group call））をサポートするものと意図され、ここで各ユーザは調停された方式でトークする許可にアクセスする能力を有する。しかしながら、ＭＣＰＴＴサービスはペアのユーザ間のプライベートコール（private call）もサポートする。ＭＣＰＴＴサービスは、ユーザ間の実際の通信経路を確立、維持、および終了するために、ＥＰＳアーキテクチャによって提供される現存の３ＧＰＰトランスポート通信メカニズムを基にしている。
近年、ミッションクリティカルプッシュツートーク（ＭＣＰＴＴ：Mission Critical Push To Talk）サービスと呼ばれるサービスが３ＧＰＰで検討されており、それはｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能である非特許文献６にも取り込まれている。プッシュツートーク（ＰＴＴ：Push To Talk）サービスは、２人以上のユーザが通信に係わってもよい調停された方法を提供する。ユーザは、（例えば、伝統的にボタンの押下によって）送信する許可を要求してもよい。ＬＴＥを通じたミッションクリティカルプッシュツートークサービスは、３ＧＰＰ進化型パケットシステム（ＥＰＳ：Evolved Packet System）サービスに基づいて、ミッションクリティカルシナリオに適する拡張ＰＴＴサービスをサポートする。ここで規定されるＭＣＰＴＴサービスの要件は、非ミッションクリティカルプッシュツートーク（ＰＴＴ：Push To Talk）サービスのための基盤を形成することもできる。ＭＣＰＴＴサービスは数人のユーザ間の通信（グループコール（group call））をサポートするものと意図され、ここで各ユーザは調停された方式でトークする許可にアクセスする能力を有する。しかしながら、ＭＣＰＴＴサービスはペアのユーザ間のプライベートコール（private call）もサポートする。ＭＣＰＴＴサービスは、ユーザ間の実際の通信経路を確立、維持、および終了するために、ＥＰＳアーキテクチャによって提供される現存の３ＧＰＰトランスポート通信メカニズムを基にしている。
【0102】
ＭＣＰＴＴサービスはサービスイネーブラ：ＧＣＳＥ＿ＬＴＥおよびＰｒｏＳｅをも基にしている。実行可能な範囲では、ＭＣＰＴＴサービスがＥＰＣネットワークのカバレージ下で使用されるかまたはネットワークカバレージのないＰｒｏＳｅに基づけば、エンドユーザの経験はとにかく同様であることが予期される。この意図を明らかにするために、要件は適用性に従って、オンネットワーク使用、オフネットワーク使用または両方にグループ化される。ＭＣＰＴＴサービスは、ユーザがトークする（声／音声を送信する）許可を要求するのを許容し、競合する要求間を調停する決定論的メカニズム（すなわち、フロア制御）を提供する。複数の要求が発生するとき、どのユーザの要求が受諾されて、どのユーザの要求が拒否または待機されるかの決定は、いくつかの特性（競合するユーザのそれぞれの優先度を含む）に基づく。ＭＣＰＴＴサービスは、優先度がより高い（例えば、緊急条件）ユーザが現行のトーカに優先する（割り込む）手段を提供する。ＭＣＰＴＴサービスは、ユーザがトークする（フロアを保持する）時間を制限し、したがって同じまたはより低い優先度のユーザにフロアを得る機会を許可するメカニズムもサポートする。
【0103】
ＭＣＰＴＴサービスは、ユーザがいくつかの別々のコールの活動性を監視する手段を提供し、ユーザが選択したコールに焦点を切り替えることを可能にする。ＭＣＰＴＴサービスユーザは、既に確立されたＭＣＰＴＴグループコールに加わってもよい（遅れコールエントリ）。加えて、ＭＣＰＴＴサービスは、現行の話者のユーザＩＤおよびユーザの位置決定特徴を提供する。ＭＣＰＴＴサービスのユーザは、商用ＰＴＴサービスのユーザより厳しい性能の期待値を抱いてもよい。
【0104】
ＭＣＰＴＴサービスはグループコールおよびプライベートコール能力を提供し、この能力はそれらと関連づけられる様々なプロセスフロー、状態および許可を有する。図１５、図１６および図１７は、グループコールおよびプライベートコールと関連づけられる高レベルフロー、状態および許可を示す。図はオンネットワークの場合およびオフネットワークの場合に当てはまり、ユーザ観点から、サービスおよび概念はオンネットワークおよびオフネットワークで同様に見えるべきである。技術的観点からは、オンネットワーク状態とオフネットワーク状態との間に差異があるだろう（例えば、オフネットワークでは、加入するにはユーザが加入するアプリケーションサーバを通知することを必要とはしないだろうし、オフネットワーク能力がオンネットワーク能力に匹敵することができる程度に応じて、詳細には他の差異もあるだろう）。
【0105】
ＭＣＰＴＴユーザがＭＣＰＴＴグループと通信したければ、ＭＣＰＴＴユーザはＭＣＰＴＴグループにアクセスする（すなわち、ＭＣＰＴＴグループメンバである）のを許容されなければならず、ＭＣＰＴＴユーザは次いで加入しなければならず、それからＭＣＰＴＴグループを自分の選択ＭＣＰＴＴグループとして有することができる。ＭＣＰＴＴユーザがグループに加入しているだけであれば、これはＭＣＰＴＴユーザがグループから受信することができるということであり、しかしながらＭＣＰＴＴユーザが選択ＭＣＰＴＴグループを有すれば、これはＭＣＰＴＴユーザが送信するためのグループである。状態の差異は、ＭＣＰＴＴユーザが複数のＭＣＰＴＴグループから受信するが、しかしＭＣＰＴＴユーザがどのＭＣＰＴＴグループに送信することを望むかを特定することを可能にする。
【0106】
特に、図１５、図１６および図１７は、特定のＭＣＰＴＴグループに関して受信および送信の両方を許容したユーザ、送信するのだけを許容されるユーザ、および受信するのだけを許容されるユーザに対するそれぞれのＭＣＰＴＴユーザ状態図を示す。本論考の状態では、この図は単に例解的な目的を果たし、要件に取って代わるものではない。その図は網羅的でなく、すべての異なるシナリオを含むわけでもない。
【0107】
ＭＣＰＴＴユーザが１つまたは複数のＭＣＰＴＴグループに加入することが可能である。通常、運用中に、ＭＣＰＴＴユーザは、自分がどのＭＣＰＴＴグループに加入することを望むかをＭＣＰＴＴサービスに通知する。これらの加入は、ＭＣＰＴＴユーザがそれらを削除、またはそれらを変更、またはサービスからサインアウトするまで効力があるままである。一部のＭＣＰＴＴユーザはあるＭＣＰＴＴグループへの永久加入を有し、それらの加入は、ネットワークで操作するときに黙示的に（すなわち、自動的に）設定される。それらのユーザに対して、ＭＣＰＴＴグループ加入は、ＭＣＰＴＴサービスがユーザに首尾よくサインインするときに開始し、ＭＣＰＴＴサービスからサインアウトするＭＣＰＴＴユーザの明示のまたは黙示の（例えば、不活動またはすべてのそのデバイスの電源遮断のため）要求が肯定応答されるときに終了する。
【0108】
ＰＴＴ要求が許可されるたびに、ユーザはＭＣＰＴＴ送信または「トークバースト」を開始することができる。ＭＣＰＴＴグループコールは１つまたは複数のＭＣＰＴＴ送信から成る。同じまたは異なるユーザからの２つの連続する送信が同じコールの一部であるか、または２番目の送信が新たなコールを開始するかどうかは、連続するＭＣＰＴＴ送信間の不活動期間の設定可能な最大長さに依存する。この不活動期間は、直前の送信の終了時に開始するハングタイムとしてみなすことができる。このタイマが動作している間、コールと関連づけられたリソースはコールに割り当てられたままであり（プリエンプションの場合は除く）、これはこのグループか、コールに関与していないグループかに対する将来のフロア要求の待ち時間を削減するはずである。不活動期間の間に新たな送信が開始すると、タイマは停止、リセット、およびその送信の終了時に再び再始動される。
【0109】
ＭＣＰＴＴサービスは、ブロードキャストグループコール、緊急グループコールおよび切迫危機グループコールを含むいくつかの「特別な」グループコールを認識する。
【0110】
＜ＭＣＰＴＴ優先度モデル＞
多くのＬＴＥ非公安ユーザが今日、１つの特定のサービスの優先度およびＱｏＳレベル（例えば、「金（gold）」、「銀（silver）」または「銅（bronze）」）に登録しており、これは常に固定した区別を提供する。このモデルは、非公安ユーザにとっては効果的で、比較的簡単であるが、公安アプリケーションの必要性となると不十分である。
多くのＬＴＥ非公安ユーザが今日、１つの特定のサービスの優先度およびＱｏＳレベル（例えば、「金（gold）」、「銀（silver）」または「銅（bronze）」）に登録しており、これは常に固定した区別を提供する。このモデルは、非公安ユーザにとっては効果的で、比較的簡単であるが、公安アプリケーションの必要性となると不十分である。
【0111】
ＭＣＰＴＴ優先度およびＱｏＳは状況による。公安ユーザは彼らの優先度を決定する有意な動的動作条件を有するので、ＭＣＰＴＴサービスはＭＣＰＴＴコールに対するリアルタイム優先度およびＱｏＳ経験を提供するものと意図される。例えば、応答者が応対している出来事の種類または応答者の全体のシフト役割は、ＬＴＥシステムからリソースを得るユーザの能力に強く影響する必要がある。
【0112】
ＭＣＰＴＴコールのオンネットワーク使用のためのＭＣＰＴＴ優先度処理が、図１８に図示するように概念的にモデル化される。概念モデルは、コール間およびコール内の優先順位付け、システム間優先順位付け、およびトランスポートレイヤ（ＥＰＳおよびＵＥ）での優先順位付けの３つの優先順位付けの領域を識別する。アプリケーションレイヤでは、一般的なネットワーク側の機能エンティティ「ＭＣＰＴＴ優先度およびＱｏＳ制御」は、各静的な要求について、ＭＣＰＴＴに関与するユーザおよびグループについての予め設定された情報の他に、それらについての動的（または状況による）情報を処理する。この処理の結果に基づいて、「ＭＣＰＴＴ優先度およびＱｏＳ制御」は他の機能エンティティ、システムまたはレイヤに情報を提供し、かつそれらとの相互作用を示して、可能な範囲で、経験の質の観点から、コールおよび送信が確立されたポリシー規則に従って適切に取り扱われることを保証する。
【0113】
図１８では、ユーザ静的属性は、おそらくいくつかの判定基準（例えば、第１の応答者、第２の応答者、監督者、発送者、管理者）の他に、司法権利上の境界およびおそらく予め設定されるシステム全体に渡る個々の優先度レベルによってユーザを分類する情報を含む。
【0114】
グループ静的属性は、グループおよび所有組織の性質／種類、グループ内の送信者および受信者のための司法権利上の境界、グループに対する通常の運用時間、他のグループに対するプリエンプション傾向、ならびにグループのデフォルト最小優先度についての情報を含む。
【0115】
ユーザ動的属性は、ユーザ／参加者の操作状況（例えば、勤務中／外）、ユーザの位置、ユーザが関与するかもしれない出来事の種類（例えば、ＭＣＰＴＴ緊急または切迫危機）、ならびにユーザが惹起したか否かを問わず、ユーザが公式に管理される出来事に個別に関与しているか否か、および肯定ならば、出来事範囲の境界、出来事重大度および出来事の解決でのユーザの割り当てられた役割を含む。
【0116】
グループ動的属性は、もしあれば、グループが現在処理している出来事の種類（例えば、ＭＣＰＴＴ緊急または切迫危機）、ならびに公式に管理される出来事への関与の場合には、出来事範囲の境界および出来事重大度を含む。
図１９に示すように、各特定のベアラに対する上位レイヤは、リアルタイム属性（ユーザ静的属性、グループ静的属性、ユーザ動的属性、グループ動的属性）に基づいて、ＭＡＣレイヤに優先度値を提供する。
図１９に示すように、各特定のベアラに対する上位レイヤは、リアルタイム属性（ユーザ静的属性、グループ静的属性、ユーザ動的属性、グループ動的属性）に基づいて、ＭＡＣレイヤに優先度値を提供する。
【0117】
ＭＡＣレイヤは、少なくとも２つの可能な方途でこの値をさらに使用してもよい：
Ａ）ＬＣＰメカニズムの一部として、すなわち論理チャネルおよび／または宛先グループ優先度と共に
Ｂ）通り／止まり決定をするために独立して（ＬＣＰ前に／後に）：この場合、論理チャネル優先順位付けは、論理チャネルが（どのグループで）どれくらいのデータに割り当てられるかを決定するものであり、ＭＣＰＴＴ優先度はフロア調停に反映するのみである。
現在、ＵＥで論理チャネルを優先順位付けするための特定の手順は規定されていない。
Ａ）ＬＣＰメカニズムの一部として、すなわち論理チャネルおよび／または宛先グループ優先度と共に
Ｂ）通り／止まり決定をするために独立して（ＬＣＰ前に／後に）：この場合、論理チャネル優先順位付けは、論理チャネルが（どのグループで）どれくらいのデータに割り当てられるかを決定するものであり、ＭＣＰＴＴ優先度はフロア調停に反映するのみである。
現在、ＵＥで論理チャネルを優先順位付けするための特定の手順は規定されていない。
【先行技術文献】
【非特許文献】
【0118】
【文献】3GPP TS 36.211、「Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)」
【文献】3GPP TS 36.321、「Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification」
【文献】3GPP TS 36.331、12.5.0、「Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification」
【文献】3GPP TS 36.300、「Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2」
【文献】3GPP TS 23.303、「Proximity-based services (ProSe); Stage 2」
【文献】3GPP TS 22.179、v.13.1.0、「Mission Critical Push to Talk (MCPTT) over LTE; Stage 1」
【発明の概要】
【0119】
１つの非限定的かつ例示的な実施形態が、近接サービスのためにユーザ機器で論理チャネル優先順位付け手順を行うときに、論理チャネルに無線リソースを割り当てるための改善された方法を提供する。
【0120】
独立請求項が非限定的かつ例示的な実施形態を提供する。有利な実施形態は従属請求項に従う。
【0121】
第１の態様によれば、本発明は、ユーザ機器が、利用可能なＰｒｏＳｅデータを持つ異なる論理チャネルに利用可能な無線リソース（例えばｅＮＢのグラントによって割り当てられるかまたはリソースプールからＵＥ自体によって選択される）を割り当てる論理チャネル優先順位付け（ＬＣＰ）手順を向上させる。上記目的で、異なるＰｒｏＳｅ論理チャネル間でリソース割当てを管理するためのＬＣＰ手順のために、優先順位付けメカニズムが導入される。優先順位付けメカニズムは大抵、それがあたかもＬＣＰ手順の一部であるかのように記載されるが、このことは必ずしも事実であるわけではなく、優先順位付けメカニズムは代替的に、ＬＣＰ手順に対して外部的であると考えられてもよい。
【0122】
背景で論じたように、異なるＰｒｏＳｅ宛先グループが規定される。第１の態様によれば、複数のＰｒｏＳｅ宛先グループの各々は、例示的にＰｒｏＳｅ宛先グループ優先度と名付けられる複数の異なる優先度からの１つを割り当てられる。異なるＰｒｏＳｅ宛先グループは、ネットワークにおける対応するＰｒｏＳｅ機能／エンティティによって設定および管理される。１つの変形によれば、異なるＰｒｏＳｅ宛先グループ優先度は、上記のまたは別のＰｒｏＳｅエンティティによってネットワークに同様に設定および管理されることができる。上記の場合、利用可能なＰｒｏＳｅ宛先グループに関する情報およびそれらの対応する優先度レベルはＵＥに送信されるものとする。他方では、ＰｒｏＳｅ宛先グループに関するこの情報およびそれらの対応する優先度レベルは、ｅＮＢが上記ユーザ機器のための無線リソースのｅＮＢによるスケジューリングを向上させるのを許容するように、ｅＮＢに送信されることもできる。なお別の変形によれば、ＰｒｏＳｅ宛先グループおよびそれらのＰｒｏＳｅ宛先グループ優先度もＵＥ（および無線基地局）に予め設定されることができ、そのためネットワークを通じた情報の交換は必要ではない。
【0123】
前述したように、異なるＰｒｏＳｅ論理チャネルがＰｒｏＳｅ直接通信のためにユーザ機器に設定され、複数のＰｒｏＳｅ宛先グループからの１つとも追加的に関連づけられる。ＰｒｏＳｅデータが送信されるべきである、すなわちＰｒｏＳｅデータがＰｒｏＳｅ論理チャネルに対する送信のために利用可能になるとき、ＵＥはその設定に応じて、ｅＮＢスケジュールリソース割当てモード（モード１とも称される）かまたはＵＥ自律リソース選択モード（モード２とも称される）かいずれかでＰｒｏＳｅ直接通信を行うことができる。いずれの方途でも、ＵＥは、ＬＣＰ手順を行うことによって異なるＰｒｏＳｅ論理チャネル（例えばＳＴＣＨ）間でＰｒｏＳｅ送信のために利用可能な無線リソース（ｅＮＢスケジュールリソースであろうとリソースプールからのリソースであろうと）を割り当てる必要がある。
【0124】
第１の態様の改善されたＬＣＰ手順はＰｒｏＳｅ論理チャネルの優先度を考慮する。特に、複数の宛先グループを特定するサイドリンク設定が記憶され、各宛先グループは、サイドリンクデータのための可能な宛先を含む、記憶装置であって、サイドリンク宛先グループのために設定される論理チャネルからの各論理チャネルに対する論理チャネル優先度を記憶する、記憶装置と、送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最高論理チャネル優先度を持つ、送信のために利用可能なサイドリンクデータを有するサイドリンク論理チャネルを持つサイドリンク宛先グループを選択し、選択したサイドリンク宛先グループに帰属するサイドリンク論理チャネルに優先度降順に無線リソースを割り当てるように構成されるスケジューリング部と、を備える、ユーザ機器間の直接通信をサポートする無線通信システムにおいて動作可能なユーザ機器が提供される。
【0125】
さらには、ユーザ機器間の直接通信をサポートする無線通信システムにおいて動作可能なネットワークノードが提供され、ネットワークノードは、複数の宛先グループを特定するサイドリンク設定がユーザ機器ごとに記憶され、各宛先グループは、サイドリンクデータのための可能な宛先を含む、記憶装置であって、サイドリンク宛先グループのために設定される論理チャネルからの各論理チャネルに対する論理チャネル優先度を記憶する、記憶装置と、送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最高論理チャネル優先度を持つ、送信のために利用可能なサイドリンクデータを有するサイドリンク論理チャネルを持つサイドリンク宛先グループを選択し、選択したサイドリンク宛先グループのユーザ機器に相応に無線リソースを割り当てるように構成されるスケジューリング部と、を備える。
【0126】
その上、ユーザ機器間の直接通信をサポートする無線通信システムにおいて動作可能なユーザ機器で行われるべき方法が提供され、方法は、複数の宛先グループを特定するサイドリンク設定を記憶し、各宛先グループは、サイドリンクデータのための可能な宛先を含み、さらに、サイドリンク宛先グループのために設定される論理チャネルからの各論理チャネルに対する論理チャネル優先度を記憶し、送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最高論理チャネル優先度を持つ、送信のために利用可能なサイドリンクデータを有するサイドリンク論理チャネルを持つサイドリンク宛先グループを選択し、選択したサイドリンク宛先グループに帰属するサイドリンク論理チャネルに優先度降順に無線リソースを割り当てる。
【0127】
開示した実施形態の追加の利益および利点は本明細書および図から明らかだろう。利益および／または利点は、明細書および図面の開示の様々な実施形態および特徴によって個々に提供されてもよく、同利益および／または利点の１つまたは複数を得るためにすべて提供される必要があるわけではない。
【0128】
これらの一般的なおよび特定の態様はシステム、方法およびコンピュータプログラム、ならびにシステム、方法およびコンピュータプログラムの任意の組合せを使用して実装されてもよい。
【0129】
以下では、例示的な実施形態が添付の図および図面を参照しつつより詳細に記載される。
【図面の簡単な説明】
【0130】
【図1】３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャを示す図である。
【図2】３ＧＰＰ ＬＴＥの全体のＥ－ＵＴＲＡＮアーキテクチャの例示的な概要を示す図である。
【図3】３ＧＰＰ ＬＴＥ（Ｒｅｌｅａｓｅ８／９）に定義されるダウンリンクスロットの例示的なダウンリンクリソースグリッドを示す図である。
【図4】３つのサブレイヤ（ＰＤＣＰ、ＲＬＣおよびＭＡＣ）で構成されるレイヤ２ユーザおよび制御プレーンプロトコルスタックを示す図である。
【図5】ＰＤＣＰ、ＲＬＣおよびＭＡＣレイヤでの異なる機能の概要であり、様々なレイヤによるＳＤＵ／ＰＤＵの処理の例示的な図である。
【図6】デバイスツーデバイス直接発見のためのＰＣ５インタフェースの概略図である。
【図7】オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）システムのための送信／受信リソースの使用を示す図である。
【図8】２つのＵＥに対するスケジューリング割当ておよびＤ２Ｄデータの送信を示す図である。
【図9】ＵＥ自律スケジューリングモード２のＤ２Ｄ通信タイミングを示す図である。
【図10】ｅＮＢスケジュールスケジューリングモード１のＤ２Ｄ通信タイミングを示す図である。
【図11】非ローミングシナリオについてのＰｒｏＳｅのための例示的なアーキテクチャモデルを示す図である。
【図12】Ｄ２Ｄ ＵＥが関連づけられることができる４つの異なる状態に関するカバレージを示す図である。
【図13】規格に規定されるＰｒｏＳｅバッファ状況報告ＭＡＣ制御要素を示す図である。
【図14】例示的なシナリオに対するＰｒｏＳｅ論理チャネル（ＰｒｏＳｅ ＬＣＧ）とＰｒｏＳｅ宛先グループとの間の関連を示す図である。
【図15】特定のＭＣＰＴＴグループに関して受信および送信の両方を許容したユーザに対するＭＣＰＴＴユーザ状態を示す図である。
【図16】特定のＭＣＰＴＴグループに関して送信のみを許容したユーザに対するＭＣＰＴＴユーザ状態を示す図である。
【図17】特定のＭＣＰＴＴグループに関して受信のみを許容したユーザに対するＭＣＰＴＴユーザ状態を示す図である。
【図18】概念的なオンネットワークＭＣＰＴＴ優先度モデルを示す図である。
【図19】レイヤモデルでの優先度の統合の概略図である。
【図20】第２の実施形態の特定の変形に係る異なるＰｒｏＳｅ ＬＣＧとＰｒｏＳｅ宛先グループとの間の関係の図である。
【図21】図２０に例示した第２の実施形態の特定の変形に係るＰｒｏＳｅ ＬＣＨとＰｒｏＳｅ宛先グループとの間の特定の関連に対するＰｒｏＳｅ ＬＣＨとＰｒｏＳｅ ＬＣＧとの間の可能なマッピングを示す図である。
【図22】第２の実施形態の別の特定の変形に係る異なるＰｒｏＳｅ ＬＣＧとＰｒｏＳｅ宛先グループとの間の関係の図である。
【図23】図２２に例示した第２の実施形態の特定の変形に係る、図２１と同じＰｒｏＳｅ ＬＣＨとＰｒｏＳｅ宛先グループとの間の特定の関連に対するＰｒｏＳｅ ＬＣＨとＰｒｏＳｅ ＬＣＧとの間の可能なマッピングを示す図である。
【図24】第２の実施形態の変形に係るＰｒｏＳｅバッファ状況報告ＭＡＣ制御要素の図である。
【図25】第５の実施形態に係る優先順位付けのための例示的な方法を例示するフロー図である。
【図26】論理チャネルに対する優先度設定のための例示的な方法を例示するフロー図である。
【図27】論理チャネルを停止／再開することによってフロー制御をサポートするための例示的な方法を例示するフロー図である。
【図28】優先度に基づいてフロー制御を行うための例示的な方法を例示するフロー図である。
【図29】サイドリンク制御情報のフォーマットを例示する概略図である。
【図30】ＭＡＣ ＰＤＵのフォーマットを例示する概略図である。
【図31】３つのＵＥのグループのための例示的なフロア制御メカニズムを実装するメッセージフローを例示する概略図である。
【図32】３つのＵＥのグループのための例示的なフロア制御メカニズムを実装するメッセージフローを例示する概略図である。
【図33】論理チャネルの優先順位付けを実装するユーザ機器の例を例示するブロック図である。
【発明を実施するための形態】
【0131】
移動局または移動ノードまたはユーザ端末またはユーザ機器は、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有してもよい。機能エンティティは、所定の機能の集合をノードの他の機能エンティティまたはネットワークに実装および／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードが通信するために介することができる通信機構または媒体にノードを取り付ける１つまたは複数のインタフェースを有してもよい。同様に、ネットワークエンティティは、機能エンティティが他の機能エンティティまたは対応ノードと通信するために介してもよい通信機構または媒体に機能エンティティを取り付ける論理インタフェースを有してもよい。
【0132】
用語「無線リソース」は、一組の請求項でおよび本出願で使用する場合、時間－周波数リソースなどの物理無線リソースを指すとして広く理解しなければならない。
【0133】
一組の請求項でおよび本出願で使用する用語「ＰｒｏＳｅ」またはその非省略形で「Proximity Services（近接サービス）」は、背景項で例示的に説明したように、ＬＴＥシステムでの近接ベースのアプリケーションおよびサービスの文脈で適用される。「Ｄ２Ｄ」などの他の専門用語もこの文脈で使用して、近接サービスのためのデバイスツーデバイス通信を指す。さらには、「ＰｒｏＳｅデータ」または「ＰｒｏＳｅ宛先グループ」などの、一組の請求項を通して利用する専門用語全体と一貫するように、「ＰｒｏＳｅ論理チャネル」の専門用語を請求項で使用するが、しかしながら、異なる用語「サイドリンク」もこの文脈で、すなわち大抵「サイドリンク論理チャネル」、すなわち近接サービス／Ｄ２Ｄのために設定される論理チャネルとして使用する。一組の請求項でおよび残りの本出願で使用する用語「ＰｒｏＳｅ宛先グループ」は、例えば３ＧＰＰ ＬＴＥで規定される１つのソースレイヤ２ＩＤ－宛先レイヤ２ＩＤ対として理解することができる。
【0134】
背景で説明したように、１つの大きな目的は現行のＬＴＥシステム全体での近接サービスの実装を継続的に向上させることである。現在では、Ｄ２Ｄ通信のためのＬＣＰ手順は、サイドリンク論理チャネルが扱われる順序がＵＥ実装次第であるように規定され、すなわちサイドリンクチャネルのための優先順位付けメカニズムはサポートされておらず、本質的にすべてのサイドリンク論理チャネルはＵＥの観点から同じ優先度を有する。さらには、現在実装されるように、１つのＭＡＣ ＰＤＵのために、ＵＥにおけるＭＡＣエンティティは同じＰｒｏＳｅ宛先グループの論理チャネルのみを考えるものとする。再び、ＰｒｏＳｅ宛先グループがどの順序で扱われるかはＵＥ実装次第である。
【0135】
現在標準化されるＬＣＰ手順は、以下から明らかになるであろう、いくつかの不利点を伴う。
【0136】
例えば、Ｄ２Ｄリソースは非効率的に使用されており、半二重課題（ＵＥが、同じ時間、すなわちＴＴＩに受信および送信することができないという課題）は軽減されることができない。より詳細には、その課題を説明するために、特定のＰｒｏＳｅ宛先グループ（例えば公安）の数人のメンバが互いの間で通信するシナリオを前提とする。同じＰｒｏＳｅ宛先グループに帰属する２つのＵＥは、ＰｒｏＳｅデータを送信するためにそれぞれのグラントを受信する。ＰｒｏＳｅ宛先グループ（およびサイドリンク論理チャネル）の選択順序はＵＥ実装次第であるので、ｅＮｏｄｅＢは、例えばこれらの２つのＵＥが同じＴＴＩでの同じＰｒｏＳｅ宛先グループへの送信のためにそれらのグラントを使用するのを防止することができない。結果的に、２つの送信ＵＥは、（ＰｒｏＳｅの半二重動作のため）他方の送信ＵＥが同じ時間に送信しているので、同じＴＴＩで他方の送信ＵＥから送信を受信することができないことになる。第一に、上記半二重課題のためにグループメンバ間の情報が異なるという危険性がある、すなわちすべてのグループメンバがすべての情報を受信することが保証されない。さらには、スケジュールしたリソースのいくつかは非効率的に使用される。
【0137】
以上説明した課題を軽減するために、以下の例示的な実施形態が発明者らによって考えられる。
【0138】
以下では、いくつかの例証的な実施形態を詳細に説明することになる。これらのいくつかは、様々な実施形態に関連して以下で説明するような特定の主要な特徴を伴って、３ＧＰＰ規格によって与えられ、かつ本背景で部分的に説明したような広範な仕様で実装されるものである。実施形態は、例えば上記技術背景に記載したように、３ＧＰＰ ＬＴＥ－Ａ（Ｒｅｌｅａｓｅ１０／１１／１２／１３）通信システムなどの移動通信システムに有利に使用されることができるが、しかし実施形態はこの特定の例示的な通信ネットワークでのその使用に限定されないことに留意するべきである。
【0139】
説明は、本開示の範囲を限定するとしてではなく、本開示をよりよく理解するための実施形態の単なる例として理解するべきである。当業者は、請求項に述べるような本開示の一般的な原理が異なるシナリオに、かつ本明細書に明記しない方途で適用されることができることを認識しているべきである。対応して、様々な実施形態の説明目的で前提とする以下のシナリオは、本発明およびその実施形態をそのように限定するものではない。
例えば、以下の実施形態に対して、概してＰｒｏＳｅ ＬＣＰ手順が現在標準化されているのと同じ目的で、すなわちＵＥが、新たな送信を行うためにＭＡＣ ＰＤＵを構築するときに、送信のための利用可能なデータを持つ異なる論理チャネルに利用可能な無線リソースを割り当てるために、使用されるであろうことを前提とする。また、いくつかのＰｒｏＳｅ宛先グループが、現在標準化されているのと同じまたは同様にして既に規定されていることを前提とする。さらには、様々なＰｒｏＳｅ論理チャネルを設定するときに、ＰｒｏＳｅ論理チャネルとＰｒｏＳｅ宛先グループとの間の関連づけがＵＥで行われることを前提とし、そのためＵＥで設定される各ＰｒｏＳｅ論理チャネルは、ＰｒｏＳｅ論理チャネルのＰｒｏＳｅデータが向けられる特定のＰｒｏＳｅ宛先グループと関連づけられる。
例えば、以下の実施形態に対して、概してＰｒｏＳｅ ＬＣＰ手順が現在標準化されているのと同じ目的で、すなわちＵＥが、新たな送信を行うためにＭＡＣ ＰＤＵを構築するときに、送信のための利用可能なデータを持つ異なる論理チャネルに利用可能な無線リソースを割り当てるために、使用されるであろうことを前提とする。また、いくつかのＰｒｏＳｅ宛先グループが、現在標準化されているのと同じまたは同様にして既に規定されていることを前提とする。さらには、様々なＰｒｏＳｅ論理チャネルを設定するときに、ＰｒｏＳｅ論理チャネルとＰｒｏＳｅ宛先グループとの間の関連づけがＵＥで行われることを前提とし、そのためＵＥで設定される各ＰｒｏＳｅ論理チャネルは、ＰｒｏＳｅ論理チャネルのＰｒｏＳｅデータが向けられる特定のＰｒｏＳｅ宛先グループと関連づけられる。
【0140】
その上、様々な実施形態がＬＣＰ手順について論じ、これに従って送信のための利用可能なデータを持つＰｒｏＳｅ論理チャネル間で無線リソースが分配される。さらなるインジケーションまたは制限が与えられない場合、割り当てられるべき無線リソースは、ｅＮＢスケジュールリソース（リソース割当てモード１）かまたは適切なリソースプールからＵＥによって自律的に決定される無線リソース（リソース割当てモード２）かいずれかであることを前提とするべきである。
【0141】
（第１の例証的な実施形態）
第１の例示的な実施形態によれば、ユーザ機器で論理チャネル優先順位付け（ＬＣＰ）手順を行うときに論理チャネルに無線リソースを割り当てるための方法が、近接サービスのために提供される。方法は、ＵＥが、新たな送信のためのＭＡＣ ＰＤＵを生成するときに、利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに利用可能な無線リソースを割り当てるのを許容する。ＰｒｏＳｅ論理チャネルはＵＥで適切に設定され、第１の実施形態によれば、すべてのＰｒｏＳｅ論理チャネルは先行技術でと同じＰｒｏＳｅ ＬＣＧ（「１１」）に割り当てられる。主な着想は、ＬＣＰ手順を行うときに優先順位付けメカニズムを導入することであり、ＬＣＰ手順はＰｒｏＳｅ宛先グループに基づいている。先に説明したように、ＭＡＣ ＰＤＵは１つの特定のＰｒｏＳｅ宛先グループに関連するＰｒｏＳｅデータのみを含むものとし、そのためＵＥはまずＰｒｏＳｅ宛先グループを選択しなければならない。このことは第１の実施形態についても該当するが、しかしながら第１の実施形態は加えて、ＰｒｏＳｅ宛先グループの各々が、（例えば「ＰｒｏＳｅ宛先グループ優先度」と名付けられる）それぞれの優先度を割り当てられることを見込む。
第１の例示的な実施形態によれば、ユーザ機器で論理チャネル優先順位付け（ＬＣＰ）手順を行うときに論理チャネルに無線リソースを割り当てるための方法が、近接サービスのために提供される。方法は、ＵＥが、新たな送信のためのＭＡＣ ＰＤＵを生成するときに、利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに利用可能な無線リソースを割り当てるのを許容する。ＰｒｏＳｅ論理チャネルはＵＥで適切に設定され、第１の実施形態によれば、すべてのＰｒｏＳｅ論理チャネルは先行技術でと同じＰｒｏＳｅ ＬＣＧ（「１１」）に割り当てられる。主な着想は、ＬＣＰ手順を行うときに優先順位付けメカニズムを導入することであり、ＬＣＰ手順はＰｒｏＳｅ宛先グループに基づいている。先に説明したように、ＭＡＣ ＰＤＵは１つの特定のＰｒｏＳｅ宛先グループに関連するＰｒｏＳｅデータのみを含むものとし、そのためＵＥはまずＰｒｏＳｅ宛先グループを選択しなければならない。このことは第１の実施形態についても該当するが、しかしながら第１の実施形態は加えて、ＰｒｏＳｅ宛先グループの各々が、（例えば「ＰｒｏＳｅ宛先グループ優先度」と名付けられる）それぞれの優先度を割り当てられることを見込む。
【0142】
ＰｒｏＳｅ宛先グループ優先度は、Ｕｕインタフェースで送信されるＭＡＣ ＰＤＵの生成のためにＬＣＰ手順内でＬＴＥにおいて使用される論理チャネル優先度と異なってもよい。技術背景に記載したように、ＵｕインタフェースでのＬＴＥアップリンク送信に関しては、基本的にすべての論理チャネルのデータがＭＡＣ ＰＤＵに多重化されることができ、論理チャネル優先度は論理チャネルが扱われる順序を決定する。しかしながらＰｒｏＳｅ通信に関しては、同じＰｒｏＳｅ宛先グループに割り当てられる論理チャネルのデータのみがＰｒｏＳｅ ＰＤＵにマッピングされることができる。
【0143】
ＰｒｏＳｅ宛先グループにそれぞれの優先度を割り当てることは、例えばネットワークにおける上位レイヤエンティティ、すなわち上記の点で役割を担う対応するＰｒｏＳｅ機能またはエンティティによって行うことができる。例えば、上記ＰｒｏＳｅ機能／エンティティは、ＰｒｏＳｅ宛先グループを既に設定および管理するものと同じであることができる。図１５に関連して背景で説明したように、そのようなＰｒｏＳｅエンティティは本明細書に規定するＰｒｏＳｅ機能であることができる。上記の場合、ＰｒｏＳｅ宛先グループに関する情報およびそれらの優先度は、ＰＣ３インタフェースを介して直接行うことができるＰｒｏＳｅ対応ＵＥなど、および／または、ｅＮｏｄｅＢなど、ネットワークにおける他のエンティティに分配される。例えば、ＰｒｏＳｅ機能／エンティティは、なんらかの上位レイヤプロトコルによって、割り当てられたＰｒｏＳｅ宛先グループと共にＰｒｏＳｅ宛先グループに関する（ＩＤなどの）情報を送信する。
【0144】
さらには、この情報はまずＥ－ＵＴＲＡＮのｅＮＢに提供することができる。ｅＮｏｄｅＢは、ＰｒｏＳｅ機能の代わりに、次いでＵＥに通知することができる。
【0145】
代替的に、ＰｒｏＳｅ宛先グループ優先度はＵＥ（およびｅＮＢ）に既に予め設定されてもよく（例えば規格によって、またはＵＩＣＣに記憶されて）、そのため対応する情報はネットワークを通じてシグナリングされなければならないのではなく、最初からＵＥ（およびｅＮＢ）で既に利用可能である。
【0146】
さらには、ＰｒｏＳｅ宛先グループに対して利用可能な実際の優先度レベルがどのように実装されることができるかに関するいくつかの可能性もある。約８つの異なるＰｒｏＳｅ宛先グループをＵＥに対して設定することができることが現在論じられている。結果的に、第１の実施形態の１つの変形はそこで、３ビットで符合化される、対応する数の８つの異なる優先度レベルを提供するものであり、ここで例えば優先度レベル１が最高であり、優先度レベル８が最低優先度であるか、またはその逆である。例えば、公安のためのＰｒｏＳｅ宛先グループは高優先度を有するだろう。しかしながら、ＰｒｏＳｅ宛先グループより少ない優先度レベルであってもよい。さらには、ＰｒｏＳｅ宛先グループ優先度に基づいて本明細書で論じる様々な実施形態はその優先度には限定されず、ＰｒｏＳｅ宛先グループの任意の他の適切な優先順位付けが可能である。
【0147】
第１の実施形態は、上論したＰｒｏＳｅ宛先グループ優先度に基づいてＬＣＰ手順のために優先順位付けメカニズムを実装する。より詳細には、第１のステップが導入され、それに従ってＵＥは、ＰｒｏＳｅデータが利用可能であり、かつ対応するＭＡＣ ＰＤＵが新たな送信のために生成されるものとするときに、ＰｒｏＳｅ宛先グループの１つをその優先度に従って選択し、そのため生成および送信されるべきＭＡＣ ＰＤＵは上記選択したＰｒｏＳｅ宛先グループに向けられるＰｒｏＳｅ論理チャネルのＰｒｏＳｅデータのみを含むことになる。例えば、ＵＥは最高優先度を持つＰｒｏＳｅ宛先グループを選択する。どのデータが実際に利用可能であるかについてそれらのＰｒｏＳｅ宛先グループのみが考えられることに留意するべきである。すなわち、例えば優先度がより高いが、送信されるべきデータのないＰｒｏＳｅ宛先グループは無視される。
【0148】
先に前提としたように、無線リソースは、モード１割当てリソースであろうとモード２割当てリソースであろうと、ＵＥがＰＣ５インタフェースを介して別のＰｒｏＳｅ ＵＥにＤ２Ｄ直接通信でデータを送信するために利用可能である。対応して、第２のステップで、ＵＥはＰｒｏＳｅ論理チャネル（例えばＳＴＣＨ）に利用可能な無線リソースを割り当てるものとするが、選択したＰｒｏＳｅ宛先グループに帰属するＰｒｏＳｅ論理チャネルのみを考える。しかしながら、どれくらい正確に、例えばどの順序でＵＥが上記選択したＰｒｏＳｅ宛先グループの様々なＰｒｏＳｅ論理チャネルを扱うかは、ここではそれぞれのＵＥ実装次第であり、この時点ではさらに詳細には特定しない。上記の点で、上記ＰｒｏＳｅ宛先グループ内のすべてのＰｒｏＳｅ論理チャネルが同じ優先度（後に説明することになるように、第２の実施形態に従って変更される）を有することに留意するべきである。
【0149】
ＭＡＣ ＰＤＵはしたがって、上記選択した高優先度ＰｒｏＳｅ宛先グループのみのＰｒｏＳｅデータで構築される。
【0150】
上記の点で、ＭＡＣ ＰＤＵは、現在標準化されるように、２つの異なるＰｒｏＳｅ宛先グループのＰｒｏＳｅデータを備えることができないことに留意するべきである。結果的に、たとえ選択したＰｒｏＳｅ宛先グループのすべてのＰｒｏＳｅ論理チャネルが扱われた後に無線リソースがなお利用可能であるとしても（すなわちＭＡＣ ＰＤＵに余地が残されるとしても）、他のＰｒｏＳｅ論理チャネルのさらなるＰｒｏＳｅデータは含めることができず、例えばＭＡＣ ＰＤＵはパディングまたは、存在すればＰｒｏＳｅ ＭＡＣ ＣＥで満たされる。
【0151】
このように生成したＭＡＣ ＰＤＵは次いで、通例のようにさらに処理および送信される。例えば、リソース割当てモードに応じて、ＭＡＣ ＰＤＵの、および先だって対応するＳＡメッセージの送信は、例えば図１５および１６に関連して背景で説明したように行うことができる。
【0152】
第１の実施形態へのさらなる任意選択の改善として、ＵＥは、ＬＣＰ手順を行うときに以下の規則をさらに考慮するべきである：
－ ＵＥは、全体のＳＤＵ（または部分的に送信されるＳＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵ）をセグメント化するべきでない。
－ ＵＥがサイドリンク論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする。
－ ＵＥはデータの送信を最大化するべきである。
－ ＵＥが、送信のために利用可能なデータを有しつつ、１０バイト以上であるサイドリンクグラントサイズを与えられれば、ＵＥは、パディングのみを送信することはしないものとする。
－ ＵＥは、全体のＳＤＵ（または部分的に送信されるＳＤＵ）が残りのリソースに収まれば、ＲＬＣ ＳＤＵ（または部分的に送信されるＳＤＵ）をセグメント化するべきでない。
－ ＵＥがサイドリンク論理チャネルからのＲＬＣ ＳＤＵをセグメント化する場合、ＵＥは、可能な限りグラントを満たすようにセグメントのサイズを最大化するものとする。
－ ＵＥはデータの送信を最大化するべきである。
－ ＵＥが、送信のために利用可能なデータを有しつつ、１０バイト以上であるサイドリンクグラントサイズを与えられれば、ＵＥは、パディングのみを送信することはしないものとする。
【0153】
これらの任意選択の規則は、背景に提示したような現在標準化されたＬＣＰ手順から取られ、第１の実施形態の改善された／支援されたＬＣＰ手順のために（第２および第３の実施形態のためにも）同様に使用することができる。
【0154】
第１の実施形態によって達成される利点は、ＰｒｏＳｅ宛先グループの選択がＵＥ実装次第ではないということである。むしろ、異なるＰｒｏＳｅ宛先グループに優先度を適切に割り当て、割り当てた優先度に基づいてＰｒｏＳｅ宛先グループをＵＥに選択させることによって、ＵＥの振る舞いは上記の点で予め決定され、したがって予見できる（例えばｅＮＢにとって）。対応して、ｅＮＢはこの予見できるＵＥの振る舞いを使用して、ｅＮＢのスケジューリングを向上させ（ｅＮＢスケジュールリソース割当てモード１が使用されるとき）、したがって、例えば、半二重課題を軽減することができる。特に、ｅＮＢは、２つのＵＥが最高優先度を有するように同じＰｒｏＳｅ宛先グループを有すれば、同じＴＴＩに対してそれらをスケジュールしないものである。半二重課題を説明したときの上論したシナリオでは、２つのＵＥが同じＰｒｏＳｅ宛先グループに同じ時間に送信することを回避するように、ｅＮＢは２つのＵＥの一方のみをスケジュールし、そして他方のＵＥを、例えば、次またはその後のＴＴＩにスケジュールするものである。無線リソースはもはや浪費されず、したがってより効率的に使用／スケジュールすることができる。
【0155】
さらには、（公安、警察などといった、重要なＰｒｏＳｅ宛先グループについてなどの）重要なＰｒｏＳｅデータは、対応するＰｒｏＳｅ宛先グループ優先度が高く設定されることになるので、不必要に遅延することはなく、したがって以上提示したように、ＬＣＰ手順を行うときにＵＥで優先して扱われることになる。
【0156】
第１の実施形態の変形によれば、以前のＬＣＰ手順を考慮することによって、ＰｒｏＳｅ宛先グループ優先度に基づくＰｒｏＳｅ宛先グループの選択はさらに改善される。言い換えると、ＰｒｏＳｅ宛先グループはそれらのＰｒｏＳｅ宛先グループ優先度の降順で厳密に扱われるのではなく、より低い優先度のＰｒｏＳｅ宛先グループの遅延および／または枯渇が回避されるように、以前のＬＣＰ手順を考慮するときに例外があってもよい。
【0157】
ＰｒｏＳｅ宛先グループの中で最高優先度を持つ、利用可能なデータを持つＰｒｏＳｅ宛先グループの中のＰｒｏＳｅ宛先グループを選択するステップは、新たな送信が行われるべきである各時間、すなわちＬＣＰ手順が行われる各時間に繰り返すことができる。上記の場合、ＰｒｏＳｅ宛先グループの中で最高優先度を有する同じ１つのＰｒｏＳｅ宛先グループが、上記ＰｒｏＳｅ宛先グループに対してＰｒｏＳｅデータが常に利用可能であることを前提として、毎回選択される。このことは、より低い優先度を持つＰｒｏＳｅ宛先グループの著しい遅延および枯渇に至ることがあり、（ＬＣＰ手順が行われる）１つのＳＡ／データ期間の間、ＵＥが１つのＰｒｏＳｅ宛先グループにのみ送信することができることを必要とする現行の標準化によって悪化される。したがって、たとえ最高優先度を持つＰｒｏＳｅ宛先グループを扱った後にＳＡ／データ期間中のどこかの点で未使用リソースが利用可能であったとしても、未使用リソースは、他のＰｒｏＳｅ宛先グループに向けられるＰｒｏＳｅデータに対して使用することができない。
【0158】
そのようなシナリオに関する不利点を回避するために、第１の実施形態の変形は、他のより低い優先度のＰｒｏＳｅ宛先グループのためにＰｒｏＳｅデータが同様に利用可能であるときに、特定のＰｒｏＳｅ宛先グループが長時間繰り返し扱われることを回避することによって、第１の優先順位付けメカニズムを改善する。
【0159】
より詳細には、ＰｒｏＳｅ宛先グループの中で最高優先度を持つ、利用可能なデータを持つＰｒｏＳｅ宛先グループの中のＰｒｏＳｅ宛先グループを選択するステップは、以前のＬＣＰで（またはいくらかの所定時間前に行ったＬＣＰで）最高優先度を持つその同じＰｒｏＳｅ宛先グループが既に扱われた場合には、たとえその後のＬＣＰ手順を行うときにこのＰｒｏＳｅ宛先グループのためのＰｒｏＳｅデータ（古いまたは新しい）が送信のために利用可能であるとしても、ステップ自体行われない。そのような場合には、その既に扱ったＰｒｏＳｅ宛先グループはＬＣＰ手順に関して一時的に無視され、そのため実際上、ＰｒｏＳｅ宛先グループの中で２番目に最高優先度を持つ、利用可能なデータを持つ残りのＰｒｏＳｅ宛先グループの中のＰｒｏＳｅ宛先グループが、ＬＣＰ手順をさらに続行するために選択される。
【0160】
第１の実施形態のこの改善された変形は、以下説明することになるように、将来のシナリオにも適用されてもよい。当面、ＵＥはＳＡ／データ期間ごとに１つの有効なＰｒｏＳｅグラントのみを有することが標準化され、そのため、たとえ、ＵＥが第２のＰｒｏＳｅグラントを受信したとしても、ＵＥは、新たなグラントを選んで「古い」ものを破棄することになる。さらには、このＰｒｏＳｅグラントが有効である１つのＳＡ／データ期間の間、ＵＥは、１つのＰｒｏＳｅ宛先グループにのみ送信することができる。結果として、たとえ、最初に選択したＰｒｏＳｅ宛先グループのために利用可能であるデータがないとしても、グラントからの未使用無線リソースを使用して別のＰｒｏＳｅ宛先グループにデータを送信することは可能でない。このことはリソースの浪費であり、したがって、このことは、１つのＳＡ／データ期間の間に２つ以上のＰｒｏＳｅ宛先グループを扱うことができ、２つ以上のＰｒｏＳｅグラントを受信および使用することができるように将来のリリースで変わるかもしれない。別に自律選択（モード２）に関して、ＵＥはＳＡ／データ期間の間に２つ以上のＳＬグラントを選択するのを許容されてもよい。その上、１つのＭＡＣ ＰＤＵは、１つのＰｒｏＳｅ宛先グループのためのデータのみを含むことをなお必要とされることがある。
【0161】
そのような場合、複数のＰｒｏＳｅ ＭＡＣ ＰＤＵが送信されるべきであり（すなわち複数のＰｒｏＳｅ宛先グループに）、かつ、複数のＰｒｏＳｅグラントが利用可能であれば、ＰｒｏＳｅ宛先グループの選択は、ＰｒｏＳｅ宛先グループ優先度の降順に行われる。詳細には、第１のＰｒｏＳｅグラントは、ＰｒｏＳｅ宛先グループの中で最高優先度を持つ、利用可能なデータを持つＰｒｏＳｅ宛先グループに対する第１のＬＣＰ手順の間、使用される。しかしながら、第２のＰｒｏＳｅグラントは、たとえＰｒｏＳｅ宛先グループの中で最高優先度を持つＰｒｏＳｅ宛先グループに送信されるために利用可能な残りのデータがあるとしても、ＰｒｏＳｅ宛先グループの中で２番目に最高優先度を持つ、利用可能なデータを持つＰｒｏＳｅ宛先グループに対する第２のＬＣＰ手順の間、使用される。任意のさらなるＰｒｏＳｅ宛先グループおよびＰｒｏＳｅグラントに関しても同様である。
【0162】
（第２の例証的な実施形態）
第１の実施形態は先行技術の対応するＬＣＰ手順に勝る様々な利点を既に提供するとはいえ、発明者らはさらなる不利点を特定した。
第１の実施形態は先行技術の対応するＬＣＰ手順に勝る様々な利点を既に提供するとはいえ、発明者らはさらなる不利点を特定した。
【0163】
先行技術に関し、第１の実施形態の手順にも関する別の課題は、ＬＣＰ手順の間のサイドリンク論理チャネルの選択順序がＵＥ実装次第であるので、ＵＥが、最高優先度を持つ、ボイスオーバーＩＰ（ＶｏＩＰ：Voice over IP）のような遅延にクリティカルなサービスを扱うという保証がないということである。誤った、または、非最適なＵＥ実装が遅延にクリティカルなサービスに対し、大きい待ち時間およびおそらく枯渇さえ被ることがある。
【0164】
例示の目的のみで、以下、３つのＰｒｏＳｅ論理チャネル（ＬＣＨ＃１、ＬＣＨ＃２およびＬＣＨ＃３）がユーザ機器に設定され、３つのすべてが先行技術でと同じＰｒｏＳｅ ＬＣＧ（例えば「１１」）と関連づけられる例示的なシナリオを考える。ＬＣＨ＃１およびＬＣＨ＃２がＰｒｏＳｅ宛先グループ１に割り当てられ、ＬＣＨ＃３がＰｒｏＳｅ宛先グループ２に割り当てられることを例示的に前提とする。これを図２１に例示する。ＰｒｏＳｅ宛先グループ１は、ＰｒｏＳｅ宛先グループ２より高い優先度を有すると前提する。ＰｒｏＳｅデータはすべての３つの論理チャネルに対して送信されるように利用可能であり、無線リソースはＵＥによって割り当てられるように利用可能である。
【0165】
第１の実施形態の様々な変形がこのシナリオに適用されるとすれば、データが送信されるべきである２つのＰｒｏＳｅ宛先グループ間でより高い優先度を有するために、ＵＥはまずＰｒｏＳｅ宛先グループ１を選択するであろう。次いで、選択したＰｒｏＳｅ宛先グループ１の論理チャネルが扱われる順序、すなわち、ＬＣＨ＃１およびＬＣＨ＃２のうち、ＵＥ実装次第で、ＬＣＨ＃１かまたはＬＣＨ＃２かいずれかがまず扱われる。したがって、両ＬＣＨのデータのために十分な無線リソースがなければ、２つのＰｒｏＳｅ ＬＣＨの一方のデータは遅延することになり、最悪の場合、枯渇が起こることがある。このことは、これがＶｏＩＰなどの遅延にクリティカルなサービスに起こる場合、特に不利益である。例えば、ＬＣＨ＃１が遅延にクリティカルなデータを搬送していることを前提とすると、ＵＥが最初にＬＣＨ＃２を扱うことを決定すれば、対応して構築されたＭＡＣ ＰＤＵは遅延にクリティカルなサービスのデータのいずれも含まないか、またはその一部のみを含むかもしれない。
【0166】
第２の実施形態の変形はこの課題を解決するものとし、その目的で、以下詳細に説明することになるように、第２の優先順位付けレベルが導入される。以下では、第２の実施形態を、第１の実施形態に完全に基づくとして主に例解目的で説明することになり、すなわち第２の実施形態は、第２の優先順位付けレベルを追加的に実装することによって第１の実施形態を拡張するが、しかし第１の実施形態（およびその変形）のその他の特徴を維持する。しかしながら、二次優先順位付けメカニズムの使用はスタンドアロンで、すなわちＰｒｏＳｅ宛先グループをその優先度に基づいて選択する第１の優先順位付けメカニズムを有さずに使用することもできることに留意するべきである。結果的に、以下の説明が、第１の態様（および以上説明したすべてのその変形）の第１の優先順位付けメカニズムを実際には含む第２の実施形態に重点を置く一方で、第２の実施形態はそれに限定されるものではなく、スタンドアロンと考えられてもよい。
【0167】
第２の実施形態のために使用する第２の優先順位付けメカニズムは、異なるＰｒｏＳｅ論理チャネルグループ（ＰｒｏＳｅ ＬＣＧ：ProSe Logical Channel Group）およびそれらの対応する優先度間で区別をする。要するに、ＰｒｏＳｅ論理チャネルに対して１つのＰｒｏＳｅ ＬＣＧ（「１１」）のみが提供される現行の標準化（背景および例えば図１４を参照のこと）とは対照的に、ＰｒｏＳｅ直接通信のために複数のＰｒｏＳｅ ＬＣＧが規定され、ＵＥは設定ＰｒｏＳｅ論理チャネルを関連づけてもよい。さらに、複数のＰｒｏＳｅ ＬＣＧの各々は、例えば「ＰｒｏＳｅ ＬＣＧ優先度」と名付けられるそれぞれの優先度を割り当てられる。次いで、ＬＣＰ手順を行う場合、ＵＥは、ＰｒｏＳｅ論理チャネル間で利用可能なリソースを割り当てるときに、すなわちＰｒｏＳｅ論理チャネルがそれらの関連する優先度の降順に扱われるように、様々なＰｒｏＳｅ論理チャネルが帰属するＰｒｏＳｅ ＬＣＧのそれぞれの優先度を考慮する。このことは以下により詳細に説明することになる。
【0168】
異なるＰｒｏＳｅ ＬＣＧがどのように規定されるかに関するいくつかの可能性がある。とりわけ、このことは、様々なＰｒｏＳｅ宛先グループに対するＰｒｏＳｅ論理チャネルとＰｒｏＳｅ ＬＣＧとの間のマッピングがどのように実装されるかにも依存するだろう。２つの択一の可能なマッピングを以下提示することになるが、他のものが等しく可能であってもよい。
【0169】
２つの選択肢は図２０および図２２に関連して例示することになり、図中、ＰｒｏＳｅ宛先グループとＰｒｏＳｅ ＬＣＧとの間の関係を例示するものとする。両図で、合計で４つの、すなわち２ビットの対応するＰｒｏＳｅ宛先グループＩＤを持つＰｒｏＳｅ宛先グループのみがあることを例示的に前提とし、ＰｒｏＳｅ ＬＣＧを識別するために１ビットが利用可能である（０または１）ことをさらに前提とする。それぞれの例を図２１および図２３に例示し、ここで２つのＰｒｏＳｅ宛先グループおよび４つのＰｒｏＳｅ ＬＣＧを伴って異なるシナリオが前提とされる。
【0170】
第１の選択肢は図２０に関連して説明することになり、図中、各ＰｒｏＳｅ宛先グループがＰｒｏＳｅ ＬＣＧのいずれかに関連することができることを例示し、言い換えると、ＰｒｏＳｅ ＬＣＧは、規定されたＰｒｏＳｅ宛先グループに関わらず規定される。結果的に、ＰｒｏＳｅ ＬＣＧ ＩＤを使用することによって、規定されたＰｒｏＳｅ ＬＣＧ間で区別することが可能である、すなわちＰｒｏＳｅ ＬＣＧ ＩＤ：０がＰｒｏＳｅ ＬＣＧ＃１を識別し、ＰｒｏＳｅ ＬＣＧ ＩＤ：１がＰｒｏＳｅ ＬＣＧ＃２を識別する。ＵＥによる異なるＰｒｏＳｅ ＬＣＧへのＰｒｏＳｅ論理チャネルの対応するマッピングは、このことを考慮し、したがってＰｒｏＳｅ論理チャネルが帰属するＰｒｏＳｅ宛先グループから独立している。例えば、ＵＥは、そのＰｒｏＳｅ論理チャネルを設定するとき、それらの各々を規定されたＰｒｏＳｅ ＬＣＧの任意の１つに適宜割り当てることになる。このことは図２１に例示的に示され、ここでＰｒｏＳｅ ＬＣＨ＃１およびＰｒｏＳｅ ＬＣＨ＃３がＰｒｏＳｅ宛先グループ１と関連づけられると前提し、ＰｒｏＳｅ ＬＣＨ＃２はＰｒｏＳｅ宛先グループ２と関連づけられる。破線で描くように、ＰｒｏＳｅ論理チャネルの各々は、それらのＰｒｏＳｅ宛先グループとの関連にかかわらず、ＰｒｏＳｅ ＬＣＧ１～４のいずれかと関連づけられることができる。換言すれば、異なるＰｒｏＳｅ宛先グループと関連づけられるＰｒｏＳｅ ＬＣＨが同じＰｒｏＳｅ ＬＣＧにマッピングされることができる（以下に説明する第２の選択肢では可能でない）。
【0171】
図２２に例示する第２の選択肢によれば、各ＰｒｏＳｅ宛先グループに対して異なるＰｒｏＳｅ ＬＣＧが規定される。図２２の例示的なシナリオでは、合計で８つの異なるＰｒｏＳｅ ＬＣＧが４ｘ２としてあってもよく、ここで４は異なるＰｒｏＳｅ宛先グループの総数に関し、２はＰｒｏＳｅ宛先グループごとの異なるＰｒｏＳｅ ＬＣＧに関する。全ての異なるＰｒｏＳｅ ＬＣＧ間で明白に区別するために、ＰｒｏＳｅ ＬＣＧ ＩＤに加えてＰｒｏＳｅ宛先グループ（例えばＰｒｏＳｅ宛先グループＩＤ）を考慮することが必要である。換言すれば、ＰｒｏＳｅ ＬＣＧは、特定のＰｒｏＳｅ宛先グループのみに制限される。対応して、ＰｒｏＳｅ宛先グループＩＤは、単独でＰｒｏＳｅ宛先グループを明白に規定し、ＰｒｏＳｅ ＬＣＧ ＩＤとの組合せで、ＰｒｏＳｅ ＬＣＧを明白に識別するためのコードポイントを提供する。ＵＥによる異なるＰｒｏＳｅ ＬＣＧへのＰｒｏＳｅ論理チャネルの対応する可能なマッピングは、図２０および図２１に関して説明したものとも異なる。以上説明したように、ＵＥは、ＰｒｏＳｅ論理チャネルを設定するとき、それらの各々に対して特定のＰｒｏＳｅ宛先グループを適宜割り当てられることになる。ＵＥは次いで、ＰｒｏＳｅ論理チャネルの各々に対して、論理チャネルが関連づけられるＰｒｏＳｅ宛先グループに帰属するＰｒｏＳｅ ＬＣＧのみを割り当てられてもよい。このことは、図２３に例示的に示され、ここで図２１についてと同じＰｒｏＳｅ ＬＣＨとＰｒｏＳｅ宛先グループとの間の関連を前提とする。ここでは、しかしながら、ＰｒｏＳｅ ＬＣＨ１および３はＰｒｏＳｅ宛先グループ１と関連づけられるので、それらはＰｒｏＳｅ ＬＣＧ１または２、すなわち、それら自体ＰｒｏＳｅ宛先グループ１と関連づけられているものと関連づけられることができるのみである（破線を参照のこと）。同じことがＰｒｏＳｅ ＬＣＨ２に当てはまり、したがってＰｒｏＳｅ ＬＣＧ３かまたはＬＣＧ４かいずれか、すなわち、それら自体ＰｒｏＳｅ宛先グループ２と関連づけられているものに、ＵＥによってマッピングされることができるのみである。
【0172】
１つの変形によれば、異なるＰｒｏＳｅ ＬＣＧおよびそれらの優先度は、例えばネットワークにおける上位レイヤエンティティ、すなわち上記の点で役割を担うものとする対応するＰｒｏＳｅ機能またはエンティティ、例えば図１５に関連して背景に既に提示したＰｒｏＳｅ機能によって中央で規定されてもよい。上記の場合、ＰｒｏＳｅ ＬＣＧに関する情報およびそれらの優先度は、ＰＣ３インタフェースを介して直接行うことができるＰｒｏＳｅ対応ＵＥなど、ネットワークにおける他のエンティティに、および例えばなんらかの上位レイヤプロトコルを用いてｅＮｏｄｅＢに分配される。
【0173】
代替的に、ＰｒｏＳｅ ＬＣＧに関するそれぞれの情報およびそれらの優先度は、まずＥ－ＵＴＲＡＮのｅＮＢに提供され、ｅＮＢは、次いで、ＵＥと直接交信するＰｒｏＳｅ機能の代わりに、ＵＥに通知するはずである。
【0174】
代替的に、ＰｒｏＳｅ ＬＣＧおよびそれらの優先度は、ＵＥ（およびｅＮＢ）に予め設定されてもよく（例えば規格によって、またはＵＩＣＣに記憶されて）、そのため対応する情報は、ネットワークでシグナリングされなければならないのではなく、最初からＵＥ（およびｅＮＢ）で既に利用可能である。
【0175】
さらには、ＰｒｏＳｅ ＬＣＧに対して利用可能な実際の優先度レベルがどのように実装されることができるかに関するいくつかの可能性もある。このことは、例えば図２０～図２３に関連して説明したように実際の実装に応じて変化してもよいＰｒｏＳｅ ＬＣＧの総数に依存してもよい。例えば、第２の実施形態の１つの変形は、そこで、例えば最高などであるとする優先度レベル１から始まる、ＰｒｏＳｅ ＬＣＧの数と同じ数の優先度レベルを提供するものである。しかしながら、ＰｒｏＳｅ ＬＣＧより少ない優先度レベルがあってもよい。ＰｒｏＳｅ ＬＣＧの任意の他の適切な優先順位付けも可能である。
【0176】
ＰｒｏＳｅ ＬＣＧ優先度は、第２の実施形態のＬＣＰ手順で第２の優先順位付けメカニズムのために使用され、第２の優先順位付けメカニズムは、新たな送信のためのＭＡＣ ＰＤＵを構築するために利用可能な無線リソースを割り当てるときにＰｒｏＳｅ論理チャネルがどの順序で扱われるかを決定する。特に、ＰｒｏＳｅ論理チャネルは、それらがマッピングされたＰｒｏＳｅ ＬＣＧを介して関連づけられるＰｒｏＳｅ ＬＣＧ優先度を有する。第２の優先順位付けによれば、利用可能なリソースはＰｒｏＳｅ論理チャネルに、それらの対応するＰｒｏＳｅ ＬＣＧ優先度の降順に割り当てられる。
【0177】
ＭＡＣ ＰＤＵは、したがって、ＰｒｏＳｅ ＬＣＧ優先度降順にＰｒｏＳｅ論理チャネルからのＰｒｏＳｅデータで順次構築される。
【0178】
同じＰｒｏＳｅ ＬＣＧと関連づけられているＰｒｏＳｅ論理チャネルが、同じ優先度、すなわち、同じＰｒｏＳｅ ＬＣＧ優先度を有することになることに留意するべきであり、同じ関連する優先度を持つこれらの特定のＰｒｏＳｅ論理チャネルがＬＣＰ手順の間に扱われる順序は、例えばＵＥ実装次第である。
【0179】
ＰｒｏＳｅ ＬＣＧ優先度に基づいて上記第２のレベルの優先順位付けを実装することの利点は、同じＰｒｏＳｅ宛先グループに帰属するサイドリンク論理チャネルに対して、詳細な優先順位付け制御が可能であるということである。ＵＥ挙動が予測可能であるので、ｅＮＢはｅＮＢスケジュールリソース割当てモード１のために、より効率的にスケジュールすることができる。さらには、ＶｏＩＰなどの遅延にクリティカルなデータは、対応する高優先度を持つＰｒｏＳｅ ＬＣＧにＵＥがマッピングするであろうＰｒｏＳｅ論理チャネルによって伝送されることになる。結果的に、第２の実施形態に係るＬＣＰ手順が、リソースを割り当てる間これらのＰｒｏＳｅ ＬＣＧ優先度を考慮するので、遅延にクリティカルなデータはいかなる不必要な遅延なしで最初に送信されることになる。
【0180】
上述したように、第２の優先順位付けレベルは、第１の実施形態の様々な変形で実装することができ、そのため２つの後続のレベルの優先順位付けがあり、第１のステップで、ＵＥはＰｒｏＳｅ宛先グループをそれらの優先度の降順に扱い、次いで後続の第２のステップで、ＵＥは現在選択した（すなわち現在扱う）高優先度のＰｒｏＳｅ宛先グループのＰｒｏＳｅ論理チャネルをそれらの関連するＰｒｏＳｅ ＬＣＧ優先度の降順に扱う。
【0181】
代替の実装では、ＵＥは、ＰｒｏＳｅ宛先グループ優先度および論理チャネルに関連づけられるＰｒｏＳｅ ＬＣＧ優先度に基づいて、論理チャネル優先度を導出し、論理チャネルの優先度順序に論理チャネルを扱うはずである。より詳しくは、論理チャネルの優先度は、この論理チャネルと関連づけられるＰｒｏＳｅ宛先グループの優先度とこの論理チャネルと関連づけられるＰｒｏＳｅ ＬＣＧの優先度の関数であるだろう。１つの例示的な実装では、ＵＥはまず、先に説明したように、ＰｒｏＳｅ宛先グループ優先度とＰｒｏＳｅ ＬＣＧ優先度の関数を使用することによって論理チャネルの優先度を導出し、次いで論理チャネルが論理チャネル優先度順に扱われるＬＴＥアップリンクの場合と同様のＬＣＰ手順を行うはずである。
【0182】
第２の実施形態のさらなる変形は、ｅＮＢがより詳細な情報を受信するように適合バッファ状況報告を提供する。当面、ＰｒｏＳｅバッファ状況報告はＰｒｏＳｅ宛先グループごとにバッファサイズ情報を提供するが、バッファサイズ情報は上記ＰｒｏＳｅ宛先グループのすべてのＰｒｏＳｅ論理チャネルに渡る利用可能なデータ量を示す（背景および図１３を参照のこと）。さらには、すべてのサイドリンク論理チャネルは、先行技術では１つのＬＣＧにマッピングされる。結果的に、現在標準化されたＰｒｏＳｅバッファ状況報告ＭＡＣ制御要素は、１つのＰｒｏＳｅ宛先グループ内の異なる論理チャネルのデータ間で区別をしない。
【0183】
１つの変形によれば、ＰｒｏＳｅバッファ状況報告はより詳細な情報、すなわちＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧの対ごとのバッファサイズ情報を提供し、バッファサイズ情報は、上記対と関連づけられている、すなわち上記対のＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧ両方と関連づけられているすべてのＰｒｏＳｅ論理チャネルに渡るＰｒｏＳｅデータ量を示す。
【0184】
図２４は、第２の実施形態のこの変形に係るＰｒｏＳｅ ＢＳＲ ＭＡＣ制御要素を例示的に開示し、ここではＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧの各対に対して、ＭＡＣ ＣＥは以下を備える。
－ グループインデックス：グループインデックスフィールドは対のＰｒｏＳｅ宛先グループを識別する。このフィールドの長さは４ビットである。値は、ProseDestinationInfoListで報告される宛先識別情報のインデックスに設定される。
－ ＬＣＧ ＩＤ：論理チャネルグループ（Logical Channel Group）ＩＤフィールドは対のＰｒｏＳｅ ＬＣＧを識別する（したがってバッファ状況が報告されている論理チャネルを識別する）。フィールドの長さは２ビットである。
－ グループインデックス：グループインデックスフィールドは対のＰｒｏＳｅ宛先グループを識別する。このフィールドの長さは４ビットである。値は、ProseDestinationInfoListで報告される宛先識別情報のインデックスに設定される。
－ ＬＣＧ ＩＤ：論理チャネルグループ（Logical Channel Group）ＩＤフィールドは対のＰｒｏＳｅ ＬＣＧを識別する（したがってバッファ状況が報告されている論理チャネルを識別する）。フィールドの長さは２ビットである。
【0185】
バッファサイズ：バッファサイズフィールドは、ＴＴＩに対するすべてのＭＡＣ ＰＤＵが構築された後にＰｒｏＳｅ宛先グループ－ＰｒｏＳｅ ＬＣＧ対のすべての論理チャネルに渡って利用可能な総データ量を識別する。データ量はバイト数で示される。
【0186】
ＰｒｏＳｅ ＢＳＲ ＭＡＣ ＣＥのために使用される実際のフォーマットに応じて、予約ビットがあることがあり、例えば「０」に設定される。
【0187】
図２４に対して取られる特定の例では、ＬＣＨ＃１がＰｒｏＳｅ宛先グループ１およびＰｒｏＳｅ ＬＣＧ１と関連づけられ、ＬＣＨ＃２がＰｒｏＳｅ宛先グループ１およびＰｒｏＳｅ ＬＣＧ２と関連づけられ、ＬＣＨ＃３がＰｒｏＳｅ宛先グループ２およびＰｒｏＳｅ ＬＣＧ２と関連づけられることを前提とする。結果的に、３つのペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧ、すなわちＰｒｏＳｅ宛先グループ１とＰｒｏＳｅ ＬＣＧ１および２、ならびに、ＰｒｏＳｅ宛先グループ２とＰｒｏＳｅ ＬＣＧ２がある。
【0188】
上記した改善されたＰｒｏＳｅ ＢＳＲの利点は、ｅＮＢが今や同じＰｒｏＳｅ宛先グループに帰属する異なるＰｒｏＳｅ ＬＣＧ間で区別することができ、このためｅＮＢがより効率的なスケジューリングを提供するのを許容するということである。
【0189】
ＰｒｏＳｅ ＢＳＲの実際の内容に関する上記した変更によって、例えば背景で（非特許文献２の５．ｘ．１．４項に対するＲ２－１４５４３５（ＣＲ０７４４）を参照しつつ）説明した先行技術でのように、改善されたＰｒｏＳｅバッファ状況報告が追加的に規定されることができる。専らいくつかの例として：ＲＲＣは、２つのタイマＰｅｒｉｏｄｉｃ－ＰｒｏｓｅＢＳＲ－ＴｉｍｅｒおよびＲｅｔｘＰｒｏｓｅＢＳＲ－Ｔｉｍｅｒを設定することによってサイドリンクＢＳＲ報告を制御してもよく；異なるイベントがＰｒｏＳｅ ＢＳＲをトリガし；パディングＰｒｏＳｅ ＢＳＲ、規則的かつ定期的なＰｒｏＳｅ ＢＳＲなどの異なる種類のＰｒｏＳｅ ＢＳＲが存在する。
【0190】
（第３の例証的な実施形態）
第３の実施形態は、ＬＣＰ手順を行うときにＵＥのリソース割当て手順をさらに改善する。特に、第３の実施形態はＵＥ自律スケジューリングモード２に重点を置き、ここでＵＥは、新たな送信のために必要とされるときにリソースプールから無線リソースを選択する。
第３の実施形態は、ＬＣＰ手順を行うときにＵＥのリソース割当て手順をさらに改善する。特に、第３の実施形態はＵＥ自律スケジューリングモード２に重点を置き、ここでＵＥは、新たな送信のために必要とされるときにリソースプールから無線リソースを選択する。
【0191】
第３の実施形態は第１および第２の実施形態の変形のいずれかと組み合わせることができるが、しかしスタンドアロンとして実装することもできる。
【0192】
背景で説明したように、ＵＥは、それぞれＳＡメッセージおよびＤ２Ｄデータの送信のための複数のリソースプールが設けられる。したがって、以下では、ＵＥに対して、自律リソース割当てモードでのＤ２Ｄ通信のための複数のリソースプール、すなわち、より詳しくはスケジューリング割当て（ＳＡ：Scheduling Assignment）の送信のための複数のリソースプールおよび対応するＤ２Ｄデータ送信のための複数のリソースプールが規定されることを前提とする。このことは、例えばｅＮＢによって、および／または、上記の点で役割を担うネットワークにおけるＰｒｏＳｅ機能／エンティティによって、行われる。ＳＡおよびデータのためのこれらの複数のリソースプールは、例えば、ＳＩＢ１８を介してＵＥに提供される、すなわち、対応するセルのシステム情報でブロードキャストされる。
【0193】
対応して、ＵＥ自律リソース割当て（モード２）を行わなければならないときに、すなわち新たなＤ２Ｄ ＭＡＣ ＰＤＵを生成するときに、異なるリソースプールがＵＥに利用可能である。さらには、第３の実施形態に関して、第１および第２の実施形態のすべての変形に関してのように、複数のＰｒｏＳｅ宛先グループが規定されることを前提とする。第３の実施形態のいくつかの変形に関して、ＰｒｏＳｅ宛先グループの各々が特定のＰｒｏＳｅ宛先グループ優先度と関連づけられることを前提としてもよく、さらなる詳細は第１および第２の実施形態に既に提供されており、したがってここでは省略される。
【0194】
モード２であるときのＵＥによるリソース割当てをさらに向上させるために、ＵＥが（例えばＰｒｏＳｅ宛先グループの中で最高優先度を持つ）送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択した後に、様々なリソースプールの中の適切なリソースプール（より詳しくはスケジューリング割当ての送信のためのリソースプールおよび対応するデータのためのリソースプール）が、選択したＰｒｏＳｅ宛先グループに基づいてＵＥによって選択される。換言すれば、ＵＥは、選択したＰｒｏＳｅ宛先グループに適切である（ＳＡおよびデータのための）無線リソースプールを選択する。無線リソースプールのこの選択は、異なる方途で実装することができ、そのうちの２つを以下に提示することになる。
【0195】
第１の変形によれば、ＰｒｏＳｅ宛先グループとリソースプールとの間の新たなマッピングが導入され、そのため各ＰｒｏＳｅ宛先グループは、ＳＡのためのリソースプールおよびＤ２Ｄデータのためのリソースプールを割り当てられる。このマッピングは、例えば上記の点で役割を担う、ネットワークにおけるＰｒｏＳｅ機能／エンティティによって規定される。上記の場合、マッピングに関する情報は、例えばなんらかの上位レイヤプロトコルを用いてＵＥ（およびｅＮＢ）に送信される。代替的に、このマッピングは、ＵＥ（およびｅＮＢ）に予め設定されることができ（例えば規格によって、またはＵＩＣＣに記憶されて）、そのため対応するマッピングはネットワークを通じてシグナリングされる必要はなく、ＵＥ（およびｅＮＢ）で既に利用可能である。
【0196】
いずれにせよ、選択したＰｒｏＳｅ宛先グループに基づいて、ＵＥは、記憶したマッピング情報に基づいて、選択したＰｒｏＳｅ宛先グループに関連づけられている１つのリソースプールまたは複数のリソースプール（１つはＳＡのためおよび１つは対応するＤ２Ｄデータのため）を単に選択してもよい。サイドリンク制御（ＳＣ：Sidelink Control）期間とも称される１つのＳＡ／データ期間内で、Ｄ２Ｄ ＵＥは、１つのＰｒｏＳｅ宛先グループにＤ２Ｄ ＭＡＣ ＰＤＵを送信することができるのみであるので、リソースプールの選択は、ＳＡ／データ期間ごとに一度行う必要があるのみである。
【0197】
第２の変形によれば、明示的なマッピングを提供する代わりに、ＵＥは、選択したＰｒｏＳｅ宛先グループのための適切な無線リソースプールを異なって決定するものとする。特に、複数のリソースプールの各々には、例えば、リソースプール優先度と名付けられる特定の優先度が割り当てられる。
【0198】
複数のリソースプールに対して利用可能な実際の優先度レベルがどのように実装されるかに関するいくつかの可能性もある。第２の変形は、ＰｒｏＳｅ宛先グループおよびリソースプールの優先度を比較して、選択したＰｒｏＳｅ宛先グループに基づいてリソースプールを適切に選択するものとすることを見込む。結果的に、２つの優先度は、それらが有意味な方式で比較可能であるように規定されるものとする。ＰｒｏＳｅ宛先グループの優先度について先に挙げた例は、優先度レベル１が最高であり、優先度レベル８が最低であるとして、８つの異なる優先度レベルを前提とした。対応して、リソースプールの優先度は同様にして規定し、割り当てることができ、そのため重要なデータのためにのみ使用されるべきであるリソースプールには、高優先度（例えば１）が割り当てられ、より重要でないデータのために既に使用されることができるリソースプールには低優先度（例えば８）が割り当てられる。
【0199】
これらのリソースプール優先度および優先度を割り当てることは、例えば既に複数のリソースプールを設定する役割を担った、ネットワークにおける同じＰｒｏＳｅ機能／エンティティによって行われることができる。上記の場合、特定の無線リソースプールの優先度レベルの情報は、特定の無線リソースプール自体に関する情報と共に、例えばＳＩＢ１８でシグナリングされるプール設定でシグナリングすることができる。
【0200】
代替的に、優先度は、第３の実施形態の第１の変形に関するマッピングと同じ方式で、ＵＥ（およびｅＮＢ）に予め設定される（例えば規格によって、またはＵＩＣＣに記憶されて）。
【0201】
いずれにせよ、第２の変形によれば、ＵＥには複数のリソースプール（それぞれＳＡおよびＤ２Ｄデータのため）が設定され、その各々には特定の優先度レベルが割り当てた。上述したように、リソースプールの優先度は、リソースプールに関連づけられる優先度と同じ（またはより高い）グループ優先度を持つＰｒｏＳｅ宛先グループに帰属するサイドリンク論理チャネルのデータのみが上記リソースプールからの無線リソースで送信されることができるように規定される。
【0202】
対応して、ＵＥがＰｒｏＳｅ宛先グループを（ＰｒｏＳｅ宛先グループ優先度に基づいて）選択した後に、ＵＥは様々なリソースプールの優先度と選択したＰｒｏＳｅ宛先グループの優先度を比較し、選択したＰｒｏＳｅ宛先グループのＰｒｏＳｅ宛先グループ優先度と同じであるか、または、より低いプール優先度を有するリソースプール（１つはＳＡのためおよび１つはＤ２Ｄデータのため）を選択する。
【0203】
対応して、ＵＥは、選択した無線リソースプールの無線リソースに基づいて、サイドリンクグラントを決定することができる。決定したサイドリンクグラントの無線リソースは、次いで、第１および第２の実施形態の様々な変形に関して論じたＬＣＰ手順に従って、様々なＰｒｏＳｅ論理チャネルに使用され、割り当てられる。
【0204】
リソースプール選択メカニズムを有することの利点は、スケジューリング割当ておよび対応するデータ送信のためのリソースプールを選択するためのＵＥ挙動が、ｅＮｏｄｅＢの観点から予測可能であるということである。このことは、ｅＮｏｄｅＢが異なるリソースプールへの負荷を制御するのを許容する。さらには、干渉状況は、異なるリソースプールについて異なるはずであり、そのため、ＰｒｏＳｅデータ送信は異なるサービス品質（ＱｏＳ：Quality of Service）となる。
【0205】
代替的に、異なるリソースプールを異なるサイクリックプレフィックス（ＣＰ：Cyclic Prefix）長に対して規定することができ、すなわちＤ２Ｄ送信のための複数のリソースプールの１つは拡張ＣＰ長を使用するものとする一方で、Ｄ２Ｄ送信のための他のリソースプールは通常ＣＰ長を使用するものとする。
【0206】
以下では、第３の実施形態が第２の実施形態の基本変形と組み合わされるときのステップのシーケンスを簡潔に説明する。したがって、ＵＥがスケジューリングモード２（ＵＥ自律）であることを前提とする。第１のステップでは、ＵＥは、ＰｒｏＳｅ宛先グループ優先度（例えばそれらの中で最高を有するもの）に基づいて、ＵＥがこのＴＴＩ、またはＳＡ／データ期間にＤ２Ｄデータを送信したいＰｒｏＳｅ宛先グループを決定するものとする。次いで、ＵＥは、選択したＰｒｏＳｅ宛先グループに基づいて（マッピング情報に基づいて、または、上記で説明した優先度比較に基づいて）、対応するリソースプールを決定する。選択した無線リソースプールに基づいて、ＵＥは、選択した無線リソースプールからサイドリンクグラントを選択し、グラントの上記無線リソースを、選択したＰｒｏＳｅ宛先グループのＰｒｏＳｅ論理チャネルに、ＰｒｏＳｅ論理チャネルと関連づけられるＰｒｏＳｅ ＬＣＧ優先度の降順に割り当てることになる。
【0207】
第３の実施形態は、しかしながら、ｅＮＢスケジュールリソース割当てモード（モード１）にも適用することでき、モード１でスケジュールされるときに複数のリソースプールがＵＥに対しても利用可能であることを前提とする。特に、将来のリリースで、モード２のみのために現在規定されている複数のリソースプールが、モード１スケジューリングのためにも使用可能になるかもしれず、そのため、ＵＥは、ｅＮＢから受信するｅＮＢスケジュールグラントが実際にどのリソースプールを指すかを示される必要がある。
【0208】
結果的に、第３の実施形態のこの変形によれば、ＵＥがｅＮＢからサイドリンクグラントを受信するときに、第１および第２の実施形態に関連して以上説明したように、ＵＥは改善されたＬＣＰ手順を行う。しかしながら、ｅＮＢグラントを適用するために、ＵＥは、選択したＰｒｏＳｅ宛先グループに基づいて（改善されたモード１リソースプール選択に関連して第３の実施形態に関して既に論じた様々な変形のいずれかに従って）、そのリソースプールを選択することになる。
【0209】
（さらなる例証的な実施形態）
以下では、上記で説明した第１、第２および第３の実施形態の変形のいずれかと組み合わせることができるが、スタンドアロン、すなわち、第１、第２および第３の実施形態のいずれかと独立して考えられてもよい、異なる実施形態を説明することになる。
以下では、上記で説明した第１、第２および第３の実施形態の変形のいずれかと組み合わせることができるが、スタンドアロン、すなわち、第１、第２および第３の実施形態のいずれかと独立して考えられてもよい、異なる実施形態を説明することになる。
【0210】
１つの追加の実施形態に関して、ＵＥが１つのリソース割当てモードのみで設定される現在標準化された実装とは対照的に、同時に両リソース割当てモード（すなわちモード１およびモード２）を使用、すなわち設定することが可能であることを前提とする。上記の場合、リソース割当てモードは、例えば、論理チャネル固有にすることができ、そのためそのいくつかの論理チャネルは、スケジュールリソース割当てモードに設定される一方で、他の論理チャネルは、自律リソース割当てモードに設定される。ＵＥは上記の点で、例えばｅＮＢによってＲＲＣシグナリングを介して設定されてもよい。
【0211】
代替的に、ＰｒｏＳｅ論理チャネルのリソース割当てモードは、例えば、既にＰｒｏＳｅ宛先グループまたはＰｒｏＳｅ ＬＣＧの異なる優先度を割り当てる役割を担った、ネットワークにおける同じＰｒｏＳｅ機能／エンティティによって設定され、上位レイヤプロトコルによって、ＵＥまたはｅＮｏｄｅＢにシグナリングされる。
【0212】
代替的に、ＰｒｏＳｅ論理チャネルに関連づけられるリソース割当てモードは、第１の変形に関するマッピングと同じ方式で、（例えば、規格によって、または、ＵＩＣＣに記憶されて）ＵＥ（およびｅＮＢ）に予め設定される。
【0213】
結果として、ＵＥで行われるＬＣＰ手順は、次いで、サイドリンクグラントがｅＮＢから受信される場合には、例えばｅＮＢスケジュールリソース割当てモードに設定されている論理チャネルのみを考慮するであろうし、逆に、サイドリンクグラントがリソースプールからＵＥによって自律的に決定される場合には（ｅＮＢグラントなしでは）、ＵＥは、次いで、ＵＥ自律リソース割当てモードに設定されている論理チャネルのみを考慮するであろう。したがって、ＬＣＰ手順の第１のステップで、現在処理するサイドリンクグラントと同じリソース割当てモードに関連しない論理チャネルは、ＬＣＰ手順に関しては無視されるであろう。したがって、例えば、その論理チャネルには無線リソースは割り当てられないであろう。そして、第１の実施形態を考えると、ＰｒｏＳｅ宛先グループを選択するステップは、これらの無視した論理チャネルがＰｒｏＳｅ宛先グループの一部でないように行われるであろう。同様に、第２の実施形態を考えると、リソースが割り当てられる論理チャネルの順序を決定するときに、これらの無視した論理チャネルおよびそれらの関連するＰｒｏＳｅ ＬＣＧ優先度は却下されるであろう。
【0214】
さらには、ＵＥは、対応するＰｒｏＳｅ ＢＳＲでｅＮＢスケジュールリソース割当てモードに設定されるそれらの論理チャネルのデータのみを報告するであろう。
【0215】
代替的に、リソース割当てモードは、ＰｒｏＳｅ宛先グループまたはＰｒｏＳｅ論理チャネルグループに固有にすることができる。
【0216】
別の追加の実施形態に関して、Ｄ２Ｄに対して半永続スケジューリングがサポートされ、したがって、上記ＳＰＳグラントの無線リソースが、ＬＣＰ手順に従ってＰｒｏＳｅ論理チャネルに割り当てられることを前提とする。この追加の実施形態によれば、利用可能なデータを持つＰｒｏＳｅ宛先グループの中で最高優先度を持つＰｒｏＳｅ宛先グループのデータが送信されるものとし、すなわちＳＰＳリソースを使用して送信されるべき新たなＭＡＣ ＰＤＵを生成するとき、最高優先度のＰｒｏＳｅ宛先グループがＬＣＰ手順をさらに続行するために選択される。結果的に、ＳＰＳリソースは、選択したＰｒｏＳｅ宛先グループと関連づけられているＰｒｏＳｅ論理チャネルのみに割り当てられる。
【0217】
代替的に、特定のＰｒｏＳｅ宛先グループをＳＰＳに対して（予め）設定することができ、またはできず、そのためＵＥは、ＳＰＳリソースを割り当てるときに、ＳＰＳに対して設定されているＰｒｏＳｅ宛先グループのみから選択してもよい。
設定は、例えば上位レイヤシグナリングによって、例えば対応するＰｒｏＳｅ宛先グループがＳＰＳに向けられていることを示すフラグを使用することによって行われる。代替的に、ＰｒｏＳｅ宛先グループのこのＳＰＳ設定は、ＵＥに予め設定される。
設定は、例えば上位レイヤシグナリングによって、例えば対応するＰｒｏＳｅ宛先グループがＳＰＳに向けられていることを示すフラグを使用することによって行われる。代替的に、ＰｒｏＳｅ宛先グループのこのＳＰＳ設定は、ＵＥに予め設定される。
【0218】
第１の態様のＬＣＰ手順によって達成される利点の１つは、高優先度のＰｒｏＳｅ宛先グループのためのＰｒｏＳｅデータが最初に送信され、先行技術システムのように不必要に遅延しないということである。異なる優先度レベルを、所望の効果を達成するように、中央ＰｒｏＳｅ機能／エンティティによって異なるＰｒｏＳｅ宛先グループに適切に割り当てられる。
【0219】
要約すると、第１の態様に関連して論じたＰｒｏＳｅ宛先グループ優先度に基づく第１の優先順位付けレベルに加えて、第２の優先順位付けレベルがＬＣＰ手順に対して実装される。より詳細には、先行技術のようにＰｒｏＳｅ通信に関連して１つの論理チャネルグループ（ＬＣＧ）のみを提供する代わりに、第２の態様は複数のＰｒｏＳｅ ＬＣＧに基づき、それらの各々は、例えばＰｒｏＳｅ ＬＣＧ優先度と名付けられる複数の異なる優先度の１つと関連づけられる。１つの変形によれば、ＰｒｏＳｅ ＬＣＧおよび対応するＰｒｏＳｅ ＬＣＧ優先度も、上記の点で役割を担うネットワークにおけるＰｒｏＳｅ機能／エンティティによって設定および管理される。上記の場合、利用可能なＰｒｏＳｅ ＬＣＧに関する情報およびそれらの対応する優先度レベルは、ｅＮＢが上記ユーザ機器のための無線リソースのｅＮＢによるスケジューリングを向上させるのをさらに許容するように、ＵＥおよび（例えば）ｅＮＢに送信される。ＵＥは、次いで、複数のＰｒｏＳｅ ＬＣＧから１つに、ＵＥの複数の設定したＰｒｏＳｅ論理チャネル（例えばＳＴＣＨ）の各々をマッピングするものとする。
【0220】
ＰｒｏＳｅデータが送信されるべきであるとき、かつ、サイドリンクグラントは利用可能であれば（ｅＮＢによってシグナリングされたかまたはリソースプールからＵＥによって自律的に決定されたかいずれか）、第１の態様の改善されたＬＣＰ手順の拡張である、第２の態様の改善されたＬＣＰ手順は、ＰｒｏＳｅ ＬＣＧ優先度に基づく第２の優先順位付けレベルを導入する。したがって、第１の態様に係る第１の優先順位付けで、ＵＥは最高優先度を有するＰｒｏＳｅ宛先グループを選択し、そのため生成されるＰＤＵは上記選択したＰｒｏＳｅ宛先グループのＵＥに送信されるべきＰｒｏＳｅデータのみを含むことになる。次いで、第２の優先順位付けで、上記選択したＰｒｏＳｅ宛先グループのＰｒｏＳｅ論理チャネルがマッピングされるＰｒｏＳｅ ＬＣＧに関連づけられるＰｒｏＳｅ ＬＣＧ優先度を考慮することによって、利用可能なリソースはＰｒｏＳｅ論理チャネルに割り当てられ、すなわちＰｒｏＳｅ論理チャネルはそれらの対応するＰｒｏＳｅ ＬＣＧ優先度の降順に扱われる。ＰＤＵはしたがって、ＰｒｏＳｅ論理チャネルと関連づけられるＰｒｏＳｅ ＬＣＧ優先度の降順に、１つの選択したＰｒｏＳｅ宛先グループの、かつＰｒｏＳｅ論理チャネルからのＰｒｏＳｅデータで順次構築される。このように生成したＰＤＵは次いでさらに処理および送信される。
【0221】
第２の態様のＬＣＰ手順によって達成される利点の１つは、第１の態様の利点に加えて、遅延にクリティカルなサービス（ボイスオーバーＩＰなど）と関連づけられるＰｒｏＳｅデータが、上記遅延にクリティカルなデータを搬送する対応ＰｒｏＳｅ論理チャネルが（マッピングされたＰｒｏＳｅ ＬＣＧを介して関連づけられる）それらの関連する優先度に従って扱われるので、不必要に遅延しないということである。
【0222】
第２の態様の変形は、ＰｒｏＳｅ ＬＣＧへのＰｒｏＳｅ論理チャネルのマッピングがどのように行われるかについて異なっている。例えば、１つの変形で、いかなるＰｒｏＳｅ宛先グループにも関わりなく、複数のＰｒｏＳｅ ＬＣＧが規定され、ユーザ機器に設定されるＰｒｏＳｅ論理チャネルの各々が複数のＰｒｏＳｅ ＬＣＧからの１つに、すなわちＰｒｏＳｅ論理チャネルとＰｒｏＳｅ宛先グループとの間の関連に関わりなくマッピングされる。例えば、合計で４つの異なるＬＣＧをＰｒｏＳｅ用に予め規定することができ、ＵＥは、ＰｒｏＳｅ論理チャネルを設定するときにまたはその後に、ＰｒｏＳｅ論理チャネルの各々を４つのＰｒｏＳｅ ＬＣＧのうちの１つにマッピングする。この変形では、４つのＰｒｏＳｅ ＬＣＧは、対応するＬＣＧ－ＩＤによって明白に識別することができる。代替の変形では、各ＰｒｏＳｅ宛先グループに対して、異なる一組の異なるＰｒｏＳｅ ＬＣＧが規定され、例えば１つのＰｒｏＳｅ宛先グループに対する複数のＰｒｏＳｅ ＬＣＧは、任意の他のＰｒｏＳｅ宛先グループからのＰｒｏＳｅ ＬＣＧと異なっている。例えば、ＰｒｏＳｅ宛先グループごとに４つの異なるＬＣＧおよび８つの異なるＰｒｏＳｅ宛先グループを前提とすると、実際上８×４＝３２個の異なるＰｒｏＳｅ ＬＣＧがあることになり、例えばＰｒｏＳｅ宛先グループＩＤおよびＰｒｏＳｅ ＬＣＧ－ＩＤの組合せによって識別可能である。次いで、ＰｒｏＳｅ宛先グループの各々に関して、上記ＰｒｏＳｅ宛先グループと関連づけられるＰｒｏＳｅ論理チャネルの各々が、ＰｒｏＳｅ宛先グループのＰｒｏＳｅ ＬＣＧの１つにマッピングされる。後者の変形に関して、優先順位付けは、より正確に規定され、実装されることができる。
【0223】
第２の態様のさらなる変形によれば、ＰｒｏＳｅのためのバッファ状況報告手順は、より多くのバッファサイズ情報を含むように、改善されたＬＣＰ手順に適合され、したがってｅＮＢが、上記ＰｒｏＳｅ ＢＳＲを受信して、より効率的にＰｒｏＳｅリソースをスケジュールするのを許容する。特に、ＰｒｏＳｅバッファ状況報告は、（例えばＵＥで能動的に使用される、および／または例えば、ＰｒｏＳｅデータが利用可能である）ＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧの各ペアに対して、ペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧと関連づけられているＰｒｏＳｅ論理チャネルのための利用可能なＰｒｏＳｅデータのバッファサイズ情報を含むように生成される。ＵＥは次いで、移動通信システムにおけるユーザ機器のための無線リソースを制御する無線基地局に、生成したＰｒｏＳｅバッファ状況報告を送信する。
【0224】
本発明の第３の態様によれば、ＰｒｏＳｅ宛先グループは、ＵＥ自律リソーススケジューリングモード（モード２）のための適切なリソースプールを選択するために追加的に使用される。特に、複数の無線リソースプールが、例えばｅＮｏｄｅＢおよび／またはネットワークにおける役割を担うＰｒｏＳｅ機能／エンティティによってユーザ機器に対して設定される。第１の態様に関して既に説明したように、ＰｒｏＳｅ宛先グループは利用可能な無線リソースに関して優先度の降順に扱われる。
【0225】
次いで、ＰｒｏＳｅ宛先グループを選択するこのステップの後に、ＵＥは、選択したＰｒｏＳｅ宛先グループに基づいて上記リソースプールの１つを選択する。このことは異なる方途で行うことができる。
【0226】
１つの変形で、各ＰｒｏＳｅ宛先グループと上記リソースプールの１つとの間の関連があり、リソースプールはネットワークにおける役割を担うＰｒｏＳｅ機能／エンティティによって中央で決定することができ、次いでＵＥに送信されるか、またはＵＥに予め設定される。対応して、ＵＥは次いで、選択したＰｒｏＳｅ宛先グループに割り当てられている無線リソースプールを選択することができる。
【0227】
代替の変形では、無線リソースプールの各々は、（例えば前述したＰｒｏＳｅ機能／エンティティによって）特定の優先度を割り当てられ、ＵＥはまた、例えば無線基地局によるそのセルでのシステム情報ブロードキャストによって、各無線リソースプールの優先度について通知される。ＰｒｏＳｅ宛先グループが第１のステップに従って選択された後、上記選択したＰｒｏＳｅ宛先グループの優先度は、１つの特定の無線リソースプールを選択するように利用可能な無線リソースプールの優先度とＵＥによって比較される。例えば、適切な無線リソースプールは、選択したＰｒｏＳｅ宛先グループの優先度と同じ（またはより低い）優先度を有し、そのためリソースプールに関連づけられる優先度と同じ（またはより高い）のグループ優先度を持つＰｒｏＳｅ宛先グループに帰属するＰｒｏＳｅ論理チャネルのＰｒｏＳｅデータのみが、上記対応するリソースプールのリソースで送信される。
【0228】
対応して、１つの一般的な態様では、ここで開示する技術は、移動通信システムのユーザ機器で論理チャネル優先順位付け（ＬＣＰ）手順を行うときに論理チャネルに無線リソースを割り当てるための方法を特徴とする。近接サービス（ＰｒｏＳｅ）のための複数の論理チャネルがユーザ機器に設定され、ＰｒｏＳｅデータの可能な宛先としての複数のＰｒｏＳｅ宛先グループの１つと関連づけられる。さらには、複数のＰｒｏＳｅ宛先グループの各々はＰｒｏＳｅ宛先グループ優先度と関連づけられ、複数のＰｒｏＳｅ論理チャネルの各々は複数のＰｒｏＳｅ論理チャネルグループ（ＬＣＧ）からの１つにマッピングされる。また、複数のＰｒｏＳｅ ＬＣＧの各々はＰｒｏＳｅ ＬＣＧ優先度と関連づけられる。ユーザ機器は、送信のための第１のプロトコルデータユニット（ＰＤＵ）を生成するときに以下のステップを行う。ＵＥは、最高ＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択する。次いで、ＵＥは、選択したＰｒｏＳｅ宛先グループと関連づけられている、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに、それらのＰｒｏＳｅ論理チャネルがマッピングされるＰｒｏＳｅ ＬＣＧと関連づけられるＰｒｏＳｅ ＬＣＧ優先度の降順に無線リソースを割り当てる。
【0229】
上記に加えてまたは代替的に使用することができる有利な変形によれば、ＰｒｏＳｅ ＬＣＧ優先度は、ユーザ機器に予め設定されるか、または移動通信システムのＰｒｏＳｅエンティティにおけるＰｒｏＳｅ機能によって決定され、ユーザ機器に通信されるかいずれかである。後者の場合、決定したＰｒｏＳｅ ＬＣＧ優先度は、移動通信システムにおけるユーザ機器のための無線リソースを制御する無線基地局にも任意選択で通信される。
【0230】
上記に加えてまたは代替的に使用することができる有利な変形によれば、ＰｒｏＳｅ宛先グループ優先度は、ユーザ機器に予め設定されるか、または移動通信システムのＰｒｏＳｅエンティティにおけるＰｒｏＳｅ機能で決定され、ユーザ機器に通信されるかいずれかである。後者の場合、決定したＰｒｏＳｅ宛先グループ優先度は、移動通信システムにおけるユーザ機器のための無線リソースを制御する無線基地局にも任意選択で送られる。
【0231】
上記に加えてまたは代替的に使用することができる有利な変形によれば、ＰｒｏＳｅ ＬＣＧへのＰｒｏＳｅ論理チャネルのマッピングは、一組の異なるＰｒｏＳｅ ＬＣＧを規定することによって行われ、ここではユーザ機器に設定されるＰｒｏＳｅ論理チャネルの各々は一組の複数の異なるＰｒｏＳｅ ＬＣＧからの１つにマッピングされ、例えば、異なるＰｒｏＳｅ ＬＣＧはＰｒｏＳｅ ＬＣＧ ＩＤによって識別される。代替的に、各ＰｒｏＳｅ宛先グループに対して、異なる一組の異なるＰｒｏＳｅ ＬＣＧが規定され、複数のＰｒｏＳｅ宛先グループからの１つと関連づけられるＰｒｏＳｅ論理チャネルの各々は複数のＰｒｏＳｅ宛先グループの上記１つに対して規定されたその組の異なるＰｒｏＳｅ ＬＣＧの１つにマッピングされ；例えば、異なるＰｒｏＳｅ ＬＣＧはＰｒｏＳｅ宛先グループのためのＩＤおよびＰｒｏＳｅ ＬＣＧのためのＩＤの組合せによって識別される。
【0232】
上記に加えてまたは代替的に使用することができる有利な変形によれば、ＰｒｏＳｅバッファ状況報告は、ＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧの各ペアに対して、ペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧと関連づけられているＰｒｏＳｅ論理チャネルのための利用可能なＰｒｏＳｅデータのバッファサイズ情報を含んで、ユーザ機器によって生成される。次いで、生成したＰｒｏＳｅバッファ状況報告は、移動通信システムにおけるユーザ機器のための無線リソースを制御する無線基地局に送信される。１つの例では、ＰｒｏＳｅバッファ状況報告は、各ペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧに対して、ペアのＰｒｏＳｅ宛先グループのＰｒｏＳｅ宛先グループ識別情報、ペアのＰｒｏＳｅ ＬＣＧのＰｒｏＳｅ ＬＣＧ識別情報、ならびにペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧと関連づけられているＰｒｏＳｅ論理チャネルのための利用可能なＰｒｏＳｅデータのバッファサイズ情報、のいずれかの情報を含む。
【0233】
上記に加えてまたは代替的に使用することができる有利な変形によれば、最高優先度を持つＰｒｏＳｅ宛先グループのためのＰｒｏＳｅデータが、第１のＰＤＵを生成した後になお送信のために利用可能であり、ＰｒｏＳｅデータが少なくとも別のＰｒｏＳｅ宛先グループに送信されるために利用可能であるシナリオを前提とする。上記の場合、送信のための第２のＰＤＵを生成するときに、ユーザ機器は、最高ＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択するか、または、２番目に高いＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択するかいずれかである。
【0234】
上記に加えてまたは代替的に使用することができる有利な変形によれば、二組の無線リソースがユーザ機器に利用可能であり、ここでは二組の無線リソースの第１は第１のＰＤＵのための無線リソースの割当てのために使用され、二組の無線リソースの第２は第２のＰＤＵのための無線リソースの割当てのために使用される。
【0235】
対応して、１つの一般的な態様では、ここで開示する技法は、移動通信システムのユーザ機器で論理チャネル優先順位付け（ＬＣＰ）手順を行うときに論理チャネルに無線リソースを割り当てるための方法を特徴とする。近接サービス（ＰｒｏＳｅ）のための複数の論理チャネルがユーザ機器に設定され、ＰｒｏＳｅデータの可能な宛先としての複数のＰｒｏＳｅ宛先グループからの１つと関連づけられる。さらには、複数の無線リソースプールがユーザ機器に対して設定され、複数のＰｒｏＳｅ宛先グループの各々はＰｒｏＳｅ宛先グループ優先度と関連づけられる。ユーザ機器は、送信のための第１のプロトコルデータユニット（ＰＤＵ）を生成するときに以下のステップを行う。ＵＥは、最高ＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択する。次いで、ＵＥは、選択したＰｒｏＳｅ宛先グループに基づいて無線リソースプールを選択する。次いで、ＵＥは、選択したＰｒｏＳｅ宛先グループと関連づけられている、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに、選択した無線リソースプールの無線リソースを割り当てる。
【0236】
上記に加えてまたは代替的に使用することができる有利な変形によれば、選択したＰｒｏＳｅ宛先グループに基づいて無線リソースプールを選択するステップは、ネットワークエンティティから受信されるかまたはユーザ機器に予め設定されて、複数のＰｒｏＳｅ宛先グループの各々に対して複数の無線リソースプールからの関連する無線リソースプールを示す関連情報に従ってユーザ機器によって行われることができる。または、無線リソースプールの各々が複数のプール優先度からの１つを割り当てられると、ユーザ機器は、選択したＰｒｏＳｅ宛先グループのＰｒｏＳｅ宛先グループ優先度と比較して適切なプール優先度を持つ無線リソースプールを選択する。１つの例では、ＵＥは、選択したＰｒｏＳｅ宛先グループのＰｒｏＳｅ宛先グループ優先度と同じであるかまたはより低いプール優先度を有する無線リソースプールを選択するものとする。１つのさらなる具体例では、ユーザ機器は、移動通信システムにおけるユーザ機器のための無線リソースを制御する無線基地局から送信されるブロードキャスト情報を介して各無線リソースプールのプール優先度について通知される。
【0237】
上記に加えてまたは代替的に使用することができる有利な変形によれば、複数のＰｒｏＳｅ論理チャネルの各々は複数のＰｒｏＳｅ論理チャネルグループ（ＬＣＧ）からの１つにマッピングされる。さらに、複数のＰｒｏＳｅ ＬＣＧの各々は、ＰｒｏＳｅ ＬＣＧ優先度と関連づけられ、選択したＰｒｏＳｅ宛先グループと関連づけられている、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに、それらのＰｒｏＳｅ論理チャネルがマッピングされるＰｒｏＳｅ ＬＣＧと関連づけられるＰｒｏＳｅ ＬＣＧ優先度の降順に、選択した無線リソースプールの無線リソースを割り当てる。対応して、１つの一般的な態様では、ここで開示する技法は、移動通信システムのユーザ機器で論理チャネル優先順位付け（ＬＣＰ）手順を行うときに論理チャネルに無線リソースを割り当てるためのユーザ端末を特徴とする。近接サービス（ＰｒｏＳｅ）のための複数の論理チャネルがユーザ機器に設定され、ＰｒｏＳｅデータの可能な宛先としての複数のＰｒｏＳｅ宛先グループからの１つと関連づけられる。複数のＰｒｏＳｅ宛先グループの各々はＰｒｏＳｅ宛先グループ優先度と関連づけられ、ここでは複数のＰｒｏＳｅ論理チャネルの各々は複数のＰｒｏＳｅ論理チャネルグループ（ＬＣＧ）からの１つにマッピングされ、ここでは複数のＰｒｏＳｅ ＬＣＧの各々はＰｒｏＳｅ ＬＣＧ優先度と関連づけられる。ＵＥのプロセッサは、送信のための第１のプロトコルデータユニット（ＰＤＵ）を生成するときに、最高ＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択する。プロセッサはさらには、選択したＰｒｏＳｅ宛先グループと関連づけられている、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに、それらのＰｒｏＳｅ論理チャネルがマッピングされるＰｒｏＳｅ ＬＣＧと関連づけられるＰｒｏＳｅ ＬＣＧ優先度の降順に無線リソースを割り当てる。
【0238】
上記に加えてまたは代替的に使用することができる有利な変形によれば、ＵＥの記憶媒体は、ユーザ機器に予め設定されているＰｒｏＳｅ ＬＣＧ優先度を記憶する。代替的にまたは加えて、ＵＥの受信器は、移動通信システムのＰｒｏＳｅエンティティにおけるＰｒｏＳｅ機能から、上記ＰｒｏＳｅ機能によって決定されるＰｒｏＳｅ ＬＣＧ優先度を受信する。また、ＵＥの記憶媒体は、ユーザ機器に予め設定されているＰｒｏＳｅ宛先グループ優先度を記憶し、および／または受信器は、移動通信システムのＰｒｏＳｅエンティティにおけるＰｒｏＳｅ機能から、上記ＰｒｏＳｅ機能によって決定されるＰｒｏＳｅ宛先グループ優先度を受信する。上記に加えてまたは代替的に使用することができる有利な変形によれば、プロセッサは、一組の異なるＰｒｏＳｅ ＬＣＧからの１つにユーザ機器に設定されるＰｒｏＳｅ論理チャネルの各々をマッピングする。代替的に、各ＰｒｏＳｅ宛先グループに対して、異なる一組の異なるＰｒｏＳｅ ＬＣＧが規定され、プロセッサは、上記１つのＰｒｏＳｅ宛先グループに対して規定されたその組の異なるＰｒｏＳｅ ＬＣＧの１つに複数のＰｒｏＳｅ宛先グループからの１つと関連づけられるＰｒｏＳｅ論理チャネルの各々をマッピングする。
【0239】
上記に加えてまたは代替的に使用することができる有利な変形によれば、プロセッサは、各対のＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧに対して、ペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧと関連づけられているＰｒｏＳｅ論理チャネルのための利用可能なＰｒｏＳｅデータのバッファサイズ情報を含むＰｒｏＳｅバッファ状況報告を生成する。ＵＥの送信器は次いで、ユーザ機器のための無線リソースを制御する無線基地局に生成したＰｒｏＳｅバッファ状況報告を送信する。１つの例では、ＰｒｏＳｅバッファ状況報告は、各ペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧに対して以下の情報を含む：ペアのＰｒｏＳｅ宛先グループのＰｒｏＳｅ宛先グループ識別情報、ペアのＰｒｏＳｅ ＬＣＧのＰｒｏＳｅ ＬＣＧ識別情報、ならびにペアのＰｒｏＳｅ宛先グループおよびＰｒｏＳｅ ＬＣＧと関連づけられているＰｒｏＳｅ論理チャネルのための利用可能なＰｒｏＳｅデータのバッファサイズ情報。
【0240】
上記に加えてまたは代替的に使用することができる有利な変形によれば、最高優先度を持つＰｒｏＳｅ宛先グループのためのＰｒｏＳｅデータが、第１のＰＤＵを生成した後になお送信のために利用可能であり、ＰｒｏＳｅデータが少なくとも別のＰｒｏＳｅ宛先グループに送信されるために利用可能であることを前提とする。次いで、プロセッサは、送信のための第２のＰＤＵを生成するときに、最高ＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループをなお選択する。代替的に、プロセッサは、送信のための第２のＰＤＵを生成するときに、２番目に高いＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択する。
【0241】
対応して、１つの一般的な態様では、ここで開示する技術は、移動通信システムのユーザ機器で論理チャネル優先順位付け（ＬＣＰ）手順を行うときに論理チャネルに無線リソースを割り当てるためのユーザ端末を特徴とする。近接サービス（ＰｒｏＳｅ）のための複数の論理チャネルがユーザ機器に設定され、ＰｒｏＳｅデータの可能な宛先としての複数のＰｒｏＳｅ宛先グループからの１つと関連づけられる。複数の無線リソースプールがユーザ機器に対して設定され、ここでは複数のＰｒｏＳｅ宛先グループの各々はＰｒｏＳｅ宛先グループ優先度と関連づけられる。ＵＥのプロセッサは、送信のための第１のプロトコルデータユニット（ＰＤＵ）を生成するときに、最高ＰｒｏＳｅ宛先グループ優先度を持つ、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ宛先グループを選択する。プロセッサは次いで、選択したＰｒｏＳｅ宛先グループに基づいて無線リソースプールをさらに選択する。最後に、プロセッサは、選択したＰｒｏＳｅ宛先グループと関連づけられている、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに、選択した無線リソースプールの無線リソースを割り当てる。上記に加えてまたは代替的に使用することができる有利な変形によれば、プロセッサは、ネットワークエンティティから受信されるかまたはユーザ機器に予め設定されている、複数のＰｒｏＳｅ宛先グループの各々に対して関連する無線リソースプールを示す関連情報に従って無線リソースプールを選択する。代替的に、プロセッサは、選択したＰｒｏＳｅ宛先グループのＰｒｏＳｅ宛先グループ優先度と比較して適切なプール優先度を持つ無線リソースプールを選択し、ここでは無線リソースプールの各々は複数のプール優先度からの１つを割り当てられる。例えば、プロセッサは、選択したＰｒｏＳｅ宛先グループのＰｒｏＳｅ宛先グループ優先度と同じであるかまたはより低いプール優先度を有する無線リソースプールを選択する。
【0242】
上記に加えてまたは代替的に使用することができる有利な変形によれば、複数のＰｒｏＳｅ論理チャネルの各々は複数のＰｒｏＳｅ論理チャネルグループ（ＬＣＧ）からの１つにマッピングされ、ここでは複数のＰｒｏＳｅ ＬＣＧの各々はＰｒｏＳｅ ＬＣＧ優先度と関連づけられる。次いで、プロセッサは、選択したＰｒｏＳｅ宛先グループと関連づけられている、送信のために利用可能なＰｒｏＳｅデータを持つＰｒｏＳｅ論理チャネルに、それらのＰｒｏＳｅ論理チャネルがマッピングされるＰｒｏＳｅ ＬＣＧと関連づけられるＰｒｏＳｅ ＬＣＧ優先度の降順に、選択した無線リソースプールの無線リソースを割り当てる。
【0243】
（ＭＣＰＴＴのために有利である第５の実施形態）
ＭＣＰＴＴサービスは、背景で例証したように、コール（call）の要素（例えば、サービス種類、要求側識別情報（requesting identity）および対象識別情報（target identity））と関連づけられる優先度に基づいてＭＣＰＴＴグループコールに優先順位を付けるメカニズムを提供するべきである。この要件は、グループコールの優先度が、通信対象に加えて、要求側識別情報（別名発信側ユーザ／ＵＥ）に依存することができることを暗示する。このことは、ＰｒｏＳｅレイヤ２グループＩＤそれ自体が優先度を示さないことを確認する。むしろ、優先度は、ＭＣＰＴＴのアプリケーションレイヤでいくつかの要因に基づいて算定される。
また、上記した実施形態がＬＣＰのために利用されてもよい一方で、第５の実施形態は、ＭＣＰＴＴサービスに特定の利益を提供する。特に、上述にて導入したグループ優先度方式は、ＭＣＰＴＴに関していくつかの制約および不変性を有することがある。例えば、グループＡの通信がグループＢの通信より典型的に高い優先度である２つのＰｒｏＳｅグループに参加するＵＥを考えるとする。上記したようにまずグループ優先度に従ってグループを選択する宛先グループ優先順位付け方式のため、すべての他のトラヒックよりもこの特定のグループＢのトラヒックを優先させることが望ましいであろうグループＢ内で緊急事態をサポートすることは可能でないであろう。
ＭＣＰＴＴサービスは、背景で例証したように、コール（call）の要素（例えば、サービス種類、要求側識別情報（requesting identity）および対象識別情報（target identity））と関連づけられる優先度に基づいてＭＣＰＴＴグループコールに優先順位を付けるメカニズムを提供するべきである。この要件は、グループコールの優先度が、通信対象に加えて、要求側識別情報（別名発信側ユーザ／ＵＥ）に依存することができることを暗示する。このことは、ＰｒｏＳｅレイヤ２グループＩＤそれ自体が優先度を示さないことを確認する。むしろ、優先度は、ＭＣＰＴＴのアプリケーションレイヤでいくつかの要因に基づいて算定される。
また、上記した実施形態がＬＣＰのために利用されてもよい一方で、第５の実施形態は、ＭＣＰＴＴサービスに特定の利益を提供する。特に、上述にて導入したグループ優先度方式は、ＭＣＰＴＴに関していくつかの制約および不変性を有することがある。例えば、グループＡの通信がグループＢの通信より典型的に高い優先度である２つのＰｒｏＳｅグループに参加するＵＥを考えるとする。上記したようにまずグループ優先度に従ってグループを選択する宛先グループ優先順位付け方式のため、すべての他のトラヒックよりもこの特定のグループＢのトラヒックを優先させることが望ましいであろうグループＢ内で緊急事態をサポートすることは可能でないであろう。
【0244】
以下の記載では、現在の３ＧＰＰによるＭＣＰＴＴサービス検討を基礎として例を記載する。しかしながら、このメカニズムは、異なるサービスおよび宛先の優先度が効率的なグループコール動作のために重要である任意の種類のＰｒｏＳｅシステムのために利用可能であることに留意されたい。
【0245】
各サイドリンク論理チャネルが優先度レベルを割り当てられることが、実施形態５によって提供される具体的な解決策である。ＵＥは、宛先グループ優先度を考慮することなくこの優先度レベルにのみ基づく論理チャネル優先順位付け（すなわち異なるＳＬＲＢで待機されるデータを扱う順序を決定する）を行う。
【0246】
実際、この第５の実施形態はまた、グループ優先度をサポートせずに、単に特定の論理チャネルに優先度レベルを割り当てるシステムに実装してもよい。
【0247】
特に、ＵＥは図２５に示すように以下のステップを行う。ＵＥは、（利用可能なデータを有する）最高優先度サイドリンク論理チャネルをステップ２５１０で選択する。最高優先度ＬＣはここで、ＵＥによって対応されるすべての宛先グループのすべてのＬＣの中で最高優先度を有するＬＣである。選択したサイドリンク論理チャネルはＰｒｏＳｅ宛先グループを決定する。したがって、ＵＥは、最高の優先度の論理チャネルが帰属する宛先グループをステップ２５２０で決定する。決定した宛先グループは次いでデータ送信のために選択され、選択した宛先グループのＵＥの論理チャネルに対してさらなる優先順位付けが行われる。したがって、ステップ２５３０で、ＵＥは、選択したＰｒｏＳｅ宛先グループに帰属するすべてのサイドリンク論理チャネルに対してさらなる優先順位付けを行う。次いでステップ２５４０で、決定したＰｒｏＳｅ宛先グループに帰属するすべてのサイドリンク論理チャネルが優先度降順に（宛先グループのそれぞれのサイドリンク論理チャネルに関連づけられる優先度に基づいて）扱われる。扱われることは、それぞれの論理チャネルからのデータが、現行の送信タイミング（上記したサイドリンク制御（ＳＣ）期間などの送信機会）に、割り当てられるリソース上にマッピングされることを意味する。
【0248】
本手順は、モード１（ｅＮＢ制御リソース割当てモード）において、または、モード２（自律リソース割当てモード）においてのいずれかで動作するＵＥによって利用されてもよい。本手順は、送信がｅＮＢより別のエンティティによって制御される他のシステムでも動作してもよい。これは、リソース割当て手順に関わらず、利用可能であるいくらかのリソースを既に前提とするからである。
【0249】
上記手順は、新たなトランスポートブロックが生成される必要がある送信機会ごとにＵＥによって有利に行われる。ＰｒｏＳｅの文脈では、ＵＥは、現行の特定されたＰｒｏＳｅ機能性（Ｒｅｌ－１２）に従って、ＳＣ期間内で１つのＰｒｏＳｅグループにデータを送信することができるのみである。その意味では、ＵＥは、ＳＣ期間ごとに一度サイドリンク論理チャネル優先度に基づいてＰｒｏＳｅ宛先グループを選択する必要があるのみである。
【0250】
なお、優先順位付けメカニズムのステップ、すなわち選択したＰｒｏＳｅ宛先グループに帰属するサイドリンク論理チャネルへの、それらの優先度に従う、無線リソースの割当ては、各新たなトランスポートブロックに対して行われるべきである。
【0251】
これは、各新たなトランスポートブロックの形成で、データを送信するのを許容されるＵＥが、最初に最も重要なデータを伝達するために割り当てられる容量を使用するという利点を提供する。各トランスポートブロック送信につれて、送信のために利用可能なデータは変化してもよく、したがってまた、優先度に従う宛先グループおよび論理チャネルの選択はトランスポートブロックごとに異なる結果を有してもよい。とりわけクリティカルデータについて、データ送信の高速可能性は重要である。
【0252】
しかしながら、本発明はこの例に限定されないことに留意されたい。いくつかのアプリケーションに関して、Ｋ（２より大きい整数）個のトランスポートブロックごとに宛先グループが選択されてスケジューリングが行われれば、許容される。残りのトランスポートブロックは最後の割当てを使用して形成される。（したがって最後の選択した宛先グループに送信し、選択したグループに対する論理チャネルに、それらの優先度に従ってリソースを割り当てる。）
【0253】
上記した手順は、ＵＥで規定され、利用可能な各サイドリンク論理チャネルに対して優先度があり、例えば一時的にまたは永久に記憶されることを単に前提とする。その上、各サイドリンク論理チャネルに対してそれがどの宛先グループに帰属するかを特定する、ＵＥで利用可能な情報もある。
【0254】
例えば、各サイドリンク論理チャネルと関連づけられる優先度は、ＵＥによってかまたはＰｒｏＳｅ機能によってかいずれかで決定され、ＵＥにおよび／またはｅＮＢにシグナリングされてもよい。
【0255】
ＰｒｏＳｅ機能が論理チャネル優先度を決定する場合には、ＰｒｏＳｅエンティティ（ＰｒｏＳｅ機能）とＵＥ（および場合によりｅＮＢ）との間にいくらかのシグナリングが導入される必要がある。
【0256】
例えば、シグナリングは上位レイヤ、すなわち物理レイヤおよびＭＡＣレイヤを越えたレイヤ上の制御シグナリングでもよい。特に、プロトコルメッセージは、各論理チャネルに対する論理チャネル優先度を含んでもよい。論理チャネル優先度は、ＵＥでサイドリンク論理チャネルを確立するときに、例えばＵＥ識別情報、ＬＣの宛先グループ識別情報、ＬＣが帰属する論理チャネルグループおよび／またはＬＣによって搬送される特定のサービスなどの少なくとも１つに従って、ＰｒｏＳｅエンティティによって設定されてもよい。サイドリンク論理チャネルに関連づけられる優先度は、例えばアプリケーションレイヤによってトリガされるときに変更または再設定される。
【0257】
概して、優先度レベルは、（アプリケーションレイヤパケットなど）サービスの各データパケットに関連づけることもできる。同じ優先度レベルのパケットは同じベアラ、すなわちサイドリンク論理チャネルにマッピングされる。例えば、ＰｒｏＳｅサービスが２つの異なる優先度レベルと関連づけられているデータパケットを生成すれば（例えば、ビデオコールでの声およびビデオは異なる優先度を有してもよい）、（ＰｒｏＳｅエンティティにおける）ＰｒｏＳｅ機能は、ＵＥを、パケットがそれらの優先度に従ってマッピングされるＰｒｏＳｅサービスのそれぞれの２つのデータフローのための２つのサイドリンク論理チャネルを確立するように設定してもよい。その意味では、上記したような優先順位付け手順は、サービスのデータパケットに関連づけられる優先度レベルに基づいて行うこともできる。
【0258】
モード１では、リソース割当てはｅＮＢによって制御され、ｅＮＢはＵＥと同じ設定情報が提供されてもよい。より詳しくは、ｅＮＢには、それぞれの確立したサイドリンク論理チャネルに関連づけられる優先度レベルが提供されてもよい。それぞれの確立したサイドリンクＬＣと関連づけられる優先度レベルは、ＰｒｏＳｅエンティティによって、または、ＵＥによって、ｅＮＢに提供されてもよい。
【0259】
代替的に、ｅＮＢには、論理チャネルグループへのサイドリンク論理チャネルのマッピング情報およびサイドリンク論理チャネル優先度と一致した論理チャネルグループの対応する優先度レベルが提供されることができる。優先度情報およびサイドリンクバッファ状況報告に基づいて、ｅＮＢは、異なるＵＥからの送信の優先度を考慮して効率的なスケジューリングを行うことができる。現行の規定されたサイドリンクバッファ状況報告ＭＡＣ制御要素によれば、ＵＥは、ＰｒｏＳｅ宛先グループ－論理チャネルグループ対ごとにバッファ状況を報告する。したがって、対応するＰｒｏＳｅ宛先グループに、すなわちこれらのＬＣＧペア上にマッピングされるサイドリンク論理チャネルの優先度に関する情報をｅＮＢに提供することが有益である。
【0260】
有利には、ＰｒｏＳｅエンティティからのシグナリング内で、ＵＥおよび／またはｅＮＢは、サイドリンク論理チャネル優先度が、およびＬＣＧおよび宛先グループへのサイドリンク論理チャネルのマッピングが設定される。
【0261】
ＵＥがサイドリンク論理チャネルに対する論理チャネル優先度を単独で決定する場合には、ＵＥおよび／またはｅＮＢがＰｒｏＳｅ宛先グループ優先度およびＬＣＧ優先度を設定されることを前提とする。これは、先行の実施形態に関して記載したようにＰｒｏＳｅエンティティにおけるＰｒｏＳｅ機能によって行われてもよい。
【0262】
ＵＥが論理チャネル優先度を単独で決定したか、またはＰｒｏＳｅエンティティから設定を受信するかにかかわらず、ｅＮＢはなお優先度を計算するか、またはＰｒｏＳｅエンティティから設定を受信するかいずれかを行ってもよいことに留意されたい。
【0263】
ＵＥ（または場合によりｅＮＢ）は次いで論理チャネル優先度をなんらかの所定の公式に基づいて計算する。例えば、サイドリンク論理チャネル優先度は、ＰｒｏＳｅグループ優先度（ＳＬＲＢｉ）とＬＣＧ優先度（ＳＬＲＢｉ）の積として計算されてもよい。概して：
サイドリンク論理チャネル優先度＝ｆ（ＳＬＲＢｉ，ＳＬＲＢｉ）
ここで、ｆは好ましくはＰｒｏＳｅグループ優先度（ＳＬＲＢｉ）およびＬＣＧ優先度（ＳＬＲＢｉ）に比例する任意関数である。論理チャネル優先度は、先行の実施形態に記載したように、宛先グループ優先度およびＬＣＧ優先度に基づいて計算されてもよい。
サイドリンク論理チャネル優先度＝ｆ（ＳＬＲＢｉ，ＳＬＲＢｉ）
ここで、ｆは好ましくはＰｒｏＳｅグループ優先度（ＳＬＲＢｉ）およびＬＣＧ優先度（ＳＬＲＢｉ）に比例する任意関数である。論理チャネル優先度は、先行の実施形態に記載したように、宛先グループ優先度およびＬＣＧ優先度に基づいて計算されてもよい。
【0264】
論理チャネル優先度の計算を図２６に示す。図２６における方法２６００のフロー図はＵＥおよびｅＮＢのいずれで実行されてもよい。この方法はモード１の他にモード２で使用してもよい。ステップ２６１０にて、ＵＥおよび／またはｅＮＢは、優先度を計算する論理チャネルの宛先グループを決定する。この決定は、宛先グループの優先度を含むＰｒｏＳｅエンティティからの制御情報を受信することに応答して行われてもよい。ステップ２６２０にて、ＵＥは、優先度を計算する論理チャネルに対するＬＣＧ優先度を決定する。これも、ＰｒｏＳｅエンティティからＬＣＧ優先度を受信した上で行われてもよい。ステップ２６３０にて、ＵＥの地理的な位置、ＵＥの緊急状況またはＩＤなどといった、論理チャネル優先度を決定するために使用しても良いさらなるパラメータが決定されてもよい。最後に、ステップ２６４０にて、これらのパラメータに基づく計算が行われる。上記方法２６００は、ＵＥに対して設定されるすべての論理チャネルに対してＵＥおよび／またはｅＮＢによって行われてもよい。
【0265】
ＰｒｏＳｅ ＢＳＲ報告（モード１）に関して、Ｒｅｌ－１２でのＰｒｏＳｅバッファ状況報告のＭＡＣに規定される制御要素を再使用してもよい。特に、１つのＰｒｏＳｅ宛先グループに帰属するサイドリンクＬＣが４つの異なるＬＣＧにマッピングされることができる場合、ＰｒｏＳｅ ＢＳＲは、本質的に、６４個の異なる宛先グループ－ＬＣＧペア（４ビット長の宛先グループＩＤおよび２ビット長のＬＣＧ ＩＤに対応）間で区別することができる。そのようなシグナリングは、ｅＮＢによって効率的なスケジューリングが行われるのに十分な粒度（granularity）を提供するべきである。
【0266】
モード２（自律リソース割当てモード）では、上記したようなリソースプール選択が使用されてもよい。（最高優先度を持つサイドリンク論理チャネルに基づいて選択された）選択したＰｒｏＳｅ宛先グループに基づいて、リソースプールが選択される。本質的に、自律リソース割当てモードのためのセルによって設定されるリソースプールは、ＵＥが関連するリソースプールから選択するために、任意の種類の優先度（例えばグループ優先度または論理チャネル優先度）と関連づけられるべきである。これは、異なる関連する優先度でＰｒｏＳｅ送信を行っているＵＥによって使用されるリソースを分割するのに十分な手段を提供するべきである。ｅＮＢは例えば、異なる優先度のリソースプールのために異なる物理パラメータを設定することができる。ＵＥ側から、ＵＥが自律リソース割当てモードでＰｒｏＳｅ送信を行いたいとき、ＵＥはまず関連する優先度に基づいて、例えば論理チャネル優先度に従ってＰｒｏＳｅ宛先グループを選択する必要がある。選択したＰｒｏＳｅ宛先グループに基づいて、ＵＥは、リソースプールの一覧からＴｘリソースプールを選択するものとする。より詳しくは、ＵＥは、（ＰｒｏＳｅ宛先グループが選択された基である）選択したＰｒｏＳｅ宛先グループの優先度または代替的に最高優先度論理チャネルの優先度と同じであるかまたはより低い関連する優先度を有するＴｘリソースプールを使用するものとする。
【0267】
言い換えると、ＵＥは、有利には、リソースプールからデータの送信のために割り当てられるべきリソースを選択するように、および、宛先グループ優先度またはデータが送信されるべき論理チャネルと関連づけられる論理チャネル優先度に従って複数のリソースプールの中のリソースプールを選択するように、さらに設定される。リソースプールが選択される基である論理チャネル優先度が宛先グループに対する論理チャネルの中で最高論理チャネル優先度であれば、有益である。
【0268】
代替的にまたは加えて、各リソースプールに関連づけられる優先度レベルがあり、それをＵＥは選択したＰｒｏＳｅ宛先グループ内の最高優先度論理チャネルと比較する。
【0269】
様々な緊急アプリケーションのために使用してもよいＰＴＴサービスのためのより状況応答な優先順位付けを提供するために、サイドリンク論理チャネルの優先度は現行の状況、例えば地理的位置、緊急事態、第１応答者などに基づいて変化することがある。
【0270】
論理チャネル優先度の変化は動的に行われてもよく、これはグループコールの間（ベアラが設定される間）、優先度が同じのままである必要がなく、変化してもよいことを意味する。
修正（modification）は、論理チャネルパラメータ、すなわち優先度の再設定によって行われてもよい。これは、背景に規定されたように非アクセス層下のプロトコルを含むアクセス層によって行われてもよい。
修正（modification）は、論理チャネルパラメータ、すなわち優先度の再設定によって行われてもよい。これは、背景に規定されたように非アクセス層下のプロトコルを含むアクセス層によって行われてもよい。
【0271】
代替的に、新たな論理チャネルが新たな修正した優先度で設定される一方で、旧優先度を持つ論理チャネルは、バッファが空になってその論理チャネルが削除されるまで維持される。とりわけ、新優先度が旧優先度より高い場合には、この新たな論理チャネルのパケットをより高い優先度で取り扱うために、この手法は有益だろう。任意選択で、現在の（旧）優先度を持つ論理チャネルを閉じてもよい（あるいは、削除してもよい）。優先度の修正は、アプリケーションレイヤ上のＰｒｏＳｅエンティティによってトリガされてもよい。
【0272】
その送信データがバッファに記憶されている論理チャネルに対する優先度をＵＥが再構成すれば、バッファ内のそのデータに対して旧優先度（その修正前の優先度）を有効に維持することが概して有益だろう。優先度の修正が優先度を下げる場合にも、これが該当する。バッファ内のデータは、論理チャネルがより高い優先度を有した間に生成されたので、旧優先度を維持することはこれらのデータがより速く伝達されることを保証する。
【0273】
バッファが送信のためのデータをなお含んでいるチャネルに対する論理チャネル優先度の修正に応じた代替の挙動は、新たなデータが最初に取り扱われることを確実にするためにバッファを直ちにフラッシュすることである。とりわけ論理チャネルの優先度がより高い優先度に修正される場合に、この挙動は有益だろう。
【0274】
したがって、現在の優先度が修正した優先度より高ければ、ＵＥは修正前にバッファしたデータをなお現在の優先度で送信する一方で、修正後にバッファしたデータを新優先度で取り扱ってもよい。他方では、現在の優先度が新優先度より低い場合、ＵＥは修正前に記憶したデータをバッファから削除しても、すなわちバッファをフラッシュしてもよい。
【0275】
バッファフラッシングは、フラッシュしたデータがなくなることを暗示してもよい。とりわけ（ＰＴＴ）コールまたはビデオコールとしての会話サービスに関して、アプリケーションレイヤなどの上位レイヤ上の再送信は有用でないだろう。しかしながら、本発明はそれに限定されず、上位レイヤで実装されるなんらかの再送信メカニズムがあってもよい。
【0276】
しかしながら、変化の種類（優先度を増減させる）に関わらず、バッファしたデータに対して旧優先度を維持する規則を修正に応じて適用してもよいことに留意されたい。本発明は概して優先度の修正に応じて特定の挙動に限定されず、バッファも常にフラッシュしてもよい。
【0277】
さらなる選択肢が一定のシナリオに対して有利だろう。例えば、優先度の修正に応じたＵＥ挙動は、修正の理由に依存してもよい。例えば、論理チャネル優先度が緊急レベルの変化により変化する一方で、変化が増加であれば、バッファをフラッシュする。そうでなければ、バッファはフラッシュされない。
【0278】
代替的に、バッファフラッシングは、一方がバッファをフラッシュすべきことを示し、他方がデータを維持すべきことを示す２つの値を取ることができるバッファフラッシュフラグを優先度の修正メッセージに含めることによって、ＰｒｏＳｅ機能によって制御されてもよい。
【0279】
なお代替的に、ＵＥ挙動は修正後の優先度値に依存してもよい。例えば、修正した優先度が所定の優先度レベルの閾値より高い場合だけ、バッファはフラッシュされる。したがって、最も重要なデータ（例えば最高優先度を持つデータのみ）は早急に送信されるものとする一方で、他の優先度のデータは公平に取り扱われるだろう。
【0280】
（第６の実施形態：論理チャネル停止）
本発明の別の実施形態によれば、フロア制御メカニズムが提供される。本実施形態は、先行の実施形態と独立して動作してもよいし、または先に記載した実施形態のいずれかと組み合わされてもよい。第６の実施形態は、モード１およびモード２両方と利用されてもよい。
本発明の別の実施形態によれば、フロア制御メカニズムが提供される。本実施形態は、先行の実施形態と独立して動作してもよいし、または先に記載した実施形態のいずれかと組み合わされてもよい。第６の実施形態は、モード１およびモード２両方と利用されてもよい。
【0281】
ＭＣＰＴＴサービスはいくつかの特殊性を有する。特に、一度に、単一の当事者（グループコールのメンバ）のみがデータ／トークを送信（ブロードキャスト）してもよい。したがって、どのメンバが送信するべきかを選択するためのメカニズムが、システム効率に相当な影響を有するだろう。プッシュツートークシステムの文脈では、用語「フロア制御」は、とりわけ同じ送信機会にデータを送信しようとするより多くのユーザがいる場合に、グループにおけるどの特定のユーザがトークするのを許容されるかを選択し、特定のユーザに通知するプロセスを示す。
【0282】
ｗｗｗ．３ｇｐｐ．ｏｒｇで入手可能な3GPP SA6 TR 23.779、v0.6.0、「Study on System Architecture Enhancements for Mission Critical PTT over LTE」に基づいて、本質的に特定のチャネルを求めてフロアを要求する１つのＵＥ、およびそのような要求を受信した上でそれら自体の送信をオフにする他のＵＥでのアプリケーションによって、アプリケーションレイヤシグナリングを使用してフロア制御をサポートする、いくつかの提案がなされている。
【0283】
現在の検討でユーザ機器がフロアを有さず、したがってその送信を停止するとき、論理チャネルはなおアクティブのままであり、異なるグループへのデータ送信の優先順位付けのために端末によっても使用されている。
【0284】
本実施形態において、一群のユーザ機器間の直接通信をサポートする無線プッシュツートーク通信システムにおいて動作可能なユーザ機器が提供される。ユーザ機器は、ユーザ機器が無線通信システムのユーザ機器の中でデータを送信するように選択されるかどうかを決定するように設定されるフロア制御部を備える。ユーザ機器が選択されない場合、ＰｒｏＳｅグループ（一群のユーザ機器、すなわち１つの特定のＵＥの観点からの宛先グループ）に属するユーザ機器のサイドリンク論理チャネルを停止する。他方では、データ発信ユーザ機器が選択された場合、先だって停止されたそのサイドリンク論理チャネルを再開する。
【0285】
有利には、停止した論理チャネルは、上記実施形態に記載したように、優先順位付けおよびリソース割当てのために考慮されない。
【0286】
一群のユーザ機器は、２つ以上のＵＥによって形成されてもよい。フロア制御部は、プロセッサ、場合により先行の実施形態に記載したような優先順位付け手順によって使用されてもよいものと同じプロセッサによって実装されてもよい。
データ機器が選択されたかどうかの判定は、フロア制御の実装に応じて、様々な異なる方途で行われてもよい。本実施形態は、フロア制御が起こるレイヤに関わらず、任意のそのようなフロア制御のために動作してもよい。
データ機器が選択されたかどうかの判定は、フロア制御の実装に応じて、様々な異なる方途で行われてもよい。本実施形態は、フロア制御が起こるレイヤに関わらず、任意のそのようなフロア制御のために動作してもよい。
【0287】
例えば、データを送信するための許容をグループコールメンバに提供している１つのエンティティがある。中央エンティティは、ユーザ機器、グループコールのメンバの１つでもよい。例えば、ＵＥはフロアの要求（フロア要求メッセージ）を送信し、中央エンティティは要求を許可する。フロアグラントメッセージはブロードキャストされてもよく、その結果残りのステーションはそれを受信し、それらのステーションが選択されない、すなわち送信するのを許容されないと判定する。この例は、本発明を限定するものではないことに留意されたい。中央エンティティはＵＥと異なる装置であってもよい。中央エンティティは、例えばｅＮＢ、または、リレーもしくはサーバなどの別のエンティティであってもよい。
【0288】
有利には、フロア制御（フロア要求メッセージおよび場合によりフロアグラントの送信）は上位レイヤ、すなわちＭＡＣより上で行われる。特に、フロア制御はアプリケーションレイヤで行ってもよい。
【0289】
代替的に、中央エンティティが含まれなくてもよい。特に、ＵＥはすべてフロア要求を受信し、所与の時間の間のそれら自体の送信を停止してもよい。例えば、以下の実施形態により詳細に記載することにもなるように、自身の優先度および「フロア」を要求するグループ内の他のＵＥの優先度に基づいて、各ＵＥ自身が、サイドリンク論理チャネルまたはＰｒｏＳｅグループ送信を一時的に停止するべきかまたはそれらを再開するべきかを決定することができる。
【0290】
停止および再開は、様々な異なる方途で行われてもよい。論理チャネルが停止されるとき、バッファの内容は維持され、そこに記憶したデータは、論理チャネルを再開した上で送信される。
【0291】
要約すると、フロア制御メカニズムの結果に基づいて、サイドリンク論理チャネルまたはＰｒｏＳｅ宛先グループは、停止、および、ＬＣＰ手順のために再開される。停止および／または再開は、有利には、アプリケーションレイヤなどの上位レイヤによって行われても（開始されても）よい。特に、例示的な実装によれば、上位レイヤは、低位レイヤに一定のサイドリンク論理チャネル／ＰｒｏＳｅグループを停止／再開するように通知することになる。
【0292】
１つの例示的な実装によれば、各サイドリンク論理チャネルは、ＵＥに記憶される関連状況フラグを有し、それは、対応するサイドリンク論理チャネルが停止しているかまたは「アクティブ」か、を示す。ＵＥ内の上位レイヤ、例えばＰｒｏＳｅ機能は、アプリケーションレイヤ上で動作するフロア制御メカニズムの結果に従ってフラグを設定する。ＭＡＣ内のＬＣＰ手順は、トランスポートブロック生成手順の間、サイドリンク論理チャネルの優先度または、ＰｒｏＳｅグループ優先度およびＬＣＧ優先度のような任意の他の優先度だけでなく、このフラグの状況も考慮する。より詳しくは、新たなトランスポートブロックの生成のため、ＬＣＰ手順またはＭＡＣレイヤは、状況フラグが停止に設定されていないサイドリンク論理チャネルのみを考慮する。図２５に注目すると、このことは、ステップ２５１０で、アクティブフラグが設定されている（すなわち、停止しているよりむしろアクティブな）ＬＣの中で最高優先度を持つＬＣが選択されることを意味する。ステップ２５３０での優先順位付けもアクティブなチャネルの中でのみ行われる。
【0293】
より高い優先度ＵＥが現在送信している場合、グループ内の他のＵＥのサイドリンク送信は停止されるものとする。ＵＥでのＬＣＰ手順は、停止したサイドリンク論理チャネル／ＰｒｏＳｅグループを考慮しないことになる。上記したように、このことは、停止したサイドリンク論理チャネルまたはＰｒｏＳｅグループのデータを持つ新たなトランスポートブロックをＵＥが生成および送信しないことになるという結果になるだろう。
【0294】
フロア制御メカニズムがＰｒｏＳｅグループ内のＵＥに対してサイドリンク送信を承認／許容する場合、ＰｒｏＳｅグループに帰属するサイドリンク論理チャネルはアクティブになる（再開される）ものとする。ＵＥでのＬＣＰ手順は、アクティブな／再開したサイドリンク論理チャネル／ＰｒｏＳｅグループを考慮する。上位レイヤ（アプリケーションレイヤ）は、サイドリンク論理チャネル／ＰｒｏＳｅグループを停止／再開し、そのことをＭＡＣに通知してもよい。
【0295】
特に、ＵＥは以下も行うように設定されてもよい。ＵＥが現在ＳＣ期間内でデータを送信しているサイドリンク論理チャネル／ＰｒｏＳｅグループを上位レイヤが停止する場合、ＵＥはＳＣ期間内のＳＣＩ／データ（ＤＴＸ）の送信を停止するものとする。
【0296】
ＵＥは、次のＳＣ期間に対するＬＣＰ／ＢＳＲ／グラント選択手順に関して停止したサイドリンク論理チャネル／ＰｒｏＳｅグループを考慮しないことになる。
図２７は、第６の実施形態に係る例示的な方法２７００を示す。特に、ＵＥが、（ステップ２７１０で評価される）あるＰｒｏＳｅグループでフロアを得れば、ＵＥは、ステップ２７２０で、ＰｒｏＳｅグループに対するすべてのサイドリンク論理チャネルを再開するまたはアクティブにする（ＰｒｏＳｅグループに帰属するいくらかの停止した論理チャネルがあれば、それらの論理チャネルを再開する）と考え、ステップ２７３０で、実施形態１～５に記載したように優先順位付けおよび割当て手順に従って論理チャネルのバッファからデータを送信する。他方では、ＵＥがフロアを有しなければ、ステップ２７４０で、ＵＥは、あるＰｒｏＳｅグループのすべての論理チャネルを停止するものとする。
図２７は、第６の実施形態に係る例示的な方法２７００を示す。特に、ＵＥが、（ステップ２７１０で評価される）あるＰｒｏＳｅグループでフロアを得れば、ＵＥは、ステップ２７２０で、ＰｒｏＳｅグループに対するすべてのサイドリンク論理チャネルを再開するまたはアクティブにする（ＰｒｏＳｅグループに帰属するいくらかの停止した論理チャネルがあれば、それらの論理チャネルを再開する）と考え、ステップ２７３０で、実施形態１～５に記載したように優先順位付けおよび割当て手順に従って論理チャネルのバッファからデータを送信する。他方では、ＵＥがフロアを有しなければ、ステップ２７４０で、ＵＥは、あるＰｒｏＳｅグループのすべての論理チャネルを停止するものとする。
【0297】
（第７の実施形態）
上記実施形態において、フロア制御は、フロアを要求するＵＥにそれらＵＥの必要性を評価することなくフロアを割り当てるための単なるメカニズムとして記載された。しかしながら、とりわけミッションクリティカルなシナリオで、それ自体のデータを通信するより重大な必要性を有するＵＥに、最初にフロアが与えられれば、フロア制御はより効率的であろう。
上記実施形態において、フロア制御は、フロアを要求するＵＥにそれらＵＥの必要性を評価することなくフロアを割り当てるための単なるメカニズムとして記載された。しかしながら、とりわけミッションクリティカルなシナリオで、それ自体のデータを通信するより重大な必要性を有するＵＥに、最初にフロアが与えられれば、フロア制御はより効率的であろう。
【0298】
基本的に、効率的なフロア制御は、複数のユーザ（２人以上）によるマルチキャスト／ブロードキャストリソースの公平な使用法を可能にするために、１つのＵＥが別のＵＥに先取する能力を必要とする。
【0299】
フロア制御は、したがって、異なるユーザにチャネルを割り当てるための規則も必要とする。したがって、送信されるべきデータを有するユーザを単に循環的にスケジュールすることよりむしろユーザの優先順位付けも有益である。
【0300】
本実施形態において、フロア制御はＰｒｏＳｅユーザの優先度に基づき、それは以下ＵＥ優先度と呼ぶことにする。この優先度は概して、上記したような論理チャネル優先度、論理チャネルグループ優先度またはグループ優先度から独立した優先度であってもよい。しかしながら、ＵＥ優先度は、所与のＰｒｏＳｅグループ内のＰｒｏＳｅユーザのサイドリンク送信の優先度にも関連してもよい。言い換えると、論理チャネル優先度、論理チャネルグループ優先度および／または宛先グループ優先度とＵＥ優先度との間のマッピングがあってもよい。
【0301】
フロア制御でのＵＥ優先度処理を図２８に概略的に示す。特に、方法２８００は、別のユーザ機器から受信される、物理レイヤ上のサイドリンク制御情報またはメディアアクセス制御（ＭＡＣ）プロトコルデータユニット（ＰＤＵ）から、ユーザ機器優先度インジケータを抽出するステップ２８１０を含み、ここではユーザ機器優先度インジケータはユーザ機器またはユーザ機器によって送信されるべきデータの優先度を示す。ステップ２８２０にて、抽出したユーザ機器優先度インジケータは、ユーザ機器に記憶される自身のユーザ機器優先度または送信されるべきデータの優先度と比較される。自身のユーザ機器優先度が、抽出したユーザ機器優先度より低い場合、（例えば、図２７に関して記載したステップ２７１０に対応して）、ユーザ機器は、送信のために選択されず、ユーザ端末の論理チャネルに対してバッファされるデータは送信されないと判定される（２８３０）。
【0302】
ステップ２８３０は、第６の実施形態に記載したように、ＰｒｏＳｅ宛先グループに対してユーザ機器の論理チャネルを停止することも含んでもよいことに留意されたい。
【0303】
他方では、自身のユーザ機器優先度がフロアを要求するすべての他の端末の抽出したユーザ機器優先度より高ければ、（例えば、図２７に関して記載したステップ２７１０に対応して）、ユーザ機器は送信のために選択され、ユーザ端末の論理チャネルに対してバッファされるデータは送信されると判定される（２８４０）。送信（２８４０）は、実施形態１～５のいずれかに示したように、優先順位付けメカニズムに基づいて行われてもよい。
【0304】
フロア要求を送信する２つ以上のＵＥが、グループのＵＥの中で最高の同じ優先度を有すれば、同じ優先度を持つＵＥがすべて送信してもよいか、またはなんらかのランダム選択が各ＵＥによって行われて送信するべきか否かを決定してもよい。概して、これは、ＭＣＰＴＴサービスの場合、起こったとしても極めてまれであるべきである。
【0305】
たとえ先行の実施形態に示した意図がアプリケーションレイヤ上のフロア制御を適用することであったとしても、サイドリンク送信またはＰｒｏＳｅユーザの優先度は、有利にはフロア制御メカニズムへの入力である。したがって、フロア制御の少なくとも一部分を低位レイヤに、すなわち、以上例証したように物理レイヤまたはＭＡＣに移動することが有益だろう。
【0306】
したがって、データまたは／および関連するサイドリンク制御情報（ＳＣＩ：sidelink control information）はなんらかの優先度情報を含み、これに基づいて「フロア制御」メカニズムはＰＨＹ／ＭＡＣレイヤ上で実現されることができ、さらに、なんらかの上位レイヤ「フロア制御」メカニズムと比較して待ち時間の利点を有する。ＳＣＩ情報は、モード１およびモード２の両方に関して背景に既に上記したスケジューリング割当て（ＳＡ）の概念に対する別名である。
【0307】
特に、ＰＨＹおよびＭＡＣレイヤプロトコルは、アプリケーションレイヤプロトコルと比較して低い待ち時間を有する。したがって、ＰＨＹ／ＭＡＣシグナリングに優先度インジケーションを追加することが有利である。例えば、サイドリンク制御情報は、図２９に図示するように優先度フィールド２９００を備えてもよい。ＳＣＩは、ＬＴＥ Ｒｅｌ８以後でのＤＣＩにほぼ匹敵してもよい物理レイヤの制御メッセージである。ＳＣＩは、基本的に、スケジューリング割当て（ＳＡ：scheduling assignment）という名の下で上記したような割当て情報を含む、すなわちＳＣＩは、例えば、変調および符号化、冗長性バージョン（redundancy version）、周波数帯域、（サブ）フレーム、ＭＩＭＯパラメータなどのいずれかを含み、リソースをより詳細に特定してもよい。
【0308】
一定のＰｒｏＳｅグループ（宛先グループＩＤ）に送信しているＵＥは、上位レイヤによってシグナリングされてもよい（およびＰｒｏＳｅエンティティによって設定されてもよい）または端末に予め設定されてもよいそれ自体の優先度、あるいは、送信されるべきデータの優先度を、同じグループでの他のＵＥからを受信されるＳＣＩの優先度フィールド２９００（ユーザ機器優先度、ＵＥＰ）内で受信される優先度と比較する。受信したＳＣＩメッセージでの優先度がそれ自体の優先度より高ければ、送信ＵＥは、このＳＣ期間の間、および、場合により後続のＳＣ期間にもデータ／ＳＣＩを送信することを停止することになる。
【0309】
特に、ＵＥ優先度は、製造業者または事業者によってＵＥに予め設定されてもよい。より低い優先度で設定される他のＵＥに先取することができるマスタＵＥとして、いくつかのＵＥを予め設定することによって、単純であるが、効率的な実装が達成されてもよい。
【0310】
別の、より柔軟な手法は、ＰｒｏＳｅエンティティによってＵＥ優先度を設定することでもよく、この手法は、異なるミッションまたは異なるシナリオに対してＵＥ優先度を変更する利点を提供する。
【0311】
なおさらに、ＵＥ優先度は、ＵＥによって自律的に決定されてもよく、または、論理チャネル優先度のマッピングに基づいてＰｒｏＳｅエンティティによって設定されてもよい。例えば、最高の優先度を持つ論理チャネルは、高いＵＥ優先度にマッピングする一方で、すべての他のＬＣ優先度は、低いＵＥ優先度にマッピングする（ここでＵＥ優先度が、０および１、または、１および０でもよい高低２つの値のみを取ることができることを例示的に前提とする）。ＵＥ優先度は、次いで、ＵＥ優先度値上へ、所与のグループに対するＵＥの最高のＬＣをマッピングすることによって決定されてもよい。上記例は、本発明を限定するものではない。むしろ、マッピングは異なっていてもよい。例えば、高いＵＥ優先度上に２つ以上の最高ＬＣ優先度値のマッピングがあってもよい。その上、ＵＥ優先度は、３つ以上の値を取ってもよい。ＵＥ優先度が、直接、論理チャネル優先度でもよいことに留意されたい。
【0312】
（ＰｒｏＳｅエンティティによってまたはＵＥ自体によって）設定可能なＵＥ優先度は、優先度が柔軟に変更されてもよい利点を有する。１つのＵＥが異なるＰｒｏＳｅグループで異なる優先度を有してもよいように、ＵＥ優先度は、宛先（ＰｒｏＳｅ）グループごとに記憶／設定されてもよい。
【0313】
この手法に関しては、たとえフロアがＵＥによって取られるとしても、より高い優先度を持つ別のＵＥが送信ＵＥに先取して、フロアを取ってもよいことが保証される。これは、優先度が高いＵＥほど残りのＵＥより小さい待ち時間でそれらのデータを送信するという結果になる。残りのＵＥは、それらの優先度レベルでフロアが利用可能となるまで待たなければならない。展開シナリオに応じて、データが送信のためにバッファに記憶されていた時間に比例してＵＥの優先度または対応するＬＣの優先度を増加させることが有益だろう。
【0314】
代替的に、または、ＳＣＩ ＰＨＹメッセージ内の優先度フィールドに加えて、データトランスポートブロック（ＴＢ：Transport Block）は、図３０に図示するように、それぞれのＭＡＣヘッダに優先度フィールドを含んでもよい。
【0315】
ＭＡＣヘッダの優先度フィールドで通知される優先度インジケーションに基づいて、ＵＥは、上記したように、ＰｒｏＳｅグループにデータを送信するべきか否かを決定してもよい。
【0316】
特に、ＭＡＣ ＰＤＵは、ＭＡＣヘッダおよびＭＡＣペイロードを含む。図３０に図示するように、現在使用されるＭＡＣヘッダ構造は、優先度フィールドをシグナリングするために再使用されてもよい。特に、ＭＡＣヘッダは、有利には、ＭＡＣサブヘッダの「Ｒ」予約ビット内にＵＥ優先度インジケーションを含む。ＭＡＣの「Ｒ」フィールドは、後の標準バージョンで使用するために残され、したがって優先度インジケーションを導入し、初期のリリースへの後方互換性をなお維持するのに適する。ＭＡＣヘッダは非特許文献２のバージョン１２．５．０の６．２．４節に記載される。
【0317】
ＵＥ優先度フィールドは先取インジケータ（preemption indicator）を通知してもよく、これは、ＵＥが送信するのが緊急データかまたは通常データかを示す。緊急データを送信しているＵＥは、上記にて例証したように、通常データを送信しているＵＥに先取することができるであろう。特に、優先度インジケーションは、一方の値が「緊急」を示すのに対して、他方の値が通常優先度を示す単一のビットであってもよい。
【0318】
ＭＡＣヘッダには、送信ＰｒｏＳｅ ＵＥ ＩＤを識別するＳＲＣ（ソース：source）フィールドもあるので、（ＰｒｏＳｅエンティティにおける）ＰｒｏＳｅ機能は、ＰｒｏＳｅ ＵＥ ＩＤと、基本のＵＥ優先度、すなわち現在送信される特定のデータに関係ないＵＥの優先度を基本的に示すであろう対応するＵＥ優先度と、の間のマッピングを提供してもよい。一種の「緊急インジケータ」として上記したように使用することができる「Ｒ」フィールドと共に、受信ＵＥは、送信ＵＥの優先度を計算し、次いで上記した手順に従って作用することができる。すなわち、（ＰｒｏＳｅエンティティによって設定され、それ自体のＵＥに記憶される基本ＵＥ優先度を考慮して）ＭＡＣヘッダフィールドによって決定される優先度がそれ自体の優先度より高ければ、ＵＥは、このＳＣ期間、および、最適には後続のＳＣ周期にデータを送信することを停止することになり、ＵＥがデータを送信していない後続のＳＣ期間の数を、このＰｒｏＳｅグループがシグナリングまたは予め設定されることができる。言い換えると、ＵＥは、グループにおけるＵＥとそれらの基本優先度との間の割当てを記憶するように構成され、ＭＡＣヘッダからＵＥ優先度インジケータを抽出するように構成され、グループにおけるＵＥの現在のＵＥ優先度を、基本優先度および抽出した優先度インジケータの関数として計算するように構成されてもよい。これは、例えば、和の関数または乗算または任意の他の関数でもよい。この方途で、いくつかのＵＥは、より高い優先度（マスタ）で設定されてもよい一方で、現在緊急の場合、すなわち緊急データが送信されるべきである場合、低い優先度を持つＵＥがマスタＵＥに先取する可能性もなおある。
【0319】
図３１は、例示的なフロア制御メカニズムを示す。３つのＵＥのグループＧ１があり、ＵＥ１はフロア制御優先度（ＵＥ優先度）が低優先度に対応するｐ＝０、ＵＥ２は高優先度ｐ＝１、ＵＥ３は低優先度ｐ＝０である。ＵＥ１およびＵＥ２は、それらがこのグループＧ１のための送信されるべきデータをバッファに有するので、両方ともＳＣＩ（ＳＡ）を提示する。対応するＳＡ１およびＳＡ２は、すべてのそれぞれの端末によって（または、少なくともＵＥ１およびＵＥ２によって）受信される。ＵＥ１は、ＵＥ２から受信したＳＡ２からＵＥ２の優先度ｐ＝１を抽出し、それを自身の優先度ｐ＝０と比較し、自身の方が低くなる。結果的に、ＵＥ１は、現在のＳＣ期間でデータを送信しないものとする。ＵＥ２は、ＳＡ１を受信し、より高い自身のｐ＝１と抽出したｐ＝０との同様の比較をする。結果的に、ＵＥ２は、フロアを取り、データ、例えば言語データ（speech data）を送信する。
【0320】
ＵＥが有利にはＳＣ期間より長い間、送信を停止してもよいことに留意されたい。これは、言語データの場合とりわけ有利でもよく、その場合、言語部分が送信されるためにいくつかのＳＣ期間を取るだろうことを前提する。したがって、ＵＥは、ＳＣ期間より大きいフロア制御期間の継続時間の間、停止してもよい。フロア制御期間は設定可能でもよい。
【0321】
本第７の実施形態が有利には、フロア制御結果に応じて論理チャネルを停止／再開することに関する第６の実施形態と組み合わされてもよいことに留意されたい。しかしながら、第７の実施形態は第６の実施形態なしで機能してもよい。同様に、第７の実施形態は有利には第１～５の実施形態と組み合わされてもよい。
【0322】
上記実施形態の組合せの例を図３２に例示する。特に、図３１を参照しつつ記載した例と同様にグループＧ１は、ＵＥ１、ＵＥ２およびＵＥ３を含む。すべての３つのＵＥは送信されるべきデータを有し、したがって単独で実施形態１～５のいずれかに記載した優先順位付け手順を行う。結果として、ＵＥ１およびＵＥ２はグループＧ１に送信することになる一方で、ＵＥ３は別のグループに送信することになる。ＳＡ１およびＳＡ２の送信、ならびに、ＵＥ１およびＵＥ２によるそれらの相互受信は、上記したように行われる。ＵＥ１は、実施形態６に従って、送信を停止し、グループＧ１に対するその論理チャネルを停止する。
【0323】
要約すると、図３３にも例示するように、第５の実施形態によれば、ユーザ機器間の直接通信をサポートする無線通信システムにおいて動作可能なユーザ機器は、複数の宛先グループを特定するサイドリンク設定が記憶され、各宛先グループは、サイドリンクデータのための可能な宛先を含む、記憶装置３３２０であって、サイドリンク宛先グループのために設定される論理チャネルからの各論理チャネルに対する論理チャネル優先度を記憶する、記憶装置３３２０と、送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最も高い論理チャネル優先度を持つ、送信のために利用可能なサイドリンクデータを有するサイドリンク論理チャネルを持つサイドリンク宛先グループを選択し、選択したサイドリンク宛先グループに帰属するサイドリンク論理チャネルに対して優先度の降順に無線リソースを割り当てるように構成されるスケジューリング部３３１０と、を備える。
【0324】
ユーザ端末は、行った優先順位付けに従っておよび割り当てたリソースでデータを送信する送信部３３７０をさらに含んでもよい。
【0325】
有利には、論理チャネル優先度は、データ宛先の宛先グループと関連づけられる宛先グループ優先度、搬送されるデータの種類に従ってグループ化される一群の論理チャネルと関連づけられる論理チャネルグループ優先度、ユーザ機器の地理的位置、ユーザ機器が動作している緊急レベル、およびユーザ機器識別子の少なくとも２つに依存する。
【0326】
ユーザ機器は、移動通信システムのＰｒｏＳｅエンティティにおけるＰｒｏＳｅ機能によって決定されるそれぞれの論理チャネルに対する論理チャネル優先度のインジケーションを受信し、論理優先度を記憶装置に記憶するための受信部３３６０をさらに備えてもよい。
【0327】
代替的に、ユーザ機器のスケジューリング部３３１０は、論理チャネルに対する論理チャネル優先度を決定するように構成される。このことは、グループ優先度および／またはＬＣＧ優先度などのＰｒｏＳｅエンティティから受信されるパラメータを基礎としての他に、さらに、受信および／または記憶されるパラメータに基づいて行われてもよい。
【0328】
ユーザ機器は、論理チャネルに対して送信されるべきデータを記憶するバッファ３３３０と、優先度の自身の再計算に基づいて、または、ＰｒｏＳｅ機能から受信される指令に基づいて、上記論理チャネルに対する現在の優先度を修正優先度に修正する優先度設定部３３４０と、をさらに備えてもよい。上記したように、修正は修正優先度を持つ新たな論理チャネルを開くことによって行われ、残りのデータを持つ論理チャネルを、バッファ内のデータが送信されるまで設定させてもよい。
【0329】
代替的に、修正前にバッファに記憶されたデータは、現在の優先度が修正優先度より高いか否か、修正優先度のレベル、および、修正の原因の少なくとも１つに応じてフラッシュ（flush）されるかまたは現在の優先度で送信されるかいずれかである。その上、ユーザ機器は、ユーザ機器が無線通信システムのユーザ機器の中でデータを送信するように選択されるか否かを判定し、ユーザ機器が選択されない場合、そのサイドリンク論理チャネルを停止し、データ発信ユーザ機器が選択された場合、先だって停止されたそのサイドリンク論理チャネルを再開するように構成されるフロア制御部３３５０を備えてもよく、スケジューリング部は、選択し、リソースを割り当てるためには停止された論理チャネルを考慮しない。
【0330】
例えば、フロア制御部３３５０は、ユーザ機器間および／またはＭＡＣより上のレイヤにおける近接サービスエンティティ間の無線通信システムで交換されるメッセージに従って、ユーザ機器がデータを送信するべきか否かを決定するように構成されてもよく、ユーザ機器がデータを送信するべきでないと決定した上で、ユーザ機器は、スケジューリング割当ておよび対応するデータの１回の送信に対応する期間であるサイドリンク制御期間内で自身のデータおよび／またはサイドリンク制御情報の送信を停止する。
【0331】
フロア制御部３３５０は、別のユーザ機器から受信される、物理レイヤ上のサイドリンク制御情報またはメディアアクセス制御（ＭＡＣ）プロトコルデータユニット（ＰＤＵ）から、ユーザ機器優先度インジケータを抽出し、ユーザ機器優先度インジケータは、ユーザ機器またはユーザ機器によって送信されるべきデータの優先度を示し、抽出したユーザ機器優先度インジケータを、ユーザ機器に記憶される自身のユーザ機器優先度または送信されるべきデータの優先度と比較し、自身のユーザ機器優先度が抽出したユーザ機器優先度より低い場合、ユーザ機器が送信のために選択されないと判定するようにも構成されてもよい。
【0332】
特に、ユーザ機器がフロア（floor）を有し、同時に、より高いユーザ機器優先度を持つ別のユーザ機器からのサイドリンク制御情報を受信した場合、フロア制御部は、送信を停止し、したがって他のユーザ機器にフロアを委ねるように構成される。
【0333】
ユーザ機器優先度は、ＭＡＣ ＰＤＵのＭＡＣヘッダ内で通知されても、無線通信システムの近接サービス（ＰｒｏＳｅ）エンティティによって設定されてもよい。
【0334】
ユーザ機器は、論理チャネル優先度と関連づけられるバッファ３３３０の状況を無線通信システムのネットワークノードに報告するためのバッファ状況報告部をさらに備えてもよい。
【0335】
さらには、ユーザ機器間の直接通信をサポートする無線通信システムにおいて動作可能なネットワークノードが提供され、ネットワークノードは、複数の宛先グループを特定するサイドリンク設定がユーザ機器ごとに記憶され、各宛先グループは、サイドリンクデータのための可能な宛先を含む、記憶装置であって、サイドリンク宛先グループのために設定される論理チャネルからの各論理チャネルに対する論理チャネル優先度を記憶する、記憶装置と、送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最高論理チャネル優先度を持つ、送信のために利用可能なサイドリンクデータを有するサイドリンク論理チャネルを持つサイドリンク宛先グループを選択し、選択したサイドリンク宛先グループのユーザ機器に相応に無線リソースを割り当てるように設定されるスケジューリング部と、を備える。
【0336】
その上、ネットワークノードは、優先度決定およびリソース割当てが行われるユーザ機器にスケジューリング割当てを送信するための送信部を、さらに備えてもよい。スケジューリング割当ては、１つまたは複数のグループのＵＥに帰属する複数のＵＥからの優先度およびリソース要求のその評価に基づいて、ネットワークノードによって生成される。ネットワークノードは、ＬＴＥまたは任意の他のアクセスポイントにおけるｅＮＢなどの基地局でもよい。
【0337】
その上、ユーザ機器間の直接通信をサポートする無線通信システムにおいて動作可能なユーザ機器で行われるべき方法が提供され、方法は、複数の宛先グループを特定するサイドリンク設定を記憶し、各宛先グループは、サイドリンクデータのための可能な宛先を含み、さらに、サイドリンク宛先グループのために設定される論理チャネルからの各論理チャネルに対する論理チャネル優先度を記憶し、送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最高論理チャネル優先度を持つ、送信のために利用可能なサイドリンクデータを有するサイドリンク論理チャネルを持つサイドリンク宛先グループを選択し、選択したサイドリンク宛先グループに帰属するサイドリンク論理チャネルに優先度降順に無線リソースを割り当てる方法である。
【0338】
＜本開示のハードウェアおよびソフトウェア実装＞
他の例示的な実施形態は、ハードウェアおよびソフトウェアを使用する上記した様々な実施形態の実装に関する。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）が提供される。ユーザ端末および基地局は、受信器、送信器、プロセッサなど、本明細書に記載した方法に適切に関与する対応するエンティティを含め、同方法を行う。
他の例示的な実施形態は、ハードウェアおよびソフトウェアを使用する上記した様々な実施形態の実装に関する。これに関連して、ユーザ端末（移動端末）およびｅＮｏｄｅＢ（基地局）が提供される。ユーザ端末および基地局は、受信器、送信器、プロセッサなど、本明細書に記載した方法に適切に関与する対応するエンティティを含め、同方法を行う。
【0339】
様々な実施形態がコンピューティング装置（プロセッサ）を使用して実装されてもまたは行われてもよいとさらに認識される。コンピューティング装置またはプロセッサは、例えば汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）または他のプログラマブル論理装置などでもよい。様々な実施形態はこれらの装置の組合せによって行われてもまたは具象化されてもよい。
【0340】
さらに、様々な実施形態はソフトウェアモジュールを用いて実装されてもよく、ソフトウェアモジュールはプロセッサによってまたはハードウェアで直接実行される。また、ソフトウェアモジュールおよびハードウェア実装の組合せも可能だろう。ソフトウェアモジュールは任意の種類のコンピュータ可読記憶媒体、例えばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ－ＲＯＭ、ＤＶＤなどに記憶されてもよい。
【0341】
異なる実施形態の個々の特徴が個々にまたは任意の組合せで別の実施形態の主題であることにさらに留意するべきである。
【0342】
当業者によって、多数の変形および／または修正が具体的な実施形態に示すように本開示になされてもよいことが認識されるであろう。本実施形態は、したがって、すべての点で例示的であり限定的でないと考えられるべきである。
【0343】
要約すると、本開示はユーザ機器で行われるべき方法に、およびユーザ機器間の直接通信をサポートする無線通信システムにおいて動作可能なユーザ機器に関する。したがって、サイドリンク設定がユーザ機器に記憶され、複数の宛先グループを特定し、各宛先グループはサイドリンクデータのための可能な宛先を含み、さらに、サイドリンク宛先グループのために設定される論理チャネルからの各論理チャネルに対して論理チャネル優先度が記憶される。端末は、次いで、送信のために利用可能なデータを有するサイドリンク論理チャネルの中で最も高い論理チャネル優先度を持つ、送信のために利用可能なサイドリンクデータを有するサイドリンク論理チャネルを持つサイドリンク宛先グループを選択し、選択したサイドリンク宛先グループに帰属するサイドリンク論理チャネルに優先度降順に無線リソースを割り当てる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】