(57)【要約】  本発明は、１基以上の受信側エンティティに車両用データおよび他のデータを送信する改良された車両用ＵＥに関する。車両用ＵＥは、車両用移動端末が車両用データおよび／または他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、車両用移動端末が所属しているセルを制御する無線基地局から受信する。車両用ＵＥは、アップリンクグラントにおいて示された無線リソースを使用して車両用データおよび／または他のデータを送信する。車両用移動端末は、車両用データおよび他のデータを互いに個別に処理する。
2019517173.tif 000002
【特許請求の範囲】
【請求項１】
車両用データおよび他のデータを１つ以上の受信エンティティに送信する車両用移動端末であって、
前記車両用移動端末が前記車両用データおよび／または前記他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、前記車両用移動端末が所属されたセルを制御する無線基地局から受信するように動作する受信部と、
前記アップリンクグラントにおいて示された前記無線リソースを使用して前記車両用データおよび／または前記他のデータを送信するように動作する送信部と、
を備え、
前記車両用データおよび前記他のデータを互いに個別に処理するように動作する、
車両用移動端末。
【請求項２】
前記受信したアップリンクグラントは、前記車両用移動端末が前記車両用データの送信のために使用する無線リソースを示す車両用データ専用アップリンクグラントであり、
前記送信部は、前記車両用データ専用アップリンクグラントにおいて示された前記無線リソースを使用して前記車両用データを送信するように動作し、
任意選択的に、前記車両用データ専用アップリンクグラントは、
前記車両用移動端末の車両用データ専用識別子でスクランブルされているか、または、前記示された無線リソースが前記車両用データの送信のために使用されるものであることを示す情報を含み、任意選択的に、前記情報は、前記車両用データ専用アップリンクグラントの個別フィールドに含まれているか、または前記車両用データ専用アップリンクグラントの少なくとも１つのフィールドのコードポイントとして符号化されている、
請求項１に記載の車両用移動端末。
【請求項３】
前記受信したアップリンクグラントは、前記車両用移動端末が前記車両用データおよび前記他のデータの送信のために使用することができる無線リソースを示す共通アップリンクグラントであり、
プロセッサが、前記共通アップリンクグラントにおいて示された前記無線リソースが前記車両用データの送信のために使用されるものであるか、前記他のデータの送信のために使用されるものであるか、あるいは前記車両用データおよび前記他のデータの送信のために使用されるものであるかを判定するように動作し、任意選択的に、前記判定は、前記他のデータを搬送する論理チャネルに関連付けられた優先度および前記車両用データを搬送する車両用データ論理チャネルに関連付けられた優先度に基づいており、
前記送信部は、判定された前記車両用データおよび／または前記他のデータを、前記共通アップリンクグラントにおいて示された前記無線リソースを使用して送信するように動作する、
請求項１に記載の車両用移動端末。
【請求項４】
プロセッサが、前記アップリンクグラントにおいて示された前記無線リソースを、前記車両用データを搬送する車両用データ論理チャネルに、および／または前記他のデータを搬送する論理チャネルに優先度の高い順に配置するための第１の論理チャネル優先順位付けプロシージャを実行して、前記車両用データおよび／または前記他のデータを搬送するデータパケットを生成するように動作し、
前記プロセッサは、
前記受信したアップリンクグラントにおいて示された前記無線リソースが前記車両用データの送信のために使用されるものである場合、前記車両用データを搬送するデータパケットを生成するために、前記車両用データを搬送する車両用論理チャネルのみを考慮して前記第１の論理チャネル優先順位付けプロシージャを実行するように動作し、
前記受信したアップリンクグラントにおいて示された前記無線リソースが前記他のデータの送信のために使用されるものである場合、前記他のデータを搬送するデータパケットを生成するために、前記他のデータを搬送する論理チャネルのみを考慮して前記第１の論理チャネル優先順位付けプロシージャを実行するように動作し、
前記受信したアップリンクグラントにおいて示された前記無線リソースが前記他のデータおよび前記車両用データの送信のために使用されるものである場合、前記車両用データおよび前記他のデータを搬送するデータパケットを生成するために、前記車両用データを搬送する前記車両用論理チャネルおよび前記他のデータを搬送する前記論理チャネルの両チャネルを考慮して前記第１の論理チャネル優先順位付けプロシージャを実行するように動作する、
請求項１〜３のいずれか一項に記載の車両用移動端末。
【請求項５】
少なくとも１つの車両用データ論理チャネルが、前記車両用データを搬送するために前記車両用移動端末に設定されており、各車両用データ論理チャネルは、それぞれが搬送する前記車両用データに応じた優先度と関連付けられており、前記車両用データ論理チャネルの前記優先度は、前記他のデータを搬送する論理チャネルに関連付けられた優先度と異なり、
任意選択的に、前記車両用データ論理チャネルのいくつかの優先度は、前記他のデータを搬送する論理チャネルの優先度より高く、任意選択的に、安全性メッセージを搬送する車両用データ論理チャネルの優先度のみが、前記他のデータを搬送する論理チャネルの優先度より高い、
請求項１〜４のいずれか一項に記載の車両用移動端末。
【請求項６】
プロセッサが、前記車両用移動端末において送信可能な前記車両用データの量、および前記車両用移動端末において送信可能な前記他のデータの量を個別に示すバッファ状況報告を生成するように動作し、
任意選択的に、前記車両用データを搬送する車両用データ論理チャネルが、少なくとも１つの車両用データ論理チャネルグループに割り当てられ、前記バッファ状況報告は、前記車両用データ論理チャネルグループのすべての前記車両用データ論理チャネルから送信可能な車両用データの量を示すために生成され、
任意選択的に、前記車両用データ論理チャネルの前記少なくとも１つの車両用データ論理チャネルグループへの割当ては、前記無線基地局によって制御される、
請求項１〜５のいずれか一項に記載の車両用移動端末。
【請求項７】
前記車両用データおよび前記他のデータは、サイドリンク無線インタフェースを介して他の車両用エンティティに送信され、前記車両用移動端末は、前記サイドリンク無線インタフェースを介した送信を行うために使用可能な無線リソースをそれぞれが示す少なくとも１つの無線リソースプールを有するように設定され、前記プロセッサは、前記車両用データおよび前記他のデータの内容に応じて前記車両用データまたは前記他のデータを優先し、優先された前記車両用データまたは前記他のデータを送信するために前記無線リソースプールの１つから無線リソースを選択するように動作する、
請求項１〜６のいずれか一項に記載の車両用移動端末。
【請求項８】
前記送信部は、前記無線基地局に車両用データスケジューリング要求を送信して無線リソースを要求するように動作し、前記車両用データスケジューリング要求は、要求した前記無線リソースが車両用データの送信のために使用されるものであること示し、
任意選択的に、前記受信部は、前記送信した車両用データスケジューリング要求に対する前記無線基地局からの第２のアップリンクグラントを受信するように動作し、前記送信部は、前記第２のアップリンクグラントにおいて示された前記無線リソースを使用して前記車両用データを送信するように動作する、
請求項１〜７のいずれか一項に記載の車両用移動端末。
【請求項９】
前記車両用データおよび前記他のデータは、第１の無線インタフェースを介して前記無線基地局に、および／またはサイドリンク無線インタフェースを介して他の車両用エンティティに送信される、
請求項１〜８のいずれか一項に記載の車両用移動端末。
【請求項１０】
前記受信部は、車両用データトラフィックおよび対応するサービス品質要件をサポートすることができるコアネットワークエンティティに無線基地局が接続されていることを示す車両用データ適性インジケーションを、複数の無線基地局の少なくとも１つから受信するように動作し、
前記車両用移動端末のプロセッサは、前記複数の無線基地局の中から、前記受信した車両用データ適性インジケーションの送信元である１つの無線基地局を選択して該１つの無線基地局に所属するように動作し、
任意選択的に、前記車両用データ適性インジケーションは、システム情報の一部として無線基地局によってブロードキャストされ、
任意選択的に、前記車両用データ適性インジケーションは、車両用データトラフィックが前記車両用移動端末と前記無線基地局との間で第１の無線インタフェースを介して、および／または前記車両用移動端末と他の車両用エンティティとの間でサイドリンク無線インタフェースを介してサポートされているかをさらに示す、
請求項１〜９のいずれか一項に記載の車両用移動端末。
【請求項１１】
前記送信部は、前記車両用移動端末が前記１つの無線基地局に所属する際に車両用データを送信する予定であることを示すように動作し、
任意選択的に、車両用データを送信する前記予定のインジケーションは、接続要求メッセージまたは接続再設定完了メッセージに含まれる、
請求項１０に記載の車両用移動端末。
【請求項１２】
車両用データおよび他のデータを１つ以上の受信エンティティに送信する車両用移動端末を制御する無線基地局であって、
前記車両用移動端末が前記車両用データおよび／または前記他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、前記車両用移動端末に送信するように動作する送信部と、
前記アップリンクグラントにおいて示された前記無線リソース上の前記車両用データおよび／または前記他のデータを受信するように動作する受信部と、
を備え、
前記車両用データが前記他のデータとは個別に処理されるように前記車両用移動端末を制御するように動作する、
無線基地局。
【請求項１３】
前記受信されたアップリンクグラントは、前記車両用移動端末が前記車両用データの送信のために使用することができる無線リソースを示す車両用データ専用アップリンクグラントであり、
任意選択的に、前記車両用データ専用アップリンクグラントは、
前記無線基地局のプロセッサによって前記車両用移動端末の車両用データ専用識別子でスクランブルされているか、または、
前記示された無線リソースが前記車両用データの送信のために使用されるものであることを示す情報を含み、任意選択的に、前記情報は、前記車両用データ専用アップリンクグラントの個別フィールドに含まれているか、または前記車両用データ専用アップリンクグラントの少なくとも１つのフィールドのコードポイントとして符号化されている、
請求項１２に記載の無線基地局。
【請求項１４】
少なくとも１つの車両用データ論理チャネルが、前記車両用データを搬送するために前記車両用移動端末に設定されており、各車両用データ論理チャネルは、それぞれが搬送する前記車両用データに応じた優先度と関連付けられており、前記車両用データ論理チャネルの前記優先度は、前記他のデータを搬送する論理チャネルに関連付けられた優先度と異なり、
任意選択的に、前記車両用データ論理チャネルのいくつかの優先度は、前記他のデータを搬送する論理チャネルの優先度より高く、任意選択的に、安全性メッセージを搬送する車両用データ論理チャネルの優先度のみが、前記他のデータを搬送する論理チャネルの優先度より高い、
請求項１２または１３に記載の無線基地局。
【請求項１５】
前記受信部が、前記車両用移動端末において送信可能な前記車両用データの量、および前記車両用移動端末において送信可能な前記他のデータの量を個別に示すバッファ状況報告を受信するように動作し、
任意選択的に、前記車両用データを搬送する車両用データ論理チャネルが、少なくとも１つの車両用データ論理チャネルグループに割り当てられ、前記バッファ状況報告は、前記車両用データ論理チャネルグループのすべての前記車両用データ論理チャネルから送信可能な車両用データの量を示し、
任意選択的に、前記車両用データ論理チャネルの前記少なくとも１つの車両用データ論理チャネルグループへの割当ては、前記無線基地局によって制御される、
請求項１２〜１４のいずれか一項に記載の無線基地局。
【請求項１６】
前記受信部は、無線リソースを要求する車両用データスケジューリング要求を前記車両用移動端末から受信するように動作し、前記車両用データスケジューリング要求は、要求された前記無線リソースが車両用データの送信のために使用されるものであること示し、
任意選択的に、前記送信部は、前記車両用データの送信のために使用される無線リソースを示す第２のアップリンクグラントを、前記受信した車両用データスケジューリング要求に対して前記車両用移動端末に送信するように動作し、前記受信部は、前記第２のアップリンクグラントにおいて示された無線リソースを使用して前記車両用データを受信するように動作する、
請求項１２〜１５のいずれか一項に記載の無線基地局。
【請求項１７】
前記車両用データおよび前記他のデータは、第１の無線インタフェースを介して前記無線基地局に、および／またはサイドリンク無線インタフェースを介して他の車両用エンティティに送信される、
請求項１２〜１６のいずれか一項に記載の無線基地局。
【請求項１８】
車両用データトラフィックおよび対応するサービス品質要件をサポートすることができるコアネットワークエンティティに無線基地局が接続されていることを示す車両用データ適性インジケーションを前記送信部が送信する結果、前記車両用移動端末は、受信される車両用データ適性インジケーションの送信元である無線基地局を選択して該１つの無線基地局に所属することができ、
任意選択的に、前記車両用データ適性インジケーションは、システム情報の一部として無線基地局によってブロードキャストされ、
任意選択的に、前記車両用データ適性インジケーションは、車両用データトラフィックが前記車両用移動端末と前記無線基地局との間で第１の無線インタフェースを介して、および／または前記車両用移動端末と他の車両用エンティティとの間でサイドリンク無線インタフェースを介してサポートされているかをさらに示す、
請求項１２〜１７のいずれか一項に記載の無線基地局。
【請求項１９】
前記受信部は、前記車両用移動端末が前記無線基地局に所属する際に車両用データを送信する予定であることを示すインジケーションを受信するように動作し、
任意選択的に、車両用データを送信する予定の前記インジケーションは、接続要求メッセージまたは接続再設定完了メッセージに含まれる、
請求項１８に記載の無線基地局。
【請求項２０】
車両用移動端末が車両用データおよび他のデータを１つ以上の受信エンティティに送信するための方法であって、
前記車両用移動端末が前記車両用データおよび／または前記他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、前記車両用移動端末が所属されたセルを制御する無線基地局から受信するステップと、
前記アップリンクグラントにおいて示された前記無線リソースを使用して前記車両用データおよび／または前記他のデータを送信するステップと、
を含み、
前記車両用移動端末は、前記車両用データおよび前記他のデータを互いに個別に処理する、
方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、車両用移動端末による車両用データおよび他のデータの改良された送信に関する。本開示は、対応する（車両用）移動端末および無線基地局を提供する。
【背景技術】
【０００２】
［ＬＴＥ（Long Term Evolution）］
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High-Speed Downlink Packet Access）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ：High-Speed Uplink Packet Access）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。
【０００３】
ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、３ＧＰＰは、ＬＴＥと称される新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、ＬＴＥにおける重要な方策である。
【０００４】
ＬＴＥに関する作業項目（ＷＩ：working item）の仕様は、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access）およびＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）と称され、最終的にリリース８（ＬＴＥリリース８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（例えば、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚ）が指定されている。ダウンリンクには、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）をベースとする無線アクセスが採用されている。かかる無線アクセスを採用する理由は、この無線アクセスが低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ：Multipath Interference）を受けにくいこと、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）が使用されていること、および、さまざまな送信帯域幅の構成に対応可能なことである。アップリンクには、ＳＣ−ＦＤＭＡ（Single-Carrier Frequency Division Multiple Access：シングルキャリア周波数分割多元接続）をベースとする無線アクセスが採用されている。ユーザ機器（ＵＥ：User Equipment）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥリリース８／９では、数多くの主要なパケット無線アクセス技術（例えば、ＭＩＭＯ（Multiple-Input Multiple-Output）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が達成されている。
【０００５】
［ＬＴＥのアーキテクチャ］
ＬＴＥの全体的なアーキテクチャは、図１に示してある。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成され、ｅＮｏｄｅＢは、ユーザ機器（ＵＥ：User Equipment）向けの、Ｅ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルを終端させる。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ：Medium Access Control）レイヤ、無線リンク制御（ＲＬＣ：Radio Link Control）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ：Packet Data Control Protocol）レイヤ（これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。複数のｅＮｏｄｅＢは、Ｘ２インタフェースによって互いに接続されている。
【０００６】
また、複数のｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（Evolved Packet Core）、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（Mobility Management Entity：モビリティ管理エンティティ）、Ｓ１−Ｕによってサービングゲートウェイ（ＳＧＷ：Serving GateWay）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングして転送する一方で、ｅＮｏｄｅＢ間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インタフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ  ＧＷとの間でトラフィックを中継する）として機能する。ＳＧＷは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガする。ＳＧＷは、ユーザ機器のコンテキスト（例えばＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法的傍受の場合にユーザトラフィックの複製を実行する。
【０００７】
ＭＭＥは、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのユーザ機器の追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラのアクティブ化／非アクティブ化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ：Core Network）ノードの再配置を伴うＬＴＥ内ハンドオーバー時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法的傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インタフェースを終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのホームＨＳＳに向かうＳ６ａインタフェースを終端させる。
【０００８】
［ＬＴＥにおけるコンポーネントキャリアの構造］
３ＧＰＰ  ＬＴＥシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。３ＧＰＰ  ＬＴＥでは、各サブフレームは、図２に示すように２つのダウンリンクスロットに分割されており、第１のダウンリンクスロットが、第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を含んでいる。各サブフレームは、時間領域における所定の数のＯＦＤＭシンボルから構成され（３ＧＰＰ  ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがってＯＦＤＭシンボルそれぞれは、それぞれのサブキャリアで送信される複数の変調シンボルから構成される。ＬＴＥでは、各スロットにおける送信信号は、ＮＤＬＲＢ×ＮＲＢｓｃ本のサブキャリアとＮＤＬｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドによって記述される。ＮＤＬＲＢは、帯域幅の中のリソースブロックの数である。数ＮＤＬＲＢは、セルにおいて設定されているダウンリンク送信帯域幅に依存し、Ｎｍｉｎ，ＤＬＲＢ≦ＮＤＬＲＢ≦Ｎｍａｘ，ＤＬＲＢを満たし、この場合、Ｎｍｉｎ，ＤＬＲＢ＝６およびＮｍａｘ，ＤＬＲＢ＝１１０は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。ＮＲＢｓｃは、１個のリソースブロックの中のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、ＮＲＢｓｃ＝１２、ＮＤＬｓｙｍｂ＝７である。
【０００９】
例えば３ＧＰＰ  ＬＴＥにおいて使用されるような（例えば、ＯＦＤＭを使用する）マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Physical Resource Block）は、図２に例示したように、時間領域における連続するＯＦＤＭシンボル（例えば７個のＯＦＤＭシンボル）および周波数領域における連続するサブキャリア（例えばコンポーネントキャリアの１２本のサブキャリア）として定義される。したがって３ＧＰＰ  ＬＴＥ（リリース８）では、物理リソースブロックはリソースエレメントから構成され、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細は、例えば、参照により本明細書に援用される非特許文献１の第６．２節（http://www.3gpp.orgで入手可能）を参照）。
【００１０】
１つのサブフレームが２つのスロットで構成されているため、いわゆる「通常の」サイクリックプレフィックス（normal CP）が使用されるときにはサブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」サイクリックプレフィックス（extended CP）が使用されるときにはサブフレーム内に１２個のＯＦＤＭシンボルが存在する。専門用語のために、以下で、サブフレーム全体に広がる同一の連続するサブキャリアと同等の時間−周波数リソースは、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ばれる。
【００１１】
「コンポーネントキャリア（Component Carrier）」という用語は、周波数領域におけるいくつかのリソースブロックの組合せを示す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、この専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。
【００１２】
コンポーネントキャリアの構造に関する同様の想定が以降のリリースにも適用される。
【００１３】
［より広い帯域幅のサポートのためのＬＴＥ−Ａにおけるキャリアアグリゲーション］
世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、３ＧＰＰにおいて無線インタフェースの標準化が開始された。３ＧＰＰ  ＴＳＧ  ＲＡＮ  ＃３９会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目（Study Item）の記述が承認された。この検討項目は、Ｅ−ＵＴＲＡを進化・発展させるうえで（例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために）考慮すべき技術要素をカバーしている。
【００１４】
ＬＴＥアドバンストシステムがサポートすることができる帯域幅は１００ＭＨｚであり、一方、ＬＴＥシステムは２０ＭＨｚのみをサポートすることができる。今日、無線スペクトルの不足がワイヤレスネットワークの開発のボトルネックになっている。結果として、ＬＴＥ−Ａｄｖａｎｃｅｄシステムのために十分広いスペクトル帯域を見つけることが困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることが急務であり、キャリアアグリゲーション機能が解決策であり得る。
【００１５】
キャリアアグリゲーションでは、最大で１００ＭＨｚのより広い送信帯域幅をサポートする目的で、２つ以上のコンポーネントキャリアがアグリゲート（aggregate）される。ＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、ＬＴＥシステムにおけるいくつかのセルが、より広い１つのチャネルにアグリゲートされ、このチャネルは、たとえＬＴＥにおけるこれらのセルが異なる周波数帯域にある場合でも１００ＭＨｚに対して十分に広い。
【００１６】
少なくともコンポーネントキャリアの帯域幅がＬＴＥリリース８／９のセルのサポートされる帯域幅を超えないときには、すべてのコンポーネントキャリアをＬＴＥリリース８／９互換であるように設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＬＴＥリリース８／９互換でなくてよい。リリース８／９のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム（例：バーリング（barring））を使用することができる。
【００１７】
ユーザ機器は、自身の能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信することができる。キャリアアグリゲーションのための受信能力および／または送信能力を備えた、ＬＴＥ−Ａリリース１０のユーザ機器は、複数のサービングセル上で同時に受信および／または送信することができる。これに対して、ＬＴＥリリース８／９のユーザ機器は、コンポーネントキャリアの構造がリリース８／９の仕様に従う場合、１つのみのサービングセル上で受信および送信を行うことができる。
【００１８】
キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、各コンポーネントキャリアは、（３ＧＰＰ  ＬＴＥ（リリース８／９）のニューメロロジー（numerology）を使用して）周波数領域における最大１１０個のリソースブロックに制限される。
【００１９】
同一のｅＮｏｄｅＢ（基地局）から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、３ＧＰＰ  ＬＴＥ−Ａ（リリース１０）互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。現時点では、移動端末にダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアを多く設定することはできない。一般的なＴＤＤ配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同一である。同一のｅＮｏｄｅＢから送信されるコンポーネントキャリアは、同一のカバレッジを提供する必要はない。
【００２０】
連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、３００ｋＨｚの倍数である。これは、３ＧＰＰ  ＬＴＥ（リリース８／９）の１００ｋＨｚの周波数ラスターとの互換性を保つと同時に、１５ｋＨｚ間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、ｎ×３００ｋＨｚの間隔あけを容易にすることができる。
【００２１】
複数のキャリアをアグリゲートする影響は、ＭＡＣレイヤに及ぶのみである。ＭＡＣレイヤには、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに１つのＨＡＲＱエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大１個である（アップリンクにおけるＳＵ−ＭＩＭＯを使用しない場合）。トランスポートブロックおよびそのＨＡＲＱ再送信（発生時）は、同一のコンポーネントキャリアにマッピングする必要がある。
【００２２】
キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの１つのＲＲＣ接続のみを有する。ＲＲＣ接続の確立／再確立時、１つのセルが、ＬＴＥリリース８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）と、非アクセス層（ＮＡＳ）モビリティ情報（例：ＴＡＩ）とを提供する。ＲＲＣ接続の確立／再確立の後、そのセルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル（ＰＣｅｌｌ）と称される。接続状態では、ユーザ機器あたりつねに１つのダウンリンクＰＣｅｌｌ（ＤＬ  ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ  ＰＣｅｌｌ）が設定される。コンポーネントキャリアの設定されたセットおいて、他のセルはセカンダリセル（ＳＣｅｌｌ）と呼ばれ、ＳＣｅｌｌのキャリアはダウンリンクセカンダリコンポーネントキャリア（ＤＬ  ＳＣＣ）およびアップリンクセカンダリコンポーネントキャリア（ＵＬ  ＳＣＣ）である。１基のＵＥに対して、最大５つのサービングセル（ＰＣｅｌｌを含む）を設定することができる。
【００２３】
［ＭＡＣレイヤ／ＭＡＣエンティティ、無線ベアラ、ＱｏＳ］
ＬＴＥのＬ２レイヤのユーザプレーン／制御プレーンのプロトコルスタックは、４つのサブレイヤ、すなわちＲＲＣ、ＰＤＣＰ、ＲＬＣ、およびＭＡＣを備えている。媒体アクセス制御（ＭＡＣ）レイヤは、ＬＴＥの無線プロトコルスタックのＬ２アーキテクチャにおける最も下のサブレイヤであり、例えば３ＧＰＰ技術規格である非特許文献２によって定義されている。ＭＡＣレイヤは、下の物理レイヤとはトランスポートチャネルを通じて接続されており、上のＲＬＣレイヤとは論理チャネルを通じて接続されている。したがって、ＭＡＣレイヤは、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を実行する。送信側におけるＭＡＣレイヤは、論理チャネルを通じて受け取るＭＡＣ  ＳＤＵからＭＡＣ  ＰＤＵ（トランスポートブロックとしても知られている）を構築し、受信側におけるＭＡＣレイヤは、トランスポートチャネルを通じて受け取るＭＡＣ  ＰＤＵからＭＡＣ  ＳＤＵを復元する。
【００２４】
参照によってその全体が本明細書に援用される、技術規格である非特許文献２の第４．２．１節「ＭＡＣエンティティ」（“MAC Entities”）に示されるように、図３は、ＵＥ側ＭＡＣエンティティのありうる構造の１つを示す。一般的に、ＵＥのＭＡＣサブレイヤが以下の機能をサポートする。
−  論理チャネルとトランスポートチャネルの間のマッピング；
−  １つまたは様々な論理チャネルからのＭＡＣ  ＳＤＵの、物理レイヤからトランスポートチャネルで送達されるトランスポートブロック（ＴＢ）への多重化；
−  １つまたは様々な論理チャネルからのＭＡＣ  ＳＤＵの、物理レイヤからトランスポートチャネルで送達されるトランスポートブロック（ＴＢ）からの逆多重化；
−  スケジューリング情報の報告；
−  ＨＡＲＱによる誤り訂正；
−  論理チャネルの優先順位付け（Logical Channel Prioritization）；
−  ＳＬ用の無線リソースの選択。
【００２５】
図３から明らかなように、ＭＡＣエンティティは、また、ハイブリッドＡＲＱ（ＨＡＲＱ）エンティティ、多重化および逆多重化エンティティ、および論理チャネル優先順位付けエンティティ（アップリンクについてのみ）等のさらなるエンティティ（機能）ならびにＭＡＣエンティティの様々な制御機能を行うコントローラを備える。ＭＡＣエンティティ／ＭＡＣ機能は、参照によりその全体が本明細書に援用される非特許文献２の、例えば第５節「ＭＡＣプロシージャ」（“MAC procedure”）に詳細に定義される。
【００２６】
多重化および逆多重化エンティティでは、いくつかの論理チャネルからのデータを１つのトランスポートチャネルに多重化することも、１つのトランスポートチャネルからいくつかの論理チャネルのデータを逆多重化することもできる。多重化エンティティは、無線リソースが新規送信に利用可能な場合、ＭＡＣ  ＳＤＵからＭＡＣ  ＰＤＵを生成する。このプロセスには、どれだけのデータが各ＭＡＣ  ＰＤＵに含まれるべきか、および、いずれの論理チャネルからのデータが各ＭＡＣ  ＰＤＵに含まれるべきかを決定するために、論理チャネルからのデータの優先順位付けを行うことが含まれる。
【００２７】
ＭＡＣレイヤは、論理チャネルを通じてＲＬＣレイヤにデータ伝送サービスを提供し（参照により本明細書に援用される非特許文献２の第５．４節および第５．３節を参照）、この論理チャネルは、制御データ（例えばＲＲＣシグナリング）を伝える制御論理チャネル、またはユーザプレーンデータを伝えるトラフィック論理チャネルのいずれかである。図３に示されるように、定義される制御論理チャネルは、ブロードキャスト制御チャネル（ＢＣＣＨ：Broadcast Control CHannel）、ページング制御チャネル（ＰＣＣＨ：Paging Control CHannel）、共通制御チャネル（ＣＣＣＨ：Common Control CHannel）、マルチキャスト制御チャネル（ＭＣＣＨ：Multicast Control CHannel）、および個別制御チャネル（ＤＣＣＨ：Dedicated Control CHannel）である。トラフィック論理チャネルは、個別トラフィックチャネル（ＤＴＣＨ：Dedicated Traffic CHannel）およびマルチキャストトラフィックチャネル（ＭＴＣＨ：Multicast Traffic CHannel）である。
【００２８】
論理チャネルは、以下に詳細に説明するように、例えばバッファ状態を報告する目的で、０〜３のＬＣＧ  ＩＤを有する４つの異なる論理チャネルグループ（ＬＣＧ：Logical Channel Group）の１つに関連付けられている。
【００２９】
一方、ＭＡＣレイヤからのデータはトランスポートチャネル（ダウンリンクまたはアップリンクとして分類される）を通じて物理レイヤと交換される。無線を通じた送信方式に応じて、データがトランスポートチャネルに多重化される。定義されるダウンリンクトランスポートチャネルは、ブロードキャストチャネル（ＢＣＨ：Broadcast CHannel）、ダウンリンク共有チャネル（ＤＬ−ＳＣＨ：Downlink Shared CHannel）、ページングチャネル（ＰＣＨ：Paging CHannel）、およびマルチキャストチャネル（ＭＣＨ：Multicast CHannel）である。定義されるアップリンクトランスポートチャネルは、アップリンク共有チャネル（ＵＬ−ＳＣＨ：Uplink Shared CHannel）およびランダムアクセスチャネル（ＲＡＣＨ：Random Access CHannel）である。論理チャネルおよびトランスポートチャネル、ならびにこれらのチャネル間のマッピングに関するさらなる情報を、参照によってその全体が本明細書に援用される、３ＧＰＰの技術規格である非特許文献２の第４．５節「チャネル構造」（“Channel Structure”）で見ることができる。
【００３０】
物理レイヤは、データおよび制御情報をエアインタフェースを介して実際に送信する役割を担い、すなわち物理レイヤは、送信側ではＭＡＣトランスポートチャネルからのすべての情報をエアインタフェースを通じて伝える。
【００３１】
ＬＴＥアーキテクチャを使用するモバイルネットワークにおいて、ベアラは、ユーザ機器をインターネットのようなパケットデータネットワーク（ＰＤＮ：Packet Data Network）に接続するために使用される「トンネル」である。ＬＴＥネットワークでは、ＱｏＳがＵＥとＰＤＮゲートウエイとの間に実装され、ひとまとまりのベアラに適用される。「ベアラ」とは、基本的に、ひとまとまりのトラフィックを特別に処理するための仮想概念およびネットワーク設定一式である。例えば、ウェブブラウザトラフィックよりもＶｏＩＰパケットがネットワークによって優先される。本質上、様々な特性（例えば、遅延、送達時間、スループット、ＳＮＲ、誤り率ジッタ等）を有する各ストリームが様々なベアラにマッピングされる。したがって、ベアラはＱｏＳ制御の単位であり、１つのベアラを一組のＱｏＳ要件を満たすために使用する。
【００３２】
各ベアラは、トランスポートチャネルのプロパティ（例えば、ビットレート、パケット遅延、パケット損失、ビット誤り率、およびスケジューリングポリシー）を記述するＱｏＳパラメータセットを使用する。ここで、４つの主要パラメータの概要を述べる。
【００３３】
ＱｏＳクラスインジケータ（ＱＣＩ：QoS Class Indicator）：  ＱＣＩは、基本的には、期待される一意のベアラ処理を定義し、ネットワークノードが様々なベンダーによって開発された場合であっても、同一のＱＣＩのベアラを同様に扱うことが意図される。受信したＱＣＩ値に基づいて、各ネットワークノードは、対応する関連ベアラを処理する方法を知る。すなわち、１つのＱＣＩ値が、１つのベアラに関連付けられている。現在定義されるＱＣＩ値のリストを３ＧＰＰの非特許文献３の第６．１．７節で見ることができる。
【００３４】
割当ておよび保持の優先度（ＡＲＰ：Allocation and Retention Priority）：  ＡＲＰは、ベアラが受信する制御プレーントラフィックの転送処理を特定する。ＡＲＰによって、ベアラの確立および修正、ならびに接続の設定および解除が可能になる。例えば、ＡＲＰは、リソースが制限される際またはトラフィック輻輳の際にいずれのベアラを解除すべきかを決定するために、ＥＰＳによって使用可能である。
【００３５】
最大ビットレート（ＭＢＲ：Maximum Bit Rate）：  ＭＢＲは、リアルタイムサービスに対してのみ適用可能であり、ＧＢＲベアラに対して定義される。ＭＢＲは、ベアラ上のトラフィックが超えてはならないビットレートである。
【００３６】
保証ビットレート（ＧＢＲ：Guaranteed Bit Rate）：  ＧＢＲは、ネットワークがそのベアラについて（例えばアドミッションコントロール機能の使用を通じて）保証するビットレートを特定する。３ＧＰＰのリリース８以降では、ＧＢＲと等しいＭＢＲが設定されなければならない。すなわち、保証レートはシステムによって許容される最大レートでもある。
【００３７】
ＱＣＩは、ノード固有パラメータにアクセスするための基準として使用されるスカラーである。ノード固有パラメータは、ベアラレベルでのパケット転送処理を制御するパラメータ（例えば、スケジューリングの重み、アドミッション閾値、キュー管理閾値（queue management thresholds）、リンクレイヤプロトコル設定等）であり、また、事前アクセスノード（例えば、ｅＮｏｄｅＢ）を所有する事業者によって事前に設定されたパラメータである。規格化されたＱＣＩ値と規格化された特性との１対１のマッピングは、非特許文献３に記載されている。
【００３８】
［ＬＴＥにおけるアップリンクアクセス方式］
アップリンク送信では、カバレッジを最大にするため、ユーザ端末は高い電力効率で送信する必要がある。Ｅ−ＵＴＲＡのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのＦＤＭＡとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由は、マルチキャリア信号（ＯＦＤＭＡ）と比較して、ピーク対平均電力比（ＰＡＰＲ：Peak to Average Power Ratio）が低いこと、これに対応して電力増幅器の効率が改善されること、カバレッジも改善されること（与えられる端末ピーク電力に対してデータレートがより高いこと）である。各時間間隔において、ｅＮｏｄｅＢは、ユーザデータを送信するための固有の時間／周波数リソースをユーザに割り当て、これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局（ｅＮｏｄｅＢ）において対処する。
【００３９】
データを送信するために使用される基本的な物理リソースは、１つの時間間隔（例えばサブフレーム）にわたるサイズＢＷｇｒａｎｔの周波数リソースから構成される（符号化された情報ビットはこのリソースにマッピングされる）。送信時間間隔（ＴＴＩ：Transmission Time Interval）（例えば、１ｍｓ（すなわち、１サブフレーム））がユーザデータ送信において最も小さい時間間隔であることに留意されたい。しかしながら、サブフレームを連結することにより、１ＴＴＩより長い時間にわたる周波数リソースＢＷｇｒａｎｔをユーザに割り当てることができる。
【００４０】
［Ｌ１／Ｌ２制御シグナリング］
スケジューリングされたユーザに、ユーザの割当て状態、トランスポートフォーマット、およびその他の送信関連情報（例：ＨＡＲＱ情報、送信電力制御（ＴＰＣ：transmit power control）コマンド）を知らせる目的で、Ｌ１／Ｌ２制御シグナリングがデータと一緒にダウンリンクで送信される。Ｌ１／Ｌ２制御シグナリングは、サブフレーム内にダウンリンクデータと一緒に多重化される（ユーザ割当てがサブフレーム単位で変化しうるものと想定する）。ユーザ割当てをＴＴＩ（送信時間間隔）ベースで実行することもでき、その場合、ＴＴＩ長を、例えば、サブフレームの倍数とすることができることに留意されたい。ＴＴＩ長を、サービスエリア内ですべてのユーザに対して一定としてもよいし、異なるユーザに対して異なる長さとしてもよいし、ユーザ毎に動的としてもよい。Ｌ１／Ｌ２制御シグナリングは、一般的にはＴＴＩあたり１回のみ送信されればよい。以下では、一般性を失うことなく、ＴＴＩが１サブフレームに等しいものと想定する。
【００４１】
Ｌ１／Ｌ２制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control CHannel）で送信される。ＰＤＣＣＨは、ダウンリンク制御情報（ＤＣＩ：Downlink Control Information）としてメッセージを伝送し、ＤＣＩには、多くの場合、移動端末のための、またはＵＥのグループのためのリソース割当ておよびその他の制御情報が含まれる。いくつかのＰＤＣＣＨを１つのサブフレーム内で送信することができる。
【００４２】
ダウンリンク制御情報は、いくつかのフォーマットの形をとり、これらのフォーマットは、全体のサイズが異なり、また各フォーマットのフィールドに含まれる情報が異なる。ＬＴＥにおいて現在定義されている様々なＤＣＩフォーマットは、参照により本明細書に援用される３ＧＰＰの非特許文献４の第５．３．３．１節に詳細に記載されている。例えば、
−  フォーマット０：  ＤＣＩフォーマット０は、アップリンク送信モード１または２におけるシングルアンテナポート送信を使用したＰＵＳＣＨのためのリソースグラントを送信するために使用される。
−  フォーマット４：  ＤＣＩフォーマット４は、アップリンク送信モード２における閉ループ空間多重化送信を使用したＰＵＳＣＨのスケジューリングに使用される。
−  フォーマット５：  ＤＣＩフォーマット５は、物理サイドリンク制御チャネル（ＰＳＣＣＨ：Physical Sidelink Shared Control Channel）のスケジューリングに使用され、さらに、物理サイドリンク共有チャネル（ＰＳＳＣＨ：Physical Sidelink Shared Channel）のスケジューリングに使用されるＳＣＩフォーマット０のいくつかのフィールドを含む。特定のサーチスペースにマッピングされるＤＣＩフォーマット５における情報ビットの数が同一のサービングセルをスケジューリングするためのフォーマット０のペイロードサイズより少ない場合、フォーマット５のペイロードサイズが、フォーマット０に付加されたパディングビットを含むフォーマット０のペイロードサイズに等しくなるまで、フォーマット５に０が付加される。
【００４３】
サイドリンクの制御情報については、参照により本明細書に援用される、３ＧＰＰの技術規格である非特許文献４の第５．４．３節に定義がある。
【００４４】
ＳＣＩは、１つの宛先ＩＤのためのサイドリンクスケジューリング情報を伝えることができる。ＳＣＩフォーマット０は、ＰＳＳＣＨのスケジューリングに使用するために定義されている。次の情報がＳＣＩフォーマット０によって送信される。
・  周波数ホッピングフラグ（１ビット）
・  リソースブロック割当ておよびホッピングリソース割当て
・  時間リソースパターン（７ビット）
・  変調・符号化方式（５ビット）
・  タイミングアドバンス指示情報（１１ビット）
・  グループ宛先ＩＤ（８ビット）
【００４５】
［論理チャネル優先順位付け（ＬＣＰ：Logical Channel Prioritization）プロシージャ］
アップリンクに関しては、割り当てられた無線リソースを使用して送信されるＭＡＣ  ＰＤＵをＵＥが生成するプロセスが完全に標準化されている。ＬＣＰプロシージャは、様々なＵＥ実装において最適におよび一貫して、設定されている各無線ベアラのＱｏＳをＵＥが確実に満たすように設計されている。ＵＥは、論理チャネルごとの、新しいＭＡＣ  ＰＤＵに含めるデータ量を、ＰＤＣＣＨでシグナリングされるアップリンク送信リソースグラントメッセージに基づいて決定しなければならず、必要な場合、さらにＭＡＣ制御要素のためのスペースを割り当てなければならない。
【００４６】
複数の論理チャネルからのデータでＭＡＣ  ＰＤＵを構築するとき、最も簡単かつ最も直感的な方法は、絶対的な優先度に基づく方法であり、この方法では、ＭＡＣ  ＰＤＵのスペースを、論理チャネルの優先度の高い順に論理チャネルに割り当てる。すなわち、最も高い優先度の論理チャネルからのデータをＭＡＣ  ＰＤＵにおいて最初に処理し、続いて、次に高い優先度の論理チャネルからのデータを処理し、これをＭＡＣ  ＰＤＵのスペースがすべて占有されるまで続ける。絶対的な優先度に基づく方法は、ＵＥの実装の観点において極めて単純であるが、低い優先度の論理チャネルからのデータのリソース不足（starvation）につながることがある。リソース不足とは、高い優先度の論理チャネルからのデータがＭＡＣ  ＰＤＵのスペースすべてを占有するため、低い優先度の論理チャネルからのデータを送信できないことを意味する。
【００４７】
ＬＴＥでは、重要度の順にデータを送信するために、また、低い優先度のデータのリソース不足を回避するために各論理チャネルに優先ビットレート（ＰＢＲ：Prioritized Bit Rate）が定義される。ＰＢＲは、論理チャネルに対して保証される最小データレートである。たとえ論理チャネルの優先度が低い場合でも、ＰＢＲを保証するため少なくとも少量のＭＡＣ  ＰＤＵスペースが割り当てられる。したがってリソース不足の問題は、ＰＢＲを使用することによって回避することができる。
【００４８】
ＰＢＲでのＭＡＣ  ＰＤＵの構築は、２つのラウンドからなる。第１のラウンドで、各論理チャネルは、論理チャネル優先度の高い順に供されるが、ＭＡＣ  ＰＤＵに含まれる各論理チャネルからのデータの量は、初めは、その論理チャネルの設定ＰＢＲ値に対応する量に制限される。すべての論理チャネルがそれらのＰＢＲ値まで供された後に、ＭＡＣ  ＰＤＵ内に余地が残っていた場合、第２のラウンドが実行される。第２のラウンドでは、各論理チャネルは、再び、優先度の高い順に供される。第１のラウンドと比較した第２のラウンドの主な違いは、より低い優先度の各論理チャネルには、より高い優先度のすべての論理チャネルによって送信すべきデータがもうない場合にのみ、ＭＡＣ  ＰＤＵスペースが割り当てられ得るということである。
【００４９】
ＭＡＣ  ＰＤＵは、設定された各論理チャネルからのＭＡＣ  ＳＤＵだけではなく、ＭＡＣ  ＣＥを含んでいてもよい。パディングＢＳＲを除いて、ＭＡＣ  ＣＥは、ＭＡＣ  ＣＥがＭＡＣレイヤの動作を制御するので、論理チャネルからのＭＡＣ  ＳＤＵより高い優先度を有する。したがって、ＭＡＣ  ＰＤＵが構成されるとき、ＭＡＣ  ＣＥは、存在する場合、最初に含まれることになり、残りのスペースが論理チャネルからのＭＡＣ  ＳＤＵのために使用される。次いで、追加のスペースが残され、そのスペースがＢＳＲを含むのに十分な大きさである場合、パディングＢＳＲがトリガされ、ＭＡＣ  ＰＤＵに含まれる。
【００５０】
論理チャネル優先順位付けは、例えば、参照により本明細書に援用される３ＧＰＰの非特許文献２の第５．４．３．１節に規格化されている。論理チャネル優先順位付け（ＬＣＰ）プロシージャは、新規送信が行われる際に適用される。
【００５１】
［バッファ状態報告］
ｅＮｏｄｅＢのアップリンクリソースの割当て（すなわち、アップリンクスケジューリングを支援するために、ＵＥからｅＮｏｄｅＢへのバッファ状態報告（ＢＳＲ：Buffer Status Report）が使用される。ダウンリンクの場合については、ｅＮＢのスケジューラが、各ＵＥに送達されるデータ量を明らかに認識している。しかしながら、アップリンク方向に関しては、スケジューリング決定がｅＮＢで行われ、データのためのバッファがＵＥにあるので、ＵＬ−ＳＣＨを通じて送信される必要があるデータ量を示すために、ＵＥからｅＮＢにＢＳＲが送信されなければならない。
【００５２】
ＬＴＥにおけるバッファ状態報告ＭＡＣ制御要素は、ロングＢＳＲ（４つのＬＣＧ  ＩＤ＃０〜３に対応する４つのバッファサイズフィールドを有する）、または、ショートＢＳＲ（１つのＬＣＧ  ＩＤフィールドおよび１つの対応するバッファサイズフィールドを有する）からなる。バッファサイズフィールドは、論理チャネルグループのすべての論理チャネルに亘って利用可能なデータの総量を示し、様々なバッファサイズレベルの指数として符号化されたバイト数で示される（参照によって本明細書に援用される３ＧＰＰの非特許文献２の第６．１．３．１節も参照されたい）。
【００５３】
ショートＢＳＲおよびロングＢＳＲのいずれがＵＥによって送信されるかは、トランスポートブロックにおいて利用可能な送信リソース、空ではないバッファを有する論理チャネルグループの数、および、ＵＥにおいて特定のイベントがトリガされるかどうかに応じて決まる。
【００５４】
論理チャネルグループの概念を導入する理由は、ＵＥに５つ以上の論理チャネルが設定される場合があるが、個々の論理チャネル毎のバッファ状態報告が引き起こすシグナリングオーバーヘッドが非常に大きいことである。したがって、ｅＮＢは、各論理チャネルを論理チャネルグループに割り当てる。好ましくは、同一かまたは類似したＱｏＳ要件の論理チャネルが、同一の論理チャネルグループ内に割り当てられるべきである。
【００５５】
送信失敗に対してロバストであるために、ＬＴＥのために定義されたＢＳＲ再送信メカニズムがある。アップリンクグラントが受信されるたびに再送信ＢＳＲタイマが開始または再開される。再送信ＢＳＲタイマが満了する前にアップリンクグラントが受信されない場合、他のＢＳＲがＵＥにおいてトリガされる。
【００５６】
ＢＳＲは、次のイベントにおいてトリガされる。
・  バッファが空ではない論理チャネル（すなわち、バッファが先にデータを含んでいた論理チャネル）よりも優先度が高い論理チャネルについてデータが到着する場合
・  任意の論理チャネルについて、送信可能なデータが先に存在していない（すなわち、全てのバッファが以前から空である）ときに、データが利用可能になる場合
・  再送信ＢＳＲタイマが満了する場合
・  周期的ＢＳＲの報告期限が来る（すなわち、周期的ＢＳＲタイマが満了する）場合
・  ＢＳＲを収容することができるトランスポートブロックに予備のスペースがある場合
【００５７】
ＢＳＲに関する、および、具体的にはＢＳＲのトリガリングに関するさらに詳細な情報が、参照により本明細書に援用される３ＧＰＰの非特許文献２の第５．４．５節に説明されている。
【００５８】
ＵＥが、ＢＳＲがトリガされるときに、トランスポートブロックにＢＳＲを含めるために割り当てられるアップリンクリソースを有しない場合、ＵＥは、ｅＮｏｄｅＢにスケジューリング要求（ＳＲ：Scheduling Request）を送信して、ＢＳＲを送信するためのアップリンクリソースを割り当ててもらう。ＢＳＲを送るためのアップリンク無線リソース割当てを要求するために、単一ビットのスケジューリング要求がＰＵＣＣＨ（専用スケジューリング要求（Ｄ−ＳＲ：Dedicated Scheduling Request））で送信されるか、またはランダムアクセス手順（ＲＡＣＨ）が行われる。
【００５９】
［ＬＴＥの装置間（Ｄ２Ｄ：Device to Device）近傍サービス（ＰｒｏＳｅ）］
近傍性に基づくアプリケーションおよびサービスが、ソーシャル技術の新しいトレンドである。結びつく分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。ＬＴＥに近傍サービス（ＰｒｏＳｅ）機能を導入することにより、３ＧＰＰ業界は、この成長の見込まれる市場にサービスを提供することができると同時に、連係してＬＴＥを使用するいくつかの公共安全コミュニティの緊急なニーズに応えることができる。
【００６０】
装置間（Ｄ２Ｄ）通信は、ＬＴＥリリース１２によって導入された技術要素であり、この技術によって、セルラーネットワークに対するアンダーレイ（下層）としてのＤ２Ｄにおいてスペクトル効率を高めることができる。例えば、セルラーネットワークがＬＴＥである場合、データを伝送するすべての物理チャネルは、Ｄ２ＤシグナリングにおいてＳＣ−ＦＤＭＡを使用する。Ｄ２Ｄ通信では、ユーザ機器は、無線基地局を経由せずに、セルラーリソースを使用する直接的なリンクを通じて互いにデータ信号を送信する。本発明全体を通じて、用語「Ｄ２Ｄ」、「ＰｒｏＳｅ」、および「サイドリンク」は同義である。
【００６１】
ＬＴＥにおけるＤ２Ｄ通信は、ディスカバリおよび通信という２つの分野に焦点をあてている。
【００６２】
ＰｒｏＳｅ（近傍サービス）直接ディスカバリ（ProSe Direct Discovery）は、ＰｒｏＳｅ対応ＵＥが、ＰＣ５インタフェースを介したＥ−ＵＴＲＡ直接無線信号を使用して、その近傍の他の（１基または複数基の）ＰｒｏＳｅ対応ＵＥを発見するために使用される手順と定義されている。
【００６３】
Ｄ２Ｄ通信では、ＵＥとＵＥが、基地局（ＢＳ）を経由せずに、セルラーリソースを使用して直接的なリンクを通じて互いにデータ信号を送信する。Ｄ２Ｄユーザは、基地局の制御下にある状態で（すなわち、少なくともｅＮＢのカバレッジ内にあるときに）互いに直接通信する。したがってＤ２Ｄでは、セルラーリソースを再利用することによってシステム性能を改善することができる。
【００６４】
Ｄ２Ｄは、（ＦＤＤの場合）アップリンクＬＴＥ周波数帯において動作する、または、（ＴＤＤの場合、ただしカバレッジ外のときを除く）カバレッジを提供しているセルのアップリンクサブフレームにおいて動作する、と想定される。さらに、Ｄ２Ｄ送信／受信では、与えられたキャリアにおいて全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、Ｄ２Ｄ信号受信およびＬＴＥアップリンク送信が全二重を使用しない（すなわちＤ２Ｄ信号受信およびＬＴＥアップリンク送信を同時に行うことはできない）。
【００６５】
Ｄ２Ｄ通信では、特定の１基のＵＥ１が送信の役割であるとき（送信側ユーザ機器または送信側端末）、ＵＥ１がデータを送り、別のＵＥ２（受信側ユーザ機器）がそれを受信する。ＵＥ１およびＵＥ２は、送信の役割と受信の役割を交換することができる。ＵＥ１からの送信は、ＵＥ２に類似する１基または複数基のＵＥによって受信することができる。
【００６６】
［ＰｒｏＳｅ直接通信のレイヤ２リンク］
簡潔に言えば、２基のＵＥの間でＰＣ５インタフェースを通じてセキュアなレイヤ２リンクを確立することによって、１対１のＰｒｏＳｅ直接通信が達成される。各ＵＥは、ユニキャスト通信用のレイヤ２  ＩＤを有し、このレイヤ２  ＩＤは、ＵＥがレイヤ２リンクで送る各フレームのＳｏｕｒｃｅ  Ｌａｙｅｒ−２  ＩＤ（送信元レイヤ２  ＩＤ）フィールドと、ＵＥがレイヤ２リンクで受信する各フレームのＤｅｓｔｉｎａｔｉｏｎ  Ｌａｙｅｒ−２  ＩＤ（宛先レイヤ２  ＩＤ）に含まれる。ＵＥは、ユニキャスト通信用のレイヤ２  ＩＤが少なくともローカル範囲内で確実に一意であるようにする必要がある。したがってＵＥは、隣接するＵＥとのレイヤ２  ＩＤの衝突を、規定されていないメカニズム（例えば、衝突が検出されたときユニキャスト通信用の新しいレイヤ２  ＩＤを自身で割り当てる）を使用して処理するように準備されているべきである。１対１のＰｒｏＳｅ直接通信のためのレイヤ２リンクは、２基のＵＥのレイヤ２  ＩＤの組合せによって識別される。すなわちＵＥは、同一のレイヤ２  ＩＤを使用して、１対１のＰｒｏＳｅ直接通信のための複数のレイヤ２リンクに関与することができる。
【００６７】
１対１のＰｒｏＳｅ直接通信は、参照により本明細書に援用される非特許文献５に詳しく説明されているように、次の手順から構成される。
・  ＰＣ５を通じてセキュアなレイヤ２リンクを確立する
・  ＩＰアドレス／プレフィックスを割り当てる
・  ＰＣ５を通じてレイヤ２リンクを維持する
・  ＰＣ５を通じてレイヤ２リンクを解除する
【００６８】
図４は、ＰＣ５インタフェースを通じてセキュアなレイヤ２リンクを確立する方法を示している。
【００６９】
１．  相互認証をトリガするために、ＵＥ−１が直接通信要求（Direct Communication Request）メッセージをＵＥ−２に送る。ステップ１を実行するためには、リンク開始側（ＵＥ−１）が相手側（ＵＥ−２）のレイヤ２  ＩＤを知っている必要がある。一例として、リンク開始側は、最初にディスカバリ手順を実行することによって、または相手側を含む１対多のＰｒｏＳｅ通信に参加することによって、相手側のレイヤ２  ＩＤを認識することができる。
２．  ＵＥ−２が相互認証の手順を開始する。認証手順が正常に終了すると、ＰＣ５を通じてのセキュアなレイヤ２リンクの確立が完了する。
【００７０】
単独の（中継されない）１対１通信に関与するＵＥは、リンクローカルアドレスを使用することもできる。ＰＣ５シグナリングプロトコルは、ＵＥがＰｒｏＳｅ通信範囲内ではないときに検出するために使用されるキープアライブ機能をサポートし、したがってこのようなＵＥは、レイヤ２リンクの暗黙的な解除（release）に進むことができる。ＰＣ５を通じてのレイヤ２リンクの解除は、他方のＵＥに送信される接続解除要求（Disconnect Request）メッセージを使用することによって実行することができ、他方のＵＥは、関連するすべてのコンテキストデータも削除する。他方のＵＥは、接続解除要求メッセージを受信した時点で、接続解除応答（Disconnect Response）メッセージによって応答し、レイヤ２リンクに関連付けられたすべてのコンテキストデータを削除する。
【００７１】
［ＰｒｏＳｅ直接通信に関連する識別情報］
非特許文献６の第８．３節には、ＰｒｏＳｅ直接通信に使用するための次の識別情報が定義されている。
・  ＳＬ−ＲＮＴＩ（サイドリンク無線ネットワーク一時識別子）：ＰｒｏＳｅ直接通信のスケジューリングに使用される一意の識別情報
・  送信元レイヤ２  ＩＤ：サイドリンクＰｒｏＳｅ直接通信におけるデータの送信機を識別する。送信元レイヤ２  ＩＤは２４ビット長であり、受信機におけるＲＬＣ  ＵＭエンティティおよびＰＤＣＰエンティティを識別するため、ＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤ（論理チャネルＩＤ）と一緒に使用される。
・  宛先レイヤ２  ＩＤ：サイドリンクＰｒｏＳｅ直接通信におけるデータの対象者（target）を識別する。宛先レイヤ２  ＩＤは２４ビット長であり、ＭＡＣレイヤにおいて２つのビットストリングに分割される。
・  １つ目のビットストリングは、宛先レイヤ２  ＩＤの最下位ビット部分（８ビット）であり、サイドリンク制御レイヤ１  ＩＤとして物理レイヤに転送される。これは、サイドリンク制御における意図するデータの対象者を識別し、物理レイヤにおいてパケットをフィルタリングするために使用される。
・  ２つ目のビットストリングは、宛先レイヤ２  ＩＤの最上位ビット部分（１６ビット）であり、ＭＡＣヘッダ内で伝えられる。これは、ＭＡＣレイヤにおいてパケットをフィルタリングするために使用される。
【００７２】
ＵＥにおいて、グループを形成するために、および、送信元レイヤ２  ＩＤ、宛先レイヤ２  ＩＤ、およびサイドリンク制御レイヤ１  ＩＤを設定するために、非アクセス層シグナリング（No Access Stratum signalling）が必要である。これらの識別情報は、上位レイヤによって提供される、または上位レイヤによって提供される識別情報から導かれる。グループキャストおよびブロードキャストの場合、上位レイヤによって提供されるＰｒｏＳｅ  ＵＥ  ＩＤが送信元レイヤ２  ＩＤとして直接使用され、上位レイヤによって提供されるＰｒｏＳｅレイヤ２グループＩＤが、ＭＡＣレイヤにおいて宛先レイヤ２  ＩＤとして直接使用される。１対１の通信の場合、上位レイヤが送信元レイヤ２  ＩＤおよび宛先レイヤ２  ＩＤを提供する。
【００７３】
［近傍サービスにおける無線リソース割当て］
送信側ＵＥの観点からは、近傍サービスに対応するＵＥ（ＰｒｏＳｅ対応ＵＥ）は、リソース割当ての以下の２つのモードで動作することができる。
【００７４】
モード１は、ｅＮＢによってスケジューリングされるリソース割当てを意味する。モード１では、ＵＥは、ｅＮＢ（またはリリース１０の中継ノード）に送信リソースを要求し、それに応えてｅＮｏｄｅＢ（またはリリース１０の中継ノード）は、ＵＥが「直接」データおよび「直接」制御情報（例えばスケジューリング割当て（ＳＡ：Scheduling Assignment））を送信するために使用するリソースをスケジューリングする。ＵＥは、データを送信するためにはＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある必要がある。具体的には、ＵＥは、スケジューリング要求（Ｄ−ＳＲ（専用スケジューリング要求）またはランダムアクセス）をｅＮＢに送り、次いでバッファ状態報告（ＢＳＲ）を通常の方法で送る（次節「Ｄ２Ｄ通信における送信手順」（“Transmission procedure for D2D communication”）も参照）。ｅＮＢは、ＢＳＲに基づいて、ＵＥがＰｒｏＳｅ直接通信によって送信するデータを有するものと判断し、送信に必要なリソースを推定することができる。
【００７５】
これに対して、モード２は、ＵＥによる自律的なリソース選択を意味する。モード２では、ＵＥは、「直接」データおよび「直接」制御情報（すなわちＳＡ（スケジューリング割当て））を送信するためのリソース（時間および周波数）を、（１つまたは複数の）リソースプールから自身で選択する。例えばＳＩＢ１８の内容によって（すなわちｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎフィールドによって）１つのリソースプールが定義され、この特定のリソースプールは、セル内でブロードキャストされ、そのセル内において依然としてＲＲＣ＿ＩＤＬＥ状態にあるすべてのＵＥに共通して利用可能である。実際には、ｅＮＢは、このプールの最大４つの異なるインスタンス（すなわちＳＡメッセージおよび「直接」データを送信するための４つのリソースプール）を定義することができる。しかしながら、リリース１２では、ＵＥは、たとえ自身に複数のリソースプールが設定された場合でも、リスト内に定義されている最初のリソースプールを常に使用する。この制約は、リリース１３では削除されている。すなわち、ＵＥは、１つのＳＣ期間内に、設定されている複数のリソースプールのいくつかで送信することができる。以下では、ＵＥが送信用のリソースプールを選択する方法についてさらに説明する（非特許文献２にさらに規定されている）。
【００７６】
図５は、オーバーレイ（ＬＴＥ）システムおよびアンダーレイ（Ｄ２Ｄ）システムにおける送信／受信リソースの使用を示している。ＵＥがモード１の送信を適用するかモード２の送信を適用するかは、基本的にはｅＮｏｄｅＢが制御する。ＵＥは、Ｄ２Ｄ通信を送信（または受信）することのできるリソースを認識すると、対応するリソースを、対応する送信／受信にのみ使用する。例えば図５において、Ｄ２Ｄサブフレームは、Ｄ２Ｄ信号を受信または送信する目的にのみ使用される。Ｄ２Ｄ装置としてのＵＥは、半二重モードで動作するため、任意の時点においてＤ２Ｄ信号の受信または送信を行うことができる。同様に、図５に示したそれ以外のサブフレームは、ＬＴＥ（オーバーレイ）の送信および／または受信に使用することができる。
【００７７】
［Ｄ２Ｄ通信における送信手順］
Ｄ２Ｄデータの送信手順は、リソース割当てモードに応じて異なる。上述したように、モード１の場合には、ｅＮＢは、スケジューリング割当て（ＳＡ）およびＤ２Ｄデータ通信のためのリソースを、ＵＥからの対応する要求の後に、明示的にスケジューリングする。特に、Ｄ２Ｄ通信基本的に許可されることと、しかしながら、モード２のリソース（すなわちリソースプール）が提供されないこととを、ｅＮＢがＵＥに通知してもよい。この通知は、例えば、ＵＥによるＤ２Ｄ通信関心通知（D2D communication Interest Indication）と、対応する応答であるＤ２Ｄ通信応答（D2D Communication Response）を交換することによって行うことができる。この場合、対応する例示的なＰｒｏｓｅＣｏｍｍＣｏｎｆｉｇ情報要素にｃｏｍｍＴｘＰｏｏｌＮｏｒｍａｌＣｏｍｍｏｎが含まれない。これは、すなわち、送信を含む直接通信の開始を望むＵＥが、個々の送信ごとにリソース割当てをＥ−ＵＴＲＡＮに要求しなければならないことを意味する。したがって、このような場合、ＵＥは、個々の送信それぞれのリソースを要求しなければならない。以下に、このモード１のリソース割当ての場合の要求／許可手順の一連のステップを例示的に示す。
・  ステップ１  ＵＥがスケジューリング要求（ＳＲ：Scheduling Request）をＰＵＣＣＨを介してｅＮＢに送る。
・  ステップ２  ｅＮＢが、（ＵＥがＢＳＲを送るための）アップリンクリソースを、Ｃ−ＲＮＴＩによってスクランブルされたＰＤＣＣＨを介して許可（grant）する。
・  ステップ３  ＵＥが、バッファの状態を示すＤ２Ｄ  ＢＳＲをＰＵＳＣＨを介して送る。
・  ステップ４  ｅＮＢが、（ＵＥがデータを送るための）Ｄ２Ｄリソースを、Ｄ２Ｄ−ＲＮＴＩによってスクランブルされたＰＤＣＣＨを介して許可（grant）する。
・  ステップ５  Ｄ２Ｄ送信側ＵＥが、ステップ４で受信した許可（grant）に従って、ＳＡ／Ｄ２Ｄデータを送信する。
【００７８】
スケジューリング割当て（ＳＡ）（サイドリンク制御情報（ＳＣＩ：Sidelink Control Information）とも称する）は、制御情報（例えば対応するＤ２Ｄデータを送信するための時間−周波数リソースを指すポインタ、変調・符号化方式、グループ宛先ＩＤ）を含むコンパクトな（低ペイロードの）メッセージである。ＳＣＩは、１つの（ＰｒｏＳＥ）宛先ＩＤのサイドリンクスケジューリング情報を伝える。ＳＡ（ＳＣＩ）の内容は、基本的には上のステップ４で受信されるグラントに従う。Ｄ２ＤグラントおよびＳＡの内容（すなわちＳＣＩの内容）は、参照により本明細書に援用される３ＧＰＰの技術規格である非特許文献４の第５．４．３節に定義されている（特に、ＳＣＩフォーマット０を定義している（前出のＳＣＩフォーマット０の内容を参照））。
【００７９】
これに対して、モード２のリソース割当ての場合、上のステップ１〜４は基本的に不要であり、ＵＥは、ＳＡおよびＤ２Ｄデータを送信するためのリソースを、ｅＮＢによって設定および提供される（１つまたは複数の）送信リソースプールから自律的に選択する。
【００８０】
図６は、２基のＵＥ（ＵＥ−１およびＵＥ−２）の場合のスケジューリング割当ておよびＤ２Ｄデータの送信を例示的に示しており、スケジューリング割当てを送るためのリソースは周期的であり、Ｄ２Ｄデータの送信に使用されるリソースは、対応するスケジューリング割当てによって示される。
【００８１】
図７は、サイドリンク制御（ＳＣ：Sidelink Control）期間としても知られる、１つのＳＡ／データ期間におけるモード２（自律的スケジューリング）の場合のＤ２Ｄ通信タイミングを示している。図８は、１つのＳＡ／データ期間におけるモード１の場合（ｅＮＢが割当てをスケジューリングする場合）のＤ２Ｄ通信タイミングを示している。ＳＣ期間は、スケジューリング割当ておよびその対応するデータの送信から構成される時間枠である。
【００８２】
標準規格に現在規定されているように、例えばｅＮＢによって送られるか、またはＵＥ自身によって選択される１つのサイドリンクグラントにつき、ＵＥは複数のトランスポートブロック（ＭＡＣ  ＰＤＵ）を（１サブフレーム（ＴＴＩ）あたり１つのみ、すなわち１つずつ）送信することができるが、ＰｒｏＳｅ宛先グループは１つのみである。また、１つのトランスポートブロックの再送信は、次のトランスポートブロックの最初の送信が開始される前に完了しなければならず、すなわち複数のトランスポートブロックを送信するためのサイドリンクグラントあたり１つのみのＨＡＲＱプロセスが使用される。さらに、ＵＥはＳＣ期間あたりいくつかのサイドリンクグラントを有して使用することができるが、各サイドリンクグラントに対して異なるＰｒｏＳｅ宛先が選択される。したがって、１つのＳＣ期間においてＵＥは、１つのＰｒｏＳｅ宛先には１回のみ送信することができる。
【００８３】
サイドリンクデータの送信手順は、参照により本明細書に援用される３ＧＰＰ標準規格書である非特許文献２の第５．１４節に記載されている。この文書には、モード２の自律的なリソース選択が詳しく記載されており、１つの無線リソースプールまたは複数の無線リソースプールが設定されている場合が区別されている。
【００８４】
［ＰｒｏＳｅネットワークアーキテクチャおよびＰｒｏＳｅエンティティ］
図９は、非ローミングの場合の高レベルの例示的なアーキテクチャを示しており、ＵＥ  ＡおよびＵＥ  Ｂにおける異なるＰｒｏＳｅアプリケーションと、ネットワーク内のＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む。図９のアーキテクチャの例は、参照により本明細書に援用される非特許文献７の第４．２節「アーキテクチャの基準モデル」（“Architectural Reference Model”）からの引用である。
【００８５】
これらの機能エンティティは、参照により本明細書に援用される非特許文献７の第４．４節「機能エンティティ」（“Functional Entities”）に提示および詳しく説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅに要求されるネットワーク関連動作に使用される論理機能であり、ＰｒｏＳｅの特徴それぞれにおいて異なる役割を果たす。ＰｒｏＳｅ機能は、３ＧＰＰのＥＰＣの一部であり、近傍サービスに関係する認可、認証、データ処理など、関連するネットワークサービスすべてを提供する。ＰｒｏＳｅ直接ディスカバリおよびＰｒｏＳｅ直接通信において、ＵＥは、固有のＰｒｏＳｅ  ＵＥ識別情報、他の設定情報、および認証を、ＰｒｏＳｅ機能からＰＣ３基準点（PC3 reference point）を通じて取得することができる。ネットワーク内に複数のＰｒｏＳｅ機能を配備することができるが、説明を容易にするため、１つのＰｒｏＳｅ機能を示してある。ＰｒｏＳｅ機能は、ＰｒｏＳｅの特徴に応じた異なる役割を実行する主要な３つのサブ機能、すなわち直接提供機能（ＤＰＦ：Direct Provision Function）、直接ディスカバリネーム管理機能（Direct Discovery Name Management Function）、およびＥＰＣレベルディスカバリ機能（EPC-level Discovery Function）、から構成されている。ＤＰＦは、ＰｒｏＳｅ直接ディスカバリおよびＰｒｏＳｅ直接通信を使用するための必要なパラメータをＵＥに提供するために使用される。
【００８６】
ここで、「ＵＥ」とは、例えば以下のＰｒｏＳｅ機能をサポートするＰｒｏＳｅ対応ＵＥを意味する。
・  ＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間でＰＣ３基準点を通じてＰｒｏＳｅ制御情報を交換する
・  ＰＣ５基準点を通じての、他のＰｒｏＳｅ対応ＵＥのオープンＰｒｏＳｅ直接ディスカバリの手順
・  ＰＣ５基準点を通じた１対多のＰｒｏＳｅ直接通信の手順
・  ＰｒｏＳｅ  ＵＥとネットワークとの間の中継器（Prose UE-to-Network Relay）として動作するための手順。遠隔のＵＥは、ＰＣ５基準点を通じて、ＰｒｏＳｅ  ＵＥとネットワークとの間の中継器と通信する。ＰｒｏＳｅ  ＵＥとネットワークとの間の中継器は、レイヤ３パケット転送を使用する。
・  例えば、ＵＥとネットワークとの間の中継器の検出およびＰｒｏＳｅ直接ディスカバリのために、ＰＣ５基準点を通じて各ＰｒｏＳｅ  ＵＥの間で制御情報を交換する
・  他のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間でＰＣ３基準点を通じてＰｒｏＳｅ制御情報を交換する。ＰｒｏＳｅ  ＵＥとネットワークとの間の中継器の場合、遠隔のＵＥは、この制御情報を、ＬＴＥ−Ｕｕインタフェースを通じてＰｒｏＳｅ機能に中継されるようにＰＣ５ユーザプレーンを通じて送る。
・  パラメータ（例えば、ＩＰアドレス、ＰｒｏＳｅレイヤ２グループＩＤ、グループセキュリティマテリアル（Group security material）、無線リソースパラメータを含む）を設定する。これらのパラメータは、ＵＥにおいて事前設定することもでき、カバレッジ内にある場合、ＰＣ３基準点を通じたシグナリングによってネットワーク内のＰｒｏＳｅ機能に提供することもできる。
【００８７】
ＰｒｏＳｅアプリケーションサーバは、ＥＰＣ  ＰｒｏＳｅユーザＩＤおよびＰｒｏＳｅ機能ＩＤの格納と、アプリケーション層ユーザＩＤとＥＰＣ  ＰｒｏＳｅユーザＩＤのマッピングをサポートする。ＰｒｏＳｅアプリケーションサーバ（ＡＳ）は、３ＧＰＰの範囲外のエンティティである。ＵＥにおけるＰｒｏＳｅアプリケーションは、アプリケーション層基準点ＰＣ１を介してＰｒｏＳｅ  ＡＳと通信する。ＰｒｏＳｅ  ＡＳは、ＰＣ２基準点を介して３ＧＰＰネットワークに接続されている。
【００８８】
［Ｄ２Ｄサイドリンク論理チャネルに対するＬＣＰプロシージャ］
Ｄ２ＤにおけるＬＣＰ（論理チャネル優先順位付け）手順は、「通常の」ＬＴＥデータの場合の上述のＬＣＰプロシージャとは異なる。以下の情報は、ＰｒｏＳｅにおけるＬＣＰプロシージャを記述した非特許文献２の第５．１４．１．３．１節からの引用である。非特許文献２は、参照によりその全体が本明細書に援用される。
【００８９】
論理チャネル優先順位付けプロシージャは、新規送信が実行されるときに適用される。各サイドリンク論理チャネルは、関連付けられた優先度を有する。この優先度を、後述するＰｒｏＳｅパケットごとの優先度（ＰＰＰＰ：ProSe per packet priority）とすることができる。複数のサイドリンク論理チャネルが、関連付けられた同一の優先度を有することができる。優先度とＬＣＩＤとの間のマッピングは、ＵＥの実装に委ねられる。
【００９０】
ＭＡＣエンティティは、ＳＣ期間内に送信される各ＳＣＩに対して以下の論理チャネル優先順位付けプロシージャを実行する。
−  ＭＡＣエンティティは、以下のステップにおいてサイドリンク論理チャネルにリソースを割り当てる。
−  ステップ０：  送信可能な状態のデータを有するサイドリンク論理チャネルのうち最も高い優先度のサイドリンク論理チャネルを有し、かつ、そのＳＣ期間に対して以前に選択されていないＰｒｏＳｅ宛先を選択する。
−  ステップ１：  選択されたＰｒｏＳｅ宛先に属しており、かつ送信可能なデータを有するサイドリンク論理チャネルのうち、最も高い優先度を有するサイドリンク論理チャネルにリソースを割り当てる。
−  ステップ２：  リソースが残っている場合、（１つまたは複数の）サイドリンク論理チャネルのデータまたはＳＬグラントが最初に使い切られるまで、選択されたＰｒｏＳｅ宛先に属するサイドリンク論理チャネルを、優先度の高い順に処理する。等しい優先度に設定されているサイドリンク論理チャネルは、同等に処理されるべきである。
−  さらにＵＥは、上のスケジューリング手順時、以下の規則にも従う。
【００９１】
ＵＥは、次の規則に従ってサイドリンク論理チャネルにリソースを割り当てる。
−  ＲＬＣ  ＳＤＵ全体（または部分的に送信されるＳＤＵ）が残りのリソースに収まる場合、ＵＥはＲＬＣ  ＳＤＵ（または部分的に送信されるＳＤＵ）をセグメント化すべきではない。
−  ＵＥは、サイドリンク論理チャネルからのＲＬＣ  ＳＤＵをセグメント化する場合、グラントをできる限り満たすようにセグメントのサイズを最大にする。
−  ＵＥは、データの送信を最大にするべきである。
−  送信可能なデータを有するときに、１０バイト以上のサイドリンクグラントサイズがＭＡＣエンティティに与えられる場合、ＭＡＣエンティティはパディングのみを送信しない。
【００９２】
一般的にＭＡＣは、１つのＭＡＣ  ＰＤＵについて、同一の送信元レイヤ２  ＩＤと宛先レイヤ２  ＩＤのペアを有する論理チャネルのみを考慮する。すなわち、ＵＥにおけるＭＡＣエンティティは、１つのＭＡＣ  ＰＤＵについて、同一のＰｒｏＳｅ宛先グループの論理チャネルのみを考慮する。これは基本的には、ＵＥがＬＣＰプロシージャ時にＰｒｏＳｅ宛先を選択することを意味する。リリース１３においては、ＳＣ期間内に２つ以上のサイドリンクグラントを有することが許容される。ＵＥは、リリース１２におけるように、各サイドリンクグラントについて１つのＰｒｏＳｅ宛先グループのデータのみを送信する。しかしながら、１つのＳＣ期間内に２つ以上の有効なサイドリンクグラントを有するようにＵＥを設定することができるため、送信側ＵＥは、複数の異なるＰｒｏＳｅ宛先にデータを送信することができる（すなわち、各ＳＬグラントにおいて異なるＰｒｏＳｅ宛先にデータを送信しなければならない）。
【００９３】
［ＰｒｏＳｅにおけるＱｏＳのサポート］
リリース１３では、概して１対多のＰｒｏＳｅ通信のためにＱｏＳがサポートされている。そのために、いわゆるＰｒｏＳｅパケットごとの優先度（ＰＰＰＰ）が例えば非特許文献７において導入された。ＰｒｏＳｅパケットごとの優先度は、プロトコルデータユニット（例えばＩＰパケット）に関連付けられるスカラー値であり、プロトコルデータユニットの送信に適用される優先度の扱い（すなわちＰＣ５インタフェースで送信するための優先度の扱い）を定義する。言い換えれば、ＰｒｏＳｅ  ＰＰＰは、ＰｒｏＳｅ  ＵＥ間およびＰｒｏＳｅ中継の場合を含むＰｒｏＳｅ直接通信を使用するときにパケットの優先順位付けを可能にするために使用されるメカニズムである。
【００９４】
ＰｒｏＳｅ上位レイヤ（すなわちＰＣ５アクセス層より上）が、送信するプロトコルデータユニットをＰＣ５アクセス層に渡すとき、ＰｒｏＳｅ上位レイヤは、８つの可能な値の範囲からＰｒｏＳｅパケットごとの優先度を提供する。
【００９５】
ＰｒｏＳｅパケットごとの優先度は、宛先レイヤ２  ＩＤとは独立しており、１対１および１対多のＰｒｏＳｅ直接通信の両方に適用される。ＰｒｏＳｅパケットごとの優先度は、例えば本明細書の範囲外であるさまざまな基準（音声パケット伝送などのサービスの遅延要件や、フロア制御に関連するシグナリングなどの制御シグナリングなど）に基づいて、アプリケーション層によって選択される。
【００９６】
ＰｒｏＳｅパケットごとの優先度は、ＵＥが媒体にアクセスするモード（すなわちＰｒｏＳｅ通信用にスケジューリング式リソース割当てモードが使用されるか自律式リソース割当てモードが使用されるか）とは無関係である。ＰｒｏＳｅアクセス層は、上位レイヤから受け取るプロトコルデータユニットに関連付けられるＰｒｏＳｅパケットごとの優先度を使用して、ＵＥ内の他の送信（すなわち同一のＵＥ内で送信を待機している、さまざまな優先度に関連付けられているプロトコルデータユニット）およびＵＥ間送信（すなわち別の異なるＵＥ内で送信を待機している、さまざまな優先度に関連付けられているプロトコルデータユニット）に関連する送信を優先順位付けする。
【００９７】
優先度キュー（ＵＥ内およびＵＥ間の両方）は、優先度の厳密な順序で処理されることが予期される。すなわち、ＵＥまたはｅＮＢは、ＰｒｏＳｅパケットごとの優先度Ｎに関連付けられたすべてのパケットを、優先度Ｎ＋１に関連付けられるパケットを処理する前に処理する（小さい数ほど高い優先度を意味する）。
【００９８】
ＰＣ５インタフェース自体における優先度の扱いは、非特許文献２において、すなわち既に上述した論理チャネル優先順位付け（ＬＣＰ）手順によって特定される。サイドリンク論理チャネルごとに１つの優先度が関連付けられる（これは、例えば、レガシーＬＴＥのアップリンク動作における論理チャネルの優先度に類似する）。サイドリンク論理チャネルの生成は、リリース１２と同様にＵＥの実装に委ねられる。ＵＥは、論理チャネルを生成するとき、パケットの送信元ＩＤ／宛先ＩＤを考慮することに加えて、パケットの優先度も考慮する。同一のＰＰＰＰ値（および同一の送信元ＩＤ／宛先ＩＤ）を有するプロトコルデータユニットは、基本的には、ＰＰＰＰと同一である特定の論理チャネル優先度が関連付けられている１つのサイドリンク論理チャネルによって供される。
【００９９】
上述したように、ＵＥは、ＳＬグラントを受信するときの論理チャネル優先順位付けプロシージャ時、ＳＬデータを有するサイドリンク論理チャネルのうち、ＰＰＰＰが最も高いサイドリンク論理チャネルを有するＰｒｏＳｅグループを選択し、次いで、選択されたＰｒｏＳｅ宛先グループに属すすべてのサイドリンク論理チャネルを、優先度の高い順に処理する。
【０１００】
［ＰｒｏＳｅのためのバッファ状態報告］
バッファ状態報告はＰｒｏＳｅに適合され、現在、参照により本明細書に援用される非特許文献２の第５．１４．１．４節「バッファ状態報告」（“Buffer Status Reporting”）に定義される。
【０１０１】
（Ｄ２Ｄ）サイドリンクバッファ状態報告手順は、ＵＥのサイドリンクバッファ内の、他のＵＥに送信可能なサイドリンクデータ量の情報をサービングｅＮＢに提供するために使用される。ＲＲＣは、２つのタイマ、すなわち、Ｐｅｒｉｏｄｉｃ−ＰｒｏｓｅＢＳＲ−ＴｉｍｅｒおよびＲｅｔｘＰｒｏｓｅＢＳＲ−Ｔｉｍｅｒを設定することによってサイドリンクＢＳＲ報告を制御する。
【０１０２】
サイドリンクバッファ状態報告（ＢＳＲ）は、非特許文献２の第５．１４．１．４節に詳細に規定されるように、或る特定のイベントが発生する場合にトリガされる。
【０１０３】
さらに、参照により本明細書に援用される非特許文献２の第６．１．３．１ａ節において、以下の通りにＰｒｏＳｅ  ＢＳＲ  ＭＡＣ制御要素およびその対応する内容が定義されている。ＰｒｏＳｅバッファ状態報告（ＢＳＲ）ＭＡＣ制御要素は、報告されるＤ２Ｄ宛先グループごとに、１つのグループインデックスフィールド、１つのＬＣＧ  ＩＤフィールド、および、１つの対応するバッファサイズフィールドからなる。より詳細には、含まれる各ＰｒｏＳｅ宛先グループに対して、以下のフィールドが定義される。
・  グループインデックス：  グループインデックスフィールドは、ＰｒｏＳｅ宛先グループを識別する。このフィールドの長さは４ビットである。値には、ｄｅｓｔｉｎａｔｉｏｎＩｎｆｏＬｉｓｔで報告される宛先識別情報のインデックスが設定される。
・  ＬＣＧ  ＩＤ：  論理チャネルグループＩＤフィールドは、バッファ状態が報告されている論理チャネルのグループを識別する。フィールドの長さは２ビットである。
・  バッファサイズ：  バッファサイズフィールドは、ＴＴＩのすべてのＭＡＣ  ＰＤＵが構築された後にＰｒｏＳｅ宛先グループのすべての論理チャネルに亘って利用可能な総データ量を識別する。データ量は、バイト数で示される。
・  Ｒ：  予備ビット。「０」に設定される。
【０１０４】
図１０は、非特許文献２の第６．１．３．１ａ項から引用される、Ｎ（ＰｒｏＳｅ宛先グループの数）が偶数の場合のＰｒｏＳｅ  ＢＳＲ  ＭＡＣ制御要素を示す。
【０１０５】
［車両用通信（Vehicular Communication）−Ｖ２Ｘサービス］
３ＧＰＰでは、近傍サービス（ＰｒｏＳｅ）およびＬＴＥに基づくブロードキャストサービスを含む自動車産業に対するＬＴＥの新たな特徴の有用性を考慮するための新たな検討項目が設定された。したがって、ＰｒｏＳｅ機能は、Ｖ２Ｘサービスの良好な土台を提供するものと考えられている。車両接続技術（connected vehicle technology）は、安全性、モビリティおよび交通の効率等の陸上輸送産業における大きな挑戦のいくつかに取り組むことを目標とする。
【０１０６】
Ｖ２Ｘ通信は、或る車両から、この車両に影響しうる任意のエンティティに情報を渡すこと、またはその逆方向に情報を渡すことである。この情報交換は、安全性、モビリティ、および環境問題への応用を改善するために使用可能である。安全性、モビリティ、および環境問題への応用としては、運転補助、車両の安全性、速度調節および警告、緊急応答、走行情報、ナビゲーション、交通管理、商用車の運行計画、および支払処理が含まれる。
【０１０７】
Ｖ２Ｘサービスに対するＬＴＥのサポートには、次の３種類の様々なユースケースが含まれる。
・  Ｖ２Ｖ：  車両間のＬＴＥに基づく通信をカバーする。
・  Ｖ２Ｐ：  車両と個人が所持するデバイス（例えば、歩行者、自転車に乗っている人、ドライバ、または乗客が所持する携帯情報端末）との間のＬＴＥに基づく通信をカバーする。
・  Ｖ２Ｉ：  車両と路側機との間のＬＴＥに基づく通信をカバーする。
【０１０８】
これらの３種類のＶ２Ｘは、エンドユーザによりインテリジェントなサービスを提供するために「協調認識」（“co-operative awareness”）を使用することができる。これは、車両等の輸送エンティティ、路側インフラ、および歩行者が、各々のローカル環境についての知識（例えば、近傍の他の車両またはセンサ機器から受信した情報）を収集して、協調衝突警告または自律走行のようなさらにインテリジェントなサービスを提供するためにその知識を加工・共有することができることを意味する。
【０１０９】
Ｖ２Ｖ通信に関し、Ｅ−ＵＴＲＡＮは、許諾、認証および近傍性基準（proximity criteria）が満たされる場合に、互いに近傍に存在する各ＵＥがＥ−ＵＴＲＡ（Ｎ）を使用してＶ２Ｖ関連の情報を交換することを可能にしている。近傍性基準は、モバイルネットワーク事業者（ＭＮＯ：Mobile Network Operator）が設定することができる。しかしながら、Ｖ２Ｖサービスをサポートする各ＵＥは、Ｖ２ＸサービスをサポートするＥ−ＵＴＲＡＮを介しても、または、介さなくても、上記のような情報を交換することができる。
【０１１０】
Ｖ２ＶアプリケーションをサポートするＵＥは、例えば、Ｖ２Ｖサービスの一部として自身の位置、ダイナミクス、および属性に関するアプリケーション層の情報を送信する。Ｖ２Ｖペイロードは、様々な情報内容を収容するためにフレキシブルでなければならない。また、この情報は、ＭＮＯによって提供される設定に従って周期的に送信されてもよい。
【０１１１】
Ｖ２Ｖは、主にブロードキャストに基づく。Ｖ２Ｖには、別々の各ＵＥが直接的にＶ２Ｖ関連アプリケーション情報を交換すること、および／または、別々の各ＵＥが、Ｖ２Ｖの直通的な通信範囲が限定されているという理由から、Ｖ２Ｘサービスをサポートするインフラ（例えば、ＲＳＵ、アプリケーションサーバ等）を介してＶ２Ｖ関連アプリケーション情報を交換することが含まれる。
【０１１２】
Ｖ２Ｉ通信に関し、Ｖ２ＩアプリケーションをサポートするＵＥは、路側機にアプリケーション層情報を送信し、次いで路側機が、１つのグループの各ＵＥまたはＶ２ＩアプリケーションをサポートするＵＥにアプリケーション層情報を送信することができる。
【０１１３】
Ｖ２Ｎ（車両とネットワーク（ｅＮＢ／ＣＮ）との接続）も導入される。Ｖ２Ｎでは、一方の当事者がＵＥであり、他方の当事者がサービングエンティティであり、両者ともＶ２Ｎアプリケーションをサポートし、ＬＴＥネットワークを介して互いに通信する。
【０１１４】
Ｖ２Ｐ通信に関し、Ｅ−ＵＴＲＡＮは、許諾、認証および近傍性基準が満たされる場合に、互いに近傍に存在する各ＵＥがＥ−ＵＴＲＡＮを使用してＶ２Ｐ関連の情報を交換することを可能にしている。近傍性基準は、ＭＮＯが設定することができる。しかしながら、Ｖ２Ｐサービスをサポートする各ＵＥは、Ｖ２ＸサービスをサポートするＥ−ＵＴＲＡＮを介しても、または、介さなくても、上記のような情報を交換することができる。
【０１１５】
Ｖ２ＰアプリケーションをサポートするＵＥは、アプリケーション層情報を送信する。Ｖ２Ｘサービス（例えば、歩行者に対する警告）をサポートするＵＥを有する車両、および／またはＶ２Ｘサービス（例えば、車両に対する警告）をサポートするＵＥを有する歩行者は、そのような情報をブロードキャストすることができる。
【０１１６】
Ｖ２Ｐには、別々の各ＵＥ（一方が車両用ＵＥ、他方が歩行者のＵＥ）が直接的にＶ２Ｐ関連アプリケーション情報を交換すること、および／または、別々の各ＵＥが、Ｖ２Ｐの直通的な通信範囲が限定されているという理由から、Ｖ２Ｘサービスをサポートするインフラ（例えば、ＲＳＵ、アプリケーションサーバ等）を介してＶ２Ｐ関連アプリケーション情報を交換することが含まれる。
【０１１７】
この最近の検討項目であるＶ２Ｘについて、３ＧＰＰは、本出願のために再利用することができる非特許文献８に具体的な用語および定義を規定した。
【０１１８】
路側機（ＲＳＵ：Road Side Unit）：Ｖ２Ｉアプリケーションを使用してＵＥへの送信およびＵＥからの受信を行うことができる、Ｖ２Ｉサービスをサポートするエンティティ。ＲＳＵは、ｅＮＢまたは固定ＵＥ（stationary UE）において実装することができる。
【０１１９】
Ｖ２Ｉサービス：Ｖ２Ｘサービスの一種。一方の当事者がＵＥであり、他方の当事者がＲＳＵであり、両者がＶ２Ｉアプリケーションを使用する。
【０１２０】
Ｖ２Ｎサービス：Ｖ２Ｘサービスの一種。一方の当事者がＵＥであり、他方の当事者がサービングエンティティであり、両者がＶ２Ｎアプリケーションを使用し、ＬＴＥネットワークエンティティを介して互いに通信する。
【０１２１】
Ｖ２Ｐサービス：Ｖ２Ｘサービスの一種。通信の両当事者が、Ｖ２Ｐアプリケーションを使用するＵＥである。
【０１２２】
Ｖ２Ｖサービス：Ｖ２Ｘサービスの一種。通信の両当事者が、Ｖ２Ｖアプリケーションを使用するＵＥである。
【０１２３】
Ｖ２Ｘサービス：３ＧＰＰトランスポートを介してＶ２Ｖアプリケーションを使用する送信側または受信側のＵＥが関与する通信サービスの一種。Ｖ２Ｘサービスを、通信に関与する他方の当事者に基づき、さらにＶ２Ｖサービス、Ｖ２Ｉサービス、Ｖ２Ｐサービス、およびＶ２Ｎサービスに分割することができる。
【０１２４】
様々な種類のメッセージが、Ｖ２Ｖ通信のために定義されており、また定義されるであろう。３種類の異なるメッセージが、高度道路交通システム（ＩＴＳ：Intelligent Transport Systems）に関しＥＴＳＩによって既に定義されている（対応する欧州標準規格である非特許文献９および非特許文献１０を参照）。
・  協調認識メッセージ（ＣＡＭ：Cooperative Awareness Messages）：  車両ダイナミクスによって連続的にトリガされ、車両状態を反映する。
・  分散型環境通報メッセージ（ＤＥＮＭ：Decentralized Environmental Notification Messages）：  車両関連の安全性に係るイベントが発生する場合にのみトリガされる。
・  基本安全メッセージ（ＢＳＭ：Basic Safety Messages）：  関連する安全性アプリケーションが、ＳＡＥ  Ｊ２７３５のＢＳＭに基づき構築され、低いレイテンシやローカル化されたブロードキャストを目的として適合されている。
【０１２５】
安全性アプリケーションの例として、以下のものが含まれる。
・  前方衝突回避（ＦＣＡ：Forward Collision Avoidance）
・  緊急電子ブレーキライト（ＥＥＢＬ：Emergency Electronic Brake Lights）
・  死角警告（ＢＳＷ：Blind Spot Warning）
・  車線変更支援（ＬＣＡ：Lane Change Assist）
・  追越禁止警告（ＤＮＰＷ：Do Not Pass Warning）
・  交差点衝突警告（ＩＣＡ：Intersection Collision Warning）
・  逆走ドライバ警告（ＷＷＤＷ：Wrong Way Driver Warning）
・  協調型車間距離制御（ＣＡＣＣ：Cooperative Adaptive Cruise Control）
【０１２６】
さらに、例えば非特許文献１１に定義されるように、ＳＰａＴ（赤信号走行（ＲＬＲ：Red Light Running、左折支援（ＬＴＡ：Left Turn Assist）等）のような他のアプリケーションが存在する。Ｖ２ＶおよびＩＴＳの標準化が始まったばかりであるため、他のメッセージが今後定義されうることが期待されている。
【０１２７】
ＣＡＭは、ＩＴＳ局（ＩＴＳ−Ｓ：ITS-Station）によって継続的にブロードキャストされて他のＩＴＳ−Ｓとの状態に関する情報の交換が行われる。したがって、トラフィック負荷へのＣＡＭによる影響は、イベントトリガ型（event-triggered）のＤＥＮＭメッセージによる影響より大きい。そのため、ＩＴＳのためのＥＴＳＩによって定義されるＣＡＭメッセージのトラフィック特性は、Ｖ２Ｖトラフィックの中でより代表的と考えられる。協調認識メッセージ（ＣＡＭ）は、ＩＴＳネットワークにおいて各ＩＴＳ−Ｓ間で交換されるメッセージであり、交換により、互いの認識を生成・維持し、かつ道路網を使用する車両の協調的な動作をサポートするためのものである。ＣＡＭの送信にはポイントツーマルチポイント通信が使用される結果、ＣＡＭが発信側ＩＴＳ−Ｓから、発信側ＩＴＳ−Ｓの直接通信範囲内に位置する受信側の各ＩＴＳ−Ｓに送信される。
【０１２８】
Ｖ２Ｘメッセージの交換について様々なシナリオが予測される。１つのシナリオでは、ローカルエリアにおける複数の車両用ＵＥの間で、Ｖ２Ｘメッセージが、サイドリンクインタフェース（ＰＣ５インタフェース）を介して、直接送信されることが想定される。他のシナリオでは、Ｖ２Ｘメッセージが、アップリンクで、Ｕｕインタフェースを介して、Ｅ−ＵＴＲＡＮ（ｅＮＢ）に送信され、今度は、Ｅ−ＵＴＲＡＮ（ｅＮＢ）が、ダウンリンクで、ローカルエリアにおける複数のＵＥにＶ２Ｘメッセージを送信することが想定される。後者のシナリオをサポートするために、Ｅ−ＵＴＲＡＮは、Ｖ２Ｘメッセージのアップリンク受信およびダウンリンク送信を行う。ダウンリンクでは、Ｅ−ＵＴＲＡＮは、ブロードキャストメカニズムを使用してもよい。これらの２つのシナリオを組み合わせることもできる。
【０１２９】
専用狭域通信（ＤＳＲＣ：Dedicated Short-Range Communication）は、特に自動車での使用のために設計された一方向または双方向の狭域から中距離のワイヤレス通信チャネルであり、また、対応するプロトコルおよび標準規格一式である。ＩＥＥＥ  ８０２．１１ｐ標準規格に対応するＤＳＲＣは、車両環境にワイヤレスアクセスを追加するため、および、高度道路交通システム（ＩＴＳ）アプリケーションをサポートするために現在使用されている。
【０１３０】
［Ｖ２ＸトラフィックのためのＱｏＳ］
近年、３ＧＰＰでは、Ｖ２ＸトラフィックのためのＱｏＳ要件をどのように実装することができるかの議論が開始された。レイテンシ要件の点では、Ｖ２Ｖ／ＰサービスのためのＶ２Ｘメッセージの送信（ＬＴＥ−ＵｕインタフェースまたはＰＣ５インタフェースを介した送信）は、「送信側ＵＥから受信側ＵＥへのＶ２Ｘメッセージの送達に１００ｍｓ」というレイテンシ要件を満たさなければならない。さらに、特定のユースケース（例えば、プリクラッシュセンシング（pre-crash sensing））には、より厳密な要件が構想されうる。例えば、Ｅ−ＵＴＲＡＮは、２０ｍｓの最大レイテンシで、Ｖ２Ｖアプリケーションをサポートする２基のＵＥの間でメッセージを転送することができるべきである。
【０１３１】
ＰＣ５無線ベアラは、進化型パケットシステム（ＥＰＳ：Evolved Packet System）から提供されるＱｏＳパラメータによって制御される。さらに、ＰＣ５無線ベアラは、Ｅ−ＵＴＲＡＮの制御下において管理される。Ｅ−ＵＴＲＡＮは、ＰＣ５に基づくＱｏＳパラメータを、ＭＭＥからの初期ＵＥコンテキスト設定（Initial UE Context Setup）から取得する。現在定義されているように、ＰＣ５ベアラＱｏＳプロファイルは、ＰＰＰＰパラメータのみを含む。
【０１３２】
Ｖ２Ｘトラフィックのための様々なＱｏＳ要件を確実なものにすることができるか、また、いかに確実なものにすることができるかはまだ明らかではない。
【０１３３】
また、同一のインタフェース（すなわち、ＵｕインタフェースまたはＰＣ５インタフェース）を介して送信されたＶ２Ｘトラフィックと他のトラフィックとの共存が、確実に問題を引き起こさないようにすることが重要になる。結果的に、Ｖ２Ｘトラフィックおよび他のトラフィックについてのＱｏＳの扱いと他の手順との調整が改善されることになる。しかしながら、Ｖ２ＸアプリケーションのＱｏＳ要件を満たすためには、現在予測されているメカニズムおよびパラメータでは十分ではない可能性がある。ＰＰＰＰ自体は、保証ビットレート（ＧＢＲ）、パケット損失ミニマリズム（packet loss minimalism）、およびパケット遅延制約等を必ずしも保証しない。したがって、リリース８の無線ベアラ設定のＰＢＲ（優先ビットレート）、バケットサイズ時間（ＢＳＤ：Bucket Size Duration）等のような他のパラメータが必要になる見込みである。
【先行技術文献】
【非特許文献】
【０１３４】
【非特許文献１】3GPP TS 36.211 , "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)", version 13.0.0
【非特許文献２】3GPP technical standard TS 36.321, version 13.1.0
【非特許文献３】3GPP TS 23.203, version 13.3.0
【非特許文献４】3GPP TS 36.212, "Multiplexing and channel coding", current version v13.1 .0
【非特許文献５】3GPP TR 23.713 version 13.0.0 section 7.1.2
【非特許文献６】3GPP TS 36.300, version 13.2.0
【非特許文献７】3GPP TS 23.303 version 13.3.0
【非特許文献８】3GPP TR 21.905, version 13.0.0
【非特許文献９】ETSI EN 302 637-2 v1 .3.1
【非特許文献１０】ETSI EN 302 637- 3 v 1 .2.1
【非特許文献１１】IEEE 802.11 -13/0541 r0
【発明の概要】
【０１３５】
本発明を制限することのない例示的な実施形態は、車両用データおよび他のデータの両データを送信するための改良された車両用移動端末を提供する。
【０１３６】
本独立請求項は、本発明を制限することのない例示的な実施形態を提供する。有利な実施形態が従属請求項の主題である。
【０１３７】
また、１つの一般的な第１の態様では、本明細書において開示した技術は、１つ以上の受信側エンティティに車両用データおよび他のデータを送信するための車両用移動端末を特徴とする。車両用移動端末の受信部が、車両用移動端末が車両用データおよび／または他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、前記車両用移動端末が所属しているセルを制御する無線基地局から受信する。車両用移動端末の送信部が、アップリンクグラントにおいて示された無線リソースを使用して車両用データおよび／または他のデータを送信する。車両用移動端末は、車両用データおよび前記他のデータを互いに個別に処理するように動作する。
【０１３８】
また、１つの一般的な第１の態様では、本明細書において開示した技術は、１つ以上の受信側エンティティに車両用データおよび他のデータを送信する車両用移動端末を制御する無線基地局を特徴とする。無線基地局の送信部が、車両用移動端末が車両用データおよび／または他のデータのために使用することができる無線リソースを示すアップリンクグラントを、車両用移動端末に送信する。無線基地局の受信部が、アップリンクグラントにおいて示された無線リソースにおける車両用データおよび／または他のデータを受信する。無線基地局は、車両用データが他のデータとは個別に処理されるように車両用移動端末を制御する。
【０１３９】
また、１つの一般的な第１の態様では、本明細書において開示した技術は、車両用移動端末が１つ以上の受信側エンティティに車両用データおよび他のデータを送信するための方法を特徴とする。本方法は、車両用移動端末が車両用データおよび／または他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、車両用移動端末が所属しているセルを制御する無線基地局から受信するステップを含む。次いで、車両用データおよび／または他のデータは、アップリンクグラントにおいて示された無線リソースを使用して送信される。車両用移動端末は、車両用データおよび他のデータを互いに個別に処理する。
【０１４０】
開示されている実施形態のさらなる恩恵および利点は、本明細書および各図から明らかになるであろう。これらの恩恵および／または利点は、本明細書および図面に開示したさまざまな実施形態および特徴によって個別に提供され得、これらの恩恵および／または利点の１つまたは複数を得るためにすべてを備える必要はない。
【０１４１】
これらの一般的な態様および特定の態様は、システム、方法、コンピュータプログラム、またはこれらの任意の組合せを使用して実施することができる。
【０１４２】
以下では、例示的な実施形態について添付の図面を参照しながらより詳細に説明する。
【図面の簡単な説明】
【０１４３】
【図１】３ＧＰＰ  ＬＴＥシステムの例示的なアーキテクチャの図
【図２】３ＧＰＰ  ＬＴＥ（リリース８／９）において定義されている、サブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドの図
【図３】ＵＥ側の例示的なＭＡＣ構造を示す図
【図４】ＰｒｏＳｅ通信のためにＰＣ５を通じてレイヤ２リンクを確立する方法の概略図
【図５】オーバーレイ（ＬＴＥ）システムおよびアンダーレイ（Ｄ２Ｄ）システムにおける送信／受信リソースの使用を示す図
【図６】２基のＵＥにおけるスケジューリング割当ておよびＤ２Ｄデータの送信を示す図
【図７】ＵＥによる自律的なスケジューリングモード２の場合のＤ２Ｄ通信タイミングを示す図
【図８】ｅＮＢによりスケジューリングされるスケジューリングモード１の場合のＤ２Ｄ通信タイミングを示す図
【図９】非ローミングの場合のＰｒｏＳｅのための例示的なアーキテクチャモデルの図
【図１０】偶数個のＰｒｏＳｅ宛先グループの場合の例示的なＰｒｏＳｅバッファ状態報告ＭＡＣ制御要素を示す図
【図１１】実装例に係る対応するＳＰＳリソースまで車両用データの送信を遅らせるためのタイミング図
【発明を実施するための形態】
【０１４４】
「移動局（mobile station）」または「移動ノード（mobile node）」または「ユーザ端末（user terminal）」または「ユーザ機器（user equipment）」は、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有していてもよい。機能エンティティとは、所定の一連の機能を実施するソフトウェアモジュールもしくはハードウェアモジュール、および／または、所定の一連の機能をノードまたはネットワークの他の機能エンティティに提供するソフトウェアモジュールもしくはハードウェアモジュールを意味する。ノードは、自身を通信機器または通信設備にアタッチする１つまたは複数のインタフェースを有していてもよく、ノードはこれらのインタフェースを通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信機器または通信設備にアタッチする論理インタフェースを有していてもよく、ネットワークエンティティは論理インタフェースを通じて別の機能エンティティや通信相手ノードと通信しうる。
【０１４５】
本特許請求の範囲および本出願において使用されている「無線リソース（radio resources）」という用語は、物理無線リソース（時間−周波数リソースなど）を意味するものと広義に理解されたい。
【０１４６】
本出願において使用されている「ＰｒｏＳｅ」または、その非短縮形の「近傍サービス（Proximity Services）」という用語は、背景技術のセクションで例示的に説明したようにＬＴＥシステムにおける近接性に基づくアプリケーションおよびサービスとの関連で用いられる用語である。「Ｄ２Ｄ」等の他の専門用語も、上記関連において使用され、近接サービスのための装置間通信（Device-to-Device communication）を意味する。
【０１４７】
本出願の全体にわたって使用されている「車両用移動端末（vehicular mobile terminal）」という用語は、背景技術のセクションにおいて説明されるような３ＧＰＰの新規検討項目であるＶ２Ｘ（車両用通信）との関連において理解されたい。また、車両用移動端末は、例えば、安全性または運転支援を目的として、車両用通信（すなわち、車両に関係する情報を、車両、インフラ、歩行者等の他のエンティティに渡すこと）を行うために特に車両（例えば、自動車、商用トラック、オートバイ等）に取り付けられる移動端末として広義に理解されたい。任意選択的に、車両用移動端末は、ナビゲーションシステム（そのナビゲーションシステムも自動車に取り付けられている場合）において利用可能な情報（地図情報等）にアクセスすることができてもよい。
【０１４８】
背景技術のセクションにおいて説明したように、３ＧＰＰでは、ＬＴＥによって支援される車両用通信のための新規検討項目が導入された。この車両用通信では、Ｖ２Ｘトラフィックが、Ｕｕインタフェースおよび／またはＰＣ５インタフェースで交換可能である。したがって、Ｖ２Ｘトラフィックは、上記インタフェースのそれぞれを介して交換され、調整される必要がある他のトラフィックと共存する。具体的には、ＵＥが依然として、（上記インタフェースで送信される他のトラフィックと同様に）Ｖ２ＸトラフィックについてもＱｏＳ（サービス品質）要件を確実に満たすことが重要である。具体的には、共存問題がＶ２Ｘトラフィックと他のトラフィックとの間に発生するのは次の場合である。
・  異なるインタフェースを使用する場合（例えば、Ｕｕインタフェースを介したＶ２ＸトラフィックとＰＣ５インタフェースを介した通常のＤ２Ｄトラフィック）
・  両トラフィックがＰＣ５インタフェースを使用する場合（例えば、Ｖ２Ｘトラフィックおよび通常のＤ２Ｄトラフィックが共存する）
・  両トラフィックがＵｕインタフェースを使用する場合（例えば、Ｖ２Ｘトラフィックおよび通常のＬＴＥ  Ｕｕトラフィックが共存する）
【０１４９】
バッファ状態報告、論理チャネルの優先順位付けプロシージャの実行、無線リソースのスケジューリング、またはスケジューリング要求の送信等の重要な手順を適合・改良することによって、これらの共存問題は解決され得、また、適切なＱｏＳの扱いが担保されうる。
【０１５０】
本発明者は、上述した課題の１つまたはいくつかを緩和するため、以下の例示的な実施形態を着想した。
【０１５１】
さまざまな実施形態の特定の実装形態は、３ＧＰＰ標準規格によって与えられる、一部が背景技術のセクションで説明されている幅広い仕様の中で実施され、特に重要な特徴は、以下のさまざまな実装形態において説明するように追加される。なお、これらの実施形態は、例えば、背景技術のセクションで説明した３ＧＰＰ  ＬＴＥ−Ａ（リリース１０／１１／１２／１３）などの（または、今後のリリースの）移動通信システムにおいて有利に使用することができるが、これらの実施形態はこれらの特定の例示的な通信ネットワークでの使用に限定されないことに留意されたい。
【０１５２】
以下の説明は、本開示の範囲を制限するものとしてではなく、本開示を深く理解するための実施形態の単なる例として理解されたい。当業者には、請求項に記載されている本開示の一般的な原理を、さまざまなシナリオに、本明細書に明示的には記載されていない方法で適用できることが認識されるはずである。説明を目的として、いくつかの想定がなされているが、これらの想定は以下の実施形態の範囲を制限するものではない。
【０１５３】
説明によって明らかになるように、様々な実施形態によって、Ｖ２Ｘデータおよび他のデータの（車両用）ＵＥによる処理および送信が改良され、選択的に、リソーススケジューリング、ＬＣＰプロシージャ、バッファ状態報告、スケジューリング要求の送信等の様々な手順が改良される。したがって、他の機能（すなわちさまざまな実施形態によって変更されない機能）は、背景技術のセクションで説明したものとまったく同一のままであってもよいし、さまざまな実施形態に影響することがないように変更してもよい。この他の機能としては、例えば、車両用ＵＥに適切な無線リソースが割り当てられた後にどのようにＶ２Ｘまたは他のデータが実際に車両用ＵＥによって送信されるか、または、どのように車両用ＵＥがＶ２Ｘデータの送信またはＶ２Ｘデータの特定の内容の送信のために設定されるか等に関する他の手順が含まれる。
【０１５４】
［第１の実施形態］
以下では、前述した（１つまたは複数の）課題を解決するための第１の実施形態について詳しく説明する。第１の実施形態のさまざまな実装形態および変形形態も説明する。
【０１５５】
例として、車両に取り付けられ、かつ、本出願の背景技術のセクションにおいて説明したようにＤ２Ｄのフレームワークに基づき（すなわち、ＰＣ５インタフェースを介して）、および、ＵｕインタフェースのためのＬＴＥのフレームワークに基づき、車両用通信を行うことができる車両用ＵＥが想定されている。
【０１５６】
車両用ＵＥが両インタフェース（ＬＴＥ−ＵｕインタフェースおよびＰＣ５インタフェース）でＶ２Ｘトラフィックを個別に送信することも、同時に送信することさえもできることが想定の１つである。Ｖ２ＸトラフィックのＱｏＳ要件を保証するために、リソース割当ておよび／または車両用ＵＥにおけるリソース割当ての処理において、Ｖ２Ｘトラフィックと、他の共存する非Ｖ２Ｘトラフィック（すなわち、Ｖ２Ｘトラフィックの送信に使用されるインタフェースに応じた、通常のＤ２Ｄトラフィックまたは通常のＬＴＥ  Ｕｕトラフィック）とが区別されるべきである。より具体的には、厳密なＶ２Ｘ  ＱｏＳ要件を確実に満たすことができるようにＶ２Ｘ関連のトラフィックを他のトラフィックとは別に制御することができるべきである。以下に提示するように、Ｖ２ＸトラフィックデータのＱｏＳ要件が確実に満たされるようにｅＮｏｄｅＢおよび車両用ＵＥがどのように互いに作用し合うことができるかに関し、異なるいくつかの可能性がある。
【０１５７】
第１の実施形態の実装例によれば、ｅＮｏｄｅＢは、Ｖ２Ｘトラフィックのみの専用のアップリンクグラントを発行してもよい。その結果、該アップリンクグラントにおいて示された無線リソースは、非車両用データではなく車両用データを送信するために使用される。したがって、そのようなアップリンク無線リソース割当てでは、既にＶ２Ｘトラフィックと非Ｖ２Ｘトラフィックとを区別することができていることにより、ｅＮｏｄｅＢは、ＱｏＳ要件を満たし得るためにＵＥが何を最初に送信するかを制御することができる。例えば、車両用データを最初に送信すべきである場合、それに応じてｅＮｏｄｅＢは、Ｖ２Ｘ専用のアップリンクグラントを発行することによって、車両用トラフィックの厳密なレイテンシ要件を満たすことを可能にする。
【０１５８】
車両用データ専用アップリンクグラントを例示的に以下のように実現することができる。車両用ＵＥのために新規のＶ２Ｘ専用ＲＮＴＩが（スケジューリングに使用される通常のＣ−ＲＮＴＩに加えて）提供される。例えば、Ｖ２Ｘ関連のトラフィックを搬送するように意図される最初の無線ベアラを確立する際に、このＶ２Ｘ専用ＲＮＴＩをＵＥにシグナリングする（設定する）ことができる。これは、通常、ＭＭＥがＶ２Ｘベアラ確立用のＱＯＳ／ＱＣＩをｅＮＢにシグナリングした後に行われる。Ｖ２Ｘ専用ＲＮＴＩは、最後のＶ２Ｘ関連アプリケーションが閉じられるまでＵＥに格納されうる。あるいは、代替的に、Ｖ２Ｘ専用ＲＮＴＩは、最後のＶ２Ｘ関連アプリケーションが閉じられた後でも依然として格納され得、新規Ｖ２Ｘアプリケーションが開始されて、対応するベアラが、このＲＲＣ接続が存続する間に確立されるときに再利用されうる。さらなる機能強化として、Ｖ２Ｘ専用ＲＮＴＩは、個々のＶ２Ｘ専用アプリケーションに割り当てられうる（設定されうる）。例えば、ＢＳＭ、ＣＡＭ、ＤＥＮＢ、ＳＰａＴ等のそれぞれに１つのＶ２Ｘ専用ＲＮＴＩを割り当てる。
【０１５９】
Ｖ２Ｘ専用ＲＮＴＩが、アップリンクグラントをスクランブルするためにｅＮＢによって使用される結果、ＵＥが特別のＶ２Ｘ専用ＲＮＴＩを使用してアップリンクグラントを復号することに成功する場合に、ＵＥは、示された無線リソースが非車両用データではなく車両用データの送信のために使用されることになっていることを知る。例えば、ｅＮｏｄｅＢは、車両用データの送信に無線リソースを割り当てるために、ＳＬ−ＲＮＴＩではなくＶ２Ｘ専用ＲＮＴＩを使用してサイドリンクアップリンクグラント（例えば、ＤＣＩフォーマット５（背景技術のセクションを参照））をスクランブルする。同様に、ｅＮｏｄｅＢは、車両用データの送信に無線リソースを割り当てるために、Ｃ−ＲＮＴＩではなくＶ２Ｘ専用ＲＮＴＩを使用することによって通常のアップリンクグラント（すなわち、Ｕｕインタフェースの場合）（例えば、ＤＣＩフォーマット０（背景技術のセクションを参照））をスクランブルする。当然、ｅＮｏｄｅＢは、ＵＥが、示された無線リソースを非車両用データのみのために使用することができるように（また、以下で明らかになるように、場合によっては車両用データのためにも使用することができるように）、通常の方式で（すなわち、Ｃ−ＲＮＴＩ／ＳＬ−ＲＮＴＩを使用して）アップリンクグラントをスケジューリングすることもできる。
【０１６０】
あるいは、明確にＶ２Ｘトラフィックのための新規ＲＮＴＩを定義する代わりに、既存のアップリンクグラントを適合して、示された無線リソースが車両用データのみの送信に使用されるべきか否かをＵＥが区別できるようにしてもよい。この点に関して、適切な情報を、例えば、アップリンクグラントの個別のフィールドに含めることができ、この個別のフィールドを、ＤＣＩフォーマット０またはＤＣＩフォーマット５とすることができる。この新規フィールドは、既存のフィールドのいくつかを再調整する（例えば、あるフィールドを短縮したり、既存のフィールドに新たな意味を指定したりする）ことによって作り出すことができ、それにより、場合によっては新規ＤＣＩも一緒に必要になる。
【０１６１】
あるいは、示された無線リソースが車両用データのみのために、非車両用データのために、または、無線リソースが車両用データおよび非車両用データのために、使用されるべきであることを意味するものとＵＥによって識別されるコードポイントを定義するために、アップリンクグラントのいくつかの既存のフィールドを再利用することができる。例えば、意味がないか、または（ＵＥのＣ−ＲＮＴＩに対応する）レガシーＬＴＥトラフィックにおける予備的な値を有する既存のフィールドにおけるコードポイントのいくつかをこの目的に使用することができる。使用されうるそのようなフィールドの例は、リソースブロック割当て、ＭＣＳおよびＲＶ、ＵＬインデックス（ＴＤＤの場合のみ）、ＤＡＩ等である。これらのフィールドの２つ以上に亘るコードポイントの組合せ（すなわち、意味がないか、または（ＵＥのＣ−ＲＮＴＩに対応する）レガシーＬＴＥトラフィックにおける予期された値を有する組合せ）をこの目的に使用することもできる。例えば、ＦＤＤシステムにおいては、ＴＤＤに特有のフィールドを、この新しい目的のために（Ｖ２Ｘ用のグラントを示すために）容易に使用することができる。しかしながら、最も容易な方法は、先に説明したように新規Ｖ２Ｘ専用ＲＮＴＩを定義してあること、または新規ＤＣＩフォーマットを一緒に設計することであろう。
【０１６２】
第１の実施形態のさらなる実装例によれば、論理チャネルの優先順位付けプロシージャを、Ｖ２ＸトラフィックのＱｏＳ要件を保証する援助となるように適合可能である。背景技術のセクションで提示したように、ＬＣＰプロシージャは、様々な論理チャネルに無線リソース（アップリンクグラントによって示された無線リソース、または無線リソースプールから自律的に選択された無線リソース）を割り当ててトランスポートブロックを生成するためにＵＥによって使用される。したがって、この実装のＬＣＰプロシージャは、任意のＱｏＳ要件を満たすために必要な場合、Ｖ２Ｘデータを個別に扱うことができるように適合される。例えば、ＵｕインタフェースまたはＤ２Ｄインタフェースのために既に規格化されているＬＣＰプロシージャを適合して、アップリンクグラントが意図するトラフィックタイプ（非Ｖ２Ｘおよび／またはＶ２Ｘ）を搬送する特定の論理チャネルのみを考慮することができる。例えば、ＬＣＰプロシージャ中は、リソース割当てに関しては、他の論理チャネルは無視される。例えば、Ｖ２Ｘ専用アップリンクグラントがＵＥによって受信された場合、車両用ＵＥが、Ｖ２Ｘ論理チャネル（すなわち、車両用データを搬送するＬＣ）のみを考慮してＬＣＰプロシージャを行うことにより、車両用データを搬送する（そのインタフェースで送信される他の共存するデータは搬送しない）トランスポートブロックが生成される。反対に、非Ｖ２Ｘ専用の（すなわち、通常の）アップリンクグラントがＵＥによって受信された場合、ＵＥが、非Ｖ２Ｘ論理チャネル（すなわち、非車両用データを搬送する論理チャネル）のみを考慮してＬＣＰプロシージャを行うことにより、他のデータを搬送する（車両用データを搬送しない）トランスポートブロックが生成される。Ｖ２Ｘ論理チャネルと非Ｖ２Ｘ論理チャネルとは、次の様々な手段によって区別することができる。
−  ベアラ設定時に（ＲＲＣ接続再設定メッセージにおいて）Ｖ２Ｘベアラまたは非Ｖ２Ｘベアラを示すフラグを使用する
−  「特別な」優先度（論理チャネル優先度）またはＰＰＰＰを使用する（これらは、レガシー（システム）において定義されていない／利用可能でない）
−  Ｖ２Ｘに属するすべての論理チャネルを、レガシー（システム）において定義されていない／利用可能でないＬＣＧ  ＩＤを有する個別のＬＣＧにマッピングする等
【０１６３】
さらに、ＬＣＰプロシージャを通常の方式で実行することもでき、これにより、すべての論理チャネル（すなわち、車両用論理チャネルおよび他の論理チャネル）が考慮される。その結果、生成されるトランスポートブロックが車両用データおよび他の共存するデータの両方を搬送する。この場合、以下に説明するように、ＬＣ優先度を使用することによって依然として確実にＶ２Ｘトラフィックを個別に扱うことができる。
【０１６４】
したがって、いずれのトラフィックが送信されるかに応じて特定の論理チャネルを選択的に考慮または無視することによって、送信されるトランスポートブロックを生成する際にＵＥによって行われるＬＣＰプロシージャを車両用データおよび／または非車両用データに共通して使用することができる。一方、車両用データを扱うための、および、他の非車両用のデータを扱うための個別のＬＣＰプロシージャが提供されうる。特定のＶ２Ｘ用ＬＣＰプロシージャでは、Ｖ２Ｘ論理チャネルへのリソース割当てを扱うことができ、通常のＬＣＰプロシージャでは、通常の非車両用論理チャネルへのリソース割当てのみを扱うことができる。
【０１６５】
さらに、ＰＣ５インタフェースを介して送信されるトランスポートブロックを生成する際にＵＥによって行われると予測されるＬＣＰプロシージャは、Ｕｕインタフェース用に定義されたＬＣＰプロシージャと比べて、ＬＣ優先度（例えば、ＰＰＰＰ）のみが考慮される点で非常に単純である（背景技術のセクションを参照）。第１の実施形態の改良されたさらなる実装によれば、ＰＣ５インタフェース用の特定のＶ２Ｘ用ＬＣＰプロシージャが提供されうる。このＶ２Ｘ用ＬＣＰプロシージャは、Ｖ２Ｘ論理チャネルを考慮するだけでなく追加のＱｏＳパラメータも考慮するように適合されている。追加のＱｏＳパラメータとは、例えば、Ｕｕインタフェース用のＬＣＰプロシージャにおいて既に使用されているＱｏＳパラメータの中の（ＰＰＰＰ以外の）いくつかのパラメータまたはすべてのパラメータ（すなわち、ＬＴＥ用の論理チャネル優先順位付けの場合のようなレガシー（システム）では、ＰＢＲおよびバケットサイズ時間（ＢＳＤ）パラメータ）である。
【０１６６】
この実装のＤ２Ｄ用ＬＣＰプロシージャによって、車両用トラフィックのＱｏＳの扱いが改良される。例えば、ＰＰＰＰは、通常はアプリケーションによって割り当てられるため、ｅＮｏｄｅＢの制御下にはない。このことは、ｅＮｏｄｅＢがサービス品質を保証するために制御しているべきであるＶ２Ｘトラフィックには不十分でありうる。したがって、ＰＰＰＰに加えてＱｏＳパラメータを用いてＤ２Ｄ用ＬＣＰプロシージャを拡張することにより、厳密なＱｏＳ要件を満たすことができる。
【０１６７】
上述のＬＣＰプロシージャのさらなる改良例によれば、アップリンクグラントによって示された無線リソースは、最大限利用される。具体的には、割り当てられた無線リソースが車両用データを送信するために実際に必要なリソースより大きい場合がある（例えば、グラントによって１００バイトが割り当てられているが、８０バイトの車両用データが存在する）。そのような場合、車両用ＵＥは、パディングによってトランスポートブロックを埋めることができる。例えば、残ってしまう２０バイトは、結果として生じるトランスポートブロックが他のデータを搬送しないようにパディングされる（すなわち、様々なトラフィックタイプの多重化は行われない）。ＰＣ５インタフェースにおいては、受信機が異なることを考慮すると、Ｄ２ＤデータとＶ２Ｘデータの多重化は可能であれば回避されるべきであるが、Ｕｕインタフェースにおいては、ｅＮｏｄｅＢがＬＴＥ−ＵｕデータおよびＶ２Ｘデータの両データの同一の受信機である。したがって、残ってしまう無線リソースのためにトランスポートブロックをパディングのみによって埋める代わりに、残りの２０バイトのトランスポートブロックがＬＴＥ  Ｕｕトラフィックデータの搬送に使用されるように、ＬＴＥ−Ｕｕ送信のためにＵＥによって行われる改良されたＬＣＰプロシージャでは、通常のＬＴＥ−Ｕｕ論理チャネルを（例えば、残ってしまう無線リソースに対して開始される他のＬＣＰプロシージャ中にＬＣ優先度の高い順で）追加的に考慮することができる。この場合、このトランスポートブロックを受信するｅＮｏｄｅＢは、Ｖ２Ｘトラフィックと通常のＬＴＥ  Ｕｕトラフィックとを区別することができ、これらの個別の処理を続けることができる。
【０１６８】
さらなる実装例によれば、ＬＣＰプロシージャにおいて使用される特定の優先度をＶ２Ｘ論理チャネルに割り当てて、Ｖ２Ｘ  ＬＣを個別に扱うことができるようにしてもよい。優先度は、ｅＮＢの制御下においてＶ２Ｘ論理チャネルに割り当てられ、該Ｖ２Ｘ論理チャネルを介して搬送されるデータの内容に応じて異なっていてもよい。例えば、データパケットのサイドリンクデータに関して定義されたＰＰＰＰを、論理チャネルの優先度を定義するために再利用することができる。現在規格化された優先度の範囲は、１〜８であり、優先度１が最も高い優先度であり、優先度８が最も低い優先度である。例示的に、Ｖ２Ｘ  ＬＣのための優先度を、これらの８つの既に規格化されたＬＣ優先度の１つとすることができ、ｅＮＢによってＶ２Ｘ論理チャネルのためにリザーブしておくことができる。それにより、Ｖ２Ｘ論理チャネルを他の論理チャネルから分離することもできる。例えば、Ｖ２Ｘトラフィックが優先されるべきであると想定される場合、ｅＮＢは、すべてのＶ２Ｘ  ＬＣにＬＣ優先度１を割り当てると決定することもできるし、各Ｖ２Ｘ論理チャネルにＬＣ優先度１、２、３を割り当てて、さらにＶ２Ｘ論理チャネルにおいて（例えば、ＣＡＭメッセージ、ＤＥＮＭメッセージ、ＢＳＭメッセージの間で）優先順位付けができるようにすることもできる。
【０１６９】
あるいは、非車両用論理チャネル用に既に定義されている優先度１〜８とは異なるＶ２Ｘ論理チャネル用の新規論理チャネル優先度を定義することもできる。１つの実装例では、異なる３つの優先度（例えば、優先度９〜１１）が区別されうる。例えば、優先度９がＣＡＭを搬送するＶ２Ｘ論理チャネルに割り当てられ、優先度１０がＤＥＮＭを搬送するＶ２Ｘ論理チャネルに割り当てられ、優先度１１がＢＳＭを搬送するＶ２Ｘ論理チャネルに割り当てられる。この場合、優先度８〜１１の中で優先度９が最も高く、優先度１１が最も低い優先度である。例示的に、優先度９〜１１のそれぞれは、他の優先度１〜８のいずれよりも高い優先度であるとＵＥによって理解されうる。その結果、Ｖ２Ｘトラフィックは、他のデータトラフィック（ＬＴＥ−ＵｕトラフィックまたはＤ２Ｄトラフィック）に対して常に優先される。あるいは、優先度９のみ、優先度１０のみ、または、優先度９と１０のみが、他の優先度１〜８のいずれよりも優先度が高いという意味を有することができる。
【０１７０】
当然、これらは単なる例であり、他の優先度および優先度の割り当てが同様に可能である。例えば、個別の論理チャネル優先度（例えば、優先度１２）を、安全性には関係していないＶ２Ｘデータを搬送するＶ２Ｘ論理チャネルに付すことができる。この場合、ＵＥは、この優先度が優先度１〜８のいずれかの間であると解釈することができる（この優先度は、ｅＮＢによって設定されうる）。あるいは、非安全性Ｖ２Ｘデータを搬送するこの論理チャネルには、内容および他のデータに対する相対的優先度に応じて既存の優先度１〜８のいずれかを割り当てることもできる。
【０１７１】
いずれにせよ、ＬＣＰプロシージャにおいて適切に使用される上述のＬＣ優先度は、Ｖ２Ｘトラフィックを個別に扱うことができるようにするさらなるメカニズムである。したがって、このさらなるメカニズムは、Ｖ２ＸデータのＱｏＳ要件を確実に満たすためにｅＮＢによって使用されうる。
【０１７２】
上記では、いくつかのメカニズムに関し、同一のインタフェースを通じて送信される他の共存するトラフィックとは個別にＶ２Ｘトラフィックを扱うことができる方法を述べた。適切であれば、これらの様々なメカニズムを組み合わせることもできる。すなわち、（ｅＮＢの制御下にある）車両用ＵＥが適宜各メカニズムを一緒に実行することができる。例えば、以下に説明するように、いずれの特定のメカニズムを使用するかは、Ｖ２Ｘデータが送信されるインタフェース（ＰＣ５またはＵｕ）に応じて異なる。
【０１７３】
はじめに、車両用ＵＥとｅＮｏｄｅＢの間のＵｕインタフェースにおいて、両トラフィックタイプ（すなわち、車両用トラフィックおよび他のＬＴＥ  Ｕｕトラフィック）を多重することができると想定する。車両用トラフィックを個別に扱うために、ｅＮｏｄｅＢは、例えば、個別のグラント（すなわち、車両用データの送信のための無線リソースを割り当てるためのグラントおよび他のデータの送信のための無線リソースを割り当てるための他のグラント）を提供することができる。また、ＬＣＰプロシージャ（一般に用いられるＬＣＰプロシージャまたは個別のＶ２Ｘ専用ＬＣＰ）は、車両用データのみを搬送するトランスポートブロックが生成されるように、車両用データを搬送する論理チャネルのみを考慮する一方で他の論理チャネルを無視することによって行われる。既に上述のように、割り当てられたリソースが送信されるデータより大きい場合、パディングを使用してもよいし、あるいは例外的に、示された無線リソースが最大限使用されるように、トランスポートブロックを他のトラフィックタイプ（すなわち、ＬＴＥ  Ｕｕトラフィック）のデータで埋めてもよい。
【０１７４】
しかしながら、ｅＮｏｄｅＢが共通のグラント（すなわち、車両用データおよび非車両用データの両方に使用可能な無線リソースを割り当てるグラント）を発行する場合にも、依然としてＵＥは、Ｕｕインタフェースを介して送信されるＶ２Ｘトラフィックを個別に扱うことができる。例えば、車両用データおよび通常のＬＴＥ  Ｕｕデータを扱うための個別のＬＣＰプロシージャが予測されうる。ＵＥは、いずれのトラフィックタイプを最初に処理すべきかを（例えば、対応する各論理チャネルの各優先度に基づいて）決定する（この場合、すべての論理チャネルの中で最も優先度の高い論理チャネルに属するトラフィック（Ｖ２Ｘまたは非Ｖ２Ｘ）が最初に処理される「勝つ」（“winning”）トラフィックである）ことにより、ＵＥがデータを送信すると決定した論理チャネルのみを考慮して対応するＬＣＰプロシージャを行う。さらに、共通のＬＣＰプロシージャを使用する場合であっても依然として、２つのトラフィックタイプを個別に扱うことができる。個別の扱いは、すなわち、上述のように、車両用データを搬送する論理チャネルに適切に優先度を割り当てることにより可能である。また、共通のＬＣＰプロシージャは、共通のグラントにおいて示された無線リソースを優先度の高い順に論理チャネルに割り当てることにより行われるが、この場合、車両用論理チャネルの優先度も考慮される。
【０１７５】
ここで、両トラフィックタイプの多重化が回避されるべきＰＣ５インタフェースを想定すると、Ｕｕインタフェースについて既に詳細に説明したように１つのメカニズムまたはメカニズムの組合せ（両トラフィックタイプの多重化が起こりうるメカニズムは除く）を想定することができる。例えば、割り当てられた無線リソースが送信されるデータより大きい場合、ＰＣ５インタフェースを通じて送信されるトランスポートブロックが１つのトラフィックタイプのみ（車両用データまたは通常のＤ２Ｄデータ）のデータを搬送するべきであることを考慮してトランスポートブロックのパディングが必要となる。
【０１７６】
第１の実施形態のさらなる実装によれば、車両用ＵＥのために設定されるバッファ状態報告手順は、次のように改良される。車両用ＵＥは、送信可能な車両用データの量を示すバッファ状態報告を生成する。車両用データの量は、送信可能な他のデータ（例えば、ＬＴＥ−Ｕｕトラフィックまたは通常のＤ２Ｄトラフィック）とは個別に示される。したがって、ｅＮＢは、ＵＥがどれだけの車両用データを送信したいかを理解し、この情報を効率的な無線リソーススケジューリングに使用することができる。また、これにより、Ｖ２Ｘトラフィックのための特定のＱｏＳ要件がｅＮｏｄｅＢによって満たされうる。例えば、実施形態の特定の変形形態に応じて、ｅＮＢは、多量の車両用データが送信可能になっている場合、Ｖ２Ｘ専用アップリンクグラントを発行して確実に車両用データを最初に送信させてもよい。
【０１７７】
上記では述べなかったが、Ｖ２ＸトラフィックがＰＣ５インタフェースまたはＵｕインタフェースを使用するため、報告されるバッファ状態がＵｕインタフェースを通じて送信可能なデータを表すのか、ＰＣ５インタフェースを通じて送信可能なデータを表すのかについて、バッファ状態報告は明確である。
【０１７８】
しかしながら、車両用ＵＥがＰＣ５インタフェースおよびＵｕインタフェースの両方を介してＶ２Ｘデータの送信を行っている場合に個別のバッファ状態報告を行うこともできる。はじめに、Ｖ２Ｘ論理チャネル（この論理チャネルについてバッファ状態が報告される）がＰＣ５インタフェースに設定されているか、Ｕｕインタフェースに設定されているかをｅＮｏｄｅＢが認識していることに留意されたい。したがって、特定の論理チャネルグループに論理チャネルを割り当てる場合、ｅＮｏｄｅＢは、ＰＣ５インタフェースを通じて送信される論理チャネルとＵｕインタフェースを通じて送信される論理チャネルとを、それらのチャネルを個別のＬＣＧに割り当てることによって既に区別していてもよい。あるいは、ＵＥが、ＰＣ５インタフェースまたはＵｕインタフェースのそれぞれに対して個別のバッファ状態報告を送信することができる。
【０１７９】
さらに、特定の例示的な変形形態においてＵｕ送信のためのバッファ状態報告を想定する場合、これは、バッファ状態報告のための少なくとも１つの特定の論理チャネルグループ（例えば、Ｖ２Ｘ論理チャネルのいくつかまたはすべてが割り当てられるＶ２Ｘ専用ＬＣＧ）を定義することによって実現されうる。いずれのＶ２Ｘ論理チャネルがこのＶ２Ｘ専用ＬＣＧに割り当てられるかを、ｅＮＢが設定することができる。例えば、優先度が高い安全性Ｖ２ＸメッセージをこのＶ２Ｘ  ＬＣＧグループ（例えば、ＬＣＧ  ＩＤ１）に割り当てることができるのに対し、優先度がより低い他の各Ｖ２Ｘメッセージ（例えば、非安全性Ｖ２Ｘメッセージ）は、さらなるＶ２Ｘ  ＬＣＧグループ（例えば、ＬＣＧ  ＩＤ２）にまとめて割り当てられる。明らかなように、この例においてｅＮｏｄｅＢは、ＩＤ１およびＩＤ２を有する既に定義されたＬＣＧをＶ２Ｘのために取っておくことができる結果、ＩＤ０およびＩＤ３を有する残りのＬＣＧのみが残りの非Ｖ２Ｘ論理チャネルのグループ化に利用可能である。
【０１８０】
一例を挙げると、Ｖ２Ｘ論理チャネルのバッファ状態および残りの非Ｖ２Ｘ論理チャネルのバッファ状態を個別に搬送するために、背景技術のセクション（「バッファ状態報告」セクション）において言及した、レガシーＢＳＲ報告（ロングＢＳＲ報告）を例示的に使用することができる。各ＬＣＧについて、対応するバッファサイズフィールドがレガシーＢＳＲ  ＭＡＣ  ＣＥにおいて提供されている（非特許文献２の第６．１．３．１節を参照）。
【０１８１】
あるいは、ＬＣＧの総数が４つでは、バッファ状態報告に十分でない場合がある。特に、「他のトラフィック」（すなわち、ＬＴＥ  Ｕｕトラフィックのようなトラフィック）がより多くの予備のＬＣＧを必要とするシナリオ、または、ＢＳＭ、ＣＡＭ、ＤＥＮＭ、ＳＰａＴ等のようなＶ２Ｘアプリケーションのいくつかが自身の特定のバッファ占有率報告を必要とするシナリオにおいて、４つでは十分ではない場合がある。そのような場合、少なくとも３ビットをＬＣＧ−ＩＤのために例示的に提供して、少なくとも８つのＬＣＧを区別してもよい。上記に関し、より多くのバッファサイズフィールドを搬送することができるように、新規のＢＳＲ  ＭＡＣ  ＣＥを定義する必要がありうる。
【０１８２】
この個別のバッファ状態報告を実現する他のありうる方法は、車両用トラフィックのみのための個別のＢＳＲを持つこと（例えば、新規のＭＡＣ  ＣＥ（既に定義されているＢＳＲ  ＭＡＣ  ＣＥと異なるＭＡＣ  ＣＥ）に新規ＬＣＩＤ（例えば、「Ｖ２Ｘ  ＢＳＲ  ＭＡＣ制御要素」または「車両用ＢＳＲ  ＭＡＣ制御要素」と呼ぶ）を提供すること）である。レガシーバッファ状態報告の場合と同様に、このＢＳＲには、２つのバージョン（例えば、通常のまたは完全な車両用ＢＳＲ  ＭＡＣ制御要素、および短縮（truncated）車両用ＢＳＲ  ＭＡＣ制御要素）があり得る。下表は、新規ＢＳＲの種類（「車両用ＢＳＲ」および「短縮車両用ＢＳＲ」を示す。
【表１】
2019517173.tif 000003
【０１８３】
１つの実装例では、予備のＬＣＩＤを有する車両用ＢＳＲ  ＭＡＣ制御要素が、個別の各Ｖ２Ｘアプリケーションの特定のＬＣＧにおける各Ｖ２Ｘアプリケーションのバッファ占有率を搬送する。すなわち、ｅＮＢが、任意選択的にＶ２Ｘベアラ／論理チャネルを明示的に（例えば、フラグを使用して）設定しつつ、特定のベアラ（論理チャネルＩＤ）とＬＣＧ  ＩＤとのマッピングを設定する。このフラグは、Ｖ２Ｘベアラに割り当てられた優先度と通常のＬＴＥベアラに割り当てられた優先度とが判別不能な場合にＬＣＰプロシージャを実行する際に役立つ。
【０１８４】
例えば、ＰＣ５インタフェースに関し、
・  Ｖ２ＸベアラのためのＬＣＧ  ＩＤおよびレガシーリリース１２／１３のためのＬＣＧ  ＩＤが個別に設定されるように、サイドリンクＢＳＲ（ＳＬ  ＢＳＲ（例えば、図１０参照））のための既存のＭＡＣ制御要素が使用される（例えば、Ｖ２ＸのためのベアラがＬＣＧ  ＩＤ１にマッピングされ、レガシーサイドリンクのためのベアラがＬＣＧ−ＩＤ２にマッピングされるように設定される）。前者（Ｖ２Ｘベアラ）については、宛先インデックスフィールドによって、すべての近くの車両によって受信されることを予定されたブロードキャスト宛先を含むＶ２Ｘ宛先が識別される。後者（レガシーサイドリンク）については、宛先インデックスフィールドによって、ＰｒｏＳｅ宛先が識別される。
・  あるいは、Ｕｕの場合について上述したように使用される、サイドリンク車両用ＢＳＲのための新規ＭＡＣ制御要素が存在する。これは、任意の宛先ＩＤフィールドを要求してもよいし、要求しなくてもよい。宛先ＩＤフィールドの長さは、ＳＬ  ＢＳＲの長さと異なることもできる。
【０１８５】
第１の実施形態のさらなる実装によれば、Ｖ２Ｘ送信を行うために十分な無線リソースを有していないＵＥが使用するスケジューリング要求手順が改良される。これまで、スケジューリング要求（例えば、１ビット）は、スケジューリング要求の送信をトリガしたデータのタイプまたは優先度に関する情報を提供することなく、ＵＥによって送信されている。改良によれば、無線リソースをｅＮｏｄｅＢに要請するためのＶ２Ｘ専用スケジューリング要求が提供される。具体的には、専用のスケジューリング要求は、要求された無線リソースが車両用データの送信に使用されることを示し、したがって、ｅＮｏｄｅＢに情報が提供される。あるいは、言い換えると、専用のスケジューリング要求は、Ｖ２Ｘデータが利用可能になることによってトリガされている。これは、例示的に、他の（１つまたは複数でありうる）ＳＲ設定を設定しかつＳＲ設定ごとの目的（例えば、ＬＴＥトラフィックまたは（専用の）Ｖ２Ｘトラフィック）を示す異なるＲＲＣ設定を使用することにより実現することができる。
【０１８６】
したがって、ｅＮｏｄｅＢは、スケジューリング要求が車両用データによってトリガされたことを理解し、この情報をより効率的な無線リソーススケジューリングに使用することができる。
【０１８７】
さらなる変形形態が、このＶ２Ｘ専用スケジューリング要求に基礎を置く。この変形形態では、車両用ＵＥが送信したいあり得るデータ量をｅＮｏｄｅＢが認識していることがさらに想定される。例えば、ｅＮｏｄｅＢは、特定のサイズの周期的データがＵＥによって送信されることを知っているため、Ｖ２Ｘ専用スケジューリング要求に対して既に応答して、車両用ＵＥにスケジューリング要求をトリガした車両用データを送信するのに十分なアップリンクグラントを提供することができる。また、車両用ＵＥは、通常のＳＲ手順によって規定されるように、最初にｅＮｏｄｅＢにバッファ状態報告を送信し、さらなる無線リソースを許可してもらい、次いで車両用データを送信する必要がなくなる。これにより、送信されるアップリンクグラントが１つのみであり、バッファ状態報告を送信する必要が無いため、遅延が回避され、無線リソースが節約される。
【０１８８】
背景技術のセクションにおいて説明したように、Ｄ２Ｄ通信ではモード２の無線リソース割当て（ＵＥによる自律的なスケジューリング）も可能である。この場合、（車両用）ＵＥには、少なくとも１つの無線リソースプールが設定され、各無線リソースプールが、それぞれ、ＰＣ５インタフェースを介してＤ２Ｄ送信を行うことに使用可能な無線リソースを示す。そのように設定される場合、ＵＬグラントを（要求して）ｅＮＢから受信する代わりに、ＵＥはリソースプールから自律的に無線リソースを選択することにより自身のＵＬグラントを生成することができる。次いで、このＵＬグラントを、送信可能なデータの送信に使用することができる。
【０１８９】
既に上述の同様のメカニズムを、ＰＣ５でのモード２のスケジューリングのために実現することができる。可能であれば、Ｖ２Ｘトラフィックおよび他のＤ２Ｄトラフィックは、対応する受信機が異なりうる（すなわち、他の車両用エンティティまたは他のＤ２Ｄ  ＵＥ）ことを考慮すると、１つのトランスポートブロック（すなわち、データパケット）において多重化されるべきではないことに留意されたい。例えば、車両用ＵＥは「共通の」ＵＬグラントまたはＶ２Ｘ専用ＵＬグラントを生成してもよい。ＵＥが共通のＵＬグラントを選択するかＶ２Ｘ専用ＵＬグラントを選択するかは、実装に応じて異なりうる。例えば、上記に関し、ＵＥは、Ｄ２ＤデータおよびＶ２Ｘデータの量および／または優先度を考慮して、共通のＵＬグラントを選択するか、Ｖ２Ｘ専用のＵＬグラントを選択するかを決定してもよい。一般に、ＵＥは、次の送信機会においてＶ２Ｘデータを送信するか、通常のＤ２Ｄデータを送信するかを決定する必要がありうる。この選択は、２つのトラフィックタイプのデータパケットのＰＰＰＰに基づくことができる。例えば、優先度が最も高いトラフィックタイプが第１に送信されるために選択される。また、事前に定義されたいくつかの規則を、車両用ＵＥにおいて適用することができる。この規則とは、例えば、Ｖ２Ｘデータは通常のＤ２Ｄデータよりも常に優先されるというものやＶ２Ｘ安全性メッセージは通常のＤ２Ｄデータよりも常に優先されるというものである。
【０１９０】
いずれにせよ、上述のように、ＵＥが個別のアップリンクグラントを選択することができるため、ＵＥは、そのグラントの選択タイプ（すなわち、Ｄ２ＤまたはＶ２Ｘ）に応じたＬＣのみを選択的に考慮してＬＣＰプロシージャを行う。しかしながら、共通ＵＬグラントを有している場合でも、依然として、Ｖ２Ｘトラフィックと他のデータトラフィック（この場合、他のＤ２Ｄ  ＵＥへの通常のＤ２Ｄトラフィック）とを異なる方式で扱うことができる。この場合、車両用ＵＥは、いずれのトラフィックタイプを最初に送信するかを決めた後、適切なＬＣＰプロシージャを行うことができる。しかしながら、例えば、レガシーＤ２Ｄデータが選択される場合、さらに、背景技術のセクションにおいて説明したＤ２ＤレガシーＬＣＰプロシージャは、ＬＣＰにおいてＶ２Ｘ論理チャネルではなく通常のＤ２Ｄ論理チャネルのみを考慮して実行可能である。そのため、生成されたトランスポートブロックがＶ２Ｘデータをも含んでしまうことはない。一方、Ｖ２Ｘデータが最初に送信されるべきである場合、既存のＤ２Ｄ  ＬＣＰプロシージャを行うこともでき（この場合、ＬＣＰにおいて通常のＤ２Ｄ論理チャネルは無視される）、専用のＶ２Ｘ−ＬＣＰプロシージャを行うこともできる。既に上述のように、専用のＶ２Ｘ−ＬＣＰプロシージャでは、ＰＰＰＰ（ＬＣ優先度）だけではなく、追加のＱｏＳパラメータ（ＰＢＲ、Ｂｊ等）を考慮してもよい。
【０１９１】
他の実装によれば、車両用の関連トラフィックの送信のためにＵｕインタフェースに確立された無線ベアラは、特定の識別子（例えば、特定のＬＣ  ＩＤまたは特定の範囲のＬＣ  ＩＤ（例えば、ＬＣＩＤ１０〜１５が車両用無線ベアラのために取っておかれる））に関連付けられることによって他のレガシーＬＴＥ無線ベアラから区別される。また、ベアラが車両用ベアラとして識別されるように、ベアラを確立する間にＲＲＣ接続再設定メッセージにおいてフラグを提供してもよい。また、明確に無線ベアラを車両用無線ベアラとして識別する特別な論理チャネル用優先度の値を提供することができる。
【０１９２】
さらに他の実施形態によれば、Ｖ２Ｘトラフィックを、安全性メッセージと非安全性メッセージとにさらに分離してから、これらが区別されるように異なる方式で送信する。具体的には、安全性メッセージと非安全性メッセージとは、異なるキャリア周波数で送信される。例えば、安全性メッセージを共有のキャリア（例えば、ＰＣ５の５．９Ｇｈｚ）で、非安全性メッセージを、現在の事業者により所有されるキャリアで送信することができ、また、その逆でもよい。
【０１９３】
さらに他の実装によれば、ＵＥの半永続スケジューリング（ＳＰＳ：Semi-Persistent Scheduling）グラントのための挙動が改良される。（Ｅ）ＰＤＣＣＨでＵＥにグラントを送信するためのＵｕにおけるシグナリングオーバーヘッドを減少するために（また、先行するＢＳＲのオーバーヘッドを減少するために）、Ｖ２Ｘ送信を行う予定のＵＥに周期的なＰＣ５無線リソースを割り当てるためにＳＰＳを使用することができる。Ｖ２Ｘメッセージ（ＢＳＭ、ＣＡＭ、ＤＥＮＭ等の安全性メッセージ）のいくつかがほとんど周期的だからである。しかしながら、車両用データの周期性は、厳密に周期的ではない。パケット生成は、（ＶｏＩＰとは異なり）厳密に周期的なタイムスケジュールに沿って行われず、（例えば、車両の速度変化に応じて）周期的な間隔「付近で行われる」（“hover around”）。
【０１９４】
したがって、ｅＮＢがＳＰＳリソースを１００ｍｓごとに（すなわち、時間インスタンスｔ、ｔ＋１００、ｔ＋２００、ｔ＋３００…に）発生するように設定したが、車両用データが時間インスタンスの若干前に（例えば、ｔ＋９０に）送信可能になる場合、現在のＵＥの挙動では、次に到来しうる送信機会において車両用データを送信するために、無線リソース（例えば、この車両用データによってトリガされたＳＲ）の追加の要求がトリガされる。
【０１９５】
しかしながら、車両用データのためのＳＰＳ割当てがこのデータのＱｏＳ要件を満たすために設定されているため、これらの追加的に要求された無線リソースを使用することにより車両用データを送信することは、有利ではなく、むしろ無線リソースを無駄にしている。追加の無線リソースをスケジューリングしなければならず、また、想定より早く車両用データを送信することに使用されたからである。ＵＥのこの挙動を回避するために、以下の実装を提供する。
【０１９６】
１）  ＳＰＳ割当てによって提供される送信機会の直前に周期的な車両用データが送信可能になる場合、ＵＥは、ＳＰＳ送信機会（上記の例ではｔ＋１００）までデータをバッファに入れ、その後、ＳＰＳリソースを使用してバッファに入れた車両用データを送信する。
【０１９７】
２）  また、この周期的な車両用データは、ＳＲ／ＢＳＲをトリガするべきでない。トリガされたＳＲ／ＢＳＲによって要求される対応する動的割当てが回避されるべきだからである。
【０１９８】
３）  一方、送信可能になる他のデータが依然として、一般に使用されるスケジューリング要求およびバッファ状態報告の送信を、車両用データのためのＳＰＳリソースが存在しなかったかのようにトリガする可能性がある。
【０１９９】
４）  さらに、ＵＥにとって利用可能な動的グラントも、この特定の周期的な車両用データの送信のために使用すべきではない。ＳＰＳ無線リソースが具体的にこの特定の周期的車両用データに関し設定されたからである。
【０２００】
５）  反対に、周期的な車両用データのために設定されたＳＰＳ無線リソースも他の非車両用のデータを送信するために使用するべきでない。
【０２０１】
６）  ２つ以上のＶ２ＸのＳＰＳによって設定されたリソース割当てが存在する場合、各リソース割当てについて、上記規則が守られるべきである（他のすべてを「他のデータ」と見なす）。
【０２０２】
７）  ５）の代わりとして、非Ｖ２Ｘデータのみが「他のデータ」と見なされるべきである。すなわち、ｔ＋１００において、ＵＥは、他のＶ２Ｘアプリケーションからのデータを送信／多重化することができる。
【０２０３】
モード２の場合（ＵＥの選択によるグラントの場合）、Ｖ２Ｘデータ送信のためのグラントのＵＥによる選択に関しても、上記規則はＵＥに適用される。
【０２０４】
上記関連において、文脈に応じて、「他のデータ」という用語は、ＬＴＥトラフィック、リリース１２／１３のＰＣ５トラフィック（例えば、商用または公共安全）、「このアプリケーション以外の」アプリケーションからのＶ２Ｘデータの１つまたは複数を意味し得る。
【０２０５】
これを図１１に例示する。図１１では、どのように車両用データが、上記のように実際に設定されたＳＰＳ無線リソースの十分前に送信可能になるかが示される。しかしながら、図１１から明らかであるように、実際のデータ送信は、対応する次のＳＰＳリソースまで遅延している。
【０２０６】
上述のＳＰＳリソース設定は、「センシング」（“Sensing”）と呼ばれる概念に基づいている。センシングには、純粋なエネルギー検出センシングと、例えば、受信機がＳＰＳリソースを手放さずにいる長さを示すＳＡ（ＰＳＣＣＨ）シグナリングの内容に基づくセンシングとの少なくとも２つのタイプがあり得る。エネルギーに基づいたセンシング（例えば、ＲＳＳＩ）を、データリソース（ＰＳＳＣＨ）および／またはＳＡ（ＰＳＣＣＨ）リソースに行うことができる。
【０２０７】
データリソースに対しては、いずれのデータリソースが使用可能かをチェックするためにエネルギーセンシングが行われる。次いで、ＵＥ（Ａ）は、データ送信のために選択した（センシングの結果として選択した）リソース情報についての情報を含むＳＡを送信する。しかしながら、ＵＥ（Ａ）が送信しようとする送信機会において、選択された当該データリソースが実際に使用可能のままであると十分に結論付けることができるかは明確ではない。他のＵＥが自身のＶ２Ｘアプリケーションデータが到着する別の周期性に従って過去に（ただし、ＵＥ（Ａ）がセンシングを行った機会において）同一のデータリソース（ＰＲＢ）を使用した可能性があるからである。したがって、上記ＵＥ（Ａ）が特定のリソースで送信しようとする送信機会を確保するために、ＵＥ（Ａ）は、予定する送信機会における上記特定のリソースでのデータ送信をリザーブしうるすべての機会を監視しなければならない。この場合、好適な代替案は、（同一のデータリソースで送信することによって）所定の周期性を有するデータリソースを取っておくことのみがＵＥにとって可能であるように、周期性をデータリソースプールに割り当てることである。例えば、ＵＥが時間機会「ｔ」において送信したい場合、かつ、この送信リソースプールに割り当てられた周期性が１００ｍｓおよび５０ｍｓである場合、該送信機は、ｔ−１００および／またはｔ−５０におけるＰＲＢで送信する必要がある。この例では、同様に時間機会「ｔ」において送信しようとする新規ＵＥ（Ａ）は、該ＰＲＢに対して第一にｔ−１００およびｔ−５０の両方においてエネルギーセンシングを行うべきである。この場合、ｔ−１００およびｔ−５０の両方におけるセンシングによって、これらのリソースがこれらの両方の機会において使用されなかったことが示される場合のみ、ＵＥ（Ａ）は、機会「ｔ」における送信を開始する。
【０２０８】
上記方式には欠点が２つある。１つ目の欠点は、すべてのデータリソースに対して／すべてのデータリソースに亘ってエネルギーセンシングを行う必要がある（それにより、ＵＥのバッテリが消費される）ことである。２つ目の欠点は、送信機（あるＰＲＢを使用する送信機）が次の送信機会（すなわち、ｔ＋５０またはｔ＋１００等）において同一のリソースをもう使用する予定がないことを他の潜在的な送信機に示す手段がないことである。これらの欠点に関する改善を行うために、本明細書において、以下、他の実施形態を提示する。
【０２０９】
センシングは、潜在的な送信機がＳＡ内容自体を理解しようとするようにＳＡ（ＰＳＣＣＨ）リソースに対して行われる。センシングは「将来の」データ送信の可能性を感知するために行われる。ＳＡ内容は、対応するデータリソース（ＰＲＢ（すなわち「リソースブロック割当て」））の情報（Ｔ−ＲＰＴ等）に加えてオプションの周期性の値を示す。この意味で、示された「周期性」は、「この」ＳＡ送信（または、ＳＡの特定の反復）の時間からのオフセット、または「この」データ送信機会における特定のデータ送信（例えば、Ｔ−ＲＰＴの最初の「１」に対応するデータ送信）からのオフセットを示す。この方法によって、将来の送信機会の潜在的な送信機がすべてのデータリソースに対して／すべてのデータリソースに亘ってエネルギーセンシングを行わなくてもよくなる。ＳＡ内容（周期性を含む）から、特定の将来の機会について、すべてのＰＲＢのいずれが確かに占有されているかが明らかになるからである。次いで、エネルギーセンシングを「この」機会の「残りの」データＰＲＢに行う必要がある。さらに、この方法によって、（或るＰＲＢを使用する）送信機がＳＡに「周期性」情報を含めないことによって次の（将来の）送信機会（すなわち、ｔ＋５０またはｔ＋１００等）においてもはや同一のリソースを使用する予定がないことを他の潜在的な送信機に示すことが可能になる。潜在的な送信機は、ＳＡにいかなる「周期性」情報も見つけない場合、示されたデータリソース（ＰＲＢ（すなわち「リソースブロック割当て」））が少なくともこのＵＥ（ＳＡ送信機）によって占有されていないと結論する。
【０２１０】
さらに、長期間（例えば、５回または１０回）の将来の「機会」を取っておくことは、それほど有用ではなく、ＮＥＸＴ機会のみで十分である（「ＮＥＸＴ」は、ＰＳＣＣＨ内のブール型の情報のようなものである）。以下が、その理由である。
・  新たに入ってくる受信機に後から対処するためにＳＡ（ＰＳＣＣＨ）送信自体を停止することができないこと
・  より先の将来まで機会を取っておくことには、適用されるかがより不確実であるリスクがあること
【０２１１】
特定のデータリソースを既に使用しているＵＥ／特定のデータリソースで既に送信しているＵＥがセンシングを継続的に行う必要がないことに留意されたい。
【０２１２】
したがって、この点に関し、以下の機能強化が導入される。
機能強化１：  ＳＡ（ＰＳＣＣＨ）は、「周期性」および「Ｎｅｘｔ」に関する情報を含むか、または、
機能強化２：  各リソースプールは、それぞれに関連付けられた特定の周期性を有し、ＳＡ（ＰＳＣＣＨ）は「Ｎｅｘｔ」インジケーションを含む。
【０２１３】
［第２の実施形態］
さらに、Ｖ２Ｘサポートを効率的に実現するために、各車両用ＵＥが、（Ｕｕインタフェースおよび／またはＰＣ５インタフェースにおける）Ｖ２ＸサービスおよびそのようなＶ２ＸサービスのＱｏＳ要件を同様にサポートすることができる適当なネットワーク／セルに接続されることが重要である。具体的には、ＵＥは、任意のｅＮＢにおけるＲＲＣ接続を開始してもよく、後にＡＴＴＡＣＨ要求メッセージにおいて、ＵＥがＶ２Ｘトラフィックを行う予定であることを示す。ｅＮＢはＭＭＥを選択するが、そのＭＭＥがＶ２Ｘをサポートしていない場合があるため、ＭＭＥは接続の解除を開始する。Ｖ２Ｘ  ＱＯＳをサポートしていないＭＭＥは、ＱＣＩを割り当てることができない場合がある。そのようなＭＭＥがＶ２ＸのためのＱＯＳ要件を理解しないからである。特定のＶ２ＸベアラについてＭＭＥからのＱＣＩシグナリングがない状態では、ｅＮＢは、Ｖ２Ｘ論理チャネルに無線ベアラ特性を割り当てることができない場合があり、ＱＯＳを満たすためにレガシーＰＰＰＰのみに依存することになる。これは、上述のように不十分である。
【０２１４】
したがって、ｅＮｏｄｅＢは、車両用ＵＥによるＶ２Ｘトラフィック要求を実際にサポートするＭＭＥが見つかるまで他のＭＭＥを選択しなければならないか、あるいは、ＵＥが、Ｖ２ＸトラフィックをサポートするＭＭＥに実際に接続されたｅＮｏｄｅＢを見つけるまで他のｅＮｏｄｅＢに接続しなければならない。明らかに、この手順は、可能ではあるが、遅延要件および無線リソースの消費の点であまり効率的ではない。したがって、さらなる第２の実施形態では、これらの不利益を回避するメカニズムを提供する。この実施形態を、上述の第１の実施形態（ならびに、その変形形態および改良形態）と組み合わせて使用することもできるし、それらとは独立させて使用してもよい。
【０２１５】
具体的には、Ｖ２Ｘトラフィック（および／または、Ｖ２Ｘトラフィックのための対応するＱｏＳ要件）をサポートするＭＭＥに接続されるｅＮｏｄｅＢは、車両用ＵＥが接続に適したｅＮｏｄｅＢ（すなわち、Ｖ２ＸをサポートするＭＭＥに接続されているｅＮｏｄｅＢ）を選択することを援助するために、セル内において対応する適性インジケーションをブロードキャストしてもよい（または、直接ＵＥに送信してもよい）。また、接続またはキャンプオンのためにいくつかのｅＮｏｄｅＢから選択しなければならない車両用ＵＥは、ｅＮｏｄｅＢの中で、このＶ２Ｘ適性インジケーションをブロードキャストした（あるいは送信した）１つを選択する。
【０２１６】
Ｖ２Ｘ適性インジケーションがｅＮｏｄｅＢによってどのように送信されるかについていくつかの様々な可能性がある。１つの可能性では、Ｖ２Ｘ適性インジケーションは、ｅＮｏｄｅＢによって特定のＳＩＢのメッセージ（例えば、ＳＩＢ２８）においてブロードキャストされる。また、車両用ＵＥがそのようなＳＩＢ  ２８を受信する場合、車両用ＵＥは、Ｖ２Ｘ適性インジケーションから、ネットワークがＶ２Ｘおよび対応するＶ２Ｘサービス品質をサポートすることができることを理解する。
【０２１７】
次いで、適切なＤ２Ｄリソースプールが既に利用可能かに応じて、車両用ＵＥは、ｅＮｏｄｅＢに接続した後にＲＲＣ接続状態になり、次いで、ネットワークは、Ｕｕを使用すべきか、ＰＣ５を使用すべきか、両方を使用すべきかをＵＥに伝える。一方で、システム情報ブロードキャスト（ＳＩＢ２８）には既に、モード２のようなＶ２Ｖリソース（すなわち、少なくとも１つのＤ２Ｄ無線リソースプール）が含まれているため、ＵＥがＲＲＣアイドル状態にとどまり、無線リソースプールの１つから選択された無線リソースを使用してＰＣ５インタフェースを介してＶ２Ｖ送受信を行うことができる。しかしながら、ＰＣ５インタフェースが十分なＱｏＳ（例えば、信頼性）を提供しないと想定される場合、ＵＥは依然として、ＲＲＣ接続を開始してＵｕリソースを求めることができる（これは、Ｖ２Ｘのためにモード２のリソースが提供される場合であってもＵＥがＲＲＣ接続の確立を開始することができるようにする新規インジケーションに基づく）。
【０２１８】
例として、Ｖ２Ｖ通信用のＵｕリソースが提供されているか否かについても示すように、適性インジケーションを２ビットのインジケーションとして実装することができる。
００：  空（予備）
０１：  Ｕｕ無し；ＰＣ５有り
１０：  Ｕｕ有り；ＰＣ５無し
１１：  両方有り
【０２１９】
既に上述したように、ＵＥは、自身がＶ２Ｘトラフィックデータの送信のためにＰＣ５インタフェースおよび／またはＵｕインタフェースを使用する予定であることをｅＮｏｄｅＢに示してもよい。ＲＲＣ接続要求メッセージまたはＲＲＣ接続再設定完了メッセージにおいて、この予定をｅＮｏｄｅＢに提供することができる。より詳細には、ＲＲＣ接続要求メッセージは、Ｖ２Ｘメッセージを送信する予定を示すために新規の確立原因または新規の予備のＬＣＩＤを含んでいてもよい。あるいは、ＰＲＡＣＨの隔離（例えば、プリアンブルの分離）を、上記目的で使用することができる。一方、ＲＲＣ接続再設定完了メッセージは、Ｖ２Ｘメッセージを送信する予定を示すために新規の原因または新規の予備のＬＣ  ＩＤを含んでいてもよい。あるいは、新規ＭＡＣ  ＣＥを、上記目的で提供することができる。
【０２２０】
したがって、いずれにせよ、ｅＮｏｄｅＢは、車両用ＵＥの意図を理解し、Ｖ２Ｘをサポートする適当なＭＭＥを選択し、（Ｓ１接続確立の）対応するメッセージを該ＭＭＥに送ってもよい。したがって、ＵＥが車両用データの送信を開始できるまでに遅延は生じない。また、無線リソースもＵＥバッテリも、適切なｅＮｏｄｅＢに接続しようとする間に浪費されることがない。
【０２２１】
［さらなる実施形態］
第１の態様によれば、１基以上の受信側エンティティに車両用データおよび他のデータを送信する車両用移動端末が提供される。車両用移動端末の受信部が、車両用移動端末が車両用データおよび／または他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、前記車両用移動端末が所属しているセルを制御する無線基地局から受信する。車両用移動端末の送信部が、アップリンクグラントにおいて示された無線リソースを使用して車両用データおよび／または他のデータを送信する。車両用移動端末は、車両用データおよび前記他のデータを互いに個別に処理するように動作する。
【０２２２】
第１の態様に加えて提供される第２の態様によれば、受信したアップリンクグラントは、車両用移動端末が車両用データの送信のために使用することに使用可能な無線リソースを示す車両用データ専用アップリンクグラントである。送信部は、車両用データ専用アップリンクグラントにおいて示された無線リソースを使用して車両用データを送信する。任意選択的に、車両用データ専用アップリンクグラントは、
・  車両用移動端末の車両用データ専用識別子でスクランブルされているか、または、
・  示された無線リソースが車両用アップリンクの送信のために使用されるものであることを示す情報を含み、任意選択的に、当該情報は、車両用データ専用アップリンクグラントの個別フィールドに含まれているか、または車両用データ専用アップリンクグラントの少なくとも１つのフィールドのコードポイントとして符号化されている。
【０２２３】
第１の態様に加えて提供される第３の態様によれば、受信したアップリンクグラントは、車両用移動端末が車両用データおよび他のデータの送信のために使用することができる無線リソースを示す共通アップリンクグラントである。無線基地局のプロセッサが、共通アップリンクグラントにおいて示された無線リソースが車両用データの送信のために使用されるものであるか、他のデータの送信のために使用されるものであるか、あるいは車両用データおよび他のデータの送信のために使用されるものであるかを判定する。任意選択的に、上記判定は、他のデータを搬送する論理チャネルに関連付けられた優先度および車両用データを搬送する車両用データ論理チャネルに関連付けられた優先度に基づいている。送信部は、判定された車両用データおよび／または他のデータを、共通アップリンクグラントにおいて示された無線リソースを使用して送信する。
【０２２４】
第１の態様から第３の態様の１つに加えて提供される第４の態様によれば、車両用移動端末のプロセッサが、アップリンクグラントにおいて示された無線リソースを、車両用データを搬送する車両用データ論理チャネルに、および／または他のデータを搬送する論理チャネルに優先度の高い順に割り当てるための第１の論理チャネル優先順位付けプロシージャを実行して、車両用データおよび／または他のデータを搬送するデータパケットを生成する。プロセッサは、
・  受信したアップリンクグラントにおいて示された無線リソースが車両用データの送信のために使用されるものである場合、車両用データを搬送するデータパケットを生成するために、車両用データを搬送する車両用論理チャネルのみを考慮して第１の論理チャネル優先順位付けプロシージャを実行し、
・  受信したアップリンクグラントにおいて示された無線リソースが他のデータの送信のために使用されるものである場合、他のデータを搬送するデータパケットを生成するために、他のデータを搬送する論理チャネルのみを考慮して第１の論理チャネル優先順位付けプロシージャを実行し、
・  受信したアップリンクグラントにおいて示された無線リソースが他のデータおよび車両用データの送信のために使用されるものである場合、車両用データおよび他のデータを搬送するデータパケットを生成するために、車両用データを搬送する車両用論理チャネルおよび他のデータを搬送する論理チャネルの両チャネルを考慮して第１の論理チャネル優先順位付けプロシージャを実行する。
【０２２５】
第１の態様から第４の態様の１つに加えられる第５の態様によれば、少なくとも１つの車両用データ論理チャネルが、車両用データを搬送するために車両用移動端末に設定される。各車両用データ論理チャネルは、それぞれが搬送する車両用データに応じた優先度と関連付けられており、車両用データ論理チャネルの優先度は、他のデータを搬送する論理チャネルに関連付けられた優先度と異なる。任意選択的に、車両用データ論理チャネルのいくつかの優先度は、他のデータを搬送する論理チャネルの優先度より高い。任意選択的に、安全性メッセージを搬送する車両用データ論理チャネルの優先度のみが、他のデータを搬送する論理チャネルの優先度より高い。
【０２２６】
第１の態様から第５の態様の１つに加えられる第６の態様によれば、車両用移動端末のプロセッサが、車両用移動端末において送信可能な車両用データの量、および車両用移動端末において送信可能な他のデータの量を個別に示すバッファ状況報告を生成する。任意選択的に、車両用データを搬送する車両用データ論理チャネルが、少なくとも１つの車両用データ論理チャネルグループに割り当てられ、バッファ状況報告は、車両用データ論理チャネルグループのすべての車両用データ論理チャネルから送信可能な車両用データの量を示すために生成される。任意選択的に、車両用データ論理チャネルの少なくとも１つの車両用データ論理チャネルグループへの割当ては、無線基地局によって制御される。
【０２２７】
第１の態様から第６の態様の１つに加えられる第７の態様によれば、車両用データおよび他のデータは、サイドリンク無線インタフェースを介して他の車両用エンティティに送信されるものである。車両用移動端末は、サイドリンク無線インタフェースを介した送信を行うために使用可能な無線リソースをそれぞれが示す少なくとも１つの無線リソースプールを有するように設定される。プロセッサは、車両用データおよび他のデータの内容に応じて車両用データまたは他のデータを優先し、優先された車両用データまたは他のデータを送信するために無線リソースプールの１つから無線リソースを選択する。
【０２２８】
第１の態様から第７の態様の１つに加えられる第８の態様によれば、送信部は、無線基地局に車両用データスケジューリング要求を送信して無線リソースを要求し、車両用データスケジューリング要求は、要求された無線リソースが車両用データの送信のために使用されるものであること示す。任意選択的に、受信部は、送信した車両用データスケジューリング要求に対する無線基地局からの第２のアップリンクグラントを受信する。送信部は、第２のアップリンクグラントにおいて示された無線リソースを使用して車両用データを送信する。
【０２２９】
第１の態様から第８の態様の１つに加えられる第９の態様によれば、車両用データおよび他のデータは、第１の無線インタフェースを介して無線基地局に、および／またはサイドリンク無線インタフェースを介して他の車両用エンティティに送信される。
【０２３０】
第１の態様から第９の態様の１つに加えられる第１０の態様によれば、受信部は、車両用データトラフィックおよび対応するサービス品質要件をサポートすることができるコアネットワークエンティティに無線基地局が接続されていることを示す車両用データ適性インジケーションを、複数の無線基地局の少なくとも１つから受信する。車両用移動端末のプロセッサが、複数の無線基地局の中から、受信した車両用データ適性インジケーションの送信元である１つの無線基地局を選択して該１つの無線基地局に所属する。任意選択的に、車両用データ適性インジケーションは、システム情報の一部として無線基地局によってブロードキャストされる。任意選択的に、車両用データ適性インジケーションは、車両用データトラフィックが車両用移動端末と無線基地局との間で第１の無線インタフェースを介して、および／または車両用移動端末と他の車両用エンティティとの間でサイドリンク無線インタフェースを介してサポートされているかをさらに示す。
【０２３１】
第１０の態様に加えられる第１１の態様によれば、送信部は、車両用移動端末が１つの無線基地局に所属する際に車両用データを送信する予定であることを示す。任意選択的に、車両用データを送信する予定のインジケーションは、接続要求メッセージまたは接続再設定完了メッセージに含まれる。
【０２３２】
第１２の態様によれば、車両用データおよび他のデータを１基以上の受信エンティティに送信する車両用移動端末を制御する無線基地局が提供される。無線基地局は、車両用移動端末が車両用データおよび／または他のデータのために使用することができる無線リソースを示すアップリンクグラントを車両用移動端末に送信する送信部を備える。無線基地局の受信部が、アップリンクグラントにおいて示された無線リソースにおける車両用データおよび／または他のデータを受信する。無線基地局は、車両用データが他のデータとは個別に処理されるように車両用移動端末を制御するように動作する。
【０２３３】
第１２の態様に加えられる第１３の態様によれば、受信されたアップリンクグラントは、車両用移動端末が車両用データの送信のために使用可能な無線リソースを示す車両用データ専用アップリンクグラントである。任意選択的に、車両用データ専用アップリンクグラントは、
・  無線基地局のプロセッサによって車両用移動端末の車両用データ専用識別子でスクランブルされているか、または、
・  示された無線リソースが車両用アップリンクの送信のために使用されるものであることを示す情報を含み、任意選択的に、当該情報は、車両用データ専用アップリンクグラントの個別フィールドに含まれているか、または車両用データ専用データグラントの少なくとも１つのフィールドのコードポイントとして符号化されている。
【０２３４】
第１２の態様または第１３の態様に加えられる第１４の態様によれば、少なくとも１つの車両用データ論理チャネルが、車両用データを搬送するために車両用移動端末に設定される。各車両用データ論理チャネルは、それぞれが搬送する車両用データに応じた優先度と関連付けられており、車両用データ論理チャネルの優先度は、他のデータを搬送する論理チャネルに関連付けられた優先度と異なる。任意選択的に、車両用データ論理チャネルのいくつかの優先度は、他のデータを搬送する論理チャネルの優先度より高い。任意選択的に、安全性メッセージを搬送する車両用データ論理チャネルの優先度のみが、他のデータを搬送する論理チャネルの優先度より高い。
【０２３５】
第１２の態様から第１４の態様の１つに加えられる第１５の態様によれば、受信部は、車両用移動端末において送信可能な車両用データの量、および車両用移動端末において送信可能な他のデータの量を個別に示すバッファ状況報告を受信する。任意選択的に、車両用データを搬送する車両用データ論理チャネルが、少なくとも１つの車両用データ論理チャネルグループに割り当てられ、バッファ状況報告は、車両用データ論理チャネルグループのすべての車両用データ論理チャネルから送信可能な車両用データの量を示す。任意選択的に、車両用データ論理チャネルの少なくとも１つの車両用データ論理チャネルグループへの割当ては、無線基地局によって制御される。
【０２３６】
第１２の態様から第１５の態様の１つに加えられる第１６の態様によれば、受信部は、無線リソースを要求する車両用データスケジューリング要求を車両用移動端末から受信する。車両用データスケジューリング要求は、要求された無線リソースが車両用データの送信のために使用されるものであること示す。任意選択的に、送信部は、車両用データの送信のために使用される無線リソースを示す第２のアップリンクグラントを、受信した車両用データスケジューリング要求に対して車両用移動端末に送信し、受信部は、第２のアップリンクグラントにおいて示された無線リソースを使用して車両用データを受信するように動作する。
【０２３７】
第１２の態様から第１６の態様の１つに加えられる第１７の態様によれば、車両用データおよび他のデータは、第１の無線インタフェースを介して無線基地局に、および／またはサイドリンク無線インタフェースを介して他の車両用エンティティに送信される。
【０２３８】
第１２の態様から第１７の態様の１つに加えられる第１８の態様によれば、車両用データトラフィックおよび対応するサービス品質要件をサポートすることができるコアネットワークエンティティに無線基地局が接続されていることを示す車両用データ適性インジケーションを送信部が送信する結果、車両用移動端末は、受信される車両用データ適性インジケーションの送信元である無線基地局を選択して該１つの無線基地局に所属することができる。任意選択的に、車両用データ適性インジケーションは、システム情報の一部として無線基地局によってブロードキャストされる。任意選択的に、車両用データ適性インジケーションは、車両用データトラフィックが車両用移動端末と無線基地局との間で第１の無線インタフェースを介して、および／または車両用移動端末と他の車両用エンティティとの間でサイドリンク無線インタフェースを介してサポートされているかをさらに示す。
【０２３９】
第１８の態様に加えられる第１９の態様によれば、受信部は、車両用移動端末が無線基地局に所属する際に車両用データを送信する予定であるインジケーションを受信する。任意選択的に、車両用データを送信する予定のインジケーションは、接続要求メッセージまたは接続再設定完了メッセージに含まれる。
【０２４０】
第２０の態様によれば、車両用移動端末が車両用データおよび他のデータを１基以上の受信エンティティに送信するための方法が提供される。本方法は、車両用移動端末が車両用データおよび／または他のデータの送信のために使用することができる無線リソースを示すアップリンクグラントを、車両用移動端末が所属しているセルを制御する無線基地局から受信するステップを含む。アップリンクグラントにおいて示された無線リソースを使用して車両用データおよび／または他のデータを送信するさらなるステップが含まれる。車両用移動端末は、車両用データおよび他のデータを互いに個別に処理する。
【０２４１】
［ハードウェアおよびソフトウェアによる本開示の実施］
他の例示的な実施形態は、上述したさまざまな実施形態を、ハードウェア、ソフトウェア、またはハードウェアと協働するソフトウェアを使用して実施することに関する。これに関連して、ユーザ機器（移動端末）およびｅＮｏｄｅＢ（基地局）を提供する。ユーザ端末は、本明細書に記載されている方法を実行するように適合されており、これらの方法に適切に関与する対応するエンティティ（受信機、送信機、プロセッサなど）を含む。
【０２４２】
さまざまな実施形態がコンピューティングデバイス（プロセッサ）を使用して実施または実行されうることがさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）、または、その他プログラマブルロジックデバイスなどである。さまざまな実施形態は、これらのデバイスの組合せによっても実行または具現化されうる。特に、上述の各実施形態の説明において使用される各機能ブロックは、集積回路としてのＬＳＩによって実施することができる。各機能ブロックを個々にチップとして形成してもよいし、１つのチップを、機能的ブロックの一部または全部を含むように形成してもよい。チップは、チップに結合されたデータ入力部およびデータ出力部を有しうる。本明細書においてＬＳＩを、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩということもできる。集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。また、ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。
【０２４３】
さらに、さまざまな実施形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行されるか、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭまたはＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納され得る。さらには、複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。
【０２４４】
具体的な実施形態に示した本開示には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更および／または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。
【図１】
2019517173.tif 000004
【図２】
2019517173.tif 000005
【図３】
2019517173.tif 000006
【図４】
2019517173.tif 000007
【図５】
2019517173.tif 000008
【図６】
2019517173.tif 000009
【図７】
2019517173.tif 000010
【図８】
2019517173.tif 000011
【図９】
2019517173.tif 000012
【図１０】
2019517173.tif 000013
【図１１】
2019517173.tif 000014
【国際調査報告】
2019517173.tif 000015
2019517173.tif 000016
2019517173.tif 000017
2019517173.tif 000018
2019517173.tif 000019