(57)【特許請求の範囲】
【請求項１】
端末装置から基地局へデータを無線リレーするリレー装置であって、
前記基地局からアップリンクリソースを要求するための第１のタイプのアクセス要求メッセージを、前記基地局から応答が受信されるまで、または最大パワーレベルに達するまで、連続的に高いパワーレベルで送信し、最大パワーレベルでの前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合、前記最大パワーレベルまたは前記最大パワーレベル以上のパワーで第２のタイプのアクセス要求メッセージを送信する前記端末装置から、アクセス要求メッセージを受信する受信機と、
前記端末装置から前記最大パワーレベルまたは前記最大パワーレベル以上のパワーで送信された前記第２のタイプのアクセス要求メッセージの検出に応答して、前記端末装置へのアップリンクリソースの割当てを前記基地局に要求するためにリレーアクセス要求メッセージを前記基地局に送信する送信機と、
を備え、
前記基地局は、前記端末装置からの前記第１のタイプのアクセス要求メッセージまたは前記リレー装置からの前記リレーアクセス要求メッセージに応答して前記端末装置にアップリンクリソースの割当てを送信する、リレー装置。
【請求項２】
前記端末装置は、前記割当てアップリンクリソースでアップリンクデータを前記リレー装置に送信し、
前記リレー装置は、前記端末装置から受信した前記アップリンクデータを前記基地局にリレーする、請求項１に記載のリレー装置。
【請求項３】
前記リレー装置は、前記第２のタイプのアクセス要求メッセージの送信元の前記端末装置の識別子を判断し、前記基地局に送信される前記リレーアクセス要求メッセージに前記識別子を含め、
前記基地局は前記識別子を前記端末装置へのアップリンクリソースの割当てを送信するために利用する、請求項１または２に記載のリレー装置。
【請求項４】
前記アクセス要求メッセージはランダムアクセスチャネルで送信され、
前記リレー装置は、前記第２のタイプの前記アクセス要求メッセージの送信に利用されたランダムアクセスチャネル内での時間および／または周波数リソースから前記端末装置の識別子を判断する、請求項３に記載のリレー装置。
【請求項５】
前記リレー装置は、
前記端末装置から受信された前記第２のタイプの前記アクセス要求メッセージの受信信号パワーを測定し、
前記割当てアップリンクリソースでの前記端末装置から前記リレー装置への後続の送信のパワーレベルを制御するために前記リレーアクセス要求メッセージにおけるパワー制御情報を設定する、請求項１〜４のいずれか一項に記載のリレー装置。
【請求項６】
前記パワー制御情報は前記第２のタイプの前記アクセス要求メッセージの前記受信信号パワーからのパワーオフセットを特定する、請求項５に記載のリレー装置。
【請求項７】
前記基地局から前記端末装置に送信されるアップリンクリソースの前記割当ては、前記端末装置から前記リレー装置への後続の送信の送信パワーを制御するためのパワー制御情報を含む、請求項５または６に記載のリレー装置。
【請求項８】
前記リレー装置は、
前記第２のタイプの前記アクセス要求メッセージの前記端末装置および前記リレー装置間での伝播時間遅延を測定し、
前記伝播時間遅延に基づき、前記リレー装置での後続の送信の受信時間が他の端末装置からの送信の受信時間と同期するように、前記端末装置から前記リレー装置への後続の送信に求められるタイミングアドバンスオフセットを判断し、
前記リレーアクセス要求メッセージにおいて前記タイミングアドバンスオフセットを特定する、請求項１〜７のいずれか一項に記載のリレー装置。
【請求項９】
前記基地局から前記端末装置に送信されるアップリンクリソースの前記割当ては、前記端末装置から前記リレー装置への後続の送信のタイミングを制御するための前記タイミングアドバンスオフセットを含む、請求項８に記載のリレー装置。
【請求項１０】
前記リレーアクセス要求メッセージは、前記アクセス要求メッセージを送信した前記端末装置の識別子を含む、請求項１〜９のいずれか一項に記載のリレー装置。
【請求項１１】
前記リレー装置は、前記端末装置から受信された前記第２のタイプの前記アクセス要求メッセージに応答して、前記リレーアクセス要求メッセージを送信するためにアップリンクリソースを前記リレー装置に割当てることを前記基地局に要求し、
前記基地局は前記基地局からの要求に応答して前記リレー装置にアップリンクリソースを割当て、
前記リレー装置は、前記基地局によって前記リレー装置に割り当てられたアップリンクリソースを利用して前記リレーアクセス要求メッセージを前記基地局に送信する、請求項１〜１０のいずれか一項に記載のリレー装置。
【請求項１２】
前記第１のタイプの前記アクセス要求メッセージは、第１のランダムアクセスチャネルプリアンブルから選択されたランダムアクセスチャネルプリアンブルであり、
前記第２のタイプの前記アクセス要求メッセージは、第２のランダムアクセスチャネルプリアンブルから選択されたランダムアクセスチャネルプリアンブルであり、
前記基地局から前記端末装置へ送信されるアップリンクリソースの前記割当てはランダムアクセスレスポンスであり、
前記端末装置によって前記割当てられたアップリンクリソースで送信される前記アップリンクデータはメッセージ３である、請求項２に記載のリレー装置。
【請求項１３】
前記アップリンクデータは、制御情報およびデータの一方または双方を含む、請求項２に記載のリレー装置。
【請求項１４】
前記リレー装置は、
前記端末装置から受信した前記アップリンクデータの受信信号パワーを測定し、
前記端末装置から前記リレー装置への後続の送信のパワーレベルを制御するためにリレーアップリンクデータにおいてパワー制御情報を設定する、請求項２に記載のリレー装置。
【請求項１５】
前記リレー装置は、
前記アップリンクデータの前記端末装置および前記リレー装置間の伝播遅延時間を測定し、
前記伝播遅延時間に基づき、前記リレー装置での後続の送信の受信時間が他の端末装置からの送信の受信時間と同期するように、前記端末装置から前記リレー装置への後続の送信に求められるタイミングアドバンスオフセットを判断し、
リレーアップリンクデータにおいて前記タイミングアドバンスオフセットを特定する、請求項２に記載のリレー装置。
【請求項１６】
リレーアップリンクデータは、前記アップリンクデータを送信した前記端末装置の識別子を含む、請求項２に記載のリレー装置。
【請求項１７】
前記リレー装置は、前記端末装置から受信したアップリンクデータに応答して、リレーアップリンクデータを送信するために前記リレー装置にアップリンクデータを割当てることを前記基地局に要求し、
前記基地局は前記基地局からの要求に応答して前記リレー装置にアップリンクリソースを割当て、
前記リレー装置は、前記基地局によって前記リレー装置に割り当てられたアップリンクリソースを利用して前記リレーアップリンクデータを前記基地局に送信する、請求項１〜１６のいずれか一項に記載のリレー装置。
【請求項１８】
リレー装置を経由して基地局へデータを無線送信する端末装置であって、
前記基地局からアップリンクリソースを要求するための第１のタイプのアクセス要求メッセージを、前記基地局から応答が受信されるまで、または最大パワーレベルに達するまで、連続的に高いパワーレベルで送信し、最大パワーレベルでの前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合、前記最大パワーレベルまたは前記最大パワーレベル以上のパワーで第２のタイプのアクセス要求メッセージを送信する送信機と、
前記基地局で、第１のタイプのアクセス要求メッセージ、または端末装置から受信された第２のタイプのアクセス要求メッセージに応答して前記リレー装置によって前記基地局に送信されたリレーアクセス要求メッセージ、の受信に応答して割り当てられたアップリンクリソースの割当てを前記基地局から受信し、前記リレーアクセス要求メッセージは前記基地局にアップリンクリソースの前記端末装置への割当てを要求する、受信機と、
を備える、端末装置。
【請求項１９】
前記端末装置は、前記割当てアップリンクリソースでアップリンクデータを前記リレー装置に送信し、
前記リレー装置は、前記端末装置から受信した前記アップリンクデータを前記基地局にリレーする、請求項１８に記載の端末装置。
【請求項２０】
前記第２のタイプのアクセス要求メッセージは最大パワーレベルで送信される、請求項１９に記載の端末装置。
【請求項２１】
前記第１のタイプのアクセス要求メッセージを送信するための最大パワーレベルは、前記端末装置の最大送信パワーよりも低い、請求項１９に記載の端末装置。
【請求項２２】
前記第１のタイプの前記アクセス要求メッセージは、第１のランダムアクセスチャネルプリアンブルから選択されたランダムアクセスチャネルプリアンブルであり、
前記第２のタイプの前記アクセス要求メッセージは、第２のランダムアクセスチャネルプリアンブルから選択されたランダムアクセスチャネルプリアンブルであり、
前記基地局から前記端末装置へ送信されるアップリンクリソースの前記割当てはランダムアクセスレスポンスであり、
前記端末装置によって前記割当てられたアップリンクリソースで送信されるアップリンクデータはメッセージ３である、請求項１８に記載の端末装置。
【請求項２３】
前記アップリンクデータは、制御情報およびデータの一方または双方を含む、請求項１９に記載の端末装置。
【請求項２４】
前記基地局から前記端末装置へ送信され、受信されたアップリンクリソースの前記割当ては、前記リレー装置で受信された前記第２のタイプの前記アクセス要求メッセージの受信信号パワーから判断されたパワー制御情報を含み、
前記端末装置は、前記パワー制御情報で特定されたパワーレベルで前記アップリンクデータを送信する、請求項１９に記載の端末装置。
【請求項２５】
前記パワー制御情報は、前記リレー装置で受信された前記第２のタイプの前記アクセス要求メッセージの前記受信信号パワーからのパワーオフセットを特定する、請求項２４に記載の端末装置。
【請求項２６】
前記基地局から前記端末装置へ送信され、受信されたアップリンクリソースの前記割当ては、送信の前記リレー装置での受信時間が他の端末装置からの送信の受信時間と同期するように、前記端末装置から前記リレー装置への送信に求められるタイミングアドバンスオフセットを含み、前記タイミングアドバンスオフセットは、前記第２のタイプの前記アクセス要求メッセージの前記端末装置および前記リレー装置間の伝播遅延時間に基づいて判断される、請求項１８に記載の端末装置。
【請求項２７】
端末装置から基地局へデータを無線リレーする方法であって、
前記基地局からアップリンクリソースを要求するための第１のタイプのアクセス要求メッセージを、前記基地局から応答が受信されるまで、または最大パワーレベルに達するまで、連続的に高いパワーレベルで送信し、最大パワーレベルでの前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合、前記最大パワーレベルまたは前記最大パワーレベル以上のパワーで第２のタイプのアクセス要求メッセージを送信する前記端末装置からの前記第２のタイプのアクセス要求メッセージに応答して、前記端末装置へのアップリンクリソースの割当てを前記基地局に要求するためにリレーアクセス要求メッセージをリレー装置が前記基地局に送信することと、
前記基地局は、前記端末装置からの前記第１のタイプのアクセス要求メッセージまたは前記リレー装置からの前記リレーアクセス要求メッセージに応答して前記端末装置にアップリンクリソースの割当てを送信することと、
を含む、方法。
【請求項２８】
リレー装置を経由して基地局へデータを無線送信する方法であって、
前記基地局からアップリンクリソースを要求するための第１のタイプのアクセス要求メッセージを、前記基地局から応答が受信されるまで、または最大パワーレベルに達するまで、連続的に高いパワーレベルで端末装置が送信することと、
最大パワーレベルでの前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合、前記最大パワーレベルまたは前記最大パワーレベル以上のパワーで第２のタイプのアクセス要求メッセージを端末装置が送信することと、
前記基地局で、第１のタイプのアクセス要求メッセージ、または端末装置から受信された第２のタイプのアクセス要求メッセージに応答して前記リレー装置によって前記基地局に送信されたリレーアクセス要求メッセージ、の受信に応答して割り当てられたアップリンクリソースの割当てを前記基地局から前記端末装置が受信し、前記リレーアクセス要求メッセージは前記基地局にアップリンクリソースの前記端末装置への割当てを要求することと、
を含む、方法。
【請求項２９】
コンピュータで実行された場合にコンピュータに請求項２７または２８による方法を行わせる、コンピュータプログラム。
【請求項３０】
請求項２９の前記コンピュータプログラムを記憶する、記憶媒体。
【請求項３１】
端末装置から基地局へデータを無線リレーする装置であって、
前記基地局からアップリンクリソースを要求するための第１のタイプのアクセス要求メッセージを、前記基地局から応答が受信されるまで、または最大パワーレベルに達するまで、連続的に高いパワーレベルで送信し、最大パワーレベルでの前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合、前記最大パワーレベルまたは前記最大パワーレベル以上のパワーで第２のタイプのアクセス要求メッセージを送信する前記端末装置から受信された前記第２のタイプのアクセス要求メッセージの検出に応答して、前記端末装置へのアップリンクリソースの割当てを前記基地局に要求するためにリレーアクセス要求メッセージを前記基地局に送信する手段と、
前記端末装置から前記第１のタイプのアクセス要求メッセージまたは前記リレーアクセス要求メッセージを受信した前記基地局からの受信に応答して前記端末装置にアップリンクリソースの割当てを送信する手段と、
を備える、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信のためのリレー装置およびリレー方法に関する。本発明のさらなる観点は、基地局、端末装置およびコンピュータプログラムに関する。
【背景技術】
【０００２】
ＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）は、人間のインタラクションを典型的に必要としない通信ネットワークアプリケーションの無線技術の新たなトレンドとして種々の無線通信標準化団体において議論されている。
【０００３】
ＭＴＣの広い定義は、マシンへの及びマシンからの自動通信ネットワークである。１つの主要なカテゴリのＭＴＣデバイスは、非常に低い電力消費、非常に小さいデータの送信及び非常に多数の端末という特徴を有することが期待される。このカテゴリに収まる例示的なＭＴＣアプリケーションは、例えば、スマートグリッドシステムについての家庭用電化製品のエネルギー消費モニタリングであり得る。
【０００４】
アップリンクのみのリレーは、例えばマクロセルラーＬＴＥ（Ｌｏｎｇ−Ｔｅｒｍ−Ｅｖｏｌｕｔｉｏｎ）ネットワークにおいて展開された場合に、低コストなＭＴＣ装置での送信電力制約の問題を解決するために利用され得るネットワークトポロジである。一般的に、ｅＮｏｄｅＢ（ｅＮＢ）のマクロセルのセルエッジでＭＴＣ装置（またはユーザ端末ＵＥ）（ＭＴＣ−ＵＥ）をサポートするための十分なダウンリンク（基地局から端末装置）のシステムゲインが存在するが、ＭＴＣ装置の低出力パワーにより、アップリンク（端末装置から基地局）システムゲインはダウンリンクと比較して著しく減少する。シングルホップアップリンクのみのリレーノード（ＭＴＣ−ＲＮ）の利用は、この問題を解決するため、およびＭＴＣ−ＵＥのためのリンク予算をまとめるために用いられ得る。ＭＴＣ−ＲＮがＬＴＥＵＥと類似の特性を有することが期待されるならばシングルホップが想定される。リレーノード（ここではリレー装置とも称する）が端末装置からｅＮｏｄｅＢへアップリンクデータをリレーするために用いられるネットワークにおいては、ｅＮｏｄｅＢはドナー（ｄｏｎｏｒ）ｅＮｏｄｅＢとも称され得る。
【０００５】
アップリンクのみのシングルホップリレーはＵＳ２００８／０２８５４９９に記載されている。
【発明の概要】
【０００６】
本発明のある観点によれば、
基地局、
リレー装置および
端末装置を備え、
前記端末装置は、
前記端末装置は、前記基地局からアップリンクリソースを要求するための１または２以上の第１のタイプのアクセス要求メッセージを送信し、
送信された前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合に第２のタイプのアクセス要求メッセージを送信し、
前記基地局は、前記端末装置から受信された前記第１のタイプのアクセス要求メッセージに応答して、前記端末装置にアップリンクリソースの割当てを送信し、
前記リレー装置は、前記端末装置から受信された第２のタイプのアクセス要求メッセージに応答して、前記端末装置へのアップリンクリソースの割当てを前記基地局に要求するためにリレーアクセス要求メッセージを前記基地局に送信し、
前記基地局は、前記リレー装置から受信された前記リレーアクセス要求メッセージに応答して、前記端末装置にアップリンクリソースの割当てを送信する、無線通信システムが提供される。
アップリンクのみのリレーのためのこの修正されたランダムアクセス手順は、リレー装置に、基地局によって直接扱われ得ない端末装置を容易に識別することを可能とする（それらは、すでに前記第１のタイプのアクセス要求メッセージを経由して前記基地局に達することを試み、失敗しているからである。）。アップリンクのみのリレーネットワークは、アクセス要求メッセージ（例えば、ＵＥＲＡＣＨプリアンブルの試み）が前記基地局によって受信されることは保証されず、アップリンクのみのリレー装置の支援を必要とする。換言すれば、このメカニズムは、端末装置が必要とする場合にのみ端末装置がリレー装置に接続することを可能とし、端末装置がｅＮｏｄｅＢに直接接続できる場合には端末装置はそのようにする。
【０００７】
ある実施形態によれば、前記端末装置は、前記割当てアップリンクリソースでアップリンクデータを前記リレー装置に送信し、前記リレー装置は、前記端末装置から受信した前記アップリンクデータを前記基地局にリレーする。
【０００８】
ある実施形態によれば、前記第１のタイプのアクセス要求メッセージを、前記基地局から応答が受信されるまで、または最大パワーレベルに達するまで、連続的に高いパワーレベルで送信し、最大パワーレベルでの前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合、第２のタイプのアクセス要求メッセージを送信する。この方法では、第１のタイプの複数の連続するアクセス要求メッセージの送信に利用されるパワーランピング処理が失敗した場合にのみリレー装置が利用される。第２のタイプのアクセス要求メッセージは、第１のタイプの最後のアクセス要求メッセージを送信するために用いられたのと同一の最大パワーレベルで送信され得る。利用されるパワーランピングプロフィールは、第１のタイプのアクセス要求メッセージの送信に利用されたものと同一または異なってもよい。
【０００９】
前記第１のタイプのアクセス要求メッセージを送信するための最大パワーレベルは、前記端末装置の最大送信パワーよりも低い。これは、アップリンクシグナルが知らん位できなそうな場合に基地局と端末との間の直接無線接続が利用されることを回避するだろう。
【００１０】
ある実施形態では、前記リレー装置は、前記第２のタイプのアクセス要求メッセージの送信元の前記端末装置の識別子を判断し、前記基地局に送信される前記リレーアクセス要求メッセージに前記識別子を含める。前記基地局は前記識別子を前記端末装置へのアップリンクリソースの割当てを送信するために利用する。前記アクセス要求メッセージはランダムアクセスチャネルで送信され、前記リレー装置は、前記第２のタイプの前記アクセス要求メッセージの送信に利用されたランダムアクセスチャネル内での時間および／または周波数リソースから前記端末装置の識別子を判断してもよい。
【００１１】
ある実施形態では、前記リレー装置は、前記端末装置から受信された前記第２のタイプの前記アクセス要求メッセージの受信信号パワーを測定し、前記割当てアップリンクリソースでの前記端末装置から前記リレー装置への後続の送信のパワーレベルを制御するために前記リレーアクセス要求メッセージにおけるパワー制御情報を設定する。前記パワー制御情報は前記第２のタイプの前記アクセス要求メッセージの前記受信信号パワーからのパワーオフセットを特定してもよい。前記基地局から前記端末装置に送信されるアップリンクリソースの前記割当ては、前記端末装置から前記リレー装置への後続の送信の送信パワーを制御するためのパワー制御情報を含んでもよい。
【００１２】
ある実施形態では、
前記リレー装置は、
前記第２のタイプの前記アクセス要求メッセージの前記端末装置および前記リレー装置間での伝播時間遅延を測定し、
前記伝播時間遅延に基づき、前記リレー装置での後続の送信の受信時間が他の端末装置からの送信の受信時間と同期するように、前記端末装置から前記リレー装置への後続の送信に求められるタイミングアドバンスオフセットを判断し、
前記リレーアクセス要求メッセージにおいて前記タイミングアドバンスオフセットを特定する。
【００１３】
前記基地局から前記端末装置に送信されるアップリンクリソースの前記割当ては、前記端末装置から前記リレー装置への後続の送信のタイミングを制御するための前記タイミングアドバンスオフセットを含んでもよい。
【００１４】
前記リレーアクセス要求メッセージは、前記メッセージを送信した前記端末装置の識別子を含んでもよい。
【００１５】
ある実施形態では、
前記リレー装置は、前記端末装置から受信された前記第２のタイプの前記アクセス要求メッセージに応答して、前記リレーアクセス要求メッセージを送信するためにアップリンクリソースを前記リレー装置に割当てることを前記基地局に要求し、
前記基地局は前記基地局からの要求に応答して前記リレー装置にアップリンクリソースを割当て、
前記リレー装置は、前記基地局によって前記リレー装置に割り当てられたアップリンクリソースを利用して前記リレーアクセス要求メッセージを前記基地局に送信する。
【００１６】
前記第１のタイプの前記アクセス要求メッセージは、第１のランダムアクセスチャネルプリアンブルから選択されたランダムアクセスチャネルプリアンブルであってもよい。前記第２のタイプの前記アクセス要求メッセージは、第２のランダムアクセスチャネルプリアンブルから選択されたランダムアクセスチャネルプリアンブルであってもよい。前記基地局から前記端末装置へ送信されるアップリンクリソースの前記割当てはランダムアクセスレスポンスであってもよい。前記端末装置によって前記割当てられたアップリンクリソースで送信される前記アップリンクデータはメッセージ３であってもよい。
【００１７】
前記アップリンクデータは、制御情報およびデータの一方または双方を含んでもよいことに理解されたい。
【００１８】
前記リレー装置は、
前記端末装置から受信した前記アップリンクデータの受信信号パワーを測定し、
前記端末装置から前記リレー装置への後続の送信のパワーレベルを制御するためにリレーアップリンクデータにおいてパワー制御情報を設定してもよい。
【００１９】
前記リレー装置は、
前記アップリンクデータの前記端末装置および前記リレー装置間の伝播遅延時間を測定し、
前記伝播遅延時間に基づき、前記リレー装置での後続の送信の受信時間が他の端末装置からの送信の受信時間と同期するように、前記端末装置から前記リレー装置への後続の送信に求められるタイミングアドバンスオフセットを判断し、
前記リレーアップリンクデータにおいて前記タイミングアドバンスオフセットを特定してもよい。
【００２０】
前記リレーアップリンクデータは、前記アップリンクデータを送信した前記端末装置の識別子を含んでもよい。
【００２１】
前記リレー装置は、前記端末装置から受信した前記アップリンクデータに応答して、前記リレーアップリンクデータを送信するために前記リレー装置にアップリンクデータを割当てることを前記基地局に要求してもよい。前記基地局は前記基地局からの要求に応答して前記リレー装置にアップリンクリソースを割当ててもよい。前記リレー装置は、前記基地局によって前記リレー装置に割り当てられたアップリンクリソースを利用して前記リレーアップリンクデータを前記基地局に送信してもよい。
【００２２】
前記基地局は、前記第２のタイプの同一のアクセス要求メッセージに関して複数のリレー装置から受信されたリレーアクセス要求メッセージに応答して、
前記端末装置を扱うべきいずれかのリレー装置を選択し、
選択された前記リレー装置に前記端末装置についてのリレー装置として扱うことを通知する。
【００２３】
前記リレーアクセス要求メッセージは、前記第２のタイプの前記アクセス要求メッセージの受信パワーレベルのインジケーションを含んでもよく、
前記基地局は、最も高いパワーレベルで前記第２のタイプの前記アクセス要求メッセージを受信したリレー装置を前記サービングリレー装置として選択してもよい。
【００２４】
２または３以上の複数のリレー装置が実質的に同一なパワーレベルで前記第２のタイプのアクセス要求メッセージを受信した場合、前記基地局は、実質的に同一のパワーレベルで前記第２のタイプの前記アクセス要求メッセージを受信したリレー装置のうちで、現在最も少ない端末装置を扱っているリレー装置を前記サービングリレー装置として選択してもよい。
【００２５】
前記基地局は、前記端末装置を扱うために選択されなかった複数のリレー装置にＮＡＣＫメッセージを送信してもよい。
【００２６】
前記ＮＡＣＫメッセージは、前記複数のリレー装置の全てにグループ識別子を用いて送信されてもよい。この場合、前記サービングリレー装置として選択された前記リレー装置は、前記サービングリレー装置になることを前記基地局によって通知されたことに応じて、前記ＮＡＣＫメッセージを無視する。
【００２７】
本発明の他の観点によれば、リレー装置を経由して基地局へデータを無線送信する方法であって、
前記基地局からアップリンクリソースを要求するための１または２以上の第１のタイプのアクセス要求メッセージを送信することと、
送信された前記第１のタイプのアクセス要求メッセージに対する応答が前記端末装置で前記基地局から受信されなかった場合、第２のタイプのアクセス要求メッセージを前記端末装置から前記基地局に送信することと、
前記基地局で前記端末装置から受信した第１のタイプのアクセス要求メッセージに応答して、前記基地局から前記端末装置にアップリンクリソースの割当てを送信し、
前記リレー装置で前記端末装置から受信した前記第２のタイプのアクセス要求メッセージに応答して、前記端末装置へのアップリンクリソースの割当てを前記基地局に要求するリレーアクセス要求メッセージを前記リレー装置から前記基地局に送信し、
前記基地局で前記リレー装置から受信された前記リレーアクセス要求メッセージに応答して、前記端末装置へアップリンクリソースの割当てを前記基地局から送信する、方法が提供される。
【００２８】
本発明の他の観点によれば、端末装置からリレー装置を経由して無線送信を受信する基地局であって、
受信機と、
前記受信機で前記端末装置から受信された第１のタイプのアクセス要求メッセージに応答して、前記端末装置にアップリンクリソースの割当てを送信し、
前記受信機で前記リレー装置から受信した、前記端末装置にアップリンクリソースを割当てることを前記基地局に要求するリレーアクセス要求メッセージに応答して、端末装置にアップリンクリソースの割当てを送信し、前記リレーアクセス要求メッセージは、前記リレー装置から前記基地局に、前記リレー装置で受信された前記第２のタイプのアクセス要求メッセージに応答して送信され、
前記第２のタイプのアクセス要求メッセージは、前記基地局から前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合に前記端末装置から送信される、基地局が提供される。
【００２９】
本発明の他の観点によれば、端末装置から基地局へデータを無線リレーするリレー装置であって、
受信機と、
前記端末装置から前記受信機で受信された第２のタイプのアクセス要求メッセージに応答して、前記端末装置へのアップリンクリソースの割当てを前記基地局に要求するためにリレーアクセス要求メッセージを前記基地局に送信する送信機と、
を備え、
前記第２のタイプのアクセス要求メッセージは、送信された第１のタイプのアクセス要求メッセージに対する前記基地局からの応答が無かった場合に前記端末装置から送信され、
前記基地局は、前記端末装置からの前記第１のタイプのアクセス要求メッセージまたは前記リレー装置からの前記リレーアクセス要求メッセージに応答して前記端末装置にアップリンクリソースの割当てを送信する、リレー装置が提供される。
【００３０】
本発明の他の観点によれば、リレー装置を経由して基地局へデータを無線送信する端末装置であって、
前記基地局からアップリンクリソースを要求するための１または２以上の第１のタイプのアクセス要求メッセージを送信し、
送信された前記第１のタイプのアクセス要求メッセージに対する応答が無かった場合に第２のタイプのアクセス要求メッセージを送信する送信機と、
前記基地局で、第１のタイプのアクセス要求メッセージ、または端末装置から受信された第２のタイプのアクセス要求メッセージに応答して前記リレー装置によって前記基地局に送信されたリレーアクセス要求メッセージ、の受信に応答して割り当てられたアップリンクリソースの割当てを前記基地局から受信し、前記リレーアクセス要求メッセージは前記基地局にアップリンクリソースの前記端末装置への割当てを要求する、受信機と、
を備える、端末装置が提供される。
【００３１】
本発明のさらなる観点および特徴は添付の特許請求の範囲において定義される。
【図面の簡単な説明】
【００３２】
ここで、本発明の例示的な実施形態は、同様の部分が同じ参照符号を有する添付の図面を参照しつつ、説明されるであろう。図面において：
【図１】図１Ａおよび図１Ｂは、リレーネットワークについての対称的なアップリンク／ダウンリンクマルチホップシグナリングシナリオと非対称的なアップリンク／ダウンリンクシグナリングシナリオとの間の比較を提供する。
【図２】図２は、３ＧＰＰロングタームエボリューション（ＬＴＥ）標準に従って動作する通信システムを形成するモバイル通信ネットワーク及びモバイル通信装置の概略ブロック図である。
【図３】図３は、図２に示したネットワークにおいて利用されるダウンリンクデータ及び制御チャネル構造を概略的に図示する。
【図４】図４は、図２に示したネットワークにおいて利用されるアップリンクデータ及び制御チャネル構造を概略的に図示する。
【図５】図５は、ネットワークに接続するための移動端末のランダムアクセス手順を概略的に図示する。
【図６】図６は、ＵＥＰＲＡＣＨパワーランピングおよびリレー装置でのランダムアクセスプリアンブルの傍受を概略的に図示する。
【図７】図７は、端末装置をリレーが扱うトリガにランダムアクセス手順を利用する技術を概略的に図示する。
【図８】図８は、ランダムアクセス要求を基地局へリレーするための新たなＭＡＣ制御エレメントを概略的に図示する。
【図９】図９は、修正されたＲＡＲを概略的に図示する。
【図１０】図１０は、複数の可能性のあるサービングリレー間での調停方法を概略的に図示する。
【図１１】端末装置を扱うのに最適なリレー装置を判断するための方法を概略的に図示する。
【図１２】図１２は、いずれのリレー装置が端末装置を扱うかを示すＭＡＣ制御エレメントを概略的に図示する。
【図１３】図１３は、ダウンリンク信号についての端末装置、リレー装置および基地局のプロトコルスタック構造および信号フローを概略的に図示する。
【図１４】図１４は、アップリンク信号についての端末装置、リレー装置および基地局のプロトコルスタック構造および信号フローを概略的に図示する。
【図１５】図１５は、リレー装置でのＭＡＣメッセージのカプセル化およびリレーを概略的に図示する。
【図１６】図１６は、ＭＡＣリレーヘッダ制御エレメントの形態例を概略的に図示する。
【図１７】図１７は、全ての示されるＭＴＣ−ＵＥＭＡＣＰＤＵが存在するＭＡＣリレーＰＤＵの例を概略的に図示する。
【図１８】図１８は、いくつかの示されるＭＴＣ−ＵＥＭＡＣＰＤＵが存在しないＭＡＣリレーＰＤＵの例を概略的に図示する。
【図１９】図１９は、アップリンク通信についてリレー装置を経由して端末装置と基地局の間で通信する手順例を概略的に図示する。
【図２０】図２０は、端末装置からのメッセージを受信するため、および受信したメッセージを基地局にリレーするために利用するアップリンクリソースをリレー装置が把握するための第１の技術を概略的に図示する。
【図２１】図２１は、端末装置からメッセージが受信されなかった場合に第１の技術においてリレー装置がどのように振る舞うかを概略的に図示する。
【図２２】図２２は、端末装置からのメッセージを受信するため、および受信したメッセージを基地局にリレーするために利用するアップリンクリソースをリレー装置が把握するための第２の技術を概略的に図示する。
【図２３】図２３は、端末装置からのメッセージを受信するため、および受信したメッセージを基地局にリレーするために利用するアップリンクリソースをリレー装置が把握するための第３の技術を概略的に図示する。
【図２４】図２４は、端末装置からのメッセージを受信するため、および受信したメッセージを基地局にリレーするために利用するアップリンクリソースをリレー装置が把握するための第４の技術を概略的に図示する。
【図２５】図２５は、ＳＲの実施例を概略的に図示する。
【図２６】図２６は、ＭＴＣ−ＵＥからの送信が予想されるアップリンクリソースをＭＴＣ−ＲＮに示すための新たなＭＡＣ制御エレメントの実施例を概略的に図示する。
【図２７】図２７は、ＤｅＮＢ、ＭＴＣ−ＲＮおよびＭＴＣ−ＵＥを備える無線通信システムを概略的に図示する。
【発明を実施するための形態】
【００３３】
本発明は、２０１１年８月１９日に出願されたＵＫ特許出願ＧＢ１１１４３４２．７、および２０１１年８月１９日出願されたＵＫ特許出願ＧＢ１１１４３４５．０のパリ条約による優先権の主張の利益を享受し、これらの内容は参照されることにより本書に組み込まれる。
【００３４】
まず、図１Ａ〜図１Ｂを参照すると、これらは、リレーネットワークが適用された場合の対称的なアップリンク／ダウンリンクシングルホップシグナリングシナリオと非対称的なアップリンク／ダウンリンクシグナリングシナリオとの間の比較が提供される。図１Ａは、基地局７ａからリレー装置８ａを経由したいくつかの端末装置９ａまでのダウンリンク１０ａと、端末装置９ａからリレー装置８ａを経由した基地局７ａまでのアップリンク１１ａと、の双方上で通信がホップされる対称的なアップリンク／ダウンリンクの場合を図示する。図１Ｂは、通信が、基地局７ｂから端末装置９ｂまでのダウンリンク１０ｂ上では直接行われるが、端末装置９ｂからリレー装置８ｂを経由する基地局７ｂまでのアップリンク６ｂ上ではホップされる非対称的なアップリンク／ダウンリンクの場合を図示する。基地局７ｂは、リレー装置８ｂの動作を制御するためにダウンリンク１２ｂ（図１Ｂの破線）でリレー装置８ｂに制御シグナリングも送信し得る。しかし、リレー装置８ｂから端末装置９ｂへの送信は特に存在しない。図１Ｂの非対称的なアップリンク／ダウンリンクリレー構造は多くの利益を得ることを理解されたい。第１に、ホッピングは、より低い電力送信が用いられることを可能にするが、送信時間を増加させることが理解される。制御信号及びデータ信号の双方のホッピングは、ルート内の各中継ステップにおける受信／再送信についての処理遅延に起因して、伝達のために比較的長い時間を要する。対照的に、基地局（ＢＳ）から端末へ送信される制御信号に関して、制御信号を直接送信することによって、送信時間が低減される。一見したところ、これはリレータイプのネットワークの低送信電力の目標に反するが、実際には、基地局は、ネットワーク内の端末装置及びリレー装置と同じ送信電力の制約を受けないであろう。さらに、この構成は、ＭＴＣデバイスについて特に有利である。その理由は、このタイプのデバイスについて典型的に利用される、データシグナリングに対する制御シグナリングの相対的に多い量である。
【００３５】
ここで、３ＧＰＰロングタームエボリューション（ＬＴＥ）標準に従って動作するモバイル通信ネットワークを用いる実装を参照しつつ、本発明のある実施形態が説明されるであろう。図２は、３ＧＰＰロングタームエボリューション（ＬＴＥ）標準（規格書のリリース８）に従って動作する通信システムを形成するモバイル通信ネットワーク及びモバイル通信装置の概略ブロック図である。モバイルネットワークは、当技術分野においてエンハンストノードＢ１０１（ｅＮＢ）として知られる複数の基地局を含み、当該基地局の各々は、複数のモバイル通信装置１０５へ及び複数のモバイル通信装置１０５から無線インタフェースを経由してデータを通信することを可能にする送受信器ユニット１０３を備える。各モバイル通信装置１０５は、ｅＮＢへ及びｅＮＢからデータを通信するための送受信器と、当該モバイル通信装置を一意に識別するＵＳＩＭと、を備える。
【００３６】
各ｅＮｏｄｅＢ１０１は、カバレッジエリア（即ち、セル）を提供し、及び当該カバレッジエリア／セル内のモバイル通信装置１０２へ及びモバイル通信デバイスからデータを通信する。各ｅＮＢ１０１は、サービングゲートウェイ（Ｓ−ＧＷ）１０４へ接続され、当該Ｓ−ＧＷ１０４は、ｅＮＢ１０１へ及びｅＮＢ１０１からユーザデータをルーティングし、及び、当技術分野において既知であるように、モバイル通信装置１０５がｅＮＢ１０１間でハンドオーバする際にモビリティをサポートする。
【００３７】
モバイルネットワークは、典型的に、複数のトラッキングエリアに分けられ、当該トラッキングエリアの各々は、複数のｅＮＢを含む。複数のトラッキングエリアは共に、地理的なエリアにわたる公衆地上移動ネットワーク（ＰＬＭＮ：Public  Land  Mobile  Network）へのアクセスを提供するネットワークカバレッジエリアを形成する。Ｓ−ＧＷ１０４は、パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）１０６へ接続され、当該Ｐ−ＧＷ１０６は、パケットデータがネットワーク内へ及びネットワーク外へルーティングされるネットワークエンティティである。モバイル通信ネットワークは、Ｓ−ＧＷ１０４に接続されるモビリティマネジメントエンティティ（ＭＭＥ）１０７も含む。ＭＭＥ１０７は、ネットワークへのアクセスを試行するモバイル通信デバイス１０５を、ホーム加入者サーバ（ＨＳＳ：Home  Subscriber  Server）１０８に記憶される加入者プロファイル情報を取得することによって認証することに関与する。ＭＭＥ１０７は、ネットワークへ加わった各モバイル通信デバイス１０５のロケーションもトラッキングする。グループ化された複数のｅＮＢは、ＰＬＭＮの無線ネットワーク部分及びＰＬＭＮのインフラストラクチャ機器を形成する。即ち、Ｓ−ＧＷ、ＭＭＥ及びＰ−ＧＷは、ＰＬＭＮのコアネットワーク部分を形成する。
【００３８】
図３は、図２のＬＴＥベースのネットワークにおけるｅＮＢ１０１および通信装置１０５の間のエア（Ｕｕ）インタフェースの使用のための例示的なダウンリンクデータ及び制御チャネル構造を概略的に図示する。ＬＴＥ標準によれば、物理ダウンリンクフレームが用いられて、ダウンリンク（基地局から端末デバイス）上で制御シグナリング及びデータが通信される。図３は、当該フレームの幾らか簡略化された形態である。例えば、ＬＴＥフレームは、通常、１０個のサブフレームを含むが、６個のサブフレーム１３０のみが図３のダウンリンクフレーム１２０について表されている。図３中のＬＴＥフレーム１２０の図の下は、サブフレーム１３０のうちの１つの拡大されたバージョンである。各サブフレーム１３０において、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）１４０が示され、当該ＰＤＣＣＨ１４０は、（縦方向の）周波数帯域全体にわたって及び（水平方向の）時間軸における１〜３つのシンボルにわたって広がる時間リソース及び周波数リソースを占める。対照的に、物理ダウンリンク共有チャネル（ＰＤＳＣＨ：Physical  Down-link  Shared  CHannel）１５０は、ＰＤＣＣＨを経由して割り当てられる複数の時間リソース及び周波数リソースから成る。実際、ＰＤＣＣＨは、リソース割り当て及び対応するアドレッシング情報（例えば、無線ネットワーク一時識別子−ＲＮＴＩ）をモバイル通信装置に提供する。それ故に、モバイル通信装置は、ＲＮＴＩに基づいて、当該モバイル通信装置を対象とする（宛先アドレスとする）データを受信するためにどのリソース割り当てをデコードすべきかを知得することができる。データは、このモバイル通信装置のみについてのデータであっても、又はセル内の全てのモバイル通信装置についてのデータであってもよい。図３において、２つのリソースブロック１６２、１６４が強調されている。これらは、特定の端末デバイスのＲＮＴＩに関連付けられるＰＤＣＣＨ１４０において提供される制御情報によって当該特定の端末デバイスに割り当てられ得る。その結果、当該端末デバイスは、当該周波数／シンボル割り当てにおいて送信されるデータをデコードすべきことを知得するであろう。
【００３９】
同様に、図４は、図２に示されるネットワークにおけるｅＮＢ１０１および通信装置１０５の間のエア（Ｕｕ）インタフェース使用のための例示的なアップリンクデータ及び制御チャネル構造を概略的に図示する。ダウンリンク側と同様に、物理アップリンクフレーム２２０が用いられて、アップリンク（端末デバイスから基地局）上で制御シグナリング及びデータが通信される。繰り返しになるが、図３と同様に、図４は、当該フレームが幾らか簡略化された形態である。図４において、物理アップリンクフレーム２２０は、複数のサブフレーム２３０に分けられる。図４におけるＬＴＥフレーム２２０の図の下は、サブフレーム２３０のうちの１つの拡大されたバージョンである。各サブフレーム２３０において、物理アップリンク制御チャネル（ＰＵＣＣＨ：Physical  Uplink  Control  Channel）２４０が示され、当該ＰＵＣＣＨ２４０は、（水平方向の）全時間（シンボル）帯域にわたり並びに（縦方向の）周波数帯域の上端及び下端の部分にわたり広がる幾らかの時間リソース及び周波数リソースを占める。対照的に、物理アップリンク共有チャネル（ＰＵＳＣＨ：Physical  Up-link  Shared  CHannel）２５０は、（ダウンリンクフレームにおける）ＰＤＣＣＨを経由して割り当てられる複数の時間リソース及び周波数リソースから成る。それ故に、ＰＤＣＣＨは、制御シグナリング及びデータを送信し及び受信するためのリソース割り当て及び対応するアドレッシング情報（例えば、無線ネットワーク一時識別子−ＲＮＴＩ）をモバイル通信装置に提供する。それ故に、モバイル通信装置は、ＲＮＴＩに基づいて、どのリソース割り当て上でデータを送信すべきかを知得することができる。図４において、２つのリソースブロック２６２、２６４が強調されている。これらは、特定の端末デバイスのＲＮＴＩと関連付けられるＰＤＣＣＨ２４０において提供される制御情報によって特定の端末に割り当てられ得る。その結果、当該端末デバイスは、当該周波数／シンボル割り当てを用いてデータを送信すべきことを知得するであろう。
【００４０】
図１Ｂに示した非対象リレートポロジのコンテキストにおいては、各基地局、リレー装置および端末装置が、これらアップリンクおよびダウンリンク制御および共有チャネルをそれらの間で情報を通信するために利用することに理解されたい。特に、基地局は、ＰＤＣＣＨおよびＰＤＳＣＨを利用して端末装置およびリレー装置の双方と情報を通信することが可能である。典型的には、基地局は、受信装置のために意図されたデータを探すためのＰＤＳＣＨ上の場所を受信装置に示すためにＰＤＣＣＨを利用する。ユーザ装置は、ＰＵＣＣＨおよびＰＵＳＣＨで基地局（それが範囲内であれば）と情報を通信することも、ＰＵＣＣＨおよびＰＵＳＣＨでリレー装置と情報を通信することも可能である。リレー装置は、ＰＵＣＣＨおよびＰＵＳＣＨで基地局と情報を通信することが可能である。ある実施形態では、リレー装置は、ＰＵＳＣＨでリレー装置が端末装置から受信したデータをリレーするためのＰＵＳＣＨリソースを要求することが求められる。ある実施形態では、端末装置およびリレー装置は、ＰＵＣＣＨ上の割当（時間／周波数）リソースであって、それらがＰＵＳＣＨの時間／周波数リソースの割当てを基地局に要求する（それらのリソース上での送信により）ために利用可能なＰＵＣＣＨ上の割当リソースが提供される。端末装置およびリレー装置に割り当てられるＰＵＣＣＨリソースは事前に決められていてもよい。ある実施形態では、リレー装置は、基地局へのアップリンクリソースの要求を受信してリレーできるように、端末装置に割り当てられているＰＵＣＣＨリソースを把握している。リレー装置は、割当ての所定の性質または基地局からの直接的な通知の方法により、端末装置に割り当てられたＰＵＣＣＨリソースを把握してもよい。別の実施形態では、端末装置は、リレー装置がＰＵＣＣＨを監視し、それが責任を持つ端末装置によって生成されたどのＰＵＣＣＨ送信も抽出可能とするいずれかのＰＵＣＣＨ送信を自身で特定してもよい。
【００４１】
ランダムアクセス手順
端末装置がリレー装置によって扱われる必要があるか否か、および端末装置が利用するために適切なリレー装置を識別するためのあるメカニズムは、リレー装置がランダムアクセス手順を監視することである。ランダムアクセス手順は、端末装置が基地局へのアクセスを得るための方法である。ランダムアクセス手順は、ネットワークへの初期アクセス、接続再確立、無線セル間のハンドオーバ、ダウンリンクデータ発生およびアップリンク発生を含む幾つかのイベントに関連して行われる。ＬＴＥネットワークのランダムアクセス手順の概要図は図５に示される。
【００４２】
図５において、端末装置（ＵＥ）および基地局（ＢＳ）韓のシグナルフローが示される。４つのステージが示されている。第１のステージであるＡは、端末装置から基地局への１または２以上のランダムアクセスプリアンブルの送信である。端末装置は所定のランダムアクセスプリアンブルのグループからランダムアクセスプリアンブル（コードシーケンス）をランダムに選択する。そのプリアンブルは、端末装置が利用可能な次回の利用可能なＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）リソースで送信される。送信されたランダムアクセスプリアンブルの時間および周波数リソースにおける位置は、黙示的に送信端末装置のための一時的な識別子（ＲＡ−ＲＮＴＩ）を提供する。
【００４３】
ランダムアクセルプリアンブルが基地局で受信されると、ステージＢにて、基地局から端末装置にランダムアクセスレスポンスが送信される。ランダムアクセスレスポンスはＰＤＳＣＨで送信される。端末装置は、ＰＤＣＣＨにより、ランダムアクセスレスポンスが行われるダウンリンクリソースを知らされている。具体的には、ＰＤＣＣＨは、ランダムアクセスプリアンブルの送信に利用された時間および周波数リソースから導かれる一時的な識別子を示し、また、ランダムアクセスレスポンスが行われるだろうＰＤＳＣＨ上のリソースブロック割当て（時間および周波数リソース）を示す。端末装置は、その一時的な識別子を手段とする端末装置へのランダムアクセスレスポンスが意図されていることを認識し、ＰＤＳＣＨにおいて割り当てられたリソースブロックを注視する。ＰＤＳＣＨ上のランダムアクセスレスポンスにおけるＭＡＣヘッダは、ステージＡで基地局により受信されたランダムアクセスプリアンブルを識別するランダムアクセスプリアンブル識別子、端末装置を識別するためのさらなる一時的な識別子（Ｃ−ＲＮＴＩ）、ＰＵＳＣＨ上のアップリンクリソースの付与、および端末装置と基地局との間の距離に応じて端末装置で送信時間を調整するためのタイミングアドバンスコマンドを含む。
【００４４】
ランダムアクセスレスポンスに応答して、ステージＣにて、端末装置はメッセージ３（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔ  Ｍｅｓｓａｇｅ）を基地局に送信する。メッセージ３は、ランダムアクセスレスポンスによって割り当てられたＰＵＳＣＨリソースで送信される。
【００４５】
メッセージ３に応答して、ステージＤにて、基地局は、競合解決目的（ｃｏｎｔｅｎｔｉｏｎ  ｒｅｓｏｌｕｔｉｏｎ  ｐｕｒｐｏｓｅｓ）のために所定の情報を端末装置に送信する。この情報は、ＰＤＳＣＨ（再びＰＤＳＣＨによって割り当てられたリソース）で送信される。この情報は、競合解決が成功した場合に（一時的でない）Ｃ−ＲＮＴＩとなるさらなる一時的な識別子（Ｃ−ＲＮＴＩ）を含む。競合解決情報は、ＵＥ＿Ｃｏｎｔｅｎｔｉｏｎ＿Ｒｅｓｏｌｕｔｉｏｎ＿Ｉｄｅｎｔｉｔｙ制御エレメントに含まれる。基地局からの端末で受信されたＵＥ＿Ｃｏｎｔｅｎｔｉｏｎ＿Ｒｅｓｏｌｕｔｉｏｎ＿Ｉｄｅｎｔｉｔｙがメッセージ３で送信されたＣＣＣＨ（Ｃｏｍｍｏｍ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）ＳＤＵ（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）と整合する場合、端末装置は、競合解決は成功し、ランダムアクセス手順は成功裏に完了したとみなす。競合解決を提供する理由は、２以上の端末装置が、同一のランダムアクセスプリアンブルを同一の時間および周波数リソースで利用してネットワークにアクセスしようとし得ることである。競合端末装置によって送信されたＣＣＣＨ＿ＳＤＵｓは異なることが予想されるので、ＵＥは、それらのランダムアクセスレスポンスが成功か否かを、競合端末装置の送信したＣＣＨ＿ＳＤＵを、基地局によってＣｏｎｔｅｎｔｉｏｎ＿Ｒｅｓｏｌｕｔｉｏｎ＿Ｉｄｅｎｔｉｔｙ＿ＭＡＣ制御エレメントにおいて基地局により競合端末装置に送り返されたものと比較することにより判断することが可能である。
【００４６】
ステージＡに戻って参照すると、ランダムアクセスレスポンスが受信されない場合、一連のランダムアクセスプリアンブルが端末装置によって段階的に高パワーレベルで送信され得る（ｐｏｗｅｒ  ｒａｍｐｉｎｇ）。しかし、連続する各ランダムアクセスプリアンブルは異なるであろうことに留意されたい。
【００４７】
基地局に接続しようとする端末装置がリレー装置によって扱われる必要があるか否かの識別にランダムアクセス手順を利用するために、リレー装置は、
・新たなＭＡＣメッセージにおいてそれが見える全てのランダムアクセスの試みのＲＡ−ＲＮＴＩ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ）を基地局（ＤｅＮＢ）に報告し得る。そして、基地局は、ＭＴＣ−ＲＮに観測されたが、それが受信しなかったいずれかのランダムアクセス手順があったか否かを判断してもよい。または、
・全てのＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）プリアンブルの試みを受信し、対応するランダムアクセスレスポンスの受信を待機し得る。それがレスポンスを得られなかった試みのみ基地局に報告される。
【００４８】
しかし、ＰＲＡＣＨプリアンブルに含まれるＵＥコンテキストは何ら存在しないという事実、およびＰＲＡＣＨプリアンブルで生じるパワーランピング（ｐｏｗｅｒ  ｒａｍｐｉｎｇ）に関連して、これらの双方のメカニズムでは著しい問題がある。問題は、
・パワーランピングメカニズムにより、レスポンスの無いＰＲＡＣＨプリアンブルは、端末装置がリレー装置にネットワークへのアクセスを求めることを必ずしも意味しない。端末装置は、その最大数のＲＡＣＨプリアンブルの試み（または、プリアンブルの最大パワーに達した場合）まで継続することが許容されるべきであり、そのときにのみ、端末装置がリレー装置によって扱われるべきとみなされるべきである；
・連続するプリアンブル再送信波完全に新しく引き出されたＲＡＣＨプリアンブルを利用するので、２つのランダムアクセスプリアンブルが同一の端末装置から生じたか否かを判断することが難しい、または不可能である；
・ＲＡＣＨプリアンブルがＭＴＣ−ＵＥによって送信されたのか非ＭＴＣ−ＵＥによって送信されたのかを知る方法がない。
【００４９】
図６は、これらの問題を図示する。図６において、端末装置は一連のランダムアクセス（ＲＡＣＨ）プリアンブルＰ１，Ｐ２、Ｐ３、Ｐ４およびＰ５を送信する。これらの連続する送信は、各失敗の後に完全に新たにランダムに選択され、パワーランピングが適用されたＲＡＣＨプリアンブルを示す。Ｐ１，Ｐ２、Ｐ３およびＰ４の各々はリレー装置によって受信されるが、基地局によっては受信されない。リレー装置は、ＲＡ−ＲＮＴＩを利用する対応するＲＡＣＨレスポンスの無い受信されたＲＡＣＨプリアンブルに気付くことにより失敗を識別することが可能であるが、それらが同一の端末装置から生じたことを知ることはできない。この例において、Ｐ５は基地局によって受信され、基地局との通信において端末装置によってリレー装置が求められないことを意味する。ＲＡＣＨレスポンスは基地局によって送信され、リレー装置によって検出され得て、リレー装置にＰ５を生じさせた端末装置に関して求められないことを知らせる。しかし、リレー装置は、それらの失敗した問題に関して求められていないことを識別するために、成功したＲＡＣＨプリアンブルＰ５と失敗したプリアンブルＰ１〜Ｐ４および発生元端末装置を関連付けることができない。
【００５０】
これらの問題を緩和するために、ランダムアクセス手順のパワーランピングにおいて端末装置がその最大パワーに達した場合、従来のグループに代えて、ＲＡＣＨプリアンブルの特別なグループが利用される。ＲＡＣＨプリアンブルのスペースは仕切られ、現在、３ＧＰＰＴＳ３６．３２１のセクション５．１．２において定義されるように、グループＡおよびグループＢが利用される。当該技術をサポートするために、追加的な新たなグループ、最大パワーグループが規定され得る。ランダムアクセス手順の送信において端末装置が最大パワーに達した場合、例えばＰＲＡＣＨプリアンブル再送信が前回のＰＲＡＣＨプリアンブル送信と同じパワーで送信された場合、端末装置は新たな最大パワーグループからプリアンブルを選択する。最大パワーグループから選ばれたプリアンブルの送信は、発生元端末が基地局に直接接続することに失敗していることをリレー装置に効率的に知らせる。これは図７に示される。
【００５１】
図７においては、図６のように、従来定義された端末装置がＲ１、Ｒ２およびＲ３を選択する。これらのＲＡＣＨプリアンブルは利用され失敗するので、端末装置は送信パワーを増加させる。各ケースにおいて、従来のプリアンブルセットから新たにランダムに選択されたＲＡＣＨプリアンブルが利用される。これらのＲＡＣＨプリアンブルはリレー装置によって無視される。
【００５２】
端末装置は、プリアンブルＰ３で最大ＲＡＣＨプリアンブルパワーに達する。この最大は、（以下で議論されるように）端末装置がプリアンブル送信のために全ての利用可能なパワーを利用することを認める現在の規格書から修正され得ることに留意されたい。システム情報は、新たな最大ＲＡＣＨプリアンブルパワーに達した場合に利用される新たなプリアンブルのグループを定義するだろう。端末装置は、新たな最大ＰＲＡＣＨパワーグループからプリアンブルＰ４を選択し、ＲＡＣＨプリアンブルＰ４を送信する。好ましくは、最大パワーグループから選択されたプリアンブルは、フルパワーで送信される（従来のプリアンブルグループからの最後のプリアンブルと同じパワー、または端末装置の最大送信パワー）。これは、従来のプリアンブルでのパワーランピングにより既に遅延が出ていることの観点、および直接送信でなくリレー装置の利用は自身がさらなる遅延を生じさせることの観点から、接続がより迅速になされることを可能とする。または、パワーランピングはリレー固有プリアンブルにも利用され得る（従来のプリアンブルと同じプロフィールまたは修正されたパワーランプで）。この場合、「最大パワーグループ」は代わりに「リレープリアンブルグループ」になる。
【００５３】
これまで、従前のプリアンブルのパワーランピングは端末装置の最大送信パワーまで継続された。しかし、これは、プリアンブルは基地局で成功して受信されたが、ＰＲＡＣＨ（ランダムアクセスプリアンブルの送信に利用される）とＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  ＣＨａｎｎｅｌ）送信の間で可能性のある感度差により、
ＵＬ−ＳＣＨ（Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  ＣＨａｎｎｅｌ）上のメッセージは失敗するシナリオの結果をもたらす可能性がある。
【００５４】
この問題を緩和するために、ＰＲＡＣＨプリアンブルパワー制御アルゴリズムは、端末装置の最大送信パワーを下回るデシベル数を上限として端末装置のＰＲＡＣＨプリアンブルの送信パワーを制限するように修正され得る。
【００５５】
リレー装置は、最大ＰＲＡＣＨパワーグループのＲＡＣＨプリアンブルＲ４の使用を検出し、以下を決定する。
・第１のサブフレームのサブフレーム（すなわち、ＲＡＣＨプリアンブルの送信に用いられる時間／周波数リソース）内のＰＲＡＣＨインデックスに基づき、ＲＡ−ＲＮＴＩ；
・ＲＡＰＩＤ、すなわち、ＲＡＣＨプリアンブルＩＤ；
・ＵＬ−ＳＣＨで送信される後続のメッセージ３の送信を正しく調整できるよう、端末装置について求められるタイミングアドバンス（これは、ＲＡＣＨプリアンブル送信の端末装置からリレー装置への伝播時間遅延からリレー装置で決定され得る。）；そして選択的に、
・リレー装置で適切な受信パワーレベルで受信されるべきメッセージ３のために端末装置が必要とするパワーオフセット（これは任意であり、例えばパワーランピングがリレープリアンブルに適用される場合には必要でない。）。パワーオフセットは、リレー装置で、ＲＡＣＨプリアンブル送信の受信信号パワーから決定され得る。
【００５６】
リレー装置は、従来の端末装置と同じ方法で基地局に時間および周波数リソースを要求する（リレー装置は、リレーする端末装置から区別された異なるＲＮＴＩを有することに留意されたい。）。その後、リレー装置はＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）メッセージを介してアップリンクグラントを受信する。
【００５７】
アップリンクグラントによってリレー装置に割り当てられたリソースを介してＲＡ−ＲＮＴＩ、ＲＡＰＩＤ、タイミングアドバンスおよびパワーオフセットを基地局に送信するために、新たなＭＡＣ制御エレメント（「リレープリアンブル」制御エレメント）が利用される。
【００５８】
基地局は、ＭＡＣ＿ＲＡＲ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｒｅｓｐｏｎｓｅ）メッセージ（修正の可能性がある）を送信するために利用されるＰＤＳＣＨリソースを割当てるリレープリアンブルメッセージに含まれるＲＡ−ＲＮＴＩを利用してＰＤＣＣＨ上で応答する。上記で紹介されたように、メッセージ３の送信のために利用される、端末装置が最後のＲＡＣＨプリアンブル送信に利用したパワーからのオフセットを提供するパワー制御エレメントを含むようにＲＡＲメッセージが修正されることが有益であろうことに留意されたい。その理由は、最大パワーグループのランダムアクセスプリアンブルの送信パワーが、リレー装置への到達に求められるよりもまたは単に適切量よりもかなり高い可能性があるので、成功したプリアンブルパワーに用いられたパワーからの固定のオフセット（システム情報で送信される）にメッセージ３のための端末装置送信パワーが基づく現在のメカニズムは適切でないことである。パワーランピングは求められるのに近いパワーレベルで成功のプリアンブルが送信される結果をもたらすので、固定オフセットは従来正常に機能していた。本ケースでは、上記オフセットは新たなＭＡＣメッセージで特定されるパワーオフセットに基づく。他の方法では、ランダムアクセスレスポンスは、現在定義されているのと同じだが、ＲＡＣＨプリアンブルの直接受信に基づくのでなく、リレープリアンブルメッセージの内容からデータ移動される。
【００５９】
端末装置は、ＲＡＲを受信し、現在規定されているのと同じ方法で動作する（メッセージにパワー制御情報が含まれている場合にはパワー制御情報を除いて。）。このため、それはメッセージ３を割当てられたアップリンクリソースで送信する。一方、リレー装置はＲＡＣＨレスポンスのＰＤＣＣＨコンポーネントを受信し、その後、アップリンクグラント情報を得るために、割り当てられたＰＤＳＣＨリソースに含まれるＭＡＣ＿ＲＡＲ（修正の可能性がある）を受信するように設定し、後続のメッセージ３を受信できるように自身の受信機を設定する。リレー装置を意図しないメッセージをリレー装置が結局監視する必要があることは望ましくないものとされることに留意されたい。この場合、別個の新たな形態のアップリンクグラントがリレー装置にシグナリングされ得る。アップリンクグラントの新たな形態は、実際にはアップリンクリソースを割当てないが、リレー装置によってリレーされるべき特定の端末装置に、リレー装置が受信する必要のあるアップリンクリソースが割り当てられていることをリレー装置に示し得る。このようなメカニズムの例が以下でさらに説明される。
【００６０】
リレー装置は端末装置からメッセージ３を受信する（これは、正しくタイミングアドバンスされ、任意で、正しくパワー制御されるだろう。）。メッセージ３は、送信範囲外のＤｅＮＢによっては受信されない。
【００６１】
ＭＴＣリレー装置は、端末装置から受信されたメッセージ３を、ＭＡＣにおける「リレーアップリンクメッセージ」にカプセル化する。このメッセージのヘッダはＴＰＣ（Ｔｒａｎｓｍｉｔ  Ｐｏｗｅｒ  Ｃｏｎｔｒｏｌ）およびＴＡ（Ｔｉｍｉｎｇ  ａｄｖａｎｃｅ）を示す情報を含み得る。リレー装置は、カプセル化されたメッセージを送信するために、基地局からアップリンクリソースを要求する。
【００６２】
リレーアップリンクメッセージは、カプセル化されたメッセージ３を抽出し、上述したように競合解決の完了を続ける基地局によって受信される。
【００６３】
ランダムアクセスプリアンブルに基づいて基地局から端末装置についてのリソースを要求するために、新たなＭＡＣ制御エレメントであるリレープリアンブルメッセージが、図８に示される提案のフォーマットで提供される。図８から理解されるように、リレープリアンブルメッセージは、予約領域（Ｒ）、タイミングアドバンス領域（ＴＡ  ｃｏｍｍａｎｄ）、ＲＡＣＨプリアンブルＩＤ領域（ＲＡＰＩＤ）、パワーオフセット（Ｐｏｗｅｒ  ｃｏｎｔｒｏｌ  ｉｎｆｏ）、ランダムアクセス一時識別子（ＲＡ−ＲＮＴＩ）および任意パディング（ＰＡＤ）を有する。これらの要素は、必要サイズにメッセージを膨らませるために用いられるパディングを除き、全て上記で議論されている。
【００６４】
修正されたＲＡＲメッセージが図９に概略的に図示される。特に、修正されたＲＡＲメッセージは、予約領域（Ｒ）、タイミングアドバンス領域（ＴＡ  ｃｏｍｍａｎｄ）、アップリンク時間および周波数リソースの割当て（ＵＬ  ｇｒａｎｔ）、さらなる一時識別子（Ｃ−ＲＮＴＩ）、パワーオフセット（Ｐｏｗｅｒ  ｃｏｎｔｒｏｌ  ｉｎｆｏ）、および任意パディング（ＰＡＤ）を有する。これは従来利用されていたＲＡＲと同じフォーマットであるが、追加されたＰｏｗｅｒ  ｃｏｎｔｒｏｌ  ｉｎｆｏフィールドを有する。
【００６５】
さらに、それらは新たなグループＣのプリアンブルセットを含むようにＲＲＣ＿ＩＥ「ＲＡＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎ」に変更される必要があり得る。現在定義されているシグナリングは、この変更がリリース８ＬＴＥへの下位互換性であるということに留意されたい。
【００６６】
リレー調停（Ａｒｂｉｔｒａｔｉｏｎ）
端末装置によって送信された最大ＰＲＡＣＨパワーグループのランダムアクセスプリアンブルを受信する複数のリレー装置が存在し得る。このため、基地局は、異なるリレー装置から同一の端末装置についての複数のリレープリアンブルＭＡＣメッセージを受信し得る。これを解決するために、いずれのリレー装置が端末装置のためのサービングリレー装置になるかを決定するためのメカニズムが求められる。
【００６７】
図１０は、これを概略的に図示する。図１０において、第１のリレー装置がリレープリアンブルＭＡＣメッセージを基地局に送信する。第２のリレー装置もリレープリアンブルＭＡＣメッセージを基地局に送信する。基地局は、端末装置を扱うためにいずれのリレー装置を利用するかを決定し、受信リレー装置が、示される端末装置についてのサービングリレー装置となることを示すサービングリレーインジケーションＭＡＣメッセージを送信する。ある例では、基地局はリレープリアンブルＭＡＣメッセージのパワー制御情報を分析し、いずれのリレーが端末装置から最も強くプリアンブル送信を受信したかを判断する。そして、プリアンブル送信を最も強く受信したリレーがその端末装置についてのサービングリレー装置となることが選択される。リレー装置間の相対負荷のような他の要素も考慮され得ることに理解されたい。
【００６８】
複数のリレー装置間の調停方法の例を明らかにする図１１に概略フロー図が示される。まず、ステップＡ１で、基地局（ＤｅＮＢ）がリレー装置（ＭＴＣ−ＲＮｓ）からリレープリアンブルＭＡＣメッセージの収集を開始する。複数のＭＴＣ−ＲＮが最大ＰＲＡＣＨパワーグループで送信された同一のＰＲＡＣＨプリアンブルを観測するので、ＤｅＮＢによって複数のリレープリアンブルＭＡＣメッセージが受信される。これらのメッセージは、同一のＲＡ−ＲＮＴＩおよびＲＡＰＩＤを示すが、異なるパワー制御情報フィールドを示すだろう。ステップＡ２で、定義された時間インターバル（Ｔｃｏｌｌｅｃｔ）の後、ＤｅＮＢはＭＴＣ−ＲＮからのリレープリアンブルＭＡＣメッセージの収集を停止する。典型的な定義された時間インターバルとしては約１秒が想定される。これが経過すると、受信されたリレープリアンブルメッセージにおけるパワー制御情報に基づき、いずれのＭＴＣ−ＲＮがサービングノードになるかについての決定が行われ得る。具体的には、ステップＡ３で、ＤｅＮＢはリレープリアンブルＭＡＣメッセージについての全ての受信パワー制御情報を比較し、ステップＡ４で、最良のシグナルレベルのＭＴＣ−ＲＮを問題となっているＭＴＣ−ＵＥについてのサーバに選択する。
【００６９】
異なるＭＴＣ−ＲＮからの複数のパワー制御情報フィールドが最良のシグナルレベル（所定のデシベルレベルの範囲内）を示す場合、基地局は、ステップＡ５で、各リレー装置についての関連端末装置の数を考慮することによってそれらの中から選択する。具体的には、基地局は、最も少ない関連ＭＴＣ−ＵＥの数を有するリレー装置（最良シグナルレベルを有する中で）を好ましくは選択する（負荷バランス）。最後に、ステップＡ６で、ＤｅＮＢは、選択されたＭＴＣ−ＲＮにペイロードＡＣＫと共にサービングリレーインジケーションを送信し、ペイロードＮＡＣＫを他の全てのＭＴＣ−ＲＮに送信する。これは、新たなメッセージ「サービングリレーインジケーション」ＭＡＣ制御エレメントの方法によって達成され得る。「サービングリレーインジケーション」ＭＡＣ制御エレメントは、現在のＲＡ−ＲＮＴＩ（およびＲＡＰＩＤ）に対応するＵＥがそのメッセージの受信ＭＴＣ−ＲＮによって制御されることを示す。ＮＡＣＫインジケーションが他の全てのＭＴＣ−ＲＮに送信されるだろう。可能性のあるＮＡＣＫインジケーションの送信の実現はグループＲＮ−ＲＮＴＩメカニズムを用いる。これは、ＮＡＣＫインジケーションが、何かしらの方法により、同一のＲＡ−ＲＮＴＩを含むリレープリアンブルＭＡＣメッセージを生じさせた全てのＭＴＣ−ＲＮを対象とすることを意味する。このため、可能性のある全ての関連ＭＴＣ−ＲＮにＮＡＣＫを示す実現は、ＲＮ−ＲＮＴＩでスクランブルされたＰＤＳＣＨ割当ての利用である。選択されたＭＴＣ−ＲＮはＡＣＫおよびＮＡＣＫの双方を受信することが理解されるので、この場合、ＭＴＣ−ＲＮはこれを論理的にＡＣＫを意味すると解釈し得る。複数のＭＴＣ−ＲＮを解決するためのグループＲＮＴＩメカニズムの利用はより一般的な適用性があり、単なるＮＡＣＫメッセージの送信に限定されないことに理解されたい。
【００７０】
「サービングリレーインジケーション」ＭＡＣ制御エレメントの可能性のある形態が図１２に示される。このＭＡＣ制御エレメントは、リレープリアンブルＭＡＣ制御エレメントに含まれるＲＡ−ＲＮＴＩ、１ビットのフィールドであり「１」がリレー装置がサービングノードであることを示し「０」がサービングノードでないことを示すリレー装置識別フィールド（Ｓ）、リレープリアンブルＭＡＣ制御エレメントに含まれるＲＡＣＨプリアンブルＩＤ領域（ＲＡＰＩＤ）および予約領域（Ｒ）を含む。
【００７１】
ＭＴＣ−ＲＮが所定のＭＴＣ−ＵＥについてのサービングＭＴＣ−ＲＮとして選択されると（それがランダムアクセスプリアンブルをリレーした唯一のＭＴＣ−ＲＮであった、または、２以上の候補からＤｅＮＢ調停がそれをサービングリレーノードになることを選択したことを理由に）、ＭＴＣ−ＲＮに記憶されたサーブＭＴＣ−ＵＥのリストにそのＭＴＣ−ＵＥのエントリがなされる。そのリストは、ある形態のパワー制御コンテキスト情報と共に、ＭＴＣ−ＵＥのＣ−ＲＮＴＩ（ＤｅＮＢとＭＴＣ−ＵＥの間の通信を識別およびアクセスするために用いられる）を含み得る。このパワー制御コンテキスト情報は、ＴＰＣ（Ｔｒａｎｓｍｉｔ  Ｐｏｗｅｒ  Ｃｏｎｔｒｏｌ）コマンドを生成できるように、ＭＴＣ−ＲＮおよびＭＴＣ−ＵＥ間の対象チャネル干渉を含み得る。
【００７２】
ＭＴＣの場合、ＵＥの移動性が低く、このため、ＵＥが一度ＭＴＣ−ＲＮを介して接続されたら、同一のＭＴＣ−ＲＮに関連付けられたままでいると考えることが合理的である。移動体の場合、ＵＥ（例えば、非ＭＴＣ）は、ＤｅＮＢがＭＴＣ−ＲＮにそれが選択されたことを知らせた場合にリストに追加され得る。ＵＥがＲＲＣコネクションを切断した場合、ＵＥはリストから削除され得る。
【００７３】
ＭＡＣリレー
アップリンクのみのリレー動作の一部として、リレー装置は端末装置からＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）プロトコルデータユニット（ＰＤＵ）を受信し、ＭＡＣＰＤＵに「ＭＡＣレイヤヘッダ」と呼ばれる新たなヘッダを追加する。
【００７４】
アップリンクのみのリレーについてのダウンリンクおよびアップリンクのエンドツーエンドのプロトコルスタックの概要図が図１３および図１４で各々提供される。
【００７５】
図１３は、ダウンリンク（基地局から端末装置）エンドツーエンドプロトコルスタックを示す。プロトコルスタックは、端末装置（ＭＴＣ−ＵＥ）、リレー装置（ＭＴＣ−ＲＮ）および基地局（ＤｅＮＢ）にて示される。ＭＴＣ−ＲＮは、ＭＴＣ−ＲＮの送信及び受信機能の双方が示されるように、２つのプロトコルスタックで示される、ＭＴＣ−ＲＮは、１つのＤｅＮＢとのみ通信するが、複数のＭＴＣ−ＵＥと通信し得る。これを反映するために、ＤｅＮＢプロトコルスタックおよびＭＴＣ−ＲＮの右側のプロトコルスタック（すなわち、ＤｅＮＢとの通信に用いられるプロトコルスタック）は単一のスタック（単一のインタフェース）として示され、一方、ＭＴＣ−ＵＥおよびＭＴＣ−ＲＮの左側のプロトコルスタック（すなわち、ＭＴＣ−ＵＥとの通信に用いられるプロトコルスタック）については複数の並列なプロトコルスタックが示されている。ＭＴＣ−ＵＥおよびＤｅＮＢについてのプロトコルスタック、およびＭＴＣ−ＲＮの右側のスタックは以下のレイヤを有する（最も高いレイヤから最も低いレイヤへ）。
・ＲＲＣ（ｒａｄｉｏ  ｒｅｓｏｕｒｃｅ  ｃｏｎｔｒｏｌ）
・ＰＤＣＰ（ｐａｃｋｅｔ  ｄａｔａ  ｃｏｎｖｅｒｇｅｎｃｅ  ｐｒｏｔｏｃｏｌ）
・ＲＬＣ（ｒａｄｉｏ  ｌｉｎｋ  ｃｏｎｔｒｏｌ）
・ＭＡＣ（ｍｅｄｉｕｍ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ）
・Ｌ１（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）
【００７６】
送信装置から受信装置への送信についての高レイヤ（例えばＲＲＣレイヤ）ではじまる制御およびデータシグナリングは、物理レイヤまで多種の低レイヤを通して繰り返し変換または処理され、そして物理レイヤで受信装置へ送信される。受信装置では、物理レイヤで制御シグナリングが受信され、典型的には送信装置においてはじまったレイヤまで、例えばＲＲＣレイヤまでプロトコルスタックを経由して伝わり上がる。
【００７７】
図１３には２つのシグナルフローが示される。それらの１つ目は、ＤｅＮＢからＭＴＣ−ＵＥへのＭＴＣ−ＵＥデータおよび制御シグナルフローである。これは、ＤｅＮＢでプロトコルスタックを経由して伝わり下がり、物理レイヤ（Ｌ１）でＭＴＣ−ＵＥに直接送信される。理解されるように、ＤｅＮＢからＭＴＣ−ＵＥへのダウンリンク送信は、ＭＴＣ−ＲＮを介さず、直接行われる。ＭＴＣ−ＵＥデータおよび制御シグナルフローは、ＭＴＣ−ＵＥで受信されると、ＭＴＣ−ＵＥでプロトコルスタックを経由して伝わり上がる。２つ目のシグナルフローは、ＤｅＮＢからＭＴＣ−ＲＮへのＭＴＣ−ＲＮ制御シグナルフローである。これは、ＤｅＮＢでプロトコルスタックを経由して伝わり下がり、物理レイヤ（Ｌ１）でＭＴＣ−ＲＮへ直接送信される。ＭＴＣ−ＲＮ制御シグナルフローは、ＭＴＣ−ＲＮで受信されると、ＭＴＣ−ＲＮでプロトコルスタックを経由して伝わり上がる。ダウンリンクの場合、ＭＴＣ−ＲＮはダウンリンクでＭＴＣ−ＵＥと通信するために用いられないので、ＭＴＣ−ＲＮの左側のプロトコルスタック（ＭＴＣ−ＵＥとの通信に用いられる）は利用されない。
【００７８】
図１４は、アップリンク（端末装置から基地局）エンドツーエンドプロトコルスタックを示す。プロトコルスタックは、端末装置（ＭＴＣ−ＵＥ）、リレー装置（ＭＴＣ−ＲＮ）および基地局（ＤｅＮＢ）にて図１３と同様の構成で示される。このため、ここではレイヤ構成の説明は繰り返さない。図１３のように、複数のＭＡＣインスタンスがＭＴＣ−ＲＮおよび潜在的に複数のＭＴＣ−ＵＥとの間に提供される。
【００７９】
図１４には２つのシグナルフローが示される。それらの１つ目は、ＭＴＣ−ＵＥからＤｅＮＢへのＭＴＣ−ＵＥデータおよび制御シグナルフローである。これは、ＭＴＣ−ＵＥでプロトコルスタックを経由して伝わり下がり、物理レイヤ（Ｌ１）でＭＴＣ−ＲＮに送信される。そして、制御シグナルフローは、ＭＴＣ−ＲＮのＭＡＣレイヤまで伝わり上がり、ＭＴＣ−ＲＮで処理され（後述する方法により）、物理レイヤまで伝わり下がり、物理レイヤでＤｅＮＢへ再送信される。ＤｅＮＢでは、ＭＴＣ−ＵＥデータおよび制御シグナリングはプロトコルスタックを経由して伝わり上がる。ここから、ＭＴＣ−ＵＥデータおよび制御シグナリングはＭＴＣ−ＲＮでＭＡＣレイヤ上で処理されることを理解されたい。この理由は、ＭＴＣ−ＵＥからのデータを受信するためのプロトコルスタックの上側部分を省略できるからであり、ＭＴＣ−ＲＮの簡素化を可能とする。２つ目の信号はＭＴＣ−ＲＮからＤｅＮＢへのＭＴＣ−ＲＮ制御シグナルフローである。これは、ＭＴＣ−ＲＮでプロトコルスタックを経由して伝わり下がり、物理レイヤ（Ｌ１）でＤｅＮＢへ直接送信される。ＭＴＣ−ＲＮ制御シグナルフローは、ＤｅＮＢで受信されると、ＤｅＮＢでプロトコルスタックを経由して伝わり上がる。このため、ＭＴＣ−ＲＮおよびＤｅＮＢ間の通信リンクを制御するためにＭＴＣ−ＲＮにはフルプロトコルスタックが求められることを理解されたい。
【００８０】
図１３および図１４から、ＭＡＣレイヤで処理が行われることに理解されたい。ＭＡＣレイヤでは、データはＤＬ−ＳＣＨまたはＵＬ−ＳＣＨ上のＭＡＣプロトコルデータユニット（ＰＤＵｓ）において通信される。各ＭＡＣＰＤＵは、ＭＡＣヘッダ、０または１以上のＭＡＣサービスデータユニット（ＳＤＵｓ）、０または１以上のＭＡＣ制御エレメントおよび任意パディングを含む。ＭＡＣヘッダは、複数のサブヘッダを含んでもよく、それぞれは、ＭＡＣ制御エレメント、ＭＡＣＳＤＵまたはパディングのいずれかに対応する。サブヘッダは、ＭＡＣ制御エレメント、ＭＡＣＳＤＵまたはパディングの各々の内容およびサイズを記載する所定の情報を含む。ヘッダおよびサブヘッダは、対応するＭＡＣＳＤＵの論理チャネル、または対応するＭＡＣ制御エレメントのタイプを示すＬＣＩＤ（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ  Ｉｄｅｎｔｉｆｉｅｒ）フィールドを有してもよい。図１３および図１４において、ＭＡＣＰＤＵ（の多様な複数のタイプ）は、ＭＴＣ−ＵＥおよびＭＴＣ−ＲＮからアップリンクで、アップリンクおよびダウンリンクのＭＴＣ−ＲＮとＤｅＮＢの間で、ダウンリンクＤｅＮＢとＭＴＣ−ＵＥの間で送信される。
【００８１】
ＭＡＣＰＤＵがＭＴＣ−ＵＥからＭＴＣ−ＲＮへ送信されると、ＭＴＣ−ＲＮは新たな「ＭＡＣリレーヘッダ」をＭＡＣＰＤＵ（この段階では、それらはＭＡＣレイヤ処理への入力として扱われるので、ＳＤＵとみなされる）に追加し、ＭＡＣレイヤＰＤＵの結果をＤｅＮＢに送信する。これは図１５に概略的に図示される。図１５において、ＭＴＣ−ＵＥ３１０はＭＴＣ−ＲＮ３２０にＭＡＣＰＤＵ３１５を送信する。ＭＴＣ−ＲＮ３２０では、受信されたセグメント化されていないＭＡＣＰＤＵ３１５に、ＭＴＣＵＥ３１０を識別し（ＵＥ識別子、例えばＣ−ＲＮＴＩ）、タイミングアドバンス（ＴＡ）およびパワー制御情報（典型的にはＴＰＣ決定）を提供するリレーヘッダ３２３が提供される。タイミングアドバンス情報は、ＭＴＣ−ＲＮによって、ＭＴＣ−ＵＥからＭＴＣ−ＲＮへの送信の伝播時間遅延に基づいて導かれる。同様に、パワー制御情報は、ＭＴＣ−ＲＮによって、ＭＴＣ−ＵＥからＭＴＣ−ＲＮへの送信の受信パワーレベルに基づいて導かれる。タイミングアドバンスおよびパワー制御情報は、ＭＴＣ−ＲＮへの後続の送信の送信タイミングおよび送信パワーの設定においてＭＴＣ−ＵＥによって必要とされる。ＭＴＣ−ＲＮはＭＴＣ−ＵＥとダウンリンクで通信しないので（アップリンクのみのリレー）、この情報はＭＴＣ−ＲＮからＭＴＣ−ＵＥへ直接提供することはできない。最終的にＭＴＣ−ＵＥにこの情報が提供されるために、これはリレーヘッダ３２３に記載される。ＭＡＣリレーヘッダ制御エレメントの存在およびＭＴＣ−ＵＥからの関連するカプセル化されたＭＡＣＰＤＵのサイズを示すために、従来のＲ／Ｒ／Ｅ／ＬＣＩＤ／Ｆ／ＬおよびＲ／Ｒ／Ｅ／ＬＣＩＤエレメント（ＴＳ３６．３２１のセクション６．１．２参照）が利用され得る。さらに、ＴＳ３６．３２１で定義されるように、ＢＳＲ（ｂｕｆｆｅｒ  ｓｔａｔｕｓ  ｒｅｐｏｒｔ）のような従来のＭＡＣ制御エレメント３２２が追加され得る。ＭＡＣリレーヘッダについての新たなＬＣＩＤ値が必要となることに留意されたい。また、ＭＴＣ−ＵＥから受信されたＭＡＣＰＤＵはＭＴＣ−ＲＮにおいてＭＡＣＳＤＵとなり（カプセル化）、複数のＭＴＣ−ＵＥからの複数のＭＡＣＰＤＵはＭＴＣ−ＲＮから単一のＭＡＣＰＤＵで送信され得る。このため、連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）が可能であるが、ＭＴＣＵＥからのＭＡＣＰＤＵのセグメンテーションは難しいだろう。
【００８２】
ＭＴＣ−ＲＮでセグメンテーションを提供する難しさを説明するために、ＭＴＣ−ＵＥでは、物理リソースがアップリンクデータの送信のために割り当てられ、それらの物理リソースは搬送され得る所定数のデータビットを示すことに理解されたい。
【００８３】
ＭＴＣ−ＵＥでは、ヘッダが考慮されると、ＭＡＣレイヤが、割り当てられたリソースに挿入可能なデータ量を決定し、上位レイヤ（それはＲＬＣ）にそのサイズのパケットを要求する（これは、ＭＡＣＳＤＵまたはＲＬＣＰＤＵと呼ばれ、ＰＤＵがレイヤ出力である一方でＳＤＵがレイヤへの入力となるだろう。）。ＲＬＣは、バッファされたパケットを、通常は小さな（しかし、必ずしもそうでない）エアインタフェース上で送信されるパケットに分割する役割を担う。大きなパケットが小さなパケットに分割されると、これはセグメンテーションと称される。上記から理解されるように、これは従来ＲＬＣによって行われた。このデータがＭＡＣレイヤに到達すると、割当てに適合され（サイズにおいて）、アップリンクで送信され得る。
【００８４】
ＭＡＣレベルでのＭＴＣ−ＲＮにとっての問題は、ＭＡＣレベルでセグメンテーションを実行する手段が無いことであり（そして我々は我々のためにこの仕事を行うＲＬＣレイヤを持たない）、このため何が起きるかが以下のシンプルな例で示される。
【００８５】
ＭＴＣ−ＲＮは、ＤｅＮＢへリレーすべき２つのＭＡＣＰＤＵをＵＥから受信する。その各々は、１００ビットのサイズであり、それらは異なるＵＥからのものである。ＭＴＣ−ＲＮは自身のバッファの占有状態−２００ビットをＤｅＮＢに知らせる。ＤｅＮＢには全てのこのデータを送信する割当てを認める義務は無いので、例えば１９０ビットの割当てがなされる。我々はＭＡＣレイヤでセグメンテーション手段を持たないので、ＭＴＣ−ＲＮが有する唯一のオプションは、リレーされるべきＭＡＣＰＤＵの１つを送信し、残りの割当てを無駄にすることである。ＤｅＮＢが１００ビット未満の割当てを認めた場合、ＭＴＣ−ＲＮは何も送信できないので、状況はさらに悪いだろう。
【００８６】
これが重要な問題であれば、セグメンテーション機能を提供する新たな機能をリレーノードのＭＡＣに特別に提供することも可能であろう。しかし、これは望ましくない複雑さの増加をもたらし、ＲＬＣレベルに代えてリレーする小さな利益を持つだろう
【００８７】
しかし、ＭＴＣ−ＲＮでのセグメンテーション機能の欠如は深刻な問題ではない。なぜならば、
（１）ＭＴＣ−ＲＮとＤｅＮＢの間の無線リンクは、ＭＴＣ−ＲＮとＭＴＣ−ＵＥの間よりもかなり良好であろう。このため、ＭＴＣ−ＵＥがリレーＤｅＮＢに送信したよりもＭＴＣ−ＲＮが少ないデータを送信できるシナリオは比較的に起りそうにない。
（２）ＤｅＮＢのスケジューラはＭＴＣ−ＲＮがリレーノードであることを把握し、ＭＴＣ−ＲＮによってリレーされるＰＤＵのサイズの合理的な考えを持つことができる（なぜならば、ＤｅＮＢは、ＭＴＣ−ＲＮによって扱われるＭＴＣ−ＵＥへのこれらのＰＤＵについてのリソースをそれまで割り当てていた。）。従って、スケジューラは、上記で議論した非効率が生じないように、または少なくとも緩和するように、ＭＴＣ−ＲＮに高い優先順位で割当て、ＭＴＣ−ＲＮにアップリンクリソースを割当てることができる。
【００８８】
ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥからＭＡＣＰＤＵを受信することに失敗したとしても、ＭＡＣリレーヘッダ制御エレメントを常に送信する。このメカニズムは黙示的なＡＣＫ／ＮＡＣＫをＤｅＮＢに提供する。ＭＴＣ−ＲＮは、ＭＴＣ−ＲＮにアップリンクリソースが割り当てられていることを把握しており、このため、特定の時間および周波数リソースでＭＴＣ−ＵＥからのアップリンク送信を想定できるので、ＭＴＣ−ＵＥからのＭＡＣＰＤＵの到着が失敗したことを把握し得ることに理解されたい。
【００８９】
ＵＥからのＭＡＣＰＤＵ３１５、リレーヘッダ３２３および従来のＭＡＣ制御エレメント３２２は、ＭＴＣ−ＲＮ３２０からＤｅＮＢ３３０へ送信されるＭＡＣリレーＰＤＵ３２５を共に作り出す。
【００９０】
ＤｅＮＢ３３０で、以下の処理が生じる。
【００９１】
ＤｅＮＢ３３０は、リレーＭＡＣＰＤＵ３２５を受信し、これが従来のＵＥから普通に受信されたかのように動作する。具体的には、ＭＡＣプロセッサ３３２にて、ＡＣＫ／ＮＡＣＫインジケーションがＭＴＣ−ＲＮ３２０に関して得られ、ＴＰＣコメントがＭＴＣ−ＲＮ３２０に関して生成され、ＭＡＣレイヤではＭＡＣ制御エレメント３２２が作用される。これらのパラメータおよび動作はＭＴＣ−ＲＮ３２０に向けられることに理解されたい。
【００９２】
そして、ＤｅＮＢ３３０では、リレーデマルチプレクサ３３４が、ＭＴＣＵＥ３１０へのタイミングアドバンス制御を制御するためにＭＡＣリレーヘッダ３２３の内容を利用する。また、パワー制御ＴＰＣコマンドがヘッダ３２３に含まれるパワー情報に基づいて生成される。ＡＣＫ／ＮＡＣＫインジケーションは、ＭＡＣリレーＰＤＵ３２５内にＭＴＣＵＥ３１０からのＭＡＣＰＤＵ３１５の存在または欠如に基づいて生成される。これは、以下に説明するように、ＭＡＣリレーヘッダのＰフィールドの内容に直接、またはから決定され得る。
【００９３】
また、リレーデマルチプレクサ３３４は、もともとはＭＴＣ−ＵＥ３１０によって送信されたＭＡＣＰＤＵ３１５をＭＡＣリレーＰＤＵ３２５から抽出し、これをＭＡＣプロセッサ３３２に処理のために返送する。ＭＡＣリレーヘッダ制御エレメントに含まれるＣ−ＲＮＴＩは、ＭＡＣＰＤＵ３１５の処理のために、ＭＡＣにおいてＵＥコンテキストを識別するために利用される。そして、通常のＭＡＣＰＤＵ３１５の処理が生じ、最終的に、ＭＴＣ−ＵＥ３１０から生じたデータに対応するＭＡＣＳＤＵ３３８がプロトコルスタックの高レイヤに送られる。
【００９４】
図１６に、ＭＡＣリレーヘッダエレメントの提案形態が示される。図１６において、Ｃ−ＲＮＴＩはリレーＵＥのＣ−ＲＮＴＩであり、ＴＰＣはリレー装置でＭＴＣＵＥに関してなされたＴＰＣ決定であり、ＴＡｉｎｆｏはリレー装置でＭＴＣＵＥに関して得られたタイミングアドバンス情報であり、Ｐは関連ＭＡＣＰＤＵの存在または欠如を示す。関連ＭＡＣＰＤＵが正しく受信された場合、このビットは「１」に設定され、ＭＡＣＰＤＵがＭＡＣリレーＰＤＵのペイロードに存在し得る（すなわち、ＡＣＫがあった。）。「０」に設定された場合、ＭＡＣＰＤＵは存在しない（すなわち、ＮＡＣＫがあった。）。
【００９５】
ＭＴＣ−ＵＥからの全てのスケジュールされた送信がＭＴＣ−ＲＮによって正しく受信された場合の新たなＭＡＣリレーＰＤＵ構造の例が図１７に概略的に示される。
【００９６】
ＰＤＵのＭＡＣヘッダ４１０は、複数のサブヘッダ４１２、４１４および４１６を有する。サブヘッダ４１２は、ＭＡＣペイロードの制御エレメント４２０および４３０の各々に対応する。サブヘッダ４１４は、ＭＡＣペイロードのＳＤＵ４４０に対応し、サブヘッダ４１６は、ＭＡＣペイロードの任意パディングに対応する。概して、ＭＡＣヘッダ４１０は、関連ＭＡＣリレーヘッダ制御エレメント４３０がシグナルされ得るためにＲ／Ｒ／Ｅ／ＬＣＩＤサブヘッダ４１２で利用される新たなＬＣＩＤ値が利用可能であることを除き、ＬＴＥ規格書で現在定義されているものである。ＭＡＣ制御エレメントは好ましくは以下のように並べられるべきである。
【００９７】
最初に、従来のＭＡＣ制御エレメント４２０が記載されるべきである。図１７においてはｍ個の従来の制御エレメント４２０が提供されることに留意されたい。
【００９８】
従来のＭＡＣ制御エレメント４２０の後にＭＡＣリレーヘッダ制御エレメント４３０が挿入されるべきである。リレーされる各ＭＡＣＰＤＵについてＭＡＣリレー制御エレメント４３０が存在し、ＭＡＣリレー制御エレメント４３０の順序はリレーされるＭＡＣＰＤＵの順序と同じであり得る（この例ではＰフィールドに「１」が設定される）図１７においてはｎ個のＭＡＣリレーヘッダ制御エレメント４３０およびリレーされるｎ個のＭＡＣＰＤＵが存在することに留意されたい。
【００９９】
単一のＭＡＣリレーＰＤＵが同一のＭＴＣ−ＵＥから受信された複数のＭＡＣＰＤＵを含む場合、最初に受信されたものが組み立てられたＭＡＣリレーＰＤＵの全体の最初にあり、２番目は２番目に、などであり得る。
【０１００】
図１７においてＭＡＣＳＤＵは、実際にはＭＴＣ−ＲＮ３２０によって受信されリレーされたＭＡＣＰＤＵである（それらは、ＭＴＣ−ＵＥ３１０から送信されたＭＡＣＳＤＵ、ＭＡＣヘッダおよびＭＡＣ制御エレメントを含む。）。図１７ではｎ個のＭＡＣＳＤＵ４４０が存在することに留意されたい。
【０１０１】
図１７から分かるように、組み立てられたＭＡＣリレーＰＤＵにおいて複数のＭＡＣＳＤＵ４４０が存在する。上記で議論したように、これらのＭＡＣＳＤＵ４４０の各々は、実際にはＭＴＣ−ＵＥから送信され、ＭＴＣ−ＲＮによって受信されたＭＡＣＰＤＵである。これらは、単一のＵＥ（受信されたＭＡＣＰＤＵは複数の送信の時間インターバル（ＴＴＩ）にわたって記憶される。）または複数の異なるＵＥから到来し得る。このため、単一のＭＡＣリレーＰＤＵを形成するための、複数のＭＴＣ−ＵＥからの複数のＭＡＣＰＤＵの連結形態が可能である。しかし、ＭＴＣ−ＵＥから受信されたＭＡＣＰＤＵのセグメンテーションはできないことに留意されたい。
【０１０２】
ＭＴＣ−ＵＥからの幾つかのスケジュールされた送信がＭＴＣ−ＲＮによって正しく受信されなかった場合の新たなＭＡＣリレーＰＤＵ構造の例が図１８に概略的に示される。スケジュールされた送信は、全く受信されなかった場合、または誤って受信された場合（破損または不完全）に、正しく受信されなかったとみなされ得る。
【０１０３】
図１８において、ＭＡＣヘッダ５１０になおもｎ個のＭＡＣリレーヘッダが存在し、これは、ＭＴＣ−ＲＮが同数のスケジュールされたＭＴＣ−ＵＥ送信を報告するからである。図１７と同様、従来のＭＡＣ制御エレメント５２０のセットが、ＭＡＣリレーヘッダ５３０、ＭＡＣＳＤＵ５４０、および任意パディングのセットとして存在する。図１８において、いくつかのＭＡＣリレーヘッダ制御エレメント５３０は、ＭＡＣＰＤＵが関連アップリンクグラントについて正しく受信されなかったことを示す「０」が設定されたＰフィールドを有する。それがｐ個のケースあった仮定する。Ｐフィールドが「０」に設定されたＭＡＣリレーヘッダ制御エレメント５３０については、関連付けられたＭＡＣＳＤＵは存在しない。このため、ＭＡＣＳＤＵ５４０（ＭＴＣ−ＵＥから実際に受信されたＭＡＣＰＤＵ）の総数は、ｎ−ｐである。「１」に設定されたＰを有するＭＡＣリレーヘッダ５３０の順序は、ＭＡＣリレーＰＤＵに含まれるＭＡＣＳＤＵと正確に対応すべきである。さらに、単一のＭＴＣ−ＵＥからの複数のＭＡＣＰＤＵを単一のＭＡＣリレーＰＤＵが報告する場合、ＭＡＣリレー制御エレメントおよび関連ＭＡＣＳＤＵ（しかしこれらは全てが存在しないかもしれないが）は、それらが受信されることがスケジュールされた順序であるべきである。
【０１０４】
以下のテーブル１において、ＭＡＣリレーヘッダ制御エレメントについての提案される新たなＬＣＩＤが強調して示される（強調されていない値は、現在ＬＴＥ規格書で定義される値である。）。
【０１０５】
【表１】
0005990585.tif 000002
テーブル１  ＭＡＣリレーヘッダ制御エレメントについての提案される新たなＬＣＩＤ
【０１０６】
リレー制御
ランダムアクセス手順に続いてリレーによってＵＥデータのリレーを扱う手順がここで図１９を参照して説明される。ＭＴＣ−ＵＥは、ＤｅＮＢにデータを送信することを望んだ場合、それまでに割り当てられた時間／周波数リソースのＰＵＣＣＨ上でスケジューリングリクエスト（ＳＲ）を送信する。これは、典型的には割り当てられた時間／周波数リソース内の単一ビット（送信された、または送信されなかった）である。ＤｅＮＢは、ＭＴＣ−ＵＥにアップリンクを割当ててシグナルするためにＳＲを受信する役割がある。
【０１０７】
ＭＴＣ−ＵＥからのリソース要求
ＵＥにＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）リソースが割り当てられていない場合、ランダムアクセス手順を行う必要があり、これは詳細に上述され、図１９に示される。
【０１０８】
ランダムアクセス手順が完了すると、ＭＴＣ−ＵＥは割り当てられたＰＵＣＣＨリソースでＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）を送信する。ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥに割り当てられているＰＵＣＣＨリソースが知らされており、それらのインスタンスでＰＵＣＣＨ送信の受信を試みる。ＭＴＣ−ＵＥに割り当てられたＰＵＣＣＨリソースをＭＴＣ−ＲＮが把握するための２つのメカニズムは以下の通りである。
（１）ランダムアクセス手順の直後に、ＰＵＣＣＨリソースは、ＤｅＮＢによって送信される暗号化されていないＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐ  ＲＲＣメッセージにおいてＭＴＣ−ＵＥに割り当てられる。このため、ＭＴＣ−ＲＮは、このＲＲＣメッセージのためにＰＤＣＣＨおよびＰＤＳＣＨを監視し、ＭＴＣ−ＵＥからのＰＵＣＣＨの受信のための設定に、このメッセージによって提供されるコンフィグレーション情報を使用することが可能である；
（２）扱うＭＴＣ−ＵＥに割り当てられたＰＵＣＣＨリソースをリレーノードに知らせるために新たなＲＲＣメッセージが利用され得る。新たなＲＲＣメッセージは、ＤｅＮＢによって、例えばＰＤＣＣＨおよび／またはＰＤＳＣＨ上で直接ＭＴＣ−ＲＮに送信され得る。第１のオプションに対するこのオプションの利点は、第１のオプションでは、ＰＵＣＣＨが再構成（ｒｅｃｏｎｆｉｇｕｒｅｄ）された場合に、後続のＲＲＣメッセージは暗号化されるので、ＭＴＣ−ＲＮはそれを判断することができない可能性があることである。
【０１０９】
ＭＴＣ−ＲＮにより責任を持つＭＴＣ−ＵＥに関してＰＵＣＣＨが受信された場合、ＭＴＣ−ＵＥのＣ−ＲＮＴＩを含む新たなＭＡＣ制御エレメント「リレーＳＲメッセージ」を生成する。ＭＴＣ−ＲＮは、リレーＳＲメッセージを基地局に送信するために、従来のＵＥと同じ方法で、アップリンクリソースを要求し、認められ得ることに留意されたい。基地局にＳＲをリレーする他のオプション、例えば、ＳＲが通常単一の１ビットフラグであることに注目し、物理レイヤ（Ｌ１）シグナリングを利用することがあることを理解されたい。ＤｅＮＢは、ＳＲに応答してＭＴＣ−ＵＥにアップリンクリソースを割当てる。このアップリンクグラントは、ＰＤＣＣＨ上でＭＴＣ−ＵＥに直接送信される。さらに以下で説明されるように、（１）リレー装置へのＭＴＣ−ＵＥアップリンク割当て、および（２）カプセル化されたＭＴＣ−ＵＥメッセージのＤｅＮＢへの送信に用いられるＭＴＣ−ＲＮのための後続のアップリンク割当て、を示す任意の追加的な別個のメッセージが存在してもよい。
【０１１０】
ＭＴＣ−ＵＥからのアップリンクＭＡＣＰＤＵをリレーする概略メカニズム
ＭＴＣ−ＵＥからのアップリンクＭＡＣＰＤＵをリレーする概略メカニズムが以下に説明される。図１９において、ＢＳＲ（Ｂｕｆｆｅｒ  Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ）が転送されるが（これは、ＳＲの後の最初の送信についての標準ケースである。アップリンクで送信されるデータがどれだけあり、そのため将来必要なアップリンクリソースがどれだけかをＤｅＮＢにアドバイスするためである。）、本発明の実施形態はユーザプレーンデータに同様に適合する。
【０１１１】
以下に説明するように可能性のあるオプションは多数あり、各々はＭＴＣ−ＲＮで行われる推定（ｉｎｆｅｒｅｎｃｅ）レベル（およびシグナリング量）に依存する。
【０１１２】
オプション１：ＭＴＣ−ＵＥへのグラントと、このグラントの、ＭＴＣ−ＲＮへのグラント示唆を伴わないＭＴＣ−ＲＮへのインジケーションを分離する
この場合、図２０に示すように以下の手順が発生する。
【０１１３】
ステップＡ１で、ＭＴＣ−ＵＥへのアップリンクリソースグラントが行われ、ＰＤＣＣＨで送信される。同時期に、ステップＡ２で、実際にはＰＵＳＣＨを割当てないがＭＴＣ−ＵＥがＰＵＳＣＨリソースを割当てられたことをＭＴＣ−ＲＮに知らせる点で従来のグラントとは異なる分離されたグラントがＭＴＣ−ＲＮになされる。これは、ＭＴＣ−ＲＮにその受信機を適切に設定することを可能とする。このグラントは２つの形態のいずれかをとりえることに留意されたい。
１．修正されたアップリンクグラント（新たなデータインジケータのような所定のパラメータは不要である。）および割り当てが行われたＵＥを示すメカニズムを含む新たなＰＤＣＣＨ形態；または、
２．ＭＴＣ−ＲＮへのダウンリンクリソースの従来のＰＤＣＣＨグラントが行われ、問題となっているＵＥ（Ｃ−ＲＮＴＩによって識別される）に送信されたアップリンクリソースを示すＭＡＣ制御エレメントが後続のＰＤＳＣＨ送信でＭＴＣ−ＲＮに送信される。このメカニズムは、ＭＡＣランダムアクセスレスポンス手順と類似するが、実際のＭＴＣ−ＵＥへのアップリンクグラントは無く、特定のＵＥにグラントが行われたことを示すインジケーションのみがある。
【０１１４】
ステップＡ３で、ＭＴＣ−ＵＥは、グラントリソースのＰＵＳＣＨで送信し、これがＭＴＣ−ＲＮによって受信される（ＤｅＮＢはこのＰＵＳＣＨを受信しない。）。ステップＡ４で、ＭＴＣ−ＲＮは、自身のバッファに新たに到着したデータを有するＵＥと同じ方法で動作し、基地局からアップリンクリソースを要求し、そしてその後に認められる（ステップＡ５）。ステップＡ６で、ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥから受信したＭＡＣＰＤＵに、パワー制御およびタイミングアドバンス情報を含むアップリンクリレーＭＡＣヘッダ（上記参照）を追加し、割り当てられたリソースでこれを基地局に送信する。また、ＭＴＣ−ＵＥからＭＡＣＰＤＵをＭＴＣ−ＲＮが受信しなかった場合、ＭＴＣ−ＲＮはそれでもＭＴＣ−ＵＥからのカプセル化されたＭＡＣメッセージを含まないアップリンクリレーＭＡＣヘッダを送信することに留意されたい。続くステップＡ６で、ＤｅＮＢはデータを受信し、新たなＭＡＣサブレイヤが、ヘッダを取り除き、最終的にそれが来たＭＴＣ−ＵＥを判断するために利用される。タイミングアドバンスおよびパワー制御情報もまたＭＡＣヘッダに存在することに留意されたい。ＡＣＫ／ＮＡＣＫは、ＭＴＣ−ＵＥからのカプセル化されたＭＡＣメッセージの存在または欠如から暗示的に伝えられる（可能性としては、ＭＡＣメッセージのヘッダ情報における「プレゼンス」ビットに基づき。）。
【０１１５】
図２１は、図２０の処理を繰り返すが、ＭＴＣ−ＲＮでＭＴＣ−ＵＥからのＰＵＳＣＨ送信が受信されなかった場合に処理がどのように修正されるかを概略的に示す。具体的には、ステップＡ１、Ａ２、Ａ４およびＡ５は図２０において同じ番号のステップと同一であるので、再度の説明はしない。ステップＡ３’は、ＰＵＳＣＨ上の送信がＭＴＣ−ＲＮに届いていないので（または代わりに不完全にまたは破損して到着して）、図２０のステップＡ３と異なる。この場合、ＭＴＣ−ＲＮはそれでもリソースを要求し、ＰＵＳＣＨ送信を基地局に送信するが、この場合にはＰＵＳＣＨ送信にＭＴＣ−ＵＥ由来のコンテンツは存在しない。この手順は、スケジュールされたＭＴＣ−ＵＥからの送信が失敗したことを基地局に効率的に知らせる。
【０１１６】
オプション２：ＭＴＣ−ＲＮへのグラントを伴わないＭＴＣ−ＵＥへの単一のＰＤＣＣＨグラント
この場合、図２２に示すように以下の手順が発生する。
【０１１７】
ステップＢ１で、ＭＴＣ−ＵＥへアップリンクリソースのグラントがなされ、ＰＤＣＣＨでＭＴＣ−ＵＥに送信される。これらのグラントリソースの分離されたインジケーションはＭＴＣ−ＲＮに送信されない。ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥに関連するメッセージを検出するためにＰＤＣＣＨを監視することが求められる（ステップＢ２）。ＭＴＣ−ＲＮは、これを、ＭＴＣ−ＲＮが把握している（例えば、上述したランダムアクセスレスポンスを通じて）、自身のＣ−ＲＮＴＩについてだけでなく（装置が自身を意図するＰＤＣＣＨデータを取得するための標準的な技術）、ＭＴＣ−ＵＥのＣ−ＲＮＴＩについてもＰＤＣＣＨでＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）マスクを行うことにより達成することが可能である。この方法では、ＭＴＣ−ＲＮは、グラントがＭＴＣ−ＵＥに提供されたことを識別し、自身の受信機を適切に設定することができる。残りの手順はオプション１で説明した通りであり、ステップＢ３、Ｂ４、Ｂ５およびＢ６は図２２および図２３のＡ３、Ａ４、Ａ５およびＡ６に対応するので、これらの記述はここでは記載されない。
【０１１８】
オプション３：ＭＴＣ−ＵＥへのグラントと、このグラントの、ＭＴＣ−ＲＮへのグラント示唆を伴うＭＴＣ−ＲＮへのインジケーションを分離する
この場合、図２３に示すように以下の手順が発生する。
【０１１９】
オプション１におけるように、ステップＣ１で、ＭＴＣ−ＵＥへのアップリンクリソースのグラントがなされ、ＰＤＣＣＨで送信される。オプション１におけるように、ステップＣ２で、実際にはＰＵＳＣＨを割当てないがＭＴＣ−ＵＥがＰＵＳＣＨリソースを割当てられたことをＭＴＣ−ＲＮに知らせる点で従来のグラントとは異なる分離されたグラントがＭＴＣ−ＲＮになされる。これは、ＭＴＣ−ＲＮに自身の受信機を適切に設定することを可能とする。オプション１におけるように、ステップＣ４にてＭＴＣ−ＵＥはグラントリソースのＰＵＳＣＨで送信し、これがＭＴＣ−ＲＮによって受信される（ＤｅＮＢはこのＰＵＳＣＨ送信を受信しない。）。オプション１とは対照的に、ステップＣ４におけるＭＴＣ−ＲＮによるメッセージの受信は、ＤｅＮＢにデータを送信するためにＭＴＣ−ＲＮによって利用される、後のサブフレームにおけるリソースのアップリンクグラントを示唆する（または、追加の明示的なインジケーションを含む）。オプションとして、基地局は（ステップＣ３で）、ステップＣ４で後続のＰＵＳＣＨ送信をリレーするためにアップリンクリソースをＭＴＣ−ＲＮに割り当てる、ＭＴＣ−ＲＮ＿ＰＵＳＣＨ割当てメッセージをＰＤＣＣＨで送信し得る。
【０１２０】
ステップ５で、ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥから受信したＭＡＣＰＤＵにアップリンクリレーＭＡＣヘッダ（以下参照）を追加し、これを割当てられたリソースで送信する。また、ＭＴＣ−ＵＥからＭＡＣＰＤＵをＭＴＣ−ＲＮが受信しなかった場合、ＭＴＣ−ＲＮはそれでもＭＴＣ−ＵＥからのカプセル化されたＭＡＣメッセージを含まないアップリンクリレーＭＡＣヘッダを送信することに留意されたい。ステップＣ５に続き、ＤｅＮＢはデータを受信し、新たなＭＡＣサブレイヤが、ヘッダを取り除き、最終的にそれが来たＭＴＣ−ＵＥを判断するために利用される。タイミングアドバンスおよびパワー制御情報もまたＭＡＣヘッダに存在することに留意されたい。ＡＣＫ／ＮＡＣＫは、ＭＴＣ−ＵＥからのカプセル化されたＭＡＣメッセージの存在または欠如から暗示的に伝えられる。
【０１２１】
オプション４：ＭＴＣ−ＲＮへのグラント示唆を伴うＭＴＣ−ＵＥへの単一のＰＤＣＣＨグラント
この場合、図２４に示すように以下の手順が発生する。
【０１２２】
オプション２におけるように、ステップＤ１にて、ＭＴＣ−ＵＥへの単一のアップリンクリソースグラントがなされ、ＰＤＣＣＨで送信される。これは、ステップＤ２でＰＤＣＣＨを監視することによりＭＴＣ−ＲＮも受信する。データをＤｅＮＢに転送する責任があることをＭＴＣ−ＲＮが知るＭＴＣ−ＵＥへの割当ての受信に基づき、後のサブフレームにおける暗示的に示される割当てが存在する。続くステップＤ３（オプションの）、Ｄ４およびＤ５はオプション３のＣ３、Ｃ４およびＣ５に対応するので、これらの記述はここでは記載されない。
【０１２３】
オプション対比
オプション１の利点は以下の通りである。
・ＭＴＣ−ＵＥへのアップリンクグラントをＭＴＣ−ＲＮに知らせるための分離されたＰＤＣＣＨの利用は、ＭＴＣ−ＲＮに、ＭＴＣ−ＵＥアップリンググラントが行われるが直接知らされる場所を見つけるためにＰＤＣＣＨを監視することを強いないことを意味する。
・ＭＴＣ−ＲＮはデータをＤｅＮＢに送信するために明示的なリソースを要求し、割り当てられる。これは、ＭＴＣ−ＲＮからのリレー送信のためのレート制御を行うことが非常に容易であるという利点がある。具体的には、ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥから実際に受信されたメッセージをリレーするために必要なアップリンクリソースのみを要求し得る。また、基地局からリソースを要求することは、複数のＭＴＣ−ＵＥからのＭＡＣＰＤＵを単一の送信に連結する容易さを改善する。
【０１２４】
オプション１の不利な点は以下の通りである。
・例えばＭＴＣ−ＵＥのＣ−ＲＮＴＩおよびＭＴＣ−ＵＥへの割当てをＭＴＣ−ＲＮに知らせるためのアップリンググラントを示すＲＡＲに類似する、新たな割り当てメカニズムが求められ得る。
・ＭＴＣ−ＵＥには、遅延ペナルティを増加させる、ＤｅＮＢへデータを送信するバックアップのためのリソース割当てが示唆されない。
【０１２５】
オプション２の利点は以下の通りである。
・ＭＴＣ−ＵＥがアップリンクリソースをグラントされたことを示すために、ＭＴＣ−ＲＮに送信されるべき分離されたインジケーションが求められない。これは、明示的なインジケーションの送信よりも効率的である。
・ＭＴＣ−ＲＮはデータをＤｅＮＢに送信するために明示的なリソースを要求し、割り当てられる。これは、ＭＴＣ−ＲＮからのリレー送信のためのレート制御を行うことが非常に容易であるという利点がある。具体的には、ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥから実際に受信されたメッセージをリレーするために必要なアップリンクリソースのみを要求し得る。また、基地局からリソースを要求することは、複数のＭＴＣ−ＵＥからのＭＡＣＰＤＵを単一の送信に連結する容易さを改善する。
【０１２６】
オプション２の不利な点は以下の通りである。
・ＭＴＣ−ＲＮは、示されるアップリンクリソースを受信するように自身の受信機を設定するために、ＭＴＣ−ＲＮを意図しない、およびＭＴＣ−ＲＮを意図するＰＤＣＣＨメッセージを見ることが必要となる。
・ＭＴＣ−ＵＥには、遅延ペナルティをもたらす、ＤｅＮＢへデータを送信するバックアップのためのリソース割当てが示唆されない。
【０１２７】
オプション３の利点は以下の通りである。
・ＭＴＣ−ＵＥへのアップリンクグラントをＭＴＣ−ＲＮに知らせるための分離されたＰＤＣＣＨの利用は、ＭＴＣ−ＲＮに、ＭＴＣ−ＵＥアップリンググラントが行われるが直接知らされる場所を見つけるためにＰＤＣＣＨを監視することを強いないことを意味する。
・ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥからデータを受信することのインジケーションからアップリンググラントを示唆される。これはシグナリングおよび遅延緩和の観点からより効率的である。
【０１２８】
オプション３の不利な点は以下の通りである。
・例えばＭＴＣ−ＵＥのＣ−ＲＮＴＩおよびＭＴＣ−ＵＥへの割当てをＭＴＣ−ＲＮに知らせるためのアップリンググラントを示すＲＡＲに類似する、新たな割り当てメカニズムが求められ得る。
・効率的なレート制御機能を行うこと困難であり、ＭＴＣ−ＲＮがＭＴＣ−ＵＥからの送信の受信に失敗した場合、送信される小さなリレーヘッダのみが存在し得る−これは実際に基地局によって割り当てられたよりも極めて小さいリソースを必要とするだろう。
【０１２９】
オプション４の利点は以下の通りである。
・ＭＴＣ−ＵＥがアップリンクリソースをグラントされたことを示すために、ＭＴＣ−ＲＮに送信されるべき分離されたインジケーションが求められない。これは、明示的なインジケーションの送信よりも効率的である。
・ＭＴＣ−ＲＮは、ＭＴＣ−ＵＥからデータを受信することのインジケーションからアップリンググラントを示唆される。これはシグナリングおよび遅延緩和の観点から明らかにより効率的である。
【０１３０】
オプション４の不利な点は以下の通りである。
・ＭＴＣ−ＲＮは、示されるアップリンクリソースを受信するように自身の受信機を設定するために、ＭＴＣ−ＲＮを意図しない、およびＭＴＣ−ＲＮを意図するＰＤＣＣＨメッセージを見ることが必要となる。
・効率的なレート制御機能を行うこと困難であり、ＭＴＣ−ＲＮがＭＴＣ−ＵＥからの送信の受信に失敗した場合、送信される小さなリレーヘッダのみが存在し得る−これは実際に基地局によって割り当てられたよりも極めて小さいリソースを必要とするだろう。
【０１３１】
総合的に、ＬＴＥネットワークにおいてオプション２がＭＴＣ装置に最良の選択を提示し得るが、上記から理解され得るように、全てのオプションがそれらの相対的なメリットを有する。
【０１３２】
ここまでの議論は、ＭＴＣ−ＲＮによってＰＵＣＣＨで受信されるスケジューリング要求（ＳＲ）をＤｅＮＢにリレーするメカニズムの必要性に注目した。これは、新たなＭＡＣ制御エレメント「リレーＳＲ」ＭＡＣ制御エレメントの利用により達成される。提案されるＭＡＣ制御エレメントの構造は図２５に示される。リレーＳＲはＭＴＣ−ＵＥのＣ−ＲＮＴＩのみを示す必要がある（ＭＡＣヘッダのＬＣＩＤがＤｅＮＢにこれがリレーＳＲであることを伝え得るので、ＢＳＲを送るために小さなアップリンク割当てが求められる。）。
【０１３３】
新たなＰＤＣＣＨアプローチは、ＤＣＩフォーマット０のカットダウンバージョン（ｃｕｔ  ｄｏｗｎ  ｖｅｒｓｉｏｎ  ｏｆ  ＤＣＩ  ｆｏｒｍａｔ  ０）（割り当てられたアップリンクリソースの受信のみを行うＭＴＣ−ＲＮによっては、ＣＱＩリクエスト、ＴＰＣコマンドおよび新たなデータインジケータは必要とされない。）を、ＭＴＣ−ＲＮがリレーの責任を持つＭＴＣ−ＵＥの実際のＣ−ＲＮＴＩを含むテーブルへのインデックスであるリレーＵＥ識別子と共に利用し得る。このテーブルは、ＲＲＣシグナリング（好ましくは）によってＭＴＣ−ＲＮにシグナリングされる。これは、もちろん、ＭＴＣ−ＲＮを正しく設定するためにＲＲＣメッセージが必要であることを意味する。
【０１３４】
ＭＴＣ−ＵＥからの送信が予想されるアップリンクリソースをＭＴＣ−ＲＮに示すための、「ＭＴＣ−ＵＥ割当て」制御エレメントと呼ばれる新たなＭＡＣ制御エレメントの実施例が図２６に概略的に示される。ＭＴＣ−ＵＥ割当て制御エレメントは、ＲＡＲ形態と類似するが、示唆されたアップリンク割当てをＭＴＣ−ＲＮがＭＴＣ−ＵＥから受信するために自身の受信機をターンオンすべきことをＭＴＣ−ＲＮに知らせるために利用されるように自身のＬＣＩＤを必要とする。ＭＴＣ−ＵＥ割当て制御エレメントは、アップリンクグラントがなされたＭＴＣ−ＵＥのＣ−ＲＮＴＩを特定するＣ−ＲＮＴＩフィールドを含む。フィールド「ＵＬグラント」はＭＴＣ−ＲＮが受信を設定すべきＭＴＣ−ＵＥに提供されたグラントを特定する。「Ｒ」フィールドはＲｅｓｅｒｖｅｄである。
【０１３５】
総合的に、ＰＤＣＣＨアプローチは、単一のメッセージを必要とするので好ましい。一方、新たなＭＡＣ制御エレメントアプローチは２つのメッセージを必要とする。その１つは、潜在的にブロックエラーレート（ＢＬＥＲ）ターゲットの影響を受けるＰＤＳＣＨで送信される（このチャネルではＨＡＲＱが動作するため）。
【０１３６】
図２７において、基地局（ＤｅＮＢ）１１００、リレー装置（ＭＴＣ−ＲＮ）１２００および端末装置（ＭＴＣ−ＵＥ）１３００を備える無線通信システム１０００の概略図が示される。ＤｅＮＢ１１００は、アンテナ１１２５を利用してエアインタフェース上でデータを送信および受信する送信機／受信機部分１１２０（送信機および受信機）を有する。また、ＤｅＮＢ１１００は、図２に示したコアネットワークエレメント（ここでは図示せず。）とのＤｅＮＢ１１００の動作の調整、およびエアインタフェース上の通信のスケジューリングを制御するプロセッサ１１４０を有する。ＤｅＮＢ１１００はバックホールリンク１１６０を経由してコアネットワークと接続される。ＤｅＮＢ１１００は通信リンク１４００のエアインタフェース上でＭＴＣ−ＲＮ１２００とダウンリンクおよびアップリンク方向の双方において通信する。
【０１３７】
ＭＴＣ−ＲＮ１２００は、アンテナ１２２５を利用してエアインタフェース上でデータを送信および受信する送信機／受信機部分１２２０（送信機および受信機）を有する。また、ＭＴＣ−ＲＮ１２００は、エアインタフェース上でのデータ受信および送信において送信機／受信機部分１２２０を制御するプロセッサ１２４０を有する。また、プロセッサ１２４０は、受信信号強度の測定およびエアインタフェース上のＭＴＣ−ＵＥからの伝播遅延を制御してもよく、上述した方法でＵＥＭＡＣＰＤＵをリレーＭＡＣＰＤＵに処理する役割を担う。ＭＴＣ−ＲＮ１２００は、通信リンク１４００のエアインタフェース上でＤｅＮＢ１１００とダウンリンクおよびアップリンク方向の双方において通信し、通信リンク１５００のエアインタフェース上でＭＴＣ−ＵＥ１３００からのアップリンク送信を受信する。通信リンク１５００は、ＭＴＣ−ＲＮ１２００はＭＴＣ−ＵＥ１３００に送信しないので、一方向である（アップリンクのみ）。
【０１３８】
ＭＴＣ−ＵＥ１３００は、アンテナ１３２５を利用してエアインタフェース上でデータを送信および受信する送信機／受信機部分１３２０（送信機および受信機）を有する。また、ＭＴＣ−ＵＥ１３００は、エアインタフェース上でのデータ受信および送信において送信機／受信機部分１３２０を制御するプロセッサ１３４０を有する。また、プロセッサ１３４０は、ＭＴＣ−ＵＥ１３００の目的に関する他の機能を制御し得る。例えば、ＭＴＣ−ＵＥがネットワークを介して測定結果（例えば、気温または電力使用）を報告することが意図された測定装置である場合、プロセッサ１３４０は、測定結果データの送信のためのパッケージング（ＭＡＣＰＤＵへの）と共に、これらの測定の実行および処理を扱う役割を担い得る。ＭＴＣ−ＵＥ１３００は、通信リンク１６００のダウンリンク方向においてＤｅｎ１１００からの送信を受信し、アップリンクの送信範囲内である場合には通信リンク１６００（破線）のアップリンク方向においてＤｅＮＢ１１００に直接送信し得る。ＭＴＣ−ＵＥ１３００が範囲外である場合、ＤｅＮＢ１１００へのＭＴＣ−ＵＥ１３００からのアップリンク送信は、ＭＴＣ−ＲＮ１２００により経由されてなされ得る。
【０１３９】
本実施形態はシングルホップリレーシチュエーションを説明したが、ＤｅＮＢが例えばＭＴＣ−ＵＥ  →  ＭＴＣ−ＲＮ１  →  ＭＴＣ−ＲＮ２  →  ＤｅＮＢの繋がりの各リンクでアップリンクリソースのスケジューリングを制御することで、マルチホップリレー構造も同様に構成され得ることに理解されたい。
【０１４０】
上記の説明は、ＬＴＥネットワークで動作するＭＴＣ装置に基づく。しかし、本発明の本質はこれに限定されず、他のネットワークおよび他のクラスの端末装置にも適用され得る。
【図１Ａ】
0005990585.tif 000003
【図１Ｂ】
0005990585.tif 000004
【図２】
0005990585.tif 000005
【図３】
0005990585.tif 000006
【図４】
0005990585.tif 000007
【図５】
0005990585.tif 000008
【図６】
0005990585.tif 000009
【図７】
0005990585.tif 000010
【図８】
0005990585.tif 000011
【図９】
0005990585.tif 000012
【図１０】
0005990585.tif 000013
【図１１】
0005990585.tif 000014
【図１２】
0005990585.tif 000015
【図１３】
0005990585.tif 000016
【図１４】
0005990585.tif 000017
【図１５】
0005990585.tif 000018
【図１６】
0005990585.tif 000019
【図１７】
0005990585.tif 000020
【図１８】
0005990585.tif 000021
【図１９】
0005990585.tif 000022
【図２０】
0005990585.tif 000023
【図２１】
0005990585.tif 000024
【図２２】
0005990585.tif 000025
【図２３】
0005990585.tif 000026
【図２４】
0005990585.tif 000027
【図２５】
0005990585.tif 000028
【図２６】
0005990585.tif 000029
【図２７】
0005990585.tif 000030