(57)【要約】      （修正有）【課題】現在のシステムに対する必要な変更ができる限り少なくなるように、Ｄ２Ｄ通信をＬＴＥシステムに組み込むことのできる方法およびシステムを開発する。【解決手段】通信装置に割り当てた上り共有チャネルリソース上で直接リンク・バッファ状態報告を送信し、直接リンク・バッファ状態報告が、通信装置からＤ２Ｄ通信の受信側端末に送信するＤ２Ｄデータの量に関する情報を基地局装置に提供するためのメッセージである送信部と、Ｄ２Ｄ通信のためのＤ２ＤリソースをスケジュールするためのＤ２Ｄグラントを受信する受信部とを具備する。直接リンク・バッファ状態報告の優先順位は、アップリンク・バッファ状態報告よりも低く、論理チャネルからのデータよりも高い。【選択図】図１２
2020109990.tif 000002
【特許請求の範囲】
【請求項１】
通信装置に割り当てた上り共有チャネル（ＵＬ−ＳＣＨ）リソース上で、直接リンク・バッファ状態報告を送信し、前記直接リンク・バッファ状態報告は、前記通信装置が機器間（Ｄ２Ｄ）通信の受信側端末に送信するＤ２Ｄデータの量に関する情報を基地局装置に提供するためのメッセージである、送信部と、
前記Ｄ２Ｄ通信のためのＤ２ＤリソースをスケジュールするためのＤ２Ｄグラントを受信する受信部と、
を具備し、
リソース割当における優先順位において、前記直接リンク・バッファ状態報告は、前記通信装置が前記基地局装置へ送信する上りデータの量に関する情報を前記基地局に提供するためのメッセージであるアップリンク・バッファ状態報告よりも低く、ＵＬ−ＣＣＣＨからのデータを除く論理チャネルからのデータよりも高い、
端末装置。
【請求項２】
前記直接リンク・バッファ状態報告は、前記受信側端末に送信するデータのタイプを特定するためのインデックスを含む直接リンク・バッファ状態報告・ＭＡＣコントロールエレメント内で送信され、前記直接リンク・バッファ状態報告・ＭＡＣコントロールエレメントは、バッファ状態報告のタイプを特定するための論理チャネルＩＤを含むＭＡＣヘッダを伴う、
請求項１に記載の端末装置。
【請求項３】
前記Ｄ２Ｄリソースは、前記Ｄ２Ｄ通信のためのサブフレームのセットである、
請求項１又は２に記載の端末装置。
【請求項４】
前記直接リンク・バッファ状態報告は、前記Ｄ２Ｄデータの量に関する情報とは異なるＤ２Ｄ通信に関する情報を含む、
請求項１から３のいずれか一項に記載の端末装置。
【請求項５】
前記受信部は、物理アップリンク制御チャネル（ＰＵＣＣＨ）と物理ランダムアクセスチャネル（ＰＲＡＣＨ）のいずれかにおいて、前記ＵＬ−ＳＣＨリソースを要求するためのスケジューリング要求を前記通信装置から受信する、
請求項１から４のいずれか一項に記載の端末装置。
【請求項６】
前記直接リンク・バッファ状態報告は、第１のタイプの直接リンク・バッファ状態報告と、前記第１のタイプの直接リンク・バッファ状態報告よりも短い第２のタイプの直接リンク・バッファ状態報告とを含む、
請求項１から５のいずれか一項に記載の端末装置。
【請求項７】
前記受信部は、前記直接リンク・バッファ状態報告を送信するための一つの直接リンク・バッファ状態報告・ＭＡＣコントロールエレメントと、アップリンク・バッファ状態報告を送信するための少なくとも一つのバッファ状態報告ＭＡＣコントロールエレメントとを含むＭＡＣプロトコールデータユニット（ＰＤＵ）を受信する、
請求項１から３のいずれか一項に記載の端末装置。
【請求項８】
前記Ｄ２Ｄリソースは、前記ＵＬ−ＳＣＨリソースとは異なる、
請求項１から７のいずれか一項に記載の端末装置。
【請求項９】
前記アップリンク・バッファ状態報告及び前記直接リンク・バッファ状態報告のいずれか１つを前記上り共有チャネルにおいて受信する、
請求項１から７のいずれか一項に記載の端末装置。
【請求項１０】
１つの前記アップリンク・バッファ状態報告及び１つの前記直接リンク・バッファ状態報告を前記上り共有チャネルにおいて受信する、
請求項１から７のいずれか一項に記載の端末装置。
【請求項１１】
通信装置に割り当てた上り共有チャネル（ＵＬ−ＳＣＨ）リソース上で、直接リンク・バッファ状態報告を送信し、前記直接リンク・バッファ状態報告は、前記通信装置が機器間（Ｄ２Ｄ）通信の受信側端末に送信するＤ２Ｄデータの量に関する情報を基地局装置に提供するためのメッセージであり、
前記Ｄ２Ｄ通信のためのＤ２ＤリソースをスケジュールするためのＤ２Ｄグラントを受信し、
リソース割当における優先順位において、前記直接リンク・バッファ状態報告は、前記通信装置が前記基地局装置へ送信する上りデータの量に関する情報を前記基地局に提供するためのメッセージであるアップリンク・バッファ状態報告よりも低く、ＵＬ−ＣＣＣＨからのデータを除く論理チャネルからのデータよりも高い、
通信方法。
【請求項１２】
前記直接リンク・バッファ状態報告は、前記受信側端末に送信するデータのタイプを特定するためのインデックスを含む直接リンク・バッファ状態報告・ＭＡＣコントロールエレメント内で送信され、前記直接リンク・バッファ状態報告・ＭＡＣコントロールエレメントは、バッファ状態報告のタイプを特定するための論理チャネルＩＤを含むＭＡＣヘッダを伴う、
請求項１１に記載の通信方法。
【請求項１３】
前記Ｄ２Ｄリソースは、前記Ｄ２Ｄ通信のためのサブフレームのセットである、
請求項１１又は１２に記載の通信方法。
【請求項１４】
前記直接リンク・バッファ状態報告は、前記Ｄ２Ｄデータの量に関する情報とは異なるＤ２Ｄ通信に関する情報を含む、
請求項１１から１３のいずれか一項に記載の通信方法。
【請求項１５】
物理アップリンク制御チャネル（ＰＵＣＣＨ）と物理ランダムアクセスチャネル（ＰＲＡＣＨ）のいずれかにおいて、前記ＵＬ−ＳＣＨリソースを要求するためのスケジューリング要求を前記通信装置から受信する、
請求項１１から１４のいずれか一項に記載の通信方法。
【請求項１６】
前記直接リンク・バッファ状態報告は、第１のタイプの直接リンク・バッファ状態報告と、前記第１のタイプの直接リンク・バッファ状態報告よりも短い第２のタイプの直接リンク・バッファ状態報告とを含む、
請求項１１から１５のいずれか一項に記載の通信方法。
【請求項１７】
前記直接リンク・バッファ状態報告を送信するための一つの直接リンク・バッファ状態報告・ＭＡＣコントロールエレメントと、アップリンク・バッファ状態報告を送信するための少なくとも一つのバッファ状態報告ＭＡＣコントロールエレメントとを含むＭＡＣプロトコールデータユニット（ＰＤＵ）を受信する、
請求項１１から１３のいずれか一項に記載の通信方法。
【請求項１８】
前記Ｄ２Ｄリソースは、前記ＵＬ−ＳＣＨリソースとは異なる、
請求項１１から１７のいずれか一項に記載の通信方法。
【請求項１９】
前記アップリンク・バッファ状態報告及び前記直接リンク・バッファ状態報告のいずれか１つを前記上り共有チャネルにおいて受信する、
請求項１１から１８のいずれか一項に記載の通信方法。
【請求項２０】
１つの前記アップリンク・バッファ状態報告及び１つの前記直接リンク・バッファ状態報告を前記上り共有チャネルにおいて受信する、
請求項１１から１８のいずれか一項に記載の通信方法。
【請求項２１】
通信装置に割り当てた上り共有チャネル（ＵＬ−ＳＣＨ）リソース上で、直接リンク・バッファ状態報告を送信し、前記直接リンク・バッファ状態報告は、前記通信装置が機器間（Ｄ２Ｄ）通信の受信側端末に送信するＤ２Ｄデータの量に関する情報を基地局装置に提供するためのメッセージである、処理と、
前記Ｄ２Ｄ通信のためのＤ２ＤリソースをスケジュールするためのＤ２Ｄグラントを受信する処理と、
を制御し、
リソース割当における優先順位において、前記直接リンク・バッファ状態報告は、前記通信装置が前記基地局装置へ送信する上りデータの量に関する情報を前記基地局に提供するためのメッセージであるアップリンク・バッファ状態報告よりも低く、ＵＬ−ＣＣＣＨからのデータを除く論理チャネルからのデータよりも高い、
集積回路。
【請求項２２】
端末装置が通信装置に割り当てた上り共有チャネル（ＵＬ−ＳＣＨ）リソース上で、直接リンク・バッファ状態報告を送信し、前記直接リンク・バッファ状態報告は、前記通信装置が機器間（Ｄ２Ｄ）通信の受信側端末に送信するＤ２Ｄデータの量に関する情報を基地局装置に提供するためのメッセージであり、
前記基地局装置が前記直接リンク・バッファ状態報告を受信し、
前記基地局装置が前記Ｄ２Ｄ通信のためのＤ２ＤリソースをスケジュールするためのＤ２Ｄグラントを送信し、
前記端末装置がリソース割当における優先順位において、前記直接リンク・バッファ状態報告は、前記通信装置が前記基地局装置へ送信する上りデータの量に関する情報を前記基地局に提供するためのメッセージであるアップリンク・バッファ状態報告よりも低く、ＵＬ−ＣＣＣＨからのデータを除く論理チャネルからのデータよりも高い、
通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置間通信システムにおいてスケジューリング要求手順を実行するシステムおよび方法に関する。さらに、本発明は、本明細書に記載されている方法を実行するユーザ機器を提供する。
【背景技術】
【０００２】
ロングタームエボリューション（ＬＴＥ）
【０００３】
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。
【０００４】
ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、３ＧＰＰは、ロングタームエボリューション（ＬＴＥ）と称される新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、ＬＴＥにおける重要な方策である。
【０００５】
ＬＴＥ（ロングタームエボリューション）に関する作業項目（ＷＩ）の仕様は、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access（ＵＴＲＡ）：進化したＵＭＴＳ地上無線アクセス）およびＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network（ＵＴＲＡＮ）：進化したＵＭＴＳ地上無線アクセスネットワーク）と称され、最終的にリリース８（ＬＴＥリリース８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。詳細なシステム要件は、非特許文献１に記載されている。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（例えば、１.４ＭＨｚ、３.０ＭＨｚ、５.０ＭＨｚ、１０.０ＭＨｚ、１５.０ＭＨｚ、および２０.０ＭＨｚ）が指定されている。ダウンリンクには、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ）を受けにくく、また、サイクリックプレフィックス（ＣＰ）を使用しており、さらに、さまざまな送信帯域幅の構成に対応可能だからである。アップリンクには、ＳＣ−ＦＤＭＡ（シングルキャリア周波数分割多元接続：Single-Carrier Frequency Division Multiple Access）をベースとする無線アクセスが採用されており、なぜなら、ユーザ機器（ＵＥ）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。リリース８のＬＴＥでは、数多くの重要なパケット無線アクセス技術（例えば、ＭＩＭＯ（多入力多出力）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が達成されている。
【０００６】
Ｅ−ＵＴＲＡＮのアーキテクチャ
【０００７】
図１は、全体的なアーキテクチャを示しており、図２は、Ｅ−ＵＴＲＡＮのアーキテクチャをより詳細に示している。Ｅ−ＵＴＲＡＮは、１基または複数基のｅＮｏｄｅＢから構成され、ｅＮｏｄｅＢは、ユーザ機器に向かうＥ−ＵＴＲＡユーザプレーンプロトコル（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーンプロトコル（ＲＲＣ）を終端処理する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ）レイヤ（これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質（ＵＬ  ＱｏＳ）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。複数のｅＮｏｄｅＢは、Ｘ２インタフェースによって互いに接続されている。
【０００８】
また、複数のｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（Evolved Packet Core：進化したパケットコア）、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（Mobility Management Entity：移動管理エンティティ）、Ｓ１−Ｕによってサービングゲートウェイ（Ｓ−ＧＷ：Serving Gateway）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングして転送する一方で、ｅＮｏｄｅＢ間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、ＬＴＥと別の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インタフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ  ＧＷとの間でトラフィックを中継する）として機能する。Ｓ−ＧＷは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガーする。ＳＧＷは、ユーザ機器のコンテキスト（例えばＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法傍受（lawful interception）の場合にユーザトラフィックの複製を実行する。
【０００９】
ＭＭＥは、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのユーザ機器の追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラのアクティブ化／非アクティブ化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバー時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インタフェースを終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのホームＨＳＳに向かうＳ６ａインタフェースを終端させる。
【００１０】
ＬＴＥにおけるコンポーネントキャリアの構造
【００１１】
３ＧＰＰ  ＬＴＥシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。３ＧＰＰ  ＬＴＥで、各サブフレームは、図３に示すように２つのダウンリンクスロットに分割され、そこにおいて、第１のダウンリンクスロットは、第１のＯＦＤＭシンボル内の制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは、時間領域内の所与の数のＯＦＤＭシンボルで構成され（３ＧＰＰ  ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、ＯＦＤＭシンボルは、各々、図４にも示すように、ＮＤＬＲＢ×ＮＲＢｓｃ個のそれぞれのサブキャリアで送信されるいくつかの変調シンボルで構成される。
【００１２】
例えば３ＧＰＰロングタームエボリューション（ＬＴＥ）において使用されるような、例えばＯＦＤＭを使用する、マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロックは、図４に例示したように、時間領域におけるＮＤＬｓｙｍｂ個の連続するＯＦＤＭシンボルおよび周波数領域におけるＮＲＢｓｃ個の連続するサブキャリアとして定義される。したがって、３ＧＰＰ  ＬＴＥ（リリース８）では、物理リソースブロックは、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する、ＮＤＬｓｙｍｂ×ＮＲＢｓｃ個のリソース要素で構成される（ダウンリンクリソースグリッドについてさらに詳しくは、例えば、３ＧＰＰのウェブサイトで入手可能であり、参照により本明細書に組み込まれている、非特許文献２の６.２節を参照）。
【００１３】
「コンポーネントキャリア」という用語は、いくつかのリソースブロックの組合せを意味する。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、その専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。
【００１４】
ＬＴＥのさらなる発展（ＬＴＥ−Ａ）
【００１５】
世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、３ＧＰＰ（第３世代パートナーシッププロジェクト）において無線インタフェースの標準化が開始された。３ＧＰＰ  ＴＳＧ  ＲＡＮ  ＃３９会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目の記述が３ＧＰＰにおいて承認された。この検討項目は、Ｅ−ＵＴＲＡを進化・発展させるうえで（例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために）考慮すべき技術要素をカバーしている。以下では、ＬＴＥ−Ａを対象として現在検討されている２つの重要な技術要素について説明する。
【００１６】
より広い帯域幅をサポートするためのＬＴＥ−Ａにおけるキャリアアグリゲーション
【００１７】
ＬＴＥアドバンストシステムがサポートすることができる帯域幅は１００ＭＨｚであり、一方、ＬＴＥシステムは２０ＭＨｚのみをサポートすることができる。今日、無線スペクトルの欠如がワイヤレスネットワークの開発のボトルネックになり、結果として、ＬＴＥアドバンストシステムのために十分広いスペクトル帯域を見つけることは困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることは急務であり、ここにおいて、可能性のある答えは、キャリアアグリゲーション機能である。
【００１８】
キャリアアグリゲーションでは、最大で１００ＭＨｚの広い送信帯域幅をサポートする目的で、２つ以上のコンポーネントキャリア（ＣＣ）がアグリゲートされる。ＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、ＬＴＥシステムにおけるいくつかのセルが、より広い１つのチャネルにアグリゲートされ、このチャネルは、たとえＬＴＥにおけるこれらのセルが異なる周波数帯域である場合でも１００ＭＨｚに対して十分に広い。ユーザ機器は、次のように自身の能力に応じて１つまたは複数のコンポーネントキャリア（ＣＣ）を同時に受信または送信することができる。
−  キャリアアグリゲーション（ＣＡ）のための受信能力もしくは送信能力またはその両方を備えた、リリース１０のユーザ機器は、複数のサービングセルに対応する複数のコンポーネントキャリア（ＣＣ）上で同時に受信する、もしくは送信する、またはその両方を行うことができる。
−  ＬＴＥリリース８／９のユーザ機器は、１つのみのサービングセルに対応する１つのコンポーネントキャリア（ＣＣ）上で受信し、１つのコンポーネントキャリア（ＣＣ）上で送信することができる。
【００１９】
キャリアアグリゲーション（ＣＡ）は、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方についてサポートされ、各コンポーネントキャリアは、リリース８／９の計算方式（numerology）を使用するとき周波数領域における最大１１０個のリソースブロックに制限される。
【００２０】
同じｅＮＢから送信される、場合によってはアップリンクとダウンリンクとで異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、ユーザ機器を構成することが可能である。
【００２１】
同じｅＮｏｄｅＢ（基地局）から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。ダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアが多くなるように移動端末を構成することはできない。
【００２２】
一般的なＴＤＤ配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じｅＮｏｄｅＢから送信されるコンポーネントキャリアは、必ずしも同じカバレッジを提供する必要はない。
【００２３】
コンポーネントキャリアは、ＬＴＥリリース８／９互換である。しかしながら、リリース８／９のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム（例：バーリング）を使用することができる。
【００２４】
連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、３００ｋＨｚの倍数である。これは、３ＧＰＰ  ＬＴＥ（リリース８／９）の１００ｋＨｚの周波数ラスターとの互換性を保つと同時に、１５ｋＨｚ間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、ｎ×３００ｋＨｚの間隔あけを容易にすることができる。
【００２５】
複数のキャリアをアグリゲートする影響は、ＭＡＣ層に及ぶのみである。ＭＡＣ層には、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに１つのＨＡＲＱエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大１個である（アップリンクにおけるＳＵ−ＭＩＭＯを使用しない場合）。トランスポートブロックおよびそのＨＡＲＱ再送信（発生時）は、同じコンポーネントキャリアにマッピングする必要がある。
【００２６】
図５および図６は、それぞれ、ダウンリンクおよびアップリンクにおける、キャリアアグリゲーションが設定されているときの第２層の構造を示している。ＭＡＣと第１層との間にトランスポートチャネルが存在し、ＭＡＣとＲＬＣとの間に論理チャネルが存在する。
【００２７】
キャリアアグリゲーション（ＣＡ）が設定されているとき、ユーザ機器はネットワークとの１つのＲＲＣ接続を有するのみである。ＲＲＣ接続の確立／再確立／ハンドオーバー時、１つのサービングセルが、ＮＡＳモビリティ情報（例えばＴＡＩ）を提供し、ＲＲＣ接続の再確立／ハンドオーバー時、１つのサービングセルがセキュリティ入力を提供する。このセルは、プライマリセル（ＰＣｅｌｌ）と称される。ＰＣｅｌｌに対応するキャリアは、ダウンリンクではダウンリンクプライマリコンポーネントキャリア（ＤＬ  ＰＣＣ）であり、アップリンクではアップリンクプライマリコンポーネントキャリア（ＵＬ  ＰＣＣ）である。
【００２８】
ユーザ機器の能力に応じて、セカンダリセル（ＳＣｅｌｌ）を、ＰＣｅｌｌとの組合せにおいてサービングセルのセットを形成するように構成することができる。ＳＣｅｌｌに対応するキャリアは、ダウンリンクではダウンリンクセカンダリコンポーネントキャリア（ＤＬ  ＳＣＣ）であり、アップリンクではアップリンクセカンダリコンポーネントキャリア（ＵＬ  ＳＣＣ）である。
【００２９】
したがって、ユーザ機器に対して設定されるサービングセルのセットは、つねに、１つのＰＣｅｌｌと１つまたは複数のＳＣｅｌｌとからなる。
−  各ＳＣｅｌｌごとに、ダウンリンクリソースに加えてアップリンクリソースのユーザ機器による使用を設定することができる。したがって、設定されるＤＬ  ＳＣＣの数はＵＬ  ＳＣＣの数よりもつねに大きいかまたは等しく、アップリンクリソースのみを使用するようにＳＣｅｌｌを設定することはできない。
−  ユーザ機器の観点からは、各アップリンクリソースは１つのサービングセルにのみ属する。
−  設定することができるサービングセルの数は、ＵＥのアグリゲーション能力によって決まる。
−  ＰＣｅｌｌセルは、ハンドオーバー手順時（すなわちセキュリティキーの変更およびＲＡＣＨ手順時）にのみ変更されうる。
−  ＰＣｅｌｌは、ＰＵＣＣＨの送信に使用される。
−  ＰＣｅｌｌは、ＳＣｅｌｌとは異なり非アクティブ化することができない。
−  ＰＣｅｌｌにおいてレイリーフェージング（ＲＬＦ）が発生すると再確立がトリガーされるが、ＳＣｅｌｌにレイリーフェージング（ＲＬＦ）が発生しても再確立はトリガーされない。
−  非アクセス層（ＮＡＳ）情報はダウンリンクＰＣｅｌｌから取得される。
【００３０】
コンポーネントキャリアの設定および再設定は、ＲＲＣによって行うことができる。アクティブ化および非アクティブ化は、ＭＡＣ制御要素を介して行われる。ＬＴＥ内ハンドオーバー時、ＲＲＣによって、ハンドオーバー先セルで使用するためのＳＣｅｌｌを追加、削除、または再設定することもできる。ＳＣｅｌｌの再設定、追加、および削除は、ＲＲＣによって実行することができる。ＬＴＥ内ハンドオーバー時、さらに、ハンドオーバー先セルにおけるＰＣｅｌｌと一緒に使用するＳＣｅｌｌの追加、削除、または再設定を、ＲＲＣによって実行することができる。新しいＳＣｅｌｌを追加するときには、そのＳＣｅｌｌの必要なすべてのシステム情報を送るために専用のＲＲＣシグナリングが使用され（接続モード時）、ユーザ機器は、ブロードキャストされるシステム情報をＳＣｅｌｌから直接取得する必要がない。
【００３１】
キャリアアグリゲーションを使用するようにユーザ機器が構成されているとき、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアの一対がつねにアクティブである。この対のうちのダウンリンクコンポーネントキャリアは、「ダウンリンクアンカーキャリア」と称されることもある。同じことはアップリンクについてもあてはまる。
【００３２】
キャリアアグリゲーションが設定されているとき、同時に複数のコンポーネントキャリアについてユーザ機器をスケジューリングすることができるが、一度に行うことのできるランダムアクセス手順は最大で１つである。クロスキャリアスケジューリング（cross-carrier scheduling）では、コンポーネントキャリアのＰＤＣＣＨによって別のコンポーネントキャリアのリソースをスケジューリングすることができる。この目的のため、それぞれのＤＣＩフォーマットにコンポーネントキャリア識別フィールド（「ＣＩＦ」と称する）が導入されている。
【００３３】
クロスキャリアスケジューリングが行われていないときには、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアとをリンクすることによって、グラントが適用されるアップリンクコンポーネントキャリアを識別することができる。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアのリンクは、必ずしも１対１である必要はない。言い換えれば、同じアップリンクコンポーネントキャリアに複数のダウンリンクコンポーネントキャリアをリンクすることができる。一方で、１つのダウンリンクコンポーネントキャリアは、１つのアップリンクコンポーネントキャリアのみにリンクすることができる。
【００３４】
ＬＴＥにおけるＲＲＣ状態
【００３５】
以下では、ＬＴＥにおける２つの主たる状態である「ＲＲＣ＿ＩＤＬＥ」および「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ」を中心に説明する。
【００３６】
ＲＲＣ＿ＩＤＬＥでは、無線は有効ではないが、ネットワークによってＩＤが割り当てられて追跡されている。具体的には、ＲＲＣ＿ＩＤＬＥ状態の移動端末は、セルの選択および再選択を実行する（言い換えれば、キャンプオンするセルを決定する）。セルの（再）選択プロセスでは、適用可能な無線アクセス技術（ＲＡＴ）それぞれの適用可能な各周波数の優先順位、無線リンクの品質、およびセルのステータス（すなわちセルが禁止または予約されているか）が考慮される。ＲＲＣ＿ＩＤＬＥ状態の移動端末は、ページングチャネルを監視して着呼を検出し、さらにシステム情報を取得する。システム情報の主たる構成要素は、ネットワーク（Ｅ−ＵＴＲＡＮ）がセルの（再）選択プロセスを制御することのできるパラメータである。ＲＲＣは、ＲＲＣ＿ＩＤＬＥ状態の移動端末に適用される制御シグナリング、すなわちページングおよびシステム情報を指定する。ＲＲＣ＿ＩＤＬＥ状態における移動端末の挙動については、非特許文献３（参照によって本明細書に組み込まれている）の例えば８.４.２節に規定されている。
【００３７】
ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態では、移動端末は、ｅＮｏｄｅＢとのアクティブな無線動作を有する。Ｅ−ＵＴＲＡＮでは、共有データチャネルを介して（ユニキャスト）データを伝送することができるように、移動端末に無線リソースが割り当てられる。この動作をサポートするため、移動端末は、時間および周波数の共有送信リソースの動的な割当てを示すために使用される対応する制御チャネルを監視する。移動端末は、Ｅ−ＵＴＲＡＮが移動端末にとって最適なセルを選択できるように、自身のバッファ状態およびダウンリンクチャネル品質の報告と、隣接セルの測定情報を、ネットワークに提供する。これらの測定報告には、別の周波数や無線アクセス技術（ＲＡＴ）を使用するセルが含まれる。さらに、ユーザ機器はシステム情報を受信し、このシステム情報は、送信チャネルを使用するために要求される情報から主として構成される。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のユーザ機器は、自身のバッテリの寿命を延ばすため、不連続受信（ＤＲＸ）サイクルを使用するように構成することができる。ＲＲＣとは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のユーザ機器の挙動をＥ−ＵＴＲＡＮが制御するためのプロトコルである。
【００３８】
論理チャネルおよびトランスポートチャネル
【００３９】
ＭＡＣ層は、論理チャネルを通じてＲＬＣ層にデータ伝送サービスを提供する。論理チャネルは、ＲＲＣシグナリングなどの制御データを伝える制御論理チャネルか、またはユーザプレーンデータを伝えるトラフィック論理チャネルのいずれかである。ブロードキャスト制御チャネル（ＢＣＣＨ）、ページング制御チャネル（ＰＣＣＨ）、共通制御チャネル（ＣＣＣＨ）、マルチキャスト制御チャネル（ＭＣＣＨ）、および専用制御チャネル（ＤＣＣＨ）は、制御論理チャネルである。専用トラフィックチャネル（ＤＴＣＨ）およびマルチキャストトラフィックチャネル（ＭＴＣＨ）は、トラフィック論理チャネルである。
【００４０】
ＭＡＣ層からのデータは、トランスポートチャネルを通じて物理層と交換される。データは、無線送信方式に応じてトランスポートチャネル内に多重化される。トランスポートチャネルは、次のようにダウンリンクまたはアップリンクとして分類される。ブロードキャストチャネル（ＢＣＨ）、ダウンリンク共有チャネル（ＤＬ−ＳＣＨ）、ページングチャネル（ＰＣＨ）、およびマルチキャストチャネル（ＭＣＨ）は、ダウンリンクトランスポートチャネルであり、アップリンク共有チャネル（ＵＬ−ＳＣＨ）およびランダムアクセスチャネル（ＲＡＣＨ）は、アップリンクトランスポートチャネルである。
【００４１】
ダウンリンクおよびアップリンクそれぞれにおいて、論理チャネルとトランスポートチャネルの間で多重化が行われる。
【００４２】
第１層／第２層（Ｌ１／Ｌ２）制御シグナリング
【００４３】
スケジューリング対象のユーザに、ユーザの割当てステータスと、トランスポートフォーマットと、その他のデータ関連情報（例：ＨＡＲＱ情報、送信電力制御（ＴＰＣ）コマンド）を知らせる目的で、第１層／第２層制御シグナリングがデータと一緒にダウンリンクで送信される。第１層／第２層制御シグナリングは、サブフレーム内にダウンリンクデータと一緒に多重化される（ユーザ割当てがサブフレーム単位で変化しうるものと想定する）。なお、ユーザ割当てをＴＴＩ（送信時間間隔）ベースで実行することもでき、その場合、ＴＴＩ長はサブフレームの倍数であることに留意されたい。ＴＴＩ長は、サービスエリアにおいてすべてのユーザに対して一定とする、ユーザ毎に異なる、あるいはユーザ毎に動的とすることもできる。第１層／第２層制御シグナリングは、一般的にはＴＴＩあたり１回送信するのみでよい。
【００４４】
第１層／第２層制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）で送信される。ＰＤＣＣＨは、ダウンリンク制御情報（ＤＣＩ）としてメッセージを伝え、ダウンリンク制御情報（ＤＣＩ）には、移動端末またはユーザ機器のグループのリソース割当て情報およびその他の制御情報が含まれる。一般的には、いくつかのＰＤＣＣＨを１つのサブフレーム内で送信することができる。
【００４５】
なお、３ＧＰＰ  ＬＴＥでは、アップリンクデータ送信のための割当て（アップリンクスケジューリンググラントまたはアップリンクリソース割当てとも称する）も、ＰＤＣＣＨで送信されることに留意されたい。
【００４６】
スケジューリンググラントに関連して、第１層／第２層制御シグナリングで送られる情報は、次の２つのカテゴリ、すなわち、カテゴリ１の情報を伝える共有制御情報（ＳＣＩ：Shared Control Information）と、カテゴリ２／３の情報を伝えるダウンリンク制御情報（ＤＣＩ：Downlink Control Information）に分けることができる。
【００４７】
カテゴリ１の情報を伝える共有制御情報（ＳＣＩ）
【００４８】
第１層／第２層制御シグナリングの共有制御情報部分は、リソース割当て（指示）に関連する情報を含む。共有制御情報は、一般に以下の情報を含む。
−  リソースが割り当てられるユーザを示すユーザ識別情報。
−  ユーザに割り当てられるリソース（リソースブロック（ＲＢ））を示すリソースブロック（ＲＢ）割当て情報。割り当てられるリソースブロックの数は動的とすることができる。
−  割当ての持続時間（オプション）（複数のサブフレーム（またはＴＴＩ）にわたる割当てが可能である場合）。
【００４９】
これらの情報に加えて、共有制御情報は、他のチャネルの設定およびダウンリンク制御情報（ＤＣＩ）の設定（以下を参照）に応じて、アップリンク送信に対するＡＣＫ／ＮＡＣＫ、アップリンクスケジューリング情報、ＤＣＩに関する情報（例：リソース、変調・符号化方式（ＭＣＳ））などの情報を含むことができる。
【００５０】
カテゴリ２／３の情報を伝えるダウンリンク制御情報（ＤＣＩ）
【００５１】
第１層／第２層制御シグナリングのダウンリンク制御情報の部分は、カテゴリ１の情報によって示されるスケジューリング対象のユーザに送信されるデータの送信フォーマットに関連する情報（カテゴリ２の情報）を含む。さらに、再送信プロトコルとして（ハイブリッド）ＡＲＱを使用する場合、カテゴリ２の情報は、ＨＡＲＱ（カテゴリ３）情報を伝える。ダウンリンク制御情報は、カテゴリ１に従ってスケジューリングされるユーザによって復号されるのみでよい。ダウンリンク制御情報は、一般には以下に関する情報を含む。
−  カテゴリ２の情報：  変調方式、トランスポートブロック（ペイロード）サイズまたは符号化率、ＭＩＭＯ（多入力多出力）に関連する情報など。トランスポートブロック（あるいはペイロードサイズ）または符号化率のいずれかをシグナリングすることができる。いずれの場合も、これらのパラメータは、変調方式情報およびリソース情報（割り当てられたリソースブロックの数）を使用することによって相互に計算することができる。
−  カテゴリ３の情報：  ＨＡＲＱに関連する情報（例えば、ハイブリッドＡＲＱプロセス番号、冗長バージョン、再送信シーケンス番号）
【００５２】
ダウンリンク制御情報は、全体のサイズと、フィールドに含まれる情報とが異なるいくつかのフォーマットの形をとる。ＬＴＥにおいて現在定義されている異なるＤＣＩフォーマットを以下に示し、また非特許文献４（３ＧＰＰのウェブサイトにおいて入手可能であり、参照によって本明細書に組み込まれている）の５.３.３.１節に詳しく記載されている。
【００５３】
フォーマット０：  ＤＣＩフォーマット０は、ＰＵＳＣＨのためのリソースグラントを送信する目的で使用される。
【００５４】
ＤＣＩフォーマットと、ＤＣＩにおいて送信される具体的な情報に関するさらなる詳細については、技術規格、または非特許文献５（参照によって本明細書に組み込まれている）の９.３節を参照されたい。
【００５５】
ダウンリンクデータおよびアップリンクデータの送信
【００５６】
ダウンリンクデータ送信に関して、第１層／第２層制御シグナリングは、ダウンリンクパケットデータ送信と一緒に、個別の物理チャネル（ＰＤＣＣＨ）で送信される。この第１層／第２層制御シグナリングは、一般には以下に関する情報を含む。
−  データが送信される（１つまたは複数の）物理リソース（例えば、ＯＦＤＭの場合のサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合の符号）。移動端末（受信機）は、データが送信されるリソースをこの情報によって識別することができる。
−  ユーザ機器が、第１層／第２層制御シグナリングにおけるキャリア指示フィールド（ＣＩＦ：Carrier Indication Field）を有するように構成されているとき、この情報は、その特定の制御シグナリング情報が対象とするコンポーネントキャリアを識別する。これにより、１つのコンポーネントキャリアを対象とする割当てを別のコンポーネントキャリアで送ることが可能になる（「クロスキャリアスケジューリング」）。クロススケジューリングされる側のキャリアは、例えば、ＰＤＣＣＨが含まれないコンポーネントキャリアとすることができ、すなわち、クロススケジューリングされる側のコンポーネントキャリアは、第１層／第２層制御シグナリングを伝えない。
−  送信に使用されるトランスポートフォーマット。例えば、データのトランスポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（変調・符号化方式）レベル、スペクトル効率、符号化率などが挙げられる。ユーザ機器（受信機）は、復調、デ・レートマッチング（de-rate-matching）、および復号のプロセスを開始する目的で、情報ビットサイズ、変調方式、および符号化率を、この情報（通常はリソース割当て（例えばユーザ機器に割り当てられるリソースブロックの数）と組み合わせる）によって識別することができる。変調方式は明示的にシグナリングすることができる。
−  ハイブリッドＡＲＱ（ＨＡＲＱ）情報：
・  ＨＡＲＱプロセス番号：  ユーザ機器は、データがマッピングされているハイブリッドＡＲＱプロセスを識別することができる。
・  シーケンス番号または新規データインジケータ（ＮＤＩ）：  ユーザ機器は、送信が新しいパケットであるか再送信されたパケットであるかを識別することができる。ＨＡＲＱプロトコルにおいて軟合成が実施される場合、シーケンス番号または新規データインジケータとＨＡＲＱプロセス番号とを組み合わせることにより、復号の前にＰＤＵのための送信の軟合成が可能である。
・  冗長バージョンおよび／またはコンステレーションバージョン：  それぞれ、使用されているハイブリッドＡＲＱ冗長バージョン（デ・レートマッチングに必要である）、および、使用されている変調コンステレーションバージョン（復調に必要である）を、ユーザ機器に知らせる。
−  ユーザ機器の識別情報（ＵＥ  ＩＤ）：  第１層／第２層制御シグナリングの対象であるユーザ機器を知らせる。一般的な実装においては、制御情報が別のユーザ機器に読み取られることを防止する目的で、この情報を使用して第１層／第２層制御シグナリングのＣＲＣをマスクする。
【００５７】
アップリンクパケットデータ送信を可能にするため、送信の詳細をユーザ機器に知らせる目的で、第１層／第２層制御シグナリングがダウンリンク（ＰＤＣＣＨ）で送信される。この第１層／第２層制御シグナリングは、一般には以下に関する情報を含む。
−  ユーザ機器がデータ送信に使用するべき（１つまたは複数の）物理リソース（例えば、ＯＦＤＭの場合のサブキャリアまたはサブキャリアブロック、ＣＤＭＡの場合の符号）。
−  ユーザ機器が、第１層／第２層制御シグナリングにおけるキャリア指示フィールド（ＣＩＦ）を有するように構成されているとき、この情報は、その特定の制御シグナリング情報が対象とするコンポーネントキャリアを識別する。これにより、１つのコンポーネントキャリアを対象とする割当てを別のコンポーネントキャリアで送ることが可能になる。クロススケジューリングされる側のキャリアは、例えば、ＰＤＣＣＨが含まれないコンポーネントキャリアとすることができ、すなわち、クロススケジューリングされる側のコンポーネントキャリアは、第１層／第２層制御シグナリングを伝えない。
−  アップリンクグラントの第１層／第２層制御シグナリングは、アップリンクコンポーネントキャリアにリンクされているダウンリンクコンポーネントキャリアで送られる、または、いくつかのダウンリンクコンポーネントキャリアが同じアップリンクコンポーネントキャリアにリンクされている場合、いくつかのダウンリンクコンポーネントキャリアのうちの１つで送られる。
−  ユーザ機器が送信に使用するべきトランスポートフォーマット。例えば、データのトランスポートブロックサイズ（ペイロードサイズ、情報ビットサイズ）、ＭＣＳ（変調・符号化方式）レベル、スペクトル効率、符号化率などが挙げられる。ユーザ機器（送信機）は、変調、レートマッチング、および符号化のプロセスを開始する目的で、情報ビットサイズ、変調方式、および符号化率を、この情報（通常はリソース割当て（例えばユーザ機器に割り当てられるリソースブロックの数）と組み合わせる）によって取得することができる。場合によっては、変調方式を明示的にシグナリングすることができる。
−  ハイブリッドＡＲＱ情報：
・  ＨＡＲＱプロセス番号：  データの取得先のハイブリッドＡＲＱプロセスをユーザ機器に知らせる。
・  シーケンス番号または新規データインジケータ：  新しいパケットを送信するのか、あるいはパケットを再送信するのかをユーザ機器に知らせる。ＨＡＲＱプロトコルにおいて軟合成が実施される場合、シーケンス番号または新規データインジケータとＨＡＲＱプロセス番号とを組み合わせることにより、復号の前にプロトコルデータユニット（ＰＤＵ）のための送信の軟合成が可能である。
・  冗長バージョンおよび／またはコンステレーションバージョン：  それぞれ、使用するハイブリッドＡＲＱ冗長バージョン（レートマッチングに必要である）、および、使用する変調コンステレーションバージョン（変調に必要である）を、ユーザ機器に知らせる。
−  ユーザ機器識別情報（ＵＥ  ＩＤ）：  データを送信するべきユーザ機器を知らせる。一般的な実装においては、この情報は、制御情報が別のユーザ機器に読み取られることを防止する目的で、この情報を使用して第１層／第２層制御シグナリングのＣＲＣをマスクする。
【００５８】
上に挙げたさまざまな情報をアップリンクデータ送信およびダウンリンクデータ送信において実際に送信するとき、いくつかの可能な方法が存在する。さらには、アップリンクおよびダウンリンクにおいて、第１層／第２層制御情報は、追加の情報を含むこともでき、あるいは、いくつかの情報を省くことができる。例えば以下のとおりである。
−  同期ＨＡＲＱプロトコルの場合、ＨＡＲＱプロセス番号が必要ないことがある（すなわちシグナリングされない）。
−  チェイス合成（Chase Combining）を使用する（冗長バージョンもしくはコンステレーションバージョンまたはその両方がつねに同じである）場合、または、冗長バージョンのシーケンスもしくはコンステレーションバージョンのシーケンスまたはその両方が事前に定義されている場合、冗長バージョンもしくはコンステレーションバージョンまたはその両方が必要ないことがある。
−  電力制御情報を制御シグナリングにさらに含めることができる。
−  ＭＩＭＯに関連する制御情報（例えばプリコーディング情報）を制御シグナリングにさらに含めることができる。
−  複数のコードワードによるＭＩＭＯ送信の場合、複数のコードワードのためのトランスポートフォーマットもしくはＨＡＲＱ情報またはその両方を含めることができる。
【００５９】
ＬＴＥにおいて（物理アップリンク共有チャネル（ＰＵＳＣＨ）を対象として）ＰＤＣＣＨでシグナリングされるアップリンクリソース割当てにおいては、第１層／第２層制御情報にＨＡＲＱプロセス番号が含まれず、なぜならＬＴＥのアップリンクには同期ＨＡＲＱプロトコルが採用されるためである。アップリンク送信に使用されるＨＡＲＱプロセスは、タイミングによって認識される。さらに、冗長バージョン（ＲＶ）情報は、トランスポートフォーマット情報と一緒に符号化され、すなわち冗長バージョン（ＲＶ）情報はトランスポートフォーマット（ＴＦ）フィールドに埋め込まれることに留意されたい。トランスポートフォーマット（ＴＦ）／変調・符号化方式（ＭＣＳ）フィールドは、例えば５ビットのサイズを有し、これは３２個のエントリに対応する。ＴＦ／ＭＣＳテーブルの３個のエントリは、冗長バージョン（ＲＶ）１、ＲＶ２、またはＲＶ３を示すために予約されている。ＭＣＳテーブルの残りのエントリは、ＲＶ０を暗黙的に示す変調・符号化方式（ＭＣＳ）レベル（トランスポートブロックサイズ（ＴＢＳ））をシグナリングするために使用される。ＰＤＣＣＨのＣＲＣフィールドのサイズは１６ビットである。
【００６０】
ＬＴＥにおいてＰＤＣＣＨでシグナリングされるダウンリンク割当て（ＰＤＳＣＨ）においては、冗長バージョン（ＲＶ）は、２ビットのフィールドにおいて個別にシグナリングされる。さらに、変調次数情報がトランスポートフォーマット情報と一緒に符号化される。アップリンクの場合と同様に、５ビットのＭＣＳフィールドがＰＤＣＣＨでシグナリングされる。エントリのうち３個は、明示的な変調次数をシグナリングするために予約されており、トランスポートフォーマット（トランスポートブロック）情報は提供されない。残りの２９個のエントリにおいては、変調次数およびトランスポートブロックサイズの情報がシグナリングされる。
【００６１】
ＬＴＥにおけるアップリンクアクセス方式
【００６２】
アップリンク送信では、カバレッジを最大にするため、ユーザ端末による電力効率の高い送信が必要である。Ｅ−ＵＴＲＡのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのＦＤＭＡとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由として、マルチキャリア信号（ＯＦＤＭＡ）と比較して、ピーク対平均電力比（ＰＡＰＲ）が低く、これに対応して電力増幅器の効率が改善され、カバレッジの向上が見込まれる（与えられる端末ピーク電力に対してデータレートが高い）。各時間間隔において、ＮｏｄｅＢは、ユーザデータを送信するための固有の時間／周波数リソースをユーザに割り当て、これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局（ＮｏｄｅＢ）において対処する。
【００６３】
データを送信するために使用される基本的な物理リソースは、１つの時間間隔（例えば０.５ｍｓのサブフレーム）にわたるサイズＢＷｇｒａｎｔの周波数リソースから構成される（符号化された情報ビットはこのリソースにマッピングされる）。なおサブフレーム（送信時間間隔（ＴＴＩ）とも称する）は、ユーザデータを送信するための最小の時間間隔である。しかしながら、サブフレームを連結することにより、１ＴＴＩよりも長い時間にわたる周波数リソースＢＷｇｒａｎｔをユーザに割り当てることも可能である。
【００６４】
ＬＴＥにおけるアップリンクのスケジューリング方式
【００６５】
アップリンクの方式として、スケジューリング制御式の（すなわちｅＮＢによって制御される）アクセスと、コンテンション（競合）ベースのアクセスの両方を使用することができる。
【００６６】
スケジューリング制御式アクセスの場合、アップリンクデータを送信するための特定の時間長の特定の周波数リソース（すなわち時間／周波数リソース）が、ユーザ機器に割り当てられる。しかしながら、コンテンションベースのアクセス用に、いくらかの時間／周波数リソースを割り当てることができる。コンテンションベースの時間／周波数リソースの範囲内では、ユーザ機器は、最初にスケジューリングされることなく送信することができる。ユーザ機器がコンテンションベースのアクセスを行う１つのシナリオは、例えばランダムアクセスであり、すなわち、ユーザ機器があるセルへの最初のアクセスを行うとき、またはアップリンクリソースを要求するために最初のアクセスを行うときである。
【００６７】
スケジューリング制御式アクセスの場合、ＮｏｄｅＢのスケジューラが、アップリンクデータ送信のための固有の周波数／時間リソースをユーザに割り当てる。具体的には、スケジューラは以下を決定する。
−  送信を許可する（１つまたは複数の）ユーザ機器
−  物理チャネルリソース（周波数）
−  移動端末が送信に使用するべきトランスポートフォーマット（変調・符号化方式（ＭＣＳ））
【００６８】
割当て情報は、第１層／第２層制御チャネルで送られるスケジューリンググラントを介してユーザ機器にシグナリングされる。以下では説明を簡潔にするため、このチャネルをアップリンクグラントチャネルと称する。スケジューリンググラントメッセージには、情報として、周波数帯域のうちユーザ機器による使用を許可する部分と、グラントの有効期間と、これから行うアップリンク送信にユーザ機器が使用しなければならないトランスポートフォーマットとが、少なくとも含まれる。最も短い有効期間は１サブフレームである。グラントメッセージには、選択される方式に応じて追加の情報も含めることができる。アップリンク共有チャネル（ＵＬ−ＳＣＨ）で送信する権利を許可するグラントとしては、「各ユーザ機器に対する」グラントのみが使用される（すなわち「各ユーザ機器における各無線ベアラに対する」グラントは存在しない）。したがってユーザ機器は、割り当てられたリソースを何らかの規則に従って無線ベアラの間で分配する必要がある。トランスポートフォーマットは、ＨＳＵＰＡの場合とは異なり、ユーザ機器側では選択しない。ｅＮＢが、何らかの情報（例えば、報告されたスケジューリング情報およびＱｏＳ情報）に基づいてトランスポートフォーマットを決定し、ユーザ機器は、選択されたトランスポートフォーマットに従わなければならない。ＨＳＵＰＡでは、ＮｏｄｅＢが最大限のアップリンクリソースを割り当てて、ユーザ機器は、それに応じてデータ送信用の実際のトランスポートフォーマットを選択する。
【００６９】
無線リソースのスケジューリングは、サービス品質（ＱｏＳ）を決めるうえで、共有チャネルアクセスネットワークにおいて最も重要な機能であるため、効率的なサービス品質（ＱｏＳ）管理を可能にする目的で、ＬＴＥにおけるアップリンクスケジューリング方式が満たしているべき要件がいくつかある。
−  優先順位の低いサービスのリソース不足を避けるべきである。
−  個々の無線ベアラ／サービスにおいてサービス品質（ＱｏＳ）が明確に区別されるべきである。
−  どの無線ベアラ／サービスのデータが送信されるのかをｅＮＢのスケジューラが識別できるように、アップリンク報告において、きめ細かいバッファ状態報告（例えば、無線ベアラごとの報告、または無線ベアラグループごとの報告）を可能にするべきである。
−  異なるユーザのサービスの間でサービス品質（ＱｏＳ）を明確に区別できるようにするべきである。
−  無線ベアラごとに最小限のビットレートを提供できるようにするべきである。
【００７０】
上にリストした条件から理解できるように、ＬＴＥのスケジューリング方式の１つの重要な側面は、事業者が、自身の総セル容量を、異なるＱｏＳクラスの個々の無線ベアラの間で分配することを制御できるメカニズムを提供することである。無線ベアラのＱｏＳクラスは、前述したようにサービングゲートウェイからｅＮＢにシグナリングされる対応するＳＡＥベアラのＱｏＳプロファイルによって識別される。事業者は、自身の総セル容量のうちの特定の量を、特定のＱｏＳクラスの無線ベアラに関連付けられる総トラフィックに割り当てることができる。クラスに基づくこの方法を採用する主たる目的は、パケットの処理を、パケットが属するＱｏＳクラスに応じて区別できるようにすることである。
【００７１】
アップリンクスケジューリングにおけるバッファ状態報告手順／スケジューリング要求手順
【００７２】
スケジューリングの通常のモードは、動的なスケジューリングであり、ダウンリンク送信リソースを割り当てるダウンリンク割当てメッセージと、アップリンク送信リソースを割り当てるアップリンクグラントメッセージとによる。これらのメッセージが有効であるのは、通常では特定の１つのサブフレームの間である。これらのメッセージは、すでに前述したように、ユーザ機器のＣ−ＲＮＴＩを使用してＰＤＣＣＨで送信される。動的なスケジューリングは、トラフィックがバースト性であり速度が動的であるサービスタイプ（ＴＣＰなど）において効率的である。
【００７３】
動的なスケジューリングに加えて、パーシステントスケジューリング（persistent scheduling）が定義されており、パーシステントスケジューリング方式では、無線リソースを半静的に設定して、１サブフレームより長い期間にわたりユーザ機器に割り当てることができるため、各サブフレームごとにＰＤＣＣＨを通じた特定のダウンリンク割当てメッセージやアップリンクグラントメッセージの必要性が回避される。パーシステントスケジューリングは、データパケットが小さく周期的でありサイズがほぼ一定であるＶｏＩＰなどのサービスに有用である。動的なスケジューリングの場合と比較して、ＰＤＣＣＨのオーバーヘッドが大幅に減少する。
【００７４】
ｅＮｏｄｅＢによるアップリンクリソースの割当て（すなわちアップリンクスケジューリング）を支援する目的で、ユーザ機器からｅＮｏｄｅＢへのバッファ状態報告（ＢＳＲ）が使用される。ｅＮＢのスケジューラは、ダウンリンクの場合、各ユーザ機器に配信されるデータの量を当然ながら認識している。しかしながらアップリンク方向の場合、スケジューリングの決定はｅＮＢにおいて行われるが、データのバッファはユーザ機器内にあるため、ＵＬ−ＳＣＨを通じて送信する必要のあるデータ量を示す目的で、ユーザ機器からｅＮＢにバッファ状態報告（ＢＳＲ）を送らなければならない。
【００７５】
ＬＴＥにおいては、バッファ状態報告のＭＡＣ制御要素（ＢＳＲ）は基本的に２種類あり、ロングＢＳＲ（論理チャネルグループ（ＬＣＧ）のＩＤ  ＃０〜＃３に対応する４つのバッファサイズフィールドを有する）またはショートＢＳＲ（１つの論理チャネルグループ（ＬＣＧ）のＩＤフィールドと、１つの対応するバッファサイズフィールドを有する）である。バッファサイズフィールドは、論理チャネルグループのすべての論理チャネルにわたる利用可能な合計データ量を示し、異なるバッファサイズレベルのインデックスとして符号化されたバイト数で示される（非特許文献６（参照によって本明細書に組み込まれている）の６.１.３.１節も参照）。これに加えて、短縮されたデータを使用するさらなるタイプのバッファ状態報告が存在し、このバッファ状態報告は２バイト長である。
【００７６】
ユーザ機器によってショートＢＳＲまたはロングＢＳＲのどちらが送信されるかは、トランスポートブロックにおける利用可能な送信リソースと、空ではないバッファを有する論理チャネルのグループの数と、ユーザ機器において特定のイベントがトリガーされるかによって決まる。ロングＢＳＲは、４つの論理チャネルグループのデータ量を報告するのに対して、ショートＢＳＲは、最高位の論理チャネルグループのみについて、バッファに格納されているデータ量を示す。
【００７７】
論理チャネルグループのコンセプトを導入する理由として、ユーザ機器に５つ以上の論理チャネルが設定されている場合、個々の論理チャネルそれぞれのバッファ状態を報告するとシグナリングオーバーヘッドが大きくなりすぎる。したがってｅＮＢは、各論理チャネルを論理チャネルグループに割り当てる。好ましくは、ＱｏＳ要件が同じかまたは類似する論理チャネルが同じ論理チャネルグループに割り当てられるべきである。
【００７８】
バッファ状態報告（ＢＳＲ）は、例えば次のイベントの場合にトリガーすることができる。
−  バッファが空ではない論理チャネルよりも高い優先順位を有する論理チャネルのデータが到着するとき
−  いずれかの論理チャネルにおいて、それまでは送信するデータが存在しなかった状態から、データが利用可能となるとき
−  再送信ＢＳＲタイマーが切れるとき
−  周期的なＢＳＲ報告のタイミングになるとき（すなわちｐｅｒｉｏｄｉｃＢＳＲタイマーが切れるとき）
−  ＢＳＲを格納できる余分なスペースがトランスポートブロック内に存在するとき
【００７９】
送信の失敗に対する堅牢性を高める目的で、ＬＴＥにはバッファ状態報告の再送信メカニズムが定義されている。アップリンググラントが再開されたときに、再送信ＢＳＲタイマーが起動または再起動される。再送信ＢＳＲタイマーが切れる前にアップリンググラントが受信されない場合、そのユーザ機器は別のバッファ状態報告をトリガーする。
【００８０】
バッファ状態報告がトリガーされたとき、バッファ状態報告をトランスポートブロック（ＴＢ）に含めるためのアップリンクリソースがユーザ機器に割り当てられていない場合、ユーザ機器は、ＰＵＣＣＨ（物理アップリンク制御チャネル）（設定されている場合）でスケジューリング要求（ＳＲ）を送る。設定されているＰＵＣＣＨに専用スケジューリング要求（Ｄ−ＳＲ）リソースが存在しない場合、ユーザ機器は、バッファ状態報告（ＢＳＲ）情報をｅＮＢに送信するためのＵＬ−ＳＣＨリソースを要求する目的でランダムアクセス手順（ＲＡＣＨ手順）を開始する。ただし周期的なバッファ状態報告（ＢＳＲ）を送信する場合、ユーザ機器はスケジューリング要求（ＳＲ）の送信をトリガーしないことに留意されたい。
【００８１】
さらには、特定のスケジューリングモードにおいてスケジューリング要求（ＳＲ）送信の機能強化が導入されており、送信グラントのための第１層／第２層制御シグナリングのオーバーヘッドを節約する目的で、リソースが所定の周期で永続的に（パーシステントに）割り当てられる（セミパーシステントスケジューリング（ＳＰＳ）と称される）。セミパーシステントスケジューリングの対象として主として考慮されるサービスの一例はＶｏＩＰである。トークスパート（talk-spurt）の間、コーデックにおいて２０ｍｓごとにＶｏＩＰパケットが生成される。したがって、ｅＮｏｄｅＢは、アップリンクリソースまたはダウンリンクリソースを２０ｍｓごとに永続的に（パーシステントに）割り当てることができ、これらのリソースを使用してＶｏＩＰパケットを送信することができる。一般的には、セミパーシステントスケジューリング（ＳＰＳ）は、トラフィック挙動を予想できる（すなわちビットレートが一定であり、パケットの到着タイミングが周期的である）サービスにおいて恩恵がある。アップリンク方向にセミパーシステントスケジューリング（ＳＰＳ）が設定される場合、ｅＮｏｄｅＢは、設定されている特定の論理チャネルについてスケジューリング要求（ＳＲ）のトリガリング／送信をオフにすることができ、すなわち、これら特定の設定されている論理チャネルにデータが到着することによってＢＳＲがトリガーされても、スケジューリング要求（ＳＲ）がトリガーされない。この種類の機能強化の理由として、セミパーシステントに（半永続的に）割り当てられたリソースを使用する論理チャネル（ＶｏＩＰパケットを伝える論理チャネル）のためのスケジューリング要求（ＳＲ）を送ることは、ｅＮＢのスケジューリングにおいて意味がなく、したがって回避すべきである。
【００８２】
バッファ状態報告（ＢＳＲ）（特にバッファ状態報告のトリガー）に関するさらなる詳細については、非特許文献６（参照によって本明細書に組み込まれている）の５.４.５節に説明されている。
【００８３】
論理チャネルの優先順位付け
【００８４】
ユーザ機器は、複数の無線ベアラ間でのアップリンクリソースの共有を管理するアップリンク伝送速度制御機能を有する。以下では、このアップリンク伝送速度制御機能を論理チャネル優先順位付け手順とも称する。論理チャネル優先順位付け（ＬＣＰ）手順は、新しい送信が行われるとき、すなわちトランスポートブロックを生成する必要があるときに、適用される。容量を割り当てるための提案されている１つの方式では、各ベアラが、それぞれの最小限のデータレートに相当する割当てを受け取るまで、優先順位の順序で各ベアラにリソースを割り当て、さらなる容量があれば、それを例えば優先順位の順序でベアラに割り当てる。
【００８５】
論理チャネル優先順位付け（ＬＣＰ）手順についての後からの説明から明らかになるように、ユーザ機器に属する論理チャネル優先順位付け（ＬＣＰ）手順は、ＩＰの世界で周知であるトークンバケットモデルに基づいて実施される。トークンバケットモデルの基本的な機能は以下のとおりである。ある量のデータを送信する権利を表すトークンが、周期的に特定の速度でバケットに追加される。ユーザ機器にリソースが割り当てられると、バケットの中のトークンの数によって表される量までデータを送信することが許可される。ユーザ機器は、データを送信するとき、送信されるデータ量に相当する数のトークンを削除する。バケットが満杯である場合、それ以上のトークンは破棄される。トークンの追加に関して、このプロセスの反復周期はＴＴＩ毎であるものと想定できるが、トークンが１秒ごとに追加されるように、この周期を長くすることも容易である。基本的には、１ｍｓごとにトークンをバケットに追加する代わりに、１秒ごとに１０００個のトークンを追加することもできる。以下では、リリース８において使用されている論理チャネル優先順位付け（ＬＣＰ）手順について説明する。
【００８６】
論理チャネル優先順位付け（ＬＣＰ）手順のさらなる詳細については、非特許文献７（参照によって本明細書に組み込まれている）の５.４.３.１節に説明されている。
【００８７】
ＲＲＣは、アップリンクデータのスケジューリングを、各論理チャネルごとのシグナリングによって制御する。このシグナリングにおいて、ｐｒｉｏｒｉｔｙ（優先順位）は、値が大きいほど、低い優先順位レベルを示す。ｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅは、優先ビットレート（ＰＢＲ：Prioritized Bit Rate）を設定する。ｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎは、バケットサイズ期間（ＢＳＤ：Bucket Size Duration）を設定する。優先ビットレートの背後にある発想は、リソース不足の発生を回避する目的で、（ビットレートが保証されない（非ＧＢＲ）低優先順位のベアラを含めて）ベアラそれぞれに最小限のビットレートをサポートすることである。各ベアラは、少なくとも、優先ビットレート（ＰＢＲ）を達成するための十分なリソースを取得する必要がある。
【００８８】
ユーザ機器は、論理チャネルｊごとに変数Ｂｊを維持する。Ｂｊは、関連する論理チャネルが確立されるときに０に初期化され、ＴＴＩごとに積ＰＢＲ×ＴＴＩ時間長だけインクリメントされていく（ＰＢＲは論理チャネルｊの優先ビットレート）。ただし、Ｂｊの値はバケットサイズを超えることはできず、Ｂｊの値が論理チャネルｊのバケットサイズより大きくなると、Ｂｊの値はバケットサイズに設定される。論理チャネルのバケットサイズは、優先ビットレート（ＰＢＲ）×バケットサイズ期間（ＢＳＤ）に等しく、優先ビットレート（ＰＢＲ）およびバケットサイズ期間（ＢＳＤ）は上位層によって設定される。
【００８９】
ユーザ機器は、新しい送信を実行するとき、以下の論理チャネル優先順位付け手順を実行する。
−  ユーザ機器は、以下のステップで論理チャネルにリソースを割り当てる。
−  ステップ１：  Ｂｊ＞０である論理チャネルすべてに、優先順位の順序の大きい順にリソースを割り当てる。無線ベアラの優先ビットレート（ＰＢＲ）が「無限大」に設定されている場合、ユーザ機器は、その無線ベアラで送信可能な状態のデータすべてに対してリソースを割り当てた後、より低い優先順位の（１つまたは複数の）無線ベアラの優先ビットレート（ＰＢＲ）を満たす。
−  ステップ２：  ユーザ機器は、ステップ１において論理チャネルｊに使われたＭＡＣ  ＳＤＵの合計サイズだけＢｊを減らす。
なおこの時点で、Ｂｊの値が負にもなりうることに留意されたい。
−  ステップ３：  リソースが残っている場合、すべての論理チャネルに、（Ｂｊの値には無関係に）優先順位の順序の厳密な降順でリソースを割り当て、その論理チャネルのデータがなくなる、またはアップリンクグラントが使い果たされる、のいずれかの状態になるまで、続ける。同じ優先順位に設定されている論理チャネルは、同等に割り当てるものとする。
−  さらにユーザ機器は、上のスケジューリング手順時に以下の規則にも従う。
−  ＲＬＣ  ＳＤＵ（または一部分が送信されるＳＤＵあるいは再送信されるＲＬＣ  ＰＤＵ）全体が、残っているリソースに収まる場合、ユーザ機器は、そのＲＬＣ  ＳＤＵ（または一部分が送信されるＳＤＵあるいは再送信されるＲＬＣ  ＰＤＵ）を分割しないべきである。
−  ユーザ機器は、論理チャネルからのＲＬＣ  ＳＤＵを分割する場合、グラントができる限り使用されるようにセグメントのサイズを最大にする。
−  ユーザ機器は、データの送信を最大限に行うべきである。
【００９０】
論理チャネル優先順位付け手順では、ユーザ機器は次の相対的な優先順位を降順に考慮する。
−  Ｃ−ＲＮＴＩのＭＡＣ制御要素またはＵＬ−ＣＣＣＨからのデータ
−  バッファ状態報告（ＢＳＲ）のＭＡＣ制御要素（パディングのために含まれるＢＳＲを除く）
−  電力ヘッドルーム報告（ＰＨＲ）のＭＡＣ制御要素
−  論理チャネルからのデータ（ＵＬ−ＣＣＣＨからのデータを除く）
−  パディングのために含まれるバッファ状態報告（ＢＳＲ）のＭＡＣ制御要素
【００９１】
キャリアアグリゲーション（前のセクションで説明した）の場合、ユーザ機器が１ＴＴＩ中に複数のＭＡＣ  ＰＤＵを送信するように要求されたときには、ステップ１〜３および関連する規則を、各グラントに独立して適用する、またはグラントの容量の合計に適用することができる。さらに、グラントを処理する順序も、ユーザ機器の実装に委ねられる。ユーザ機器が１ＴＴＩ中に複数のＭＡＣ  ＰＤＵを送信するように要求されたときに、どのＭＡＣ  ＰＤＵにＭＡＣ制御要素を含めるかの決定は、ユーザ機器の実装に委ねられる。
【００９２】
アップリンク電力制御
【００９３】
移動通信システムにおけるアップリンク送信電力制御は、重要な目的を持つ。アップリンク送信電力制御は、要求されるサービス品質（ＱｏＳ）が達成されるようにビットあたり十分なエネルギを送信する必要性と、システムの別のユーザとの干渉を最小限にし、かつ移動端末のバッテリ寿命を最大にする必要性との間で、バランスをとる。この目的を達成する中で、電力制御（ＰＣ）の役割は、要求される信号対干渉雑音比（ＳＩＮＲ）を提供すると同時に、隣接セルに引き起こされる干渉を制御するうえで極めて重要となる。アップリンクにおける古典的な電力制御方式の発想では、すべてのユーザが同じ信号対干渉雑音比（ＳＩＮＲ）で受信する（完全な補償（full compensation）として知られている）。３ＧＰＰでは、これに代えて、ＬＴＥにおいて部分電力制御（ＦＰＣ：Fractional Power Control）の使用を採用した。この新しい機能では、経路損失の大きいユーザは低い信号対干渉雑音比（ＳＩＮＲ）要件で動作し、したがって多くの場合、隣接セルに引き起こされる干渉が小さい。
【００９４】
ＬＴＥでは、物理アップリンク共有チャネル（ＰＵＳＣＨ）、物理アップリンク制御チャネル（ＰＵＣＣＨ）、およびサウンディング基準信号（ＳＲＳ）について、詳細な電力制御式が指定されている（非特許文献８の５.１節）。これらのアップリンク信号それぞれの電力制御式は、同じ基本原理に従う。いずれの場合も、電力制御式は、２つの主項、すなわちｅＮｏｄｅＢによってシグナリングされる静的パラメータまたは半静的パラメータから導かれる、開ループの基本動作点と、サブフレームごとに更新される動的オフセット、の合計と考えることができる。
【００９５】
リソースブロックあたりの送信電力を決めるための、開ループの基本動作点は、セル間干渉やセル負荷など複数の要因に依存する。開ループの基本動作点は、さらに２つの成分として、半静的な基本レベルＰ０（セル内のすべてのユーザ機器の共通電力レベル（測定単位：ｄＢｍ）とユーザ機器に固有なオフセットとからなる）と、開ループの経路損失補償の成分とに、分解することができる。リソースブロックあたりの電力の動的オフセットの部分は、さらに２つの成分として、使用される変調・符号化方式（ＭＣＳ）に依存する成分と、明示的な送信電力制御（ＴＰＣ：Transmitter Power Control）コマンドとに、分解することができる。
【００９６】
変調・符号化方式（ＭＣＳ）に依存する成分（ＬＴＥ仕様ではΔＴＦと称し、ＴＦは「トランスポートフォーマット」を表す）は、リソースブロック（ＲＢ）あたりの送信電力を、送信される情報のデータレートに従って適合させることができる。
【００９７】
動的オフセットのもう１つの成分は、ユーザ機器に固有な送信電力制御（ＴＰＣ）コマンドである。このコマンドは、２種類のモード、すなわち、累積ＴＰＣ（accumulative TPC）コマンド（ＰＵＳＣＨ、ＰＵＣＣＨ、およびＳＲＳに対して利用できる）と、絶対ＴＰＣコマンド（ＰＵＳＣＨに対してのみ利用できる）とにおいて、動作することができる。ＰＵＳＣＨに対するこれら２つのモードの間の切替えは、ユーザ機器ごとにＲＲＣシグナリングによって半静的に設定される（すなわちモードを動的に変更することはできない）。累積ＴＰＣコマンドの場合、各ＴＰＣコマンドは、前のレベルを基準としたときの電力ステップをシグナリングする。
【００９８】
電力ヘッドルーム報告
【００９９】
ｅＮｏｄｅＢが複数のユーザ機器に対してアップリンク送信リソースを適切にスケジューリングすることを支援する目的で、ユーザ機器は、利用可能な電力ヘッドルームをｅＮｏｄｅＢに報告できることが重要である。
【０１００】
ｅＮｏｄｅＢは、ユーザ機器が使用することのできる、サブフレームあたりのさらなるアップリンク帯域幅を、電力ヘッドルーム報告を使用して求めることができる。これは、リソースの無駄を回避する目的で、アップリンク送信リソースを使用できないユーザ機器にリソースが割り当てられることを回避する役割を果たす。
【０１０１】
電力ヘッドルーム報告の範囲は、＋４０〜−２３ｄＢである。範囲の負の部分は、ユーザ機器が受信したアップリンクグラントによって、自身が利用できるよりも多くの送信電力が要求される場合に、電力の不足の程度をｅＮｏｄｅＢにシグナリングすることができる。これにより基地局は、次のグラントのサイズを小さくすることができ、送信リソースが解放されて別のユーザ機器に割り当てられる。
【０１０２】
電力ヘッドルーム報告は、ユーザ機器がアップリンク送信グラントを有するサブフレームにおいてのみ送ることができる。報告は、送られるサブフレームに関連する。電力ヘッドルーム報告をトリガーするための複数の基準として、以下が定義されている。
−  前回の電力ヘッドルーム報告以降に、推定される経路損失が大きく変化した
−  前回の電力ヘッドルーム報告以降に、設定されているよりも長い時間が経過した
−  設定されている数よりも多くの閉ループＴＰＣコマンドがユーザ機器によって実施された
【０１０３】
これらのトリガーそれぞれを制御するパラメータは、システムの負荷状況と、スケジューリングアルゴリズムの要件とに応じて、ｅＮｏｄｅＢが設定することができる。より具体的には、ＲＲＣが、２つのタイマーｐｅｒｉｏｄｉｃＰＨＲ−Ｔｉｍｅｒ（電力ヘッドルーム報告の周期タイマー）およびｐｒｏｈｉｂｉｔＰＨＲ−Ｔｉｍｅｒ（電力ヘッドルーム報告の禁止タイマー）を設定し、測定されたダウンリンク経路損失の変化を示すｄｌ−ＰａｔｈｌｏｓｓＣｈａｎｇｅをシグナリングして電力ヘッドルーム報告をトリガーすることによって、電力ヘッドルーム報告を制御する。
【０１０４】
電力ヘッドルーム報告は、ＭＡＣ制御要素として送られる。このＭＡＣ制御要素は１オクテットからなり、上位の２ビットが予約されており、下位の６ビットが、上述した６４ｄＢ値（１ｄＢ間隔）を表す。図７は、このＭＡＣ制御要素の構造を示している。
【０１０５】
サブフレームｉにおけるユーザ機器の有効な電力ヘッドルームＰＨは、次式によって定義される。
【数１】
2020109990.tif 000003
【０１０６】
電力ヘッドルームは、範囲［４０；−２３］ｄＢ（１ｄＢ間隔）の中の最も近い値に丸められる。
【０１０７】
ＰＣＭＡＸは、最大ＵＥ送信電力（送信電力）であり、ＰＣＭＡＸ＿Ｌ〜ＰＣＭＡＸ＿Ｈの所定の範囲内でユーザ機器によって選択される値である。
【数２】
2020109990.tif 000004
式中、ＰＥＭＡＸはネットワークによってシグナリングされる値である。
【０１０８】
ＭＰＲは電力低減値であり、さまざまな変調方式および送信帯域幅に関連付けられるＡＣＬＲ（隣接チャネル漏洩電力比：Adjacent Channel Leakage Power Ratio）を制御するために使用される。
【０１０９】
Ａ・ＭＰＲは、追加最大電力低減である。この値は帯域に固有であり、ネットワークによって設定されるときに適用される。したがってＰＣＭＡＸは、ユーザ機器の実装に固有であり、したがってｅＮＢには認識されていない。
【０１１０】
ΔＴＣに関するさらなる詳細については、非特許文献９（参照によって本明細書に組み込まれている）の６.２.５節に規定されている。
【０１１１】
ＬＴＥの装置間（Ｄ２Ｄ）近傍サービス
【０１１２】
近接性に基づくアプリケーションおよびサービスは、ソーシャル技術の新しいトレンドである。識別される分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。ＬＴＥに近傍サービス（ＰｒｏＳｅ）機能を導入することにより、３ＧＰＰ業界は、この成長の見込まれる市場にサービスを提供することができると同時に、連係してＬＴＥを使用するいくつかの公共安全コミュニティの緊急なニーズに応えることができる。
【０１１３】
装置間（Ｄ２Ｄ）通信は、ＬＴＥリリース１２における技術要素である。装置間（Ｄ２Ｄ）通信技術によって、セルラーネットワークに対するアンダーレイ（下層）としてのＤ２Ｄにおいてスペクトル効率を高めることができる。例えば、セルラーネットワークがＬＴＥである場合、データを伝えるすべての物理チャネルは、Ｄ２ＤシグナリングにおいてＳＣ−ＦＤＭＡを使用する。Ｄ２Ｄ通信では、ユーザ機器（ＵＥ）は、基地局を経由せずに、セルラーリソースを使用する直接的なリンクを通じて互いにデータ信号を送信する。図９は、Ｄ２Ｄ互換の通信システムにおける１つの可能なシナリオを示している。
【０１１４】
ＬＴＥにおけるＤ２Ｄ通信
【０１１５】
「ＬＴＥにおけるＤ２Ｄ通信」は、発見および通信という２つの分野に焦点をあてているが、本発明は、ほとんどが通信部分に関連する。したがって以下では、通信部分の技術背景を中心に説明する。
【０１１６】
装置間（Ｄ２Ｄ）通信は、ＬＴＥ−Ａにおける技術要素である。Ｄ２Ｄ通信では、ユーザ機器は、基地局（ＢＳ）を経由せずに、セルラーリソースを使用して直接的なリンクを通じて互いにデータ信号を送信する。Ｄ２Ｄのユーザは、直接通信するが、基地局の制御下のままである（少なくともｅＮＢのカバレッジ内であるとき）。したがってＤ２Ｄでは、セルラーリソースを再利用することによってシステムの性能を改善することができる。
【０１１７】
Ｄ２Ｄは、アップリンクＬＴＥスペクトル（ＦＤＤの場合）において動作する、またはカバレッジを提供しているセルのアップリンクサブフレーム（ＴＤＤの場合、ただしカバレッジ外のときを除く）において動作するものと想定する。さらに、Ｄ２Ｄ送信／受信では、与えられたキャリアにおける全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、Ｄ２Ｄ信号受信とＬＴＥアップリンク送信とによる全二重を使用しない（すなわちＤ２Ｄ信号受信およびＬＴＥアップリンク送信を同時に行うことはできない）。
【０１１８】
Ｄ２Ｄ通信では、ユーザ機器１が送信の役割であるとき（送信側ユーザ機器）、ユーザ機器１がデータを送り、ユーザ機器２（受信側ユーザ機器）がそれを受信する。ユーザ機器１およびユーザ機器２は、送信の役割と受信の役割を変えることができる。ユーザ機器１からの送信は、１基または複数基のユーザ機器（ユーザ機器２など）によって受信することができる。
【０１１９】
ユーザプレーンのプロトコルに関して、Ｄ２Ｄ通信に関連する合意内容（非特許文献１０の９.２節）を以下に示す。
−  ＰＤＣＰ：
○  １：Ｍ  Ｄ２Ｄブロードキャスト通信データ（すなわちＩＰパケット）は、通常のユーザプレーンデータとして扱うべきである。
○  １：Ｍ  Ｄ２Ｄブロードキャスト通信データには、ＰＤＣＰにおけるヘッダ圧縮／圧縮解除を適用することができる。
・  公共安全に関連するＤ２Ｄブロードキャスト動作では、ＰＤＣＰにおけるヘッダ圧縮にＵ−モードを使用する。
−  ＲＬＣ：
○  １：Ｍ  Ｄ２Ｄブロードキャスト通信にはＲＬＣ  ＵＭを使用する。
○  セグメント化および再構築はＲＬＣ  ＵＭによって第２層においてサポートされる。
○  受信側ユーザ機器は、送信側のピアユーザ機器あたり少なくとも１つのＲＬＣ  ＵＭエンティティを維持する必要がある。
○  最初のＲＬＣ  ＵＭデータユニットを受信する前に受信機のＲＬＣ  ＵＭエンティティを設定する必要はない。
○  現時点では、ユーザプレーンデータを送信するＤ２Ｄ通信においてＲＬＣ  ＡＭまたはＲＬＣ  ＴＭの必要性は認識されていない。
−  ＭＡＣ：
○  １：Ｍ  Ｄ２Ｄブロードキャスト通信ではＨＡＲＱフィードバックを想定しない。
○  受信側ユーザ機器は、受信機のＲＬＣ  ＵＭエンティティを識別する目的で送信元ＩＤを認識する必要がある。
○  ＭＡＣヘッダには、ＭＡＣ層におけるパケットフィルタリングを可能にする第２層（Ｌ２）送信先ＩＤが含まれる。
○  第２層（Ｌ２）送信先ＩＤは、ブロードキャストアドレス、グループキャストアドレス、またはユニキャストアドレスとすることができる。
・  第２層（Ｌ２）グループキャスト／ユニキャスト：  ＭＡＣヘッダにおいて伝えられる第２層（Ｌ２）送信先ＩＤによって、受信されたＲＬＣ  ＵＭ  ＰＤＵを、たとえそれを受信機のＲＬＣエンティティに渡す前であっても破棄することが可能となる。
・  第２層（Ｌ２）ブロードキャスト：  受信側ユーザ機器は、すべての送信機からの受信されたすべてのＲＬＣ  ＰＤＵを処理し、再構築してＩＰパケットを上位層に渡す。
○  ＭＡＣサブヘッダには、（複数の論理チャネルを区別するための）論理チャネルＩＤ（ＬＣＩＤ）が含まれる。
○  Ｄ２Ｄでは、少なくとも多重化／逆多重化、優先順位の処理、およびパディングが有用である。
【０１２０】
リソース割当て
【０１２１】
Ｄ２Ｄ通信におけるリソース割当てについては現在検討が進められており、非特許文献１０（参照によって本明細書に組み込まれている）の９.２.３節に、現時点での形式が記載されている。
【０１２２】
送信側ユーザ機器の観点からは、ユーザ機器はリソース割当ての次の２つのモードで動作することができる。
−  モード１：  直接データ（direct data）および直接制御情報（direct control information）を送信するためにユーザ機器によって使用される正確なリソースを、ｅＮｏｄｅＢまたはリリース１０の中継ノードがスケジューリングする。
−  モード２：  直接データおよび直接制御情報を送信するためのリソースを、ユーザ機器自身がリソースプールから選択する。
【０１２３】
Ｄ２Ｄ通信に対応するユーザ機器は、カバレッジ内の場合にモード１を少なくともサポートする。Ｄ２Ｄ通信に対応するユーザ機器は、少なくともカバレッジ周縁部もしくはカバレッジ外またはその両方の場合にモード２をサポートする。
【０１２４】
カバレッジ内のユーザ機器およびカバレッジ外のユーザ機器は、Ｄ２Ｄ通信を受信するためにリソースプール（時間／周波数）を認識している必要がある。
【０１２５】
すべてのユーザ機器（モード１（「スケジューリング式」）およびモード２（「自律的」））にリソースプール（時間／周波数）が提供され、ユーザ機器はリソースプールの中でスケジューリング割当ての受信を試みる。
【０１２６】
モード１では、ユーザ機器はｅＮｏｄｅＢからの送信リソースを要求する。ｅＮｏｄｅＢは、スケジューリング割当ておよびデータを送信するための送信リソースをスケジューリングする。
−  ユーザ機器は、スケジューリング要求（専用スケジューリング要求（Ｄ−ＳＲ）またはＲＡＣＨ手順）をｅＮｏｄｅＢに送った後にバッファ状態報告（ＢＳＲ）を送り、ｅＮｏｄｅＢは、ユーザ機器がＤ２Ｄ送信を実行しようとしていることと、必要な量のリソースとを、そのバッファ状態報告（ＢＳＲ）に基づいて求めることができる。
−  モード１では、ユーザ機器は、Ｄ２Ｄ通信を送信するためにＲＲＣ接続されている必要がある。
【０１２７】
モード２の場合、ユーザ機器にリソースプール（時間／周波数）が提供され、ユーザ機器は、Ｄ２Ｄ通信を送信するためのリソースをリソースプールから選択する。
【０１２８】
図８は、オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）における送信リソースおよび受信リソースを概略的に示している。ユーザ機器がモード１送信を適用するかモード２送信を適用するかは、ｅＮｏｄｅＢが制御する。ユーザ機器は、Ｄ２Ｄ通信を送信（または受信）することのできるリソースを認識すると、対応するリソースを、対応する送信／受信にのみ使用する。図８の例においては、Ｄ２Ｄサブフレームは、Ｄ２Ｄ信号を受信または送信する目的にのみ使用される。Ｄ２Ｄ装置としてのユーザ機器は、半二重モードで動作するため、任意の時点においてＤ２Ｄ信号の受信または送信のいずれかを行うことができる。同様に、同じ図８において、Ｄ２Ｄサブフレーム以外のサブフレームはＬＴＥ（オーバーレイ）の送信もしくは受信またはその両方に使用することができる。
【０１２９】
Ｄ２Ｄ発見は、自身に関心のある、近傍における他のＤ２Ｄ対応装置を識別する手順／プロセスである。この目的のため、発見されることを望むＤ２Ｄ装置は、何らかの発見信号を（特定のネットワークリソースで）送り、その発見信号に関心のある受信側ユーザ機器が、このような送信側Ｄ２Ｄ装置を認識する。非特許文献１０の８節には、Ｄ２Ｄ発見メカニズムに関する現時点における詳細が記載されている。次の２つのタイプの発見手順が定義されている。
○  タイプ１：  発見信号を送信するためのリソースが、ユーザ機器に固有ではない方式で割り当てられる発見手順
○  タイプ２：  発見信号を送信するためのリソースが、ユーザ機器に固有な方式で割り当てられる発見手順
○  タイプ２Ａ：  発見信号の送信のたびにリソースが割り当てられる
○  タイプ２Ｂ：  発見信号を送信するためのリソースがセミパーシステントに（半永続的に）割り当てられる
【０１３０】
Ｄ２Ｄリソースを割り当てるためのスケジューリング方式に関して、現在、Ｄ２Ｄに関連するスケジューリング要求（ＳＲ）／バッファ状態報告（ＢＳＲ）のシグナリングをＬＴＥ−Ａシステムにどのように組み込むか、すなわち、ＬＴＥのバッファ状態報告（ＢＳＲ）／スケジューリング要求（ＳＲ）のメカニズム、およびリソース（例えばＰＵＣＣＨでの専用スケジューリング要求（Ｄ−ＳＲ）やＰＲＡＣＨリソース）を、Ｄ２Ｄ通信の目的に再利用するか）に焦点をあてて検討されている。実際に考慮されている方式によると、ｅＮｏｄｅＢは、スケジューリング手順を実行するため、Ｄ２ＤサブフレームまたはＤ２Ｄ領域内に、専用リソースまたはコンテンションベースのリソースを設定する。言い換えれば、スケジューリング要求（ＳＲ）もしくはバッファ状態報告（ＢＳＲ）またはその両方に関連するＤ２Ｄ送信は、Ｄ２Ｄ送信に専用のサブフレームの専用リソースで、ｅＮｏｄｅＢに送られる。したがってユーザ機器は、スケジューリング手順を実行するためのメッセージ（すなわちスケジューリング要求（ＳＲ）やバッファ状態報告（ＢＳＲ））を含めて、Ｄ２Ｄに関連するすべての送信用に、Ｄ２Ｄサブフレーム／領域内のリソースのみを使用する。
【０１３１】
この方法の欠点として、Ｄ２ＤサブフレームまたはＤ２Ｄ領域内のリソース（専用スケジューリング要求（Ｄ−ＳＲ）のためのＰＵＣＣＨリソースや、コンテンションベースのスケジューリング要求（ＳＲ）のためのＲＡＣＨリソース）をｅＮｏｄｅＢがサポートしなければならないとき、無線リソース管理が極めて複雑になりうる。
【０１３２】
結果として、これらのリソースをすべてのＤ２Ｄ対応ユーザ機器にシグナリングする必要もあり、また、これらのリソースをＤ２Ｄデータ／発見メッセージの送信用に使用することはできず、これによりデータ送信の性能が低下する。さらには、Ｄ２Ｄサブフレーム内に新規のＰＵＣＣＨリソースを設定する場合、ＬＴＥの標準規格（ＲＡＮ４）に対するさらなる変更も必要である。
【０１３３】
さらには、ｅＮｏｄｅＢは、Ｄ２Ｄユーザ機器からのＤ−ＳＲ／ＰＲＡＣＨ／ＢＳＲを受信する目的で、Ｄ２Ｄリソースの監視もしくは受信またはその両方を行うことが要求される。したがってこの解決策は、ｅＮｏｄｅＢの過大な負荷につながる。
【先行技術文献】
【非特許文献】
【０１３４】
【非特許文献１】3GPP, TR 25.913 (“Requirements for Evolved UTRA and Evolved UTRAN”
【非特許文献２】3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)”, version 8.9.0 or 9.0.0, section 6.2
【非特許文献３】TS 25.912
【非特許文献４】3GPP TS 36.212, “Multiplexing and channel coding”
【非特許文献５】LTE - The UMTS Long Term Evolution - From Theory to Practice, Edited by Stefania Sesia, Issam Toufik, Matthew Baker,
【非特許文献６】3GPP TS 36.321 v 10.5.0
【非特許文献７】3GPP TS 36.321 V8
【非特許文献８】TS36.213
【非特許文献９】3GPP TS TS36.101, Vers. 12.0.0
【非特許文献１０】3GPP TS 36.843 vers. 12.0.0
【非特許文献１１】TS36.321 version 11.2.0
【発明の概要】
【発明が解決しようとする課題】
【０１３５】
Ｄ２Ｄ通信をＬＴＥシステムに組み込む目的で、ＬＴＥシステムのいくつかの側面（データ通信の手順やスペクトルなど）を引き継ぐ。一例として、アップリンク通信においては、ＬＴＥシステムのアップリンクスペクトルを装置間通信にも使用する。
【０１３６】
本発明の目的は、現在のシステムに対する必要な変更ができる限り少なくなるように、装置間（Ｄ２Ｄ）通信をＬＴＥシステムに組み込むことのできる方法およびシステムを開発することである。より具体的には、本発明は、装置間通信におけるスケジューリング要求手順およびバッファ状態報告（ＢＳＲ）手順をＬＴＥシステムに組み込むシステムおよび方法を開発することを目的とする。
【課題を解決するための手段】
【０１３７】
この目的は、独立請求項の主題によって解決される。有利な実施形態は、従属請求項の主題である。
【０１３８】
本発明の主たる一態様は、通信装置に割り当てた上り共有チャネル（ＵＬ−ＳＣＨ）リソース上で、直接リンク・バッファ状態報告を送信し、前記直接リンク・バッファ状態報告は、前記通信装置が機器間（Ｄ２Ｄ）通信の受信側端末に送信するＤ２Ｄデータの量に関する情報を基地局装置に提供するためのメッセージである、送信部と、前記Ｄ２Ｄ通信のためのＤ２ＤリソースをスケジュールするためのＤ２Ｄグラントを受信する受信部と、を具備し、リソース割当における優先順位において、前記直接リンク・バッファ状態報告は、前記通信装置が前記基地局装置へ送信する上りデータの量に関する情報を前記基地局に提供するためのメッセージであるアップリンク・バッファ状態報告よりも低く、ＵＬ−ＣＣＣＨからのデータを除く論理チャネルからのデータよりも高い、端末装置である。
【０１３９】
本発明の第１の態様によると、データを直接リンクデータチャネル（direct link data channel）を通じて受信側ユーザ機器に送信する必要のあるＤ２Ｄ対応の送信側ユーザ機器は、このデータを送信するためのリソースが割り当てられるようにｅＮｏｄｅＢのサービスを使用する。これを目的として、ユーザ機器は、Ｄ２Ｄデータ送信に専用のサブフレームのリソースを使用せずに、ｅＮｏｄｅＢを経由する標準的なアップリンク通信に専用のサブフレームのリソースを使用して、スケジューリング情報をｅＮＢに送る。受信したスケジューリング要求が、直接リンクチャネルを通じてデータを送信するためのリソースを割り当てる要求なのか、ｅＮＢを通じてデータを送信するためのリソースを割り当てる要求なのかをｅＮＢが区別できるようにする目的で、ユーザ機器は、スケジューリング情報と一緒に、そのスケジューリング情報に関連する識別情報も送ることができる。
【０１４０】
ユーザ機器は、アップリンクデータチャネル（例えばＰＵＳＣＨ）の、ＬＴＥのデータ伝送およびスケジューリングメッセージの送信に使用されるフレームにおいて、バッファ状態報告をｅＮｏｄｅＢに送ることが有利である。
【０１４１】
本発明のさらなる態様によると、スケジューリング情報を送るためにユーザ機器に利用可能なリソースが存在しない場合、ユーザ機器は、スケジューリング情報を送る前に、そのスケジューリング情報をｅＮＢに送るためのアップリンクデータチャネルのリソースの割当てを要求するスケジューリング要求を、ｅＮＢに送ることができる。このスケジューリング要求の送信は、２つのイベントによってトリガーすることができる。第１のトリガー条件は、送信側ユーザ機器の送信バッファ内に、送信するべきデータが存在することである。第２のトリガー条件は、送信バッファ内のデータが、前回のスケジューリング情報の送信以降に、所定の量だけ変化することである。送信バッファ内のデータは、前回のスケジューリング情報がトリガーされた、または送られた時点における送信バッファ内のデータ量を基準として所定の量だけ増大することが有利である。さらなる有利な実装形態によると、この第２のトリガー条件は、代替形態では、送信バッファ内のデータが所定のしきい値を超えた場合に、満たされたものとみなすことができる。
【０１４２】
上述した第１の態様によると、送信側ユーザ機器であって、通信システムにおいてデータを直接リンク接続を通じて受信側ユーザ機器に送信するようにされている、送信側ユーザ機器、を提供する。送信側ユーザ機器は、通信システムにおいてリソースを要求するようにさらにされており、さらに、データを直接リンク接続を通じて受信側ユーザ機器に送信するためのリソースの割当てのための直接リンクスケジューリング情報（direct link scheduling information）を基地局に送信するように構成されている送信ユニット、を備えている。直接リンクスケジューリング情報は、データを基地局に送信するためのアップリンクデータチャネルで基地局に送信される。
【０１４３】
これに加えて、またはこれに代えて、さらなる発展形態によると、送信側ユーザ機器において、直接リンクスケジューリング情報は、ＭＡＣ制御要素において送信される。送信ユニットは、直接リンクスケジューリング情報に関連する識別番号を、アップリンクデータチャネルで基地局に送信するようにさらにされており、識別番号は、ＭＡＣ制御要素を識別する。さらなる発展形態によると、直接リンクスケジューリング情報のＭＡＣ制御要素は、ＬＴＥ論理チャネルのデータおよび／またはＬＴＥトラフィックのためのアップリンクスケジューリング情報をさらに含むデータユニット、に格納されることが有利である。このデータユニットは、Ｄ２Ｄ  ＭＡＣ  ＣＥと、ＬＴＥデータパケット（ＭＡＣ  ＳＤＵ）および／またはＬＴＥ  ＭＡＣ  ＣＥとを含むＬＴＥ  ＭＡＣプロトコルデータユニット、とすることができる。
【０１４４】
これに加えて、またはこれに代えて、送信側ユーザ機器は、直接リンク接続を通じて受信側ユーザ機器に送信されるデータを一時的に格納するようにされている送信バッファ、をさらに備えており、直接リンクスケジューリング情報は、送信バッファ内に格納されているデータに関連する値を含む。
【０１４５】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報は、アップリンクデータチャネルで基地局に送信されるアップリンクスケジューリング情報よりも高い優先順位を有し、アップリンクスケジューリング情報は、基地局を通じてのアップリンクデータ送信のためのリソース割当てに使用される。直接リンクスケジューリング情報およびアップリンクスケジューリング情報は、ＬＴＥ送信におけるＭＡＣプロトコルデータユニットにおいて送信されることが有利である。
【０１４６】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報において、送信バッファ内に格納されているデータに関連する値は、直接リンク接続を通じて受信側ユーザ機器に送信されるビット／バイトの合計量とすることができる。
【０１４７】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報は、直接リンク接続を通じて送信されるデータのタイプに関する情報、をさらに含む。
【０１４８】
上述した本発明のさらなる態様によると、送信側ユーザ機器は、前述した要素に加えて、または代えて、第１のトリガー条件および第２のトリガー条件を格納するようにされているメモリ、をさらに備えていることができる。第１のトリガー条件は、送信バッファ内に新しいデータが到着することを要求し、この新しいデータは、直接リンク接続を通じて受信側ユーザ機器に送信される予定である。第２のトリガー条件は、送信バッファ内のデータに関連する値が、所定の値だけ変化することを要求する。送信側ユーザ機器は、処理ユニットをさらに含み、この処理ユニットは、第１のトリガー条件が満たされているかを判定し、第１のトリガー条件が満たされている場合、第２のトリガー条件が満たされているかを判定するようにされている。送信ユニットは、第２のトリガー条件が満たされているものと処理ユニットが判定した場合に、直接リンクスケジューリング情報を基地局に送信するためのアップリンクリソースの割当てを要求する直接リンクスケジューリング要求、を送信するようにさらにされている。
【０１４９】
送信バッファ内のデータの量は、前回のスケジューリング情報が基地局に送られた時点における送信バッファ内のデータ量を基準として所定の量だけ変化することが有利である。これに代えて、送信バッファ内のデータ量が特定のしきい値を超えた場合、送信バッファ内のデータ量が変化したものとみなすことができる。
【０１５０】
これに加えて、またはこれに代えて、直接リンクスケジューリング要求は、アップリンク制御チャネルで、またはランダムアクセスチャネルで、基地局に送信される。さらには、送信バッファ内のデータに関連する値は、送信バッファ内のデータの量とすることができ、送信バッファ内のデータが、直接リンクスケジューリング情報の前回の送信以降に所定の値だけ変化した場合に、直接リンクスケジューリング情報の送信がトリガーされる。
【０１５１】
上述した本発明のさらなる態様によると、通信システムにおいて送信側ユーザ機器によってリソースを要求する通信方法であって、データが送信側ユーザ機器から直接リンクを通じて受信側ユーザ機器に送信される、方法、を提供する。本方法は、データを直接リンク接続を通じて受信側ユーザ機器に送信するためのリソースの割当てのための直接リンクスケジューリング情報を、送信側ユーザ機器において基地局に送信するステップ、を含む。直接リンクスケジューリング情報は、データを基地局に送信するためのアップリンクデータチャネルで、基地局に送信することができる。
【０１５２】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報は、ＭＡＣ制御要素において送信され、直接リンクスケジューリング情報を送信するステップは、直接リンクスケジューリング情報に関連する識別番号を、アップリンクデータチャネルで基地局に送信するステップであって、識別番号がＭＡＣ制御要素を識別する、ステップ、を含む。さらなる発展形態によると、直接リンクスケジューリング情報のＭＡＣ制御要素は、ＬＴＥ論理チャネルのデータおよび／またはＬＴＥトラフィックのためのアップリンクスケジューリング情報をさらに含みうるＭＡＣデータユニット、に格納されることが有利である。このデータユニットは、ＬＴＥ  ＭＡＣプロトコルデータユニットとすることができる。
【０１５３】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報は、送信側ユーザ機器における送信バッファ内に格納されているデータに関連する値、を含み、送信バッファは、直接リンクを通じて受信側ユーザ機器に送信されるデータを一時的に格納するようにされている。
【０１５４】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報は、アップリンクデータチャネルで基地局に送信されるアップリンクスケジューリング情報よりも高い優先順位を有し、アップリンクスケジューリング情報は、基地局を通じてのアップリンクデータ送信のためのリソース割当てに使用される。
【０１５５】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報において、送信バッファ内に格納されているデータに関連する値は、直接リンク接続を通じて受信側ユーザ機器に送信されるビットの合計量である。
【０１５６】
これに加えて、またはこれに代えて、直接リンクスケジューリング情報は、直接リンク接続を通じて送信されるデータのタイプに関する情報、をさらに含む。
【０１５７】
さらなる態様によると、上述した本方法は、第１のトリガー条件および第２のトリガー条件を定義するステップ、を含む。第１のトリガー条件は、送信バッファ内に新しいデータが到着することを要求し、この新しいデータは、直接リンク接続を通じて受信側ユーザ機器に送信される予定である。第２のトリガー条件は、送信バッファ内のデータに関連する値が所定の値だけ変化することを要求する。本方法は、第１のトリガー条件が満たされているかを送信側ユーザ機器において判定するステップと、第１のトリガー条件が満たされている場合、第２のトリガー条件が満たされているかを、送信側ユーザ機器によって判定するステップと、をさらに含む。送信側ユーザ機器において、処理ユニットが、第２のトリガー条件が満たされているものと判定した場合に、直接リンクスケジューリング情報を基地局に送信するためのアップリンクリソースの割当てを要求する直接リンクスケジューリング要求、を送信する。
【０１５８】
これに加えて、またはこれに代えて、直接リンクスケジューリング要求は、アップリンク制御チャネルで、またはランダムアクセスチャネルで、基地局に送信される。
【０１５９】
さらには、送信バッファ内のデータに関連する値は、送信バッファ内のデータの量とすることができ、送信バッファ内のデータが、直接リンクスケジューリング情報の前回の送信以降に所定の値だけ変化した場合に、直接リンクスケジューリング情報の送信がトリガーされる。
【０１６０】
上の本方法による、送信側ユーザ機器によって直接リンク接続を通じて送信されるデータは、基地局をバイパスして受信側ユーザ機器に直接送られることが有利である。
【０１６１】
上の送信ユニットおよび方法では、直接リンク通信を通じてのデータ送信に専用のリソースで、データを受信側ユーザ機器に送信することができ、かつ、基地局へのアップリンクデータ送信に専用のリソースで、データを基地局を通じて送信することができ、これは有利である。
【０１６２】
以下では、本発明について、添付の図面を参照しながらさらに詳しく説明する。図面において類似または対応する細部には、同じ参照番号を付してある。
【図面の簡単な説明】
【０１６３】
【図１】３ＧＰＰ  ＬＴＥシステムの例示的なアーキテクチャを示している。
【図２】３ＧＰＰ  ＬＴＥのＥ−ＵＴＲＡＮアーキテクチャ全体の例示的な概要を示している。
【図３】３ＧＰＰ  ＬＴＥ（リリース８／９）に定義されているダウンリンクコンポーネントキャリアの例示的サブフレーム境界の図である。
【図４】３ＧＰＰ  ＬＴＥ（リリース８／９）に定義されているダウンリンクスロットの例示的ダウンリンクリソースグリッドの図である。
【図５】ダウンリンクのキャリアアグリゲーションが有効になっている状態における３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）の第２層構造を示している。
【図６】ダウンリンクのキャリアアグリゲーションが有効になっている状態における３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）の第２層構造を示している。
【図７】ＭＡＣ制御要素の構造を示している。
【図８】Ｄ２Ｄサブフレームの中の、オーバーレイ（ＬＴＥ）およびアンダーレイ（Ｄ２Ｄ）における送信リソースおよび受信リソースを示している概略図である。
【図９】Ｄ２Ｄ対応ユーザ機器を含むシステムを示している概略図である。
【図１０】本発明の第１の実施形態による、スケジューリングを目的として送信側ユーザ機器（ＵＥ１）と基地局（ｅＮＢ）との間で交換されるメッセージと、送信側ユーザ機器（ＵＥ１）と受信側ユーザ機器（ＵＥ２）との間のデータ交換とを示している概略図である。
【図１１】本発明によるスケジューリング方法およびシステムの一実装形態による、ＭＡＣプロトコルデータユニット（ＰＤＵ）の構成を示している。
【図１２】本発明の第２の実施形態による、スケジューリングを目的として送信側ユーザ機器（ＵＥ１）と基地局（ｅＮＢ）との間で交換されるメッセージと、送信側ユーザ機器（ＵＥ１）と受信側ユーザ機器（ＵＥ２）との間のデータ交換とを示している概略図である。
【図１３】本発明の第２の実施形態による、スケジューリングを目的として送信側ユーザ機器（ＵＥ１）と基地局（ｅＮＢ）との間で交換されるメッセージと、送信側ユーザ機器（ＵＥ１）と受信側ユーザ機器（ＵＥ２）との間のデータ交換とを示している流れ図である。
【図１４】Ｄ２Ｄ発見信号の受信を記述した流れ図である。
【図１５】隣接セルにおける発見手順を示している概略図である。
【発明を実施するための形態】
【０１６４】
以下の段落では、本発明のさまざまな実施形態について説明する。例示のみを目的として、ほとんどの実施形態は、上の背景技術のセクションにおいて一部を説明した３ＧＰＰ  ＬＴＥ（リリース８／９）およびＬＴＥ−Ａ（リリース１０／１１／１２）移動通信システムによる無線アクセス方式に関連して概説してある。本発明は、例えば、上の背景技術のセクションにおいて説明した３ＧＰＰ  ＬＴＥ−Ａ（リリース１０／１１／１２）通信システムなどの移動通信システムにおいて有利に使用することができるが、本発明はこの特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。
【０１６５】
請求項および本明細書において使用されている「直接リンク」という用語は、ネットワークが関与することなくデータを直接交換することを可能にする、２基のＤ２Ｄユーザ機器の間の通信リンク（通信チャネル）として理解されたい。言い換えれば、通信チャネルは、データを直接交換するのに十分に近い、通信システム内の２基のユーザ機器の間に、ｅＮｏｄｅＢ（基地局）をバイパスして確立される。この用語は、ｅＮｏｄｅＢによって管理されるユーザ機器間のデータトラフィックを意味する「ＬＴＥリンク」または「ＬＴＥ（アップリンク）トラフィック」と対照される語として使用されている。
【０１６６】
請求項および本明細書において使用されている「送信側ユーザ機器」という用語は、データを送信および受信することのできるモバイルデバイスとして理解されたい。形容詞である「送信側」は、一時的な動作を明確に示すことを目的としているにすぎない。この用語は、データを受信する動作を一時的に実行するモバイルデバイスを意味する「受信側ユーザ機器」と対照される語として使用されている。
【０１６７】
請求項および本明細書において使用されている「新しいデータ」という語は、送信バッファに到着して格納される（それまで送信バッファ内に存在していなかった）データとして理解されたい。このデータ（データパケット）は、上位層（例えばＩＰ層）から受け取られ、送信バッファの中に入れられる。この語は、「古いデータ」（そのデータが受信側において正しく受信されたことが送信プロトコルによって確認されない限り送信バッファ内に保持されるデータを意味する）と対照される語として使用されている。
【０１６８】
請求項および本明細書において、データおよび送信バッファに関連して使用されている「到着する」という語は、ユーザ機器によって送信される予定のデータが、送信できるように対応する論理チャネルの送信バッファに「入る」、「入れられる」、または「一時的に格納される」こととして理解されたい。
【０１６９】
以下では、本発明のいくつかの実施形態について詳しく説明する。以下の説明は、本発明を制限するものではなく、本発明を深く理解するための本発明の実施形態の単なる例であるものとして理解されたい。当業者には、請求項に記載されている本発明の一般的な原理を、さまざまなシナリオに、本明細書に明示的に説明されていない方法で適用できることが認識されるであろう。したがって、さまざまな実施形態を説明する目的で想定される以下のシナリオは、本発明をそのようなシナリオに制限するものではない。
【０１７０】
本発明は、主として、ＬＴＥシステムにおける装置間（Ｄ２Ｄ）通信におけるスケジューリング手順を対象としている。Ｄ２Ｄ対応ユーザ機器は、リソースの割当てのための２つのモードで動作することができる。第１の動作モード（モード１）によると、データを直接リンクチャネルを通じて受信側ユーザ機器に送信するために送信側ユーザ機器によって使用される正確なリソースを、ｅＮｏｄｅＢがスケジューリングする。具体的には、送信側ユーザ機器が、リソースの割当ての要求をｅＮｏｄｅＢに送り、ｅＮｏｄｅＢが、データを受信側ユーザ機器に直接送信するために送信側ユーザ機器によって必要とされる正確なリソースを、その割当ての要求に基づいてスケジューリングする（スケジューリング式動作モード）。
【０１７１】
第２の動作モード（モード２）は、コンテンション（競合）ベースの方法である。この方法によると、各ユーザ機器に、Ｄ２Ｄ通信に使用される一連のＤ２Ｄ時間／周波数リソース（リソースプールとも称する）が提供される。送信側ユーザ機器は、データおよび制御情報を直接リンク通信チャネルを通じて（１基または複数基の）受信側ユーザ機器に直接送信するためのリソースを、リソースプールから自律的に選択することができる（自律的動作モード）。
【０１７２】
スケジューリング式動作モード（モード１）においては、スケジューリング情報がアップリンクデータチャネルでｅＮｏｄｅＢに送信される。スケジューリング情報は、ＰＵＳＣＨ（物理アップリンク共有制御チャネル）でｅＮｏｄｅＢに送られるＭＡＣ  ＢＳＲ制御要素の中のバッファ状態報告とすることができる。
【０１７３】
本発明の第１の実施形態について、図１０に関連して説明する。図１０は、スケジューリングを目的として送信側ユーザ機器（ＵＥ１）と基地局（ｅＮＢ）との間で交換されるメッセージと、送信側ユーザ機器（ＵＥ１）と受信側ユーザ機器（ＵＥ２）との間のデータ交換とを示している。送信側ユーザ機器（ＵＥ１）は、バッファ状態情報をＬＴＥアップリンクデータチャネル（ＰＵＳＣＨ）を通じてｅＮｏｄｅＢに送信することによってリソースを要求し、データを直接リンク通信チャネルを通じて受信側ユーザ機器に送信する。バッファ状態情報は、Ｄ２Ｄデータ送信（すなわち直接リンク（ＰＣ５インタフェースとも称する）を通じて送られるＤ２Ｄベアラのデータ）に関連する場合でも、Ｄ２Ｄサブフレーム（すなわち時間／周波数リソース）ではなく、ＬＴＥアップリンク時間／周波数リソースにおいて送信される。具体的には、ｅＮＢは、バッファ状態報告（ＢＳＲ）を受信すると、送信側ユーザ機器（ＵＥ１）がデータを受信側ユーザ機器（ＵＥ２）に送信できるように、Ｄ２Ｄデータ通信用に予約されている時間／周波数リソース（例えば直接リンクチャネル）からリソースを割り当てる。なお、Ｄ２Ｄデータ通信のためのリソース割当て（すなわちＤ２Ｄ送信リソースを割り当てるグラント）は、ＬＴＥのアップリンクグラントと比較して異なっていてもよいことに留意されたい。例えば、Ｄ２Ｄリソースは、１ＴＴＩのみではなく、より長い時間枠にわたり割り当てることができる。一般的には、Ｄ２Ｄリソース割当てグラントには、新規のダウンリンク制御フォーマット（ＤＣＩ）が使用されるものと予測される。さらに、新規のＲＮＴＩ（すなわちＬＴＥのアップリンクグラントにおいて使用されるＣ−ＲＮＴＩとは異なるＤ２Ｄ  ＲＮＴＩ）によって、ＤＣＩをスクランブルすることもできる。割り当てられたリソースが、すべてのデータを受信側ユーザ機器（ＵＥ２）に送信するのに十分ではない場合、ｅＮＢは、送信側ユーザ機器（ＵＥ１）によってデータが完全に受信側ユーザ機器（ＵＥ２）に送信されるまで、直接リンクチャネルのリソースを引き続き割り当てる。言い換えれば、送信側ユーザ機器にいったんリソースが割り当てられると、送信側ユーザ機器（ＵＥ１）と受信側ユーザ機器（ＵＥ２）は、ネットワークが関与せずに（すなわちネットワークをバイパスして）互いに通信することができ、このとき２基の移動局の間に直接的な通信チャネルが存在する。したがってデータは、最初にアップリンクリソースを使用して（例えばＰＵＳＣＨで）ｅＮｏｄｅＢに送られた後にｅＮｏｄｅＢによってＬＴＥコアネットワークを介してユーザ機器に送られるということがない。
【０１７４】
図１０に示した線図において理解できるように、スケジューリング要求手順は、通常のＬＴＥトラフィックとみなすことができ、この場合、送信側ユーザ機器（ＵＥ１）は、自身の送信用のデータバッファ（図示していない）に格納されているデータ（すなわちＤ２Ｄベアラ用に格納されているデータ）を送信するためのリソースの割当てを求める目的で、ｅＮｏｄｅＢに連絡する。その後、データを送信するためのＤ２Ｄ時間／周波数リソースをｅＮｏｄｅＢが割り当てると、ユーザ機器は、そのＤ２Ｄリソース（直接リンクデータチャネルとも称される）でのデータ送信を開始する。この時点以降、送信側ユーザ機器（ＵＥ１）と受信側ユーザ機器（ＵＥ２）との間の通信は、ｅＮｏｄｅＢの介入なしで（すなわちｅＮｏｄｅＢをバイパスして）行われる。
【０１７５】
これに代えて、またはこれに加えて、スケジューリング要求を、ｅＮＢによって割り当てられるＰＵＣＣＨのリソースを通じて（専用スケジューリング要求（Ｄ−ＳＲ）とも称される）、またはＲＡＣＨ手順を使用することによって、送信することができる。以下では、異なる想定が明記されていない限り、スケジューリング要求がトリガーされたとき、そのスケジューリング要求の送信用に、このようなＰＵＣＣＨのリソース（一般にはｅＮＢによって周期的に割り当てられる）がただちにユーザ機器に利用可能であるものと想定する。しかしながら、本発明は、代わりにＲＡＣＨ手順を使用するときにも適用することができる。専用スケジューリング要求は、通常では１ビット長であり、対応する周期的なＰＵＣＣＨリソースによってスケジューリング要求を送信できるが、バッファ状態報告や送信バッファの実際のデータなど、さらなるデータを送信するには十分ではない。背景技術のセクションで説明したように、ＬＴＥでは、バッファ状態報告がトリガーされたとき、そのバッファ状態報告を送信するために利用可能なＰＵＳＣＨリソースが存在しない場合、スケジューリング要求がトリガーされる。言い換えれば、スケジューリング要求の目的は、ユーザ機器がバッファ状態報告を送信できるようにＰＵＳＣＨリソースの割当てをｅＮＢに求めることであり、ｅＮＢは、このバッファ状態報告によって、アップリンクデータを送信するのに十分なリソースを割り当てることが可能となる。
【０１７６】
本発明の一実施形態によると、Ｄ２Ｄ対応の送信側ユーザ機器は、Ｄ２Ｄベアラのためのバッファ状態報告がトリガーされたとき（例えばＤ２Ｄベアラ用の新しいデータが到着したとき）、ＰＵＣＣＨでスケジューリング要求（ＳＲ）を送信する（Ｄ−ＳＲ）、またはＲＡＣＨ手順を実行する（コンテンションベースのスケジューリング要求）。このスケジューリング要求は、通常のＬＴＥアップリンク時間／周波数リソースにおいて（すなわちＤ２Ｄ用に予約される時間／周波数リソースではない）送信される。ｅＮＢは、このスケジューリング要求を受信すると、Ｄ２Ｄ送信側ユーザ機器にＰＵＳＣＨリソースを割り当てる。するとＤ２Ｄ送信側ユーザ機器は、すでに上述したように、Ｄ２Ｄに関連するバッファ状態情報をそのＰＵＳＣＨリソースにおいて送信する。ｅＮＢは、詳細なバッファ状態情報に基づいて、Ｄ２Ｄデータ通信のためのＤ２Ｄ時間／周波数リソースを割り当てる。スケジューリング要求の受信時にＰＵＳＣＨリソースを割り当てるとき、通常のＬＴＥアップリンクグラント／ＤＣＩ手順が使用される（すなわちアップリンクグラントがＣ−ＲＮＴＩにアドレッシングされ、ＬＴＥのＰＤＣＣＨ／ＰＵＳＣＨタイミング関係が適用される）。上述したように、第２の（すなわちＤ２Ｄに関連するバッファ状態情報を受信したときの）アップリンググラント／リソース割当てでは、異なるリソース割当てフォーマット／ＤＣＩ（例えばＤ２Ｄ  ＲＮＴＩにアドレッシングされる）を使用することができる。
【０１７７】
以下では、スケジューリング要求のトリガーについて、図１２を参照しながらさらに詳しく説明する。
【０１７８】
Ｄ２Ｄ対応ユーザ機器（図示していない）は、ＬＴＥアップリンクデータチャネルと、Ｄ２Ｄ通信用に予約される直接通信データチャネルの両方で、データを送るようにされている。これを目的として、いくつかのサブフレーム（すなわち時間／周波数リソース）がＬＴＥアップリンクトラフィック用に予約され、その一方で、別のサブフレーム（すなわち時間／周波数リソース）がＤ２Ｄ送信（Ｄ２Ｄ発見シグナリングもしくはＤ２Ｄデータ通信またはその両方とすることができる）用に予約される。ＴＤＭ方式に従って交互に並ぶように、事前定義された時間スロットが各サブフレームに割り当てられることが好ましい。一例として、上述した２つのタイプのサブフレームの一方に対して、より多くの連続するタイムスロットを予約し、より少ないリソースを要求する信号に割り当てられる期間を短くすることによって、より多くのリソースを要求する信号に、より長い期間を割り当てることができる。
【０１７９】
図１１は、図１０を参照しながら説明したスケジューリング方法およびシステムの一実装形態による、ＭＡＣプロトコルデータユニット（ＰＤＵ）の構成を示している。図１０に関連して説明したスケジューリング方法によるバッファ状態報告手順において参照されるこのＭＡＣプロトコルデータユニットには、Ｄ２Ｄに関連するシグナリングを実行するための制御要素が組み込まれている。Ｄ２Ｄ通信のためのスケジューリング情報は、Ｄ２Ｄ専用バッファ状態報告とすることが好ましく、このようなバッファ状態報告は、Ｄ２Ｄ通信用のＭＡＣ制御要素によって実施することができる。したがって、ＰＵＳＣＨで送信されるＭＡＣプロトコルデータユニットには、アップリンクのＬＴＥトラフィックにおけるスケジューリングを実行するために使用される、ＭＡＣ  ＢＳＲ／ＰＨＲ  ＣＥなどのＭＡＣ制御要素（図１１にはＭＡＣ制御要素１およびＭＡＣ制御要素２として示してある）に加えて、データを送信側ユーザ機器から直接リンクチャネルで受信側ユーザ機器に送信するためのリソースのスケジューリングを実行するのに使用される１つまたは複数のＤ２Ｄ  ＭＡＣ制御要素を含めることができる。
【０１８０】
このＭＡＣ  ＰＤＵの中のＤ２Ｄ  ＭＡＣ制御要素には、さらに識別番号を関連付けることができる。この識別番号は、例えば、予約された論理チャネルＩＤとすることができ、論理チャネルＩＤをＭＡＣ  ＰＤＵのヘッダ（すなわちＭＡＣサブヘッダ）に格納することができる。識別番号は、Ｄ２Ｄ  ＭＡＣ制御要素に対応するＲ／Ｒ／Ｅ／ＬＣＩＤサブヘッダに格納することが有利である。したがって、ｅＮｏｄｅＢは、ＭＡＣ  ＰＤＵの中のバッファ状態報告のうち、直接リンク接続を通じてのＤ２Ｄデータ送信のスケジューリング手順に使用しなければならないバッファ状態報告と、ＬＴＥセルラーアップリンクトラフィックをスケジューリングするのに使用しなければならないバッファ状態報告とを、区別することができる。この論理チャネルＩＤは、本発明の一実施形態によると、非特許文献６（参照によって本明細書に組み込まれている）の表６.２.１−２に規定されている予約されている論理チャネルＩＤ（ＬＣＩＤ）のうちの１つである。
【０１８１】
図１０を参照しながら説明したＤ２Ｄ通信方法は、ＰＵＳＣＨでのＬＴＥアップリンク送信における、新しい機能強化された論理チャネル優先順位付け（ＬＣＰ）手順をさらに含むことができる。論理チャネル優先順位付け（ＬＣＰ）手順は、一般には、複数の異なるチャネルで送信されるデータを１つのＭＡＣ  ＰＤＵ内に割り当てる役割を果たす。Ｄ２Ｄ対応ユーザ機器それぞれは、複数の異なる論理チャネルのデータおよびＭＡＣ制御要素を、この１つのＭＡＣ  ＰＤＵ内に多重化するために、ＭＡＣ層における多重化ユニット（図示していない）を含むことができる。ＭＡＣ制御要素は、例えば、ＬＴＥアップリンクトラフィックおよびＤ２Ｄ直接通信の両方のスケジューリングを実行するのに使用されるスケジューリング関連情報を伝える。
【０１８２】
論理チャネル優先順位付け（ＬＣＰ）手順は、相対的な優先順位の順序を定義し、ユーザ機器は、この順序に従ってＭＡＣ  ＰＤＵを構築することができる。ＬＴＥアップリンク送信における論理チャネル優先順位付け（ＬＣＰ）手順では、ＭＡＣ  ＰＤＵを構成するデータ部分の位置または順序を定義することが有利である。説明のみを目的とする例として、ＭＡＣ  ＰＤＵ用に１００バイトが利用可能であり、そのＭＡＣ  ＰＤＵ内に多重化されるデータが２００バイトからなる場合を考えることができる。ユーザ機器は、論理チャネル優先順位付け（ＬＣＰ）手順に基づいて、２００バイトのうちＭＡＣ  ＰＤＵにおいて送信することのできる部分およびその順序を決定することができる。次いで残りの１００バイトのデータを、次のＭＡＣ  ＰＤＵにおいて、論理チャネル優先順位付け（ＬＣＰ）手順において定義された優先順位に基づいて所定の順序で送信する。この例は説明を目的とするのみであり、本発明は、ＭＡＣ  ＰＤＵに１００バイトが利用可能である実施形態に限定されないことが、当業者には明らかに理解されるであろう。そうではなく、本発明によると、１００バイトより多くのバイト、または１００バイトより少ないバイトを、ＭＡＣ  ＰＤＵ用に利用可能とすることができる。ＭＡＣ  ＰＤＵ用に利用可能なバイト数は設計上のオプションであり、装置（ユーザ機器など）のハードウェア特性に応じてケースバイケースで設定される。
【０１８３】
有利な一方式によると、ＰＵＳＣＨで送信されるＭＡＣ  ＰＤＵは、論理チャネル優先順位付け（ＬＣＰ）手順で定義される降順において、次の優先順位に従って編成することができる。
−  Ｃ−ＲＮＴＩのＭＡＣ制御要素、またはＵＬ−ＣＣＣＨからのデータ
−  Ｄ２Ｄ  ＢＳＲのＭＡＣ制御要素
−  ＢＳＲのＭＡＣ制御要素（パディングのために含まれるＢＳＲを除く）
−  電力ヘッドルーム報告（ＰＨＲ）または拡張ＰＨＲのＭＡＣ制御要素
−  論理チャネルからのデータ（ＵＬ−ＣＣＣＨからのデータを除く）
−  パディングのために含まれるＢＳＲのＭＡＣ制御要素
【０１８４】
論理チャネル優先順位付け（ＬＣＰ）によって定義される上記の優先順位の順序によると、Ｄ２Ｄバッファ状態報告は、ＬＴＥセルラーアップリンクトラフィックにおけるスケジューリング手順を実行するために使用されるバッファ状態報告よりも、高い優先順位を有する。
【０１８５】
当然ながら、上の順序は、説明を目的とする一例にすぎない。さらなる有利な一方式によると、ＬＴＥアップリンクトラフィックに対応するバッファ状態報告に、より高い優先順位を割り当てることによって、ＬＴＥトラフィックをより重視することができる。したがって、Ｄ２Ｄ対応ユーザ機器における論理チャネル優先順位付け（ＬＣＰ）手順では、次の優先順位を降順で定義することができる。
−  Ｃ−ＲＮＴＩのＭＡＣ制御要素、またはＵＬ−ＣＣＣＨからのデータ
−  ＢＳＲのＭＡＣ制御要素（パディングのために含まれるＢＳＲを除く）
−  Ｄ２Ｄ  ＢＳＲのＭＡＣ制御要素
−  電力ヘッドルーム報告（ＰＨＲ）または拡張ＰＨＲのＭＡＣ制御要素
−  論理チャネルからのデータ（ＵＬ−ＣＣＣＨからのデータを除く）
−  パディングのために含まれるＢＳＲのＭＡＣ制御要素
【０１８６】
上に示した論理チャネル優先順位付け（ＬＣＰ）手順の例は、相対的な優先順位を定義する場合のいくつかの可能なオプションのうちの２つにすぎず、これらの例を本発明を制限するようにはみなさないものとする。当然ながら、ネットワークの構成および通信の仕様に従って、別の優先順位の順序を定義することができる。
【０１８７】
ＬＴＥシステムにおける一般的なバッファ状態報告は、１バイト長または４バイト長とすることができる（それぞれショートＢＳＲおよびロングＢＳＲ）。これに加えて、導入部分のセクション「アップリンクスケジューリングにおけるバッファ状態報告手順／スケジューリング要求手順」で説明したように、２バイトの短縮ＢＳＲも使用することができる。
【０１８８】
Ｄ２Ｄ通信のシナリオにおいては、通信の確立は、ｅＮｏｄｅＢによってではなく、個別のエンティティ（例えばコアネットワーク内のＤ２Ｄサーバやユーザ機器内のＤ２Ｄ管理エンティティなど）によって、管理／設定される。Ｄ２Ｄ管理エンティティ（ＰｒｏＳｅ管理エンティティ（ＰＭＥ）と称することもできる）は、ユーザ機器に属し、このエンティティには、Ｄ２Ｄ通信時に使用される設定パラメータ（例えばプロトコル／ベアラの設定）が提供される。設定パラメータの提供は、事前の設定によって実行する、またはネットワークカバレッジ内の場合、ＰＭＥとコアネットワーク内のＤ２Ｄ機能／サーバとの間のシグナリングによって実行する。したがってＰＭＥは、「Ｄ２Ｄベアラ」を通じてのＤ２Ｄ通信をサポートするため、あらかじめ提供された設定パラメータに基づいて第２層および物理層を設定する。Ｄ２Ｄ直接リンク接続を通じてデータを伝送するための詳細な設定パラメータ（例えばユーザ機器がどのＤ２Ｄベアラをデータ伝送に使用するか）をｅＮｏｄｅＢが認識していないため、Ｄ２Ｄデータ通信では、ＬＴＥトラフィックの場合には確保される、ネットワークの観点からのサービス品質（ＱｏＳ）制御が提供されない。ｅＮＢがＤ２Ｄベアラの詳細な設定を認識していないことがあるため、Ｄ２Ｄのバッファ状態報告には、すべてのＤ２Ｄベアラのバッファ内のデータ量のみを含めることが有利である。このことは、論理チャネルのグループのレベルで編成されるＬＴＥトラフィック／ベアラのバッファ状態報告（ＢＳＲ）とは対照的である。
【０１８９】
Ｄ２Ｄ  ＢＳＲ  ＭＡＣ  ＣＥには、送信バッファに格納されているＤ２Ｄベアラのデータ量に関する情報に加えて、Ｄ２Ｄデータ通信のスケジューリングをｅＮＢがより効率的に行うことができるようにするいくつかのさらなる情報をさらに含めることが有利である。一例として、Ｄ２Ｄバッファ状態報告は、本発明の別の実施形態によると、ｅＮＢによってＤ２Ｄ時間／周波数リソースを割り当てるべき対象のＤ２ＤトラフィックまたはＤ２Ｄベアラのタイプの指示情報を含む。Ｄ２Ｄ  ＢＳＲ  ＭＡＣ  ＣＥには、トラフィックまたはベアラのタイプを示す１つまたは複数のタイプフラグを含めることが有利である。一例として、タイプフラグには、Ｄ２Ｄ直接リンクチャネルで送信されるデータが音声データであるか、会話ではない別のタイプのデータ（ビデオデータなど）であるかに関する情報を含めることができる。
【０１９０】
ｅＮｏｄｅＢは、トラフィックベアラのタイプに関する情報を伝えるタイプフラグに基づいて、より効率的にリソースをスケジューリングすることができる。一例として、ｅＮｏｄｅＢは、タイプフラグから、送信されるデータが音声データ（ＶｏＩＰデータなど）であることを認識することができる。したがってｅＮｏｄｅＢは、ＬＴＥアップリンクデータチャネルで音声データを送信する場合に行われる通常の方法において、リソースの優先順位を割り当てることができる。具体的には、ｅＮｏｄｅＢは、特定の量のビットを周期的に送信するためのリソースを割り当てることができる。一例として、周期的な信号である音声信号の場合、ｅＮｏｄｅＢは、２０ｍｓごとにＤ２Ｄ直接リンクデータチャネルリソースを通じて送信するためのリソースを割り当てることができる。
【０１９１】
これとは異なり、Ｄ２Ｄ直接リンクデータチャネルを通じて送信されるデータが会話ではないサービス（ビデオデータなど）であることをタイプフラグが示している場合、ｅＮｏｄｅＢは、バッファ状態報告（ＢＳＲ）の中のタイプフラグ情報に基づいて、周期的ではなく１回の割当てとしてリソースを割り当てることができる。
【０１９２】
要約すれば、ＬＴＥ通信の場合、トラフィックはネットワークによって制御され、したがってｅＮｏｄｅＢは、例えば、複数の異なるベアラにおいてサポートされる必要のあるサービス品質（ＱｏＳ）に関する情報を有する。しかしながらＤ２Ｄデータトラフィックの場合、ｅＮｏｄｅＢはこの情報を取得することができず、なぜならＤ２Ｄデータトラフィックはネットワークの介入なしに発生するためである。したがってＤ２Ｄ通信の場合、ユーザ機器はこの情報をバッファ状態報告と一緒にｅＮｏｄｅＢに提供しなければならない。これを目的として、バッファ状態報告（ＢＳＲ）の中のタイプフラグ情報が、Ｄ２Ｄ直接リンクチャネルにおけるベアラおよびデータトラフィックに関する情報をｅＮｏｄｅＢに提供することが有利であり、そうしなければｅＮｏｄｅＢはこれらの情報を直接取得することができない。ｅＮＢは、いくつかのＤ２Ｄ送信側ユーザ機器の間でＤ２Ｄリソース割当てを優先順位付けする目的にも、この情報を使用することができる。一例として、ｅＮＢは、複数のスケジューリング要求（すなわちＤ２Ｄに関連するバッファ状態情報）を受信したとき、リソース割当てを優先順位付けする必要がある。この優先順位付けは、さらなる代替実施形態によると、例えば、Ｄ２Ｄバッファ状態報告のＭＡＣ  ＣＥに含まれている何らかの優先順位情報に基づいて行うことができる。優先順位情報は、例えば、上に概説したようにあらかじめ提供される設定パラメータに基づいて第２層および物理層を設定するＰＭＥから、取得することができる。一例として、ＰＭＥは、ＬＴＥベアラの場合の論理チャネルの優先順位に類似する優先順位値を、各Ｄ２Ｄベアラに関連付けることができる。Ｄ２Ｄ送信側ユーザ機器は、Ｄ２Ｄデータを送信しようとするとき、例えば、そのユーザ機器が送信リソースを要求する対象のＤ２Ｄベアラのうち優先順位が最も高いＤ２Ｄベアラの優先順位値を含めることができる。
【０１９３】
ユーザ機器には、各論理チャネルのデータ用の送信バッファメモリが設けられており、これらの送信バッファメモリは、無線リンクを通じてｅＮｏｄｅＢに正常に送信されるまでアップリンクデータを一時的に格納しておくために使用される。さらに、ユーザ機器には、データまたはバッファ状態報告を基地局に送信するために利用可能なアップリンクリソースがなく、したがってスケジューリング要求をｅＮＢに送信する必要があるが、このプロセスが、本発明の第１の実施形態によって改善される。
【０１９４】
図１０に関連して説明した方法においては、Ｄ２Ｄ直接リンクデータチャネルを通じて送信されるＤ２Ｄベアラのデータが送信側ユーザ機器の送信バッファ内に一時的に格納されたとき、送信側ユーザ機器は、Ｄ２Ｄに関連するバッファ状態報告をｅＮＢに送る。
【０１９５】
さらに、トリガーされたバッファ状態報告を送信するために利用可能なアップリンク共有チャネルリソース（ＵＬ−ＳＣＨ）が存在しない場合、Ｄ２Ｄバッファ状態報告のトリガーの後、ただちにスケジューリング要求をトリガーすることができる。
【０１９６】
前に説明したように、スケジューリング要求は、ｅＮｏｄｅＢによって割り当てられるＰＵＣＣＨのリソースを介して、またはＲＡＣＨ手順を使用することによって、送信することができる。以下では、異なる説明がなされていない限り、このようなＰＵＣＣＨのリソース（一般にはｅＮｏｄｅＢによって周期的に割り当てられる）は、スケジューリング要求がトリガーされた後にスケジューリング要求を送信できるようにユーザ機器にただちに利用可能であるものと想定する。しかしながら、代わりにＲＡＣＨ手順を使用するときにも、本発明を適用することができる。スケジューリング要求は、通常では１ビット長であり、対応する周期的なＰＵＣＣＨリソースは、スケジューリング要求を送信することはできるが、さらなるデータ（バッファ状態報告や送信バッファの実際のデータなど）を送信するには十分ではない。さらに、ｅＮＢは、ユーザ機器が直接リンク送信（Ｄ２Ｄデータ送信）のための送信リソースを要求しているのか、ＬＴＥアップリンク送信のための送信リソースを要求しているのかを、スケジューリング要求に基づいて認識することはできない。ｅＮＢは、上に概説したバッファ状態報告に基づくことではじめて、Ｄ２Ｄ送信のための要求とＬＴＥアップリンク送信のための要求とを区別することができる。
【０１９７】
図１２は、ユーザ機器における送信バッファと、Ｄ２Ｄ直接リンクデータチャネルでデータを送信するためのリソースを要求する目的で基地局と交換されるメッセージとを示している。これに加えて、図１２は、バッファ状態報告をアップリンクデータチャネルで送信する状況と、スケジューリング要求をｅＮｏｄｅＢに送信する状況と、データを直接リンクデータチャネルを通じて受信側ユーザ機器に送信する状況とを示している。図１３は、図１２に示したメッセージおよびデータの交換を実行するための送信側ユーザ機器におけるプロセスを示している。
【０１９８】
図１２に示した方法によると、Ｄ２Ｄデータ通信におけるバッファ状態報告／スケジューリング要求のトリガーは、標準のトリガリングと比較して異なる条件に基づくことができる。一例として、特定の量のデータが対応するバッファ内に蓄積したときにのみ、Ｄ２Ｄバッファ状態報告／スケジューリング要求をトリガーすることができる。バッファ状態報告／スケジューリング要求を先に延ばすことによって、より多くのデータが送信バッファ内に到着し、したがってアップリンク送信において、より多くのデータがより短い時間で伝送される。したがって、バッファ状態報告／スケジューリング要求のトリガーは、空の送信バッファに新しいデータが到着した時点でただちに実行するのではなく、送信バッファ内に十分なデータが存在するときに実行される。小さいサイズのトランスポートブロックを送信するのではなく、より大きいサイズのトランスポートブロックを送信することは、電力効率がより高い。
【０１９９】
図１２の方法は、次の例示的な方法において実施することができる。ユーザ機器におけるバッファ状態報告のトリガーは、２つの条件に依存し、これら２つの条件の両方が満たされるものとする。ＬＴＥ実装の場合における両方のトリガー条件は、バッファ状態報告の送信に関連するが、バッファ状態報告の送信は、スケジューリング要求の送信にそのままつながり、なぜならトリガーされたバッファ状態報告をユーザ機器が送信するためのリソースが利用可能ではないものと想定しているためである。したがって、トリガー条件は、スケジューリング要求の送信に対して定義されているとも言える。
【０２００】
第１のトリガー条件は、送信バッファ内で新しいデータが利用可能になることを要求し、すなわち、直接リンクデータチャネルを通じて受信側ユーザ機器（ＵＥ２）に送信される予定の上位層からのデータが、送信側ユーザ機器（ＵＥ１）の送信バッファ内に入ることを要求する。なお、第１のトリガー条件は、送信バッファ内で新しいデータが利用可能になりさえすれば、送信バッファが空であるか否かとは無関係に、かつ、新しいデータの優先順位とは無関係に、満たされることに留意されたい。
【０２０１】
この挙動は図１３に示してあり、送信側ユーザ機器（ＵＥ１）は、自身の送信バッファ内に新しいデータが到着したかをチェックする。
【０２０２】
第２のトリガー条件は、基本的に、バッファ状態報告／スケジューリング要求のトリガーを先に延ばす役割を果たし、ユーザ機器１の送信バッファ内に十分なデータが存在することを要求する。したがって一般的には、送信バッファ内のデータが所定のしきい値を上回るものとする。
【０２０３】
第２のトリガー条件については、ユーザ機器は、例えば、送信バッファ内のデータ量が、前回のバッファ状態報告がトリガーされてｅＮｏｄｅＢに送られた時点において送信バッファ内に格納されていたデータ量と比較して、所定の値Δｄだけ変化したかをチェックする。
【０２０４】
図１３においては、データ量が所定の値だけ変化することを要求する第２のトリガー条件を、送信側ユーザ機器がチェックするものと想定する。第１のトリガー条件および第２のトリガー条件を、図１３に示した順序でチェックする（すなわち最初に第１のトリガー条件、次に第２のトリガー条件）ことは理にかなっているように考えられるが、このことは必須ではない。ユーザ機器は、最初に第２のトリガー条件をチェックし、次いで第１のトリガー条件をチェックすることもできる。
【０２０５】
さらには、第２のトリガー条件（データ量が所定の値だけ変化することを要求する）が満たされる場合、そのためには必然的に第１のトリガー条件も満たされている必要があることに留意されたい。言い換えれば、送信バッファ内のデータの量が所定のデータ量だけ突然に変化するのは、送信バッファ内に新しいデータが到着した場合のみであり、送信バッファ内に新しいデータが到着することは、第１のトリガー条件の要件に相当する。したがって、一代替形態においては、第１のトリガー条件を必ずしもチェックする必要がない。送信バッファ内のデータ量が特定のしきい値を超えたときにバッファ状態報告（ＢＳＲ）／スケジューリング要求（ＳＲ）がトリガーされるように、第２のトリガー条件のみをチェックすれば十分である。
【０２０６】
上の例では、バッファ状態報告（ＢＳＲ）の送信は、送信バッファ内のデータ量が、前回にバッファ状態報告（ＢＳＲ）がトリガーされて送信された時点における送信バッファ内のデータ量を基準として所定の量だけ変化することによってトリガーされる。しかしながら、上述したトリガー方式の代わりに、別のトリガー方式を使用することができる。上述したトリガー方式に代えて、送信側ユーザ機器の送信バッファ内のデータ量が所定のしきい値を超えた場合に、バッファ状態報告（ＢＳＲ）の送信をトリガーすることができる。
【０２０７】
本発明のさらなる態様は、Ｄ２Ｄのバッファ状態報告（ＢＳＲ）を、ＰＵＳＣＨで送信されるＭＡＣ  ＰＤＵに含める、すなわち多重化するための規則に関する。現在のＬＴＥ仕様（リリース８／９／１０／１１）によると、ユーザ機器は、最大で１つのＢＳＲ  ＭＡＣ  ＣＥをＭＡＣ  ＰＤＵに含めることができるのみである。しかしながら、本発明の一実施形態によると、Ｄ２Ｄ対応ユーザ機器は、１つのＤ２Ｄ  ＢＳＲ  ＭＡＣ  ＣＥおよび１つのＬＴＥ  ＢＳＲ  ＭＡＣ  ＣＥを、ＰＵＳＣＨでｅＮＢに送信されるＭＡＣ  ＰＤＵ内に多重化することが許可される。これにより、Ｄ２Ｄスケジューリング手順に起因して通常のＬＴＥアップリンクスケジューリング手順が遅延したり影響を受けることがない。
【０２０８】
上述したシステムおよび方法の代替実装形態においては、最大で１つのＢＳＲ  ＭＡＣをＭＡＣ  ＰＤＵに含めることができるという制約を維持することができる。この代替実装形態では、標準のＬＴＥシステムにおける公知のＭＡＣ  ＰＤＵの構造に類似するＭＡＣ  ＰＤＵの構造を使用し、異なる点として、ＭＡＣ  ＰＤＵは、ＬＴＥ  ＢＳＲ  ＭＡＣ  ＣＥの代わりにＤ２Ｄ  ＢＳＲ  ＭＡＣ  ＣＥを含むことができる。このような構造の結果として、ＬＴＥ  ＢＳＲ  ＭＡＣ  ＣＥまたはＤ２Ｄ  ＢＳＲ  ＭＡＣ  ＣＥのいずれかの送信が遅延する。さらには、ＬＴＥ  ＢＳＲ  ＭＡＣ  ＣＥおよびＤ２Ｄ  ＢＳＲ  ＭＡＣ  ＣＥの一方のみがＭＡＣ  ＰＤＵに含められるため、新規の優先順位付け規則を定義する必要がある。
【０２０９】
本発明のさらに別の態様は、バッファ状態報告の取り消し手順に関する。非特許文献１１（参照によって本明細書に組み込まれている）の５.４.５節に規定されている通常のバッファ状態報告手順によると、すべてのトリガーされたバッファ状態報告（ＢＳＲ）は、送信されるＭＡＣ  ＰＤＵにバッファ状態報告（ＢＳＲ）が含められたとき、取り消される。本発明のさらなる実施形態によると、Ｄ２Ｄ対応ユーザ機器は、送信されるＭＡＣ  ＰＤＵにＤ２Ｄバッファ状態報告が含められたとき、通常の「ＬＴＥバッファ状態報告」を取り消さない。この解決策により、Ｄ２Ｄバッファ状態報告の導入によって通常のＬＴＥアップリンクスケジューリング手順／バッファ状態報告手順が影響を受けることがない。
【０２１０】
同様に、本発明のさらに別の態様によると、Ｄ２Ｄバッファ状態報告がトリガーされたことのみに起因してスケジューリング要求がトリガーされたときには、スケジューリング要求（ＳＲ）禁止タイマーを起動しない。本発明のさらなる実施形態によると、Ｄ２Ｄ対応ユーザ機器は、Ｄ２Ｄ通信のための送信リソースを要求することのみを目的としてスケジューリング要求（ＳＲ）が送られた場合、スケジューリング要求（ＳＲ）がＰＵＣＣＨで送信されたときにスケジューリング要求（ＳＲ）禁止タイマーを起動しない。すぐ上に概説した実施形態と同様に、これにより、Ｄ２Ｄ  ＢＳＲに起因してＬＴＥデータ送信（特に、ＲＲＣシグナリングなど優先順位の高いＬＴＥデータ）が遅延することがない。
【０２１１】
本発明の別の態様は、Ｄ２Ｄデータ通信におけるリソース割当てモードの選択に関する。上述したように、ユーザ機器は、Ｄ２Ｄデータ通信におけるリソースの選択に関して２つのモードで動作することができ、すなわち、スケジューリング式動作モード（モード１）および自律的動作モード（モード２）である。一般的な原理として、一実施形態によると、Ｄ２Ｄ対応ユーザ機器が動作するリソース割当てモードをｅＮＢが制御する。有利な一実装形態によると、Ｄ２Ｄベアラのデータを送信しなければならないＤ２Ｄ対応ユーザ機器は、必ず最初にモード１で動作する、すなわち、（ＲＲＣ＿ＩＤＬＥ  ＵＥの場合には）ｅＮＢとのＲＲＣ接続を確立し、前の実施形態において概説したようにバッファ状態報告／スケジューリング要求をｅＮＢに送る。ユーザ機器がＤ２Ｄ送信のためのリソース割当てを例えば所定の時間窓の中でｅＮＢから受信しない場合、あるいはｅＮＢからの明示的なシグナリング指示情報が、Ｄ２Ｄデータ送信用のＤ２Ｄ時間／周波数リソースをリソースプールから自律的に選択するようにユーザ機器に示す場合、ユーザ機器はモード２の動作に戻る。これに代えて、ｅＮＢは、そのセル内ではスケジューリング式モード動作がサポートされていないことを、例えばシステム情報ブロードキャスト（ＳＩＢ）によってシグナリングすることができる。そのセル内でモード１が利用できるか否かを示すフラグを、例えばブロードキャストすることができる。Ｄ２Ｄ対応の送信側ユーザ機器は、このフラグに基づいて、Ｄ２Ｄ送信のリソース割当てのために最初にモード１タイプの動作を試みる（そのセルにおいてモード１が動作することをフラグが示しているとき）、またはただちにモード２を使用する。さらに別の解決策として、Ｄ２Ｄの目的に予約される何らかの専用のアクセスクラスを導入することができ、ｅＮＢは、Ｄ２Ｄデータ送信用リソースを自身に直接要求する（すなわちモード１タイプの動作を使用する）ことをどのＤ２Ｄユーザ機器に許可するのかを、これらのアクセスクラスに基づいて制御することができる。基本的には、各Ｄ２Ｄユーザ機器にアクセスクラスが割り当てられ、どのクラスがリソース割当てのためにモード１を使用できるかを、ｅＮＢからの何らかのシグナリングによって示す。
【０２１２】
本発明のさらなる態様は、装置間通信をサポートすることのできるユーザ機器における論理チャネル優先順位付け（ＬＣＰ）手順に関する。ユーザ機器は、アップリンクデータチャネルを通じてデータを送信するためのＬＴＥチャネルまたはＬＴＥベアラと、Ｄ２Ｄベアラの両方を有することができる。このようなシナリオにおいては、Ｄ２Ｄベアラのデータは、Ｄ２Ｄサブフレームにおいて（言い換えれば、直接リンクデータチャネルを通じてのＤ２Ｄ送信用に設定されるリソースで）のみ送信することができる。同様に、ＬＴＥベアラのデータは、ＬＴＥ専用のサブフレーム（すなわち時間／周波数リソース）においてのみ送信することができる。さらには、ＬＴＥアップリンクチャネルを通じて送信するユーザ機器の能力と、直接リンクチャネルを通じて送信するユーザ機器の能力とを考慮する論理チャネル優先順位付け（ＬＣＰ）手順を、実装することができる。
【０２１３】
有利な実装形態においては、ＬＴＥベアラおよびＤ２Ｄベアラの両方に共通する論理チャネル優先順位付け（ＬＣＰ）手順を開発することができる。したがって、ＬＴＥのサブフレームにおいては、論理チャネル優先順位付け（ＬＣＰ）手順においてＤ２Ｄベアラのデータを考慮しない。言い換えれば、ＬＴＥのサブフレーム（すなわち時間／周波数リソース）においては、論理チャネル優先順位付け（ＬＣＰ）手順においてＤ２Ｄベアラが一時中断しているものと考えることができる。同様に、Ｄ２Ｄサブフレームにおいては、論理チャネル優先順位付け（ＬＣＰ）手順においてＬＴＥベアラを一時中断させることができる。Ｄ２Ｄ通信およびＬＴＥ通信において共通する論理チャネル優先順位付け（ＬＣＰ）手順を使用することで、Ｄ２ＤベアラおよびＬＴＥベアラの管理の複雑さを低減することができる。
【０２１４】
これに代えて、２つの個別の論理チャネル優先順位付け（ＬＣＰ）手順、すなわち、直接リンクチャネルを通じてのＤ２Ｄデータ伝送のための論理チャネル優先順位付け（ＬＣＰ）手順と、ＬＴＥデータトラフィックのための論理チャネル優先順位付け（ＬＣＰ）手順、を提供することができる。したがって、Ｄ２Ｄサブフレームにおいては、Ｄ２Ｄベアラに専用の論理チャネル優先順位付け（ＬＣＰ）手順を呼び出すことができるのに対して、ＬＴＥのみの送信用に予約されているサブフレームにおいては、ＬＴＥ用に定義されている論理チャネル優先順位付け（ＬＣＰ）手順を呼び出す。Ｄ２Ｄベアラに対してはサービス品質（ＱｏＳ）がサポートされず、したがって優先ビットレート（ＰＢＲ）を設定する必要がないため、この方式におけるＤ２Ｄ論理チャネル優先順位付け（ＬＣＰ）手順では、トークンバケットモデルを使用する必要がない。Ｄ２Ｄ用およびＬＴＥ用の２つの個別の論理チャネル優先順位付け（ＬＣＰ）手順が提供されるこの方式の利点として、Ｄ２Ｄ論理チャネル優先順位付け（ＬＣＰ）手順の設定が容易である。
【０２１５】
本発明のさらなる態様は、発見信号のアップリンク送信タイミングに関する。一般的には、Ｄ２Ｄデータ送信における送信タイミングは、ＬＴＥアップリンクデータ送信における送信タイミングとは異なる。この理由として、ＬＴＥでは、ユーザ機器のタイミングはつねにネットワークによって（すなわちｅＮｏｄｅＢによって）制御されるためである。具体的には、ネットワークは、干渉を回避する目的で、ｅＮｏｄｅＢの制御下にあるすべてのユーザ機器からのすべてのアップリンク信号が同時に受信されるように制御する。装置間通信に対応するシステムでは、データを直接リンクデータチャネルを通じて受信側ユーザ機器に送信する送信側ユーザ機器が、何らかのタイミングを、受信側ユーザ機器（または受信側ユーザ機器のグループ）と交渉しなければならない。送信側ユーザ機器および受信側ユーザ機器によって交渉されるタイミングは、ＬＴＥアップリンクデータトラフィックの場合にネットワークによって制御されるタイミングとは異なっていてよい。第１の解決策によると、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のＤ２Ｄ送信側ユーザ機器は、Ｄ２Ｄ通信の場合も、ダウンリンク基準タイミングに基づいて発見信号を送信する。ＬＴＥシステムでは、アップリンクのタイミングは、ダウンリンク基準タイミングと、ダウンリンクタイミングに対する補正としてのオフセットとによって定義される。オフセットは、タイミング調整（ＴＡ）係数と称され、その値はｅＮｏｄｅＢによって制御される。したがってこの第１の解決策によると、アップリンクの補正値は、ＦＤＤにおけるＤ２Ｄの場合には０である（Ｔ２＝０）。ＴＤＤにおいては、ＲＲＣ＿ｃｏｎｎｅｃｔｅｄ状態およびＲＲＣ＿ｉｄｌｅ状態のＤ２Ｄ送信側ユーザ機器は、６２４Ｔｓのオフセットに基づいて発見信号を送信することができる。結果として、ダウンリンクのタイミングは、Ｔ２＝６２４Ｔｓである。
【０２１６】
ＬＴＥ発見／通信およびＤ２Ｄ発見／通信用に２つの異なるタイミングが与えられるため、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態のユーザ機器は、ＭＡＣ層に属する２つの個別の独立したタイミング調整機能（タイミング調整値もしくはタイミング調整タイマーまたはその両方を含む）を有することができ、一方がＤ２Ｄ用、他方がＬＴＥ用である。
【０２１７】
Ｄ２Ｄ用のアップリンクタイミング機能は、Ｄ２Ｄサブフレームに対してのみ有効にすることが有利である。言い換えれば、ＬＴＥアップリンクサブフレームとＤ２Ｄ送信との間にアップリンクタイミングの飛び越し（jump）が存在する。さらに、Ｄ２Ｄ発見の場合のＮＴＡ＿Ｒｅｆ＿Ｄ２Ｄを０に設定することができる。
【０２１８】
さらなる有利な態様（前述した態様と一緒に、または前述した態様に代えて使用することができる）によると、Ｄ２ＤサブフレームにおけるＤ２Ｄ送信に、自律的なアップリンクタイミング調整（ダウンリンク基準タイミングを追跡する）を適用することができる。
【０２１９】
さらには、Ｄ２Ｄ通信の場合、ユーザ機器はｅＮｏｄｅＢからタイミングアドバンス（ＴＡ）コマンドを受信しない。したがって、さらなる有利な態様（前述した態様と一緒に、または前述した態様に代えて使用することができる）によると、Ｄ２Ｄ用のタイミングアドバンスタイマーを提供することができる。一例として、Ｄ２Ｄ通信の場合、タイミングアドバンス（ＴＡ）タイマーを無限大に設定し、最初のＤ２Ｄ発見手順またはＤ２Ｄ送信が行われる前に起動することができる。
【０２２０】
本発明の別の態様は、装置間通信（すなわち近傍サービス）における発見手順に関する。カバレッジ外では、発見リソースを送信／受信するための利用可能なネットワークが存在せず、したがってネットワーク側からの専用または共通のリソース割当てが不可能である。本発明のさらなる実施形態は、この問題に対処する。したがって、ネットワークのカバレッジ内にない（カバレッジ外とも称する）Ｄ２Ｄ対応ユーザ機器は、固定された周期で周期的に繰り返される固定されたシーケンスを、固定された周波数において送信することができる。この手順は、Ｄ２Ｄプライマリ同期信号を、装置の識別情報なしで、または近傍サービス（ＰｒｏＳｅ）ユーザ機器の識別情報を含めて、その実際の動作周波数には無関係に固定された周波数で送信することによって、実施することができる。このような実装形態では、別のＤ２Ｄユーザ機器による検出を極めて単純な方法で実行することができる。
【０２２１】
ネットワークのカバレッジ内にあるＤ２Ｄ対応ユーザ機器（カバレッジ内ユーザ機器とも称する）については、アイドルモードのユーザ機器と接続モードのユーザ機器（すなわちネットワークとのＲＲＣ接続が確立されているユーザ機器）とで、異なる発見手順を使用することができる。以下ではこの２つのモードについて説明する。
【０２２２】
アイドルモードのユーザ機器
【０２２３】
第１のカバレッジ内発見手順によると、Ｄ２Ｄ発見メッセージを受信するための現在のセル内のタイプ１のリソースおよびタイプ２のリソースの両方を（受信プール）、システム情報においてブロードキャストすることができる。これに加えて、現在のセルは、同じ周波数または異なる周波数の隣接セルの送信プール（および存在時にはカバレッジ外送信プール）をさらにブロードキャストすることができる。したがって発見メッセージの受信は次式によって与えられる。
受信プール＝現在のセルの送信プール＋（１つまたは複数の）隣接セルの送信プール＋カバレッジ外送信プール
【０２２４】
これに代えて、いくつかの実装形態においては、（１つまたは複数の）隣接セルの送信プールもしくはカバレッジ外送信プールまたはその両方を現在のセルによってブロードキャストしなくてもよく、なぜなら、ブロードキャストを節約するかを事業者の選択肢とすることができる、あるいは、隣接セルが異なる公衆陸上移動網（ＰＬＭＮ）に属することがあるためである。このような場合、現在のセルは、そのセル内でブロードキャストされる受信プールにはそのセルの外側からの関連する送信プールすべてが含まれないことがあることを、少なくとも示すことができる。最も単純な形式では、この指示情報は、Ｄ２Ｄシステム情報ブロック内の１ビットの指示情報（図１４では「注１」として示してある）とすることができる。
【０２２５】
さらには、受信側ユーザ機器は、現在のセルの外側に別のＤ２Ｄ装置が存在するかを判定する必要があり、そのような別のＤ２Ｄ装置の発見メッセージも、その受信側ユーザ機器にとって関心がある。したがって、この情報を、（例えばＰｒｏＳｅサーバに基づいて）上位層、例えばＮＡＳアプリケーションによって送信することができる。ユーザ機器は、現在のセル内には発見対象のＤ２Ｄ装置が存在しないものと判定した時点で、そのような発見対象のＤ２Ｄ装置が存在しうる隣接セルを見つけることができる。
【０２２６】
図１４は、上述したようにＤ２Ｄ発見信号を受信する方法を示している。
【０２２７】
Ｄ２Ｄ対応の通信システムの一実装形態によると、Ｄ２Ｄ発見手順をサポートする（すなわちタイプ１の特定のリソースもしくはタイプ２の特定のリソースまたはその両方が割り当てられている）隣接セルは、周波数が異なることがある。このような場合、隣接セルのＰＣＩ（物理セル識別子）および周波数の両方を、現在のセルのシステム情報ブロードキャストにおいて示すことが有利である。
【０２２８】
図１５は、Ｄ２Ｄ対応ユーザ機器が、隣接セルにおける発見手順を実行する状況を概略的に示している。発見メッセージの送信は、送信側ユーザ機器の最大送信電力によって制限され、したがって遠く離れたセルにおいて送信された発見メッセージは、そのＤ２Ｄ装置において受信することができない。
【０２２９】
したがって、さらなる実装形態によると、（１つまたは複数の）隣接セルからの発見メッセージを受信することを待機しているＤ２Ｄ装置は、すべての隣接セルを探索してリソースを取得する必要はなく、自身に近い隣接セルのみでよい。一例として、図１５に示したように、Ｄ２Ｄ装置は隣接セル２のＤ２Ｄリソースの検出／取得を試みず、なぜなら、隣接セル２の中のＤ２Ｄ装置から送信されても、遠すぎて届かないためである。ユーザ機器は、隣接セルｘのＤ２Ｄリソースの検出／取得を、特定の条件が満たされた場合のみ試みることが有利である。ユーザ機器は、以下の場合に、隣接セルｘ（セルｘ）のＤ２Ｄリソースを検出または取得するかを決定することが有利である。
現在のセルの品質−セルｘの品質＜しきい値１、または、
セルｘの品質≧現在のセルの品質
【０２３０】
接続モードのユーザ機器
【０２３１】
接続モードにあるユーザ機器には、受信プールに関する情報を専用シグナリング（例えばＲＲＣ情報）によってシグナリングすることができる。受信プールに関する情報には、（１つまたは複数の）隣接セルの送信プールもしくはカバレッジ外送信プールまたはその両方に関する情報を含めることができる。これに代えて、ユーザ機器は、上述したアイドルモードに関連して説明したように、この情報を取得することができる。
【０２３２】
これに加えて、接続モードのユーザ機器は、（ａ）異周波数の（１つまたは複数の）隣接セルおよびそれらのＤ２Ｄ  ＳＩを検出する、および（ｂ）異周波数リソースにおける（１つまたは複数の）発見メッセージを取得する目的で、ギャップパターン（Gap patterns）をさらに必要とする。
【０２３３】
したがって、このようなユーザ機器は、ギャップに関する情報（ギャップ長さ、反復長さ、オフセットなど）を含むギャップパターンを、サービングｅＮＢに要求することができる。これに代えて、このようなユーザ機器は、自律的なギャップ（autonomous gap）を使用することができる。
【０２３４】
上の実施形態は、主としてＤ２Ｄ発見手順の受信動作を対象としていたため、以下では、本発明の例示的な一実施形態による、Ｄ２Ｄ発見手順の送信動作について説明する。
【０２３５】
Ｄ２Ｄ対応ユーザ機器は、Ｄ２Ｄ発見信号／メッセージを送信するのにどちらのタイプのリソースを使用するべきかを決定する必要がある。したがってＤ２Ｄ対応ユーザ機器は、この決定に基づいて、（例えばタイプ２Ｂのリソースの場合に）ｅＮＢにリソースを要求する必要があり、したがってこの目的のためにＲＲＣ接続を確立する必要がある（ユーザ機器がアイドルモードであった場合）。
【０２３６】
有利な一実装形態によると、Ｄ２Ｄ発見信号または発見メッセージを送信するのに使用するべきリソースのタイプの決定は、以下の基準に基づくことができる。
１）  発見手順のタイプ（すなわち発見メッセージの送信をトリガーするアプリケーションに基づく）
−  発見用リソースのタイプとアプリケーションとの間のマッピングを、指定する、または事前に設定する、または（ＰｒｏＳｅ）発見サーバなどによって示すことができる。
２）  （例えば同じ発見アプリケーションにおいて）最後に正常に行われた発見メッセージの送信
３）アイドルモードのモビリティ状態
【０２３７】
一実装形態においては、移動速度が遅いかまたは静止しているユーザ機器は、つねに特定のリソースタイプ（例えばタイプ２Ｂ）を要求し、移動しているユーザ機器（例えば中程度の速度での移動）は、例えばタイプ１を使用することが有利である。以下のセクションでは、上述した要求のタイプについて説明する。
【０２３８】
タイプ２Ｂのリソースの要求
【０２３９】
ユーザ機器は、タイプ２Ｂのリソースを使用することを決定した場合、これらのタイプ２Ｂのリソースが割り当てられるようにｅＮＢに要求する。この要求は、以下の手順によって達成することができる。
・  専用のＲＡＣＨリソースを使用する（例えば、プリアンブル、ＲＡＣＨ送信リソース）
・  Ｍｓｇ３における新規の理由値（Ｄ２Ｄタイプ２Ｂの送信リソースを要求する）
−  ユーザ機器はＬＴＥベアラ（例えばＬＴＥコアネットワーク（ＣＮ）内で終了するベアラ）を確立するわけではないため、この目的には軽いＲＲＣプロトコルを使用することができる（例えばセキュリティコンテキストを確立する必要がない、測定の設定／報告が不要である）。
・  非アクセス層（ＮＡＳ）シグナリング
−  タイプ２Ｂを使用することをユーザ機器の非アクセス層（ＮＡＳ）がＭＭＥに知らせ、ＭＭＥはそれを確認してｅＮＢに示し、タイプ２Ｂのリソースを要求する。ｅＮＢは、そのユーザ機器にタイプ２Ｂのリソースを（ＲＲＣ再設定メッセージにおいて）割り当てる。アプリケーションとリソースの間のマッピングは固定されており、したがってＰｒｏＳｅサーバ／アプリケーション／コアネットワーク（ＣＮ）は、使用するべきリソースタイプを例えばＤ２Ｄサービスの認証時に決定する。
【０２４０】
さらに、ユーザ機器は、タイプ２Ｂのリソースを要求するときに、タイプ２Ｂのリソースを使用する推定期間を示すことができる。要求が受け入れられない場合（例えば、ユーザ機器が２Ｂリソースの拒否メッセージを受信する、ＲＲＣ接続が解除される、または特定の時間内に応答がない）、ユーザ機器はタイプ１の使用を開始する。
【０２４１】
モビリティ（ハンドオーバー、再確立）
【０２４２】
モビリティが発生すると、前に割り当てられたＤ２Ｄリソースが依然として使用可能であるとは限らない。モビリティ時、割り当てられているＤ２Ｄリソースの扱いは以下のとおりである。
・  そのまま維持する
−  Ｘ２で交渉する。例えば隣接セルは、Ｄ２Ｄ発見メッセージの送信用に同じ物理リソースを予約する
・  ハンドオーバー（ＨＯ）コマンド／再確立メッセージ（および再設定メッセージ）においてハンドオーバー先セルによって再設定する
・  ハンドオーバー（ＨＯ）コマンドを受信したとき、リソースを設定解除／解放する
−  ユーザ機器は、ハンドオーバー後、ハンドオーバー先セルにおいてリソースを要求する（ハンドオーバー先セルのｅＮＢは、ハンドオーバー元のセルと同じリソースまたは新しいリソースを割り当てることができる）
【０２４３】
発見メッセージ用のタイプ２Ｂリソースの解放
【０２４４】
有利な一実装形態によると、専用のリソース（タイプ２Ｂ）がもはや不要になったとき（すなわちユーザ機器がＤ２Ｄ発見メッセージを送信しない）、そのリソースをユーザ機器によって解放することができる。これに代えて、リソースを解放するようにｅＮＢが要求することができる（例えばＬＴＥセルラー通信における輻輳を回避するため）。このような解放は、以下に説明するように行うことができる。
・  暗黙的な解放
−  （設定された／指定された）タイマーが切れたとき
○  ユーザ機器は、そのリソース（タイプ２Ｂのリソース）をさらに維持することを望む場合、「キープアライブ」シグナリングをｅＮＢに送る必要がある。
−  モビリティ（ハンドオーバー、再確立）時：  ユーザ機器は、ハンドオーバー元セルにおいて使用していたタイプ２Ｂのリソースを単に放棄する。
−  ＲＲＣ接続の解放時（ＲＡＮ２＃８５においてすでに決定されている）：  ユーザ機器は、ハンドオーバー元セルにおいて使用していたタイプ２Ｂのリソースを単に放棄する。
・  明示的な解放
−  新規のシグナリング（ＲＲＣ、ＭＡＣ  ＣＥなど）
○  ユーザ機器がそのリソースをもはや必要としない場合、（２Ｂの解放を開始する）ユーザ機器から
○  ＬＴＥ（オーバーレイ）ネットワークにおいて輻輳が発生した場合、（２Ｂの解放を開始する）ネットワークから
ネットワークがタイプ２Ｂのリソースの解放を開始した時点で、ユーザ機器は、依然として発見メッセージ／信号を送信する必要がある場合、タイプ１のリソースの使用を開始することができる。
【０２４５】
Ｄ２Ｄに関連するシステム情報ブロードキャスト（ＳＩＢ）
【０２４６】
Ｄ２Ｄ  ＳＩＢは、アンダーレイネットワークにおけるＤ２Ｄ発見手順に関連する情報のブロードキャストである。この情報は、オーバーレイ（ＬＴＥ）ネットワークにのみ関心のあるユーザ機器には使用されない、または有用ではないことがある。ネットワークは、Ｄ２Ｄに関連する情報（Ｄ２Ｄ  ＳＩＢと称する）を個別のシステム情報ブロック（ＳＩＢ）においてブロードキャストすることができる。同じＳＩＢまたは異なるＳＩＢが、セル間発見メッセージを受信するためのＤ２Ｄリソースを示すことができる。
現在のセルにおける受信リソース＝現在のセルにおける送信リソース＋隣接セルからの送信リソース
【０２４７】
Ｄ２Ｄ  ＳＩＢの変更
【０２４８】
Ｄ２Ｄ  ＳＩＢの変更に関する情報を伝える新規のページングメッセージ（新規のＤ２Ｄ  Ｐ−ＲＮＴＩ）を使用することができる。これに代えて、タイマーに基づく（「ｘ」ｍｓより短い頻度では変更されない）メカニズムを使用することができ、したがって関心のあるＤ２Ｄ装置は、タイマーが切れたときに（のみ）Ｄ２Ｄ  ＳＩＢを再取得すればよい。別の代替形態として、Ｄ２Ｄ  ＳＩＢの変更によって、本日のＳＩＢ１内の値タグに影響を与える、または、自身の値タグを有することができる。
【０２４９】
本発明のハードウェアおよびソフトウェア実装
【０２５０】
本発明の別の態様は、上述したさまざまな実施形態および態様を、ハードウェアおよびソフトウェアを使用して実施することに関する。これに関連して、本発明は、ユーザ機器（移動端末）およびｅＮｏｄｅＢ（基地局）を提供する。ユーザ機器は、本明細書に記載されている方法を実行するようにされている。さらに、ｅＮｏｄｅＢは、各ユーザ機器のＩＰＭＩ設定品質（IPMI set quality）を、ユーザ機器から受信されたＩＰＭＩ設定品質から評価し、自身のスケジューラが異なるユーザ機器をスケジューリングするとき、それら異なるユーザ機器のＩＰＭＩ設定品質を考慮することを可能にする手段、を備えている。
【０２５１】
さらに、本発明のさまざまな実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行できることを認識されたい。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または、その他プログラマブルロジックデバイスなどである。本発明のさまざまな実施形態は、これらのデバイスの組合せによって実行または具体化することもできる。
【０２５２】
さらに、本発明のさまざまな実施形態は、ソフトウェアモジュールによって実施することもでき、ソフトウェアモジュールは、プロセッサによって実行される、またはハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭやＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納され得る。
【０２５３】
さらには、本発明の複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の発明の主題とすることができることに留意されたい。
【０２５４】
具体的な実施形態に示した本発明には、広義に記載されている本発明の趣旨または範囲から逸脱することなく、さまざまな変更や修正を行うことができることが、当業者には理解されるであろう。したがって、本発明の実施形態は、あらゆる点において説明を目的としており、本発明を制限するものではないものとみなされたい。
【図１】
2020109990.tif 000005
【図２】
2020109990.tif 000006
【図３】
2020109990.tif 000007
【図４】
2020109990.tif 000008
【図５】
2020109990.tif 000009
【図６】
2020109990.tif 000010
【図７】
2020109990.tif 000011
【図８】
2020109990.tif 000012
【図９】
2020109990.tif 000013
【図１０】
2020109990.tif 000014
【図１１】
2020109990.tif 000015
【図１２】
2020109990.tif 000016
【図１３】
2020109990.tif 000017
【図１４】
2020109990.tif 000018
【図１５】
2020109990.tif 000019