JP2022549266A - ランダムアクセスプロシージャのための方法および装置 - Google Patents

Abstract

本開示の様々な実施形態が、ランダムアクセスのための方法を提供する。端末デバイスによって実施され得る方法は、ネットワークノードからリソース設定情報を受信することを含む。本方法は、受信されたリソース設定情報に基づいて、２ステップランダムアクセスプロシージャにおけるネットワークノードからの応答メッセージへのフィードバックのためのアップリンクリソースを決定することをさらに含む。【選択図】図４Ａ

Description

本開示は、一般に、通信ネットワークに関し、より詳細には、ランダムアクセスプロシージャのための方法および装置に関する。

このセクションは、本開示のより良い理解を容易にし得る態様を紹介する。したがって、このセクションの記述は、この観点において読み取られるべきであり、従来技術にあるものまたは従来技術にないものに関する承認として理解されるべきではない。

通信サービスプロバイダおよびネットワーク事業者は、たとえば、必須のネットワークサービスおよび性能を提供することによって、消費者に価値および便宜を与えるための課題に絶えず直面している。ネットワーキングおよび通信技術の急速な発展とともに、ｌｏｎｇ－ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）および新無線（ｎｅｗ ｒａｄｉｏ：ＮＲ）ネットワークなど、無線通信ネットワークは、より低いレイテンシを伴って高いトラフィック容量およびエンドユーザデータレートを達成することが期待される。ネットワークノードに接続するために、ランダムアクセス（ＲＡ）プロシージャが、端末デバイスについて始動され得る。ＲＡプロシージャでは、ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックなどのフィードバックが、端末デバイスからネットワークノードに送信され得る。ＲＡプロシージャは、端末デバイスがネットワークノードとの特定のサービスのためのセッションを確立することを可能にすることができる。

本発明の概要は、発明を実施するための形態において以下でさらに説明される概念の選択を簡略化された形で紹介するために提供される。本発明の概要は、請求される主題の主要な特徴または不可欠な特徴を識別するものではなく、請求される主題の範囲を限定するために使用されるものでもない。

第５世代（５Ｇ）／新無線（ＮＲ）ネットワークなどの無線通信ネットワークは、フレキシブルなネットワーク設定をサポートすることが可能であり得る。様々なシグナリング手法（たとえば、４ステップ手法、２ステップ手法など）が、ネットワークノードとの接続をセットアップするための端末デバイスのＲＡプロシージャのために使用され得る。２ステップＲＡプロシージャでは、端末デバイスは、（メッセージＡまたは略してｍｓｇＡとしても知られる）メッセージ中で物理アップリンク共有チャネル（ＰＵＳＣＨ）とともにＲＡプリアンブルをネットワークノードに送信し、（メッセージＢまたは略してｍｓｇＢとしても知られる）応答メッセージをネットワークノードから受信することができる。

本開示の様々な実施形態が、ＲＡのためのソリューションを提案し、そのソリューションは、たとえば、送信効率を増加させるように、複数のフィードバックのためのリソース割り当てを可能にすることによって、レイテンシを改善し、２ステップＲＡプロシージャなどのＲＡプロシージャのためのより良い応答性を提供することができる。

本明細書で述べられる「ＰＲＡＣＨオケージョン」、「ランダムアクセスチャネル（ＲＡＣＨ）オケージョン」または「ＲＡオケージョン」という用語は、ＲＡプロシージャにおけるプリアンブル送信のために使用可能な時間周波数リソースを指し、これは「ランダムアクセスオケージョン（ＲＯ）」と呼ばれることもあることが了解され得る。これらの用語は、本明細書では互換的に使用され得る。

同様に、本明細書で述べられる「ＰＵＳＣＨオケージョン」、「アップリンク共有チャネルオケージョン」または「共有チャネルオケージョン」という用語は、ＲＡプロシージャにおけるＰＵＳＣＨ送信のために使用可能な時間周波数リソースを指し、これは「物理アップリンク共有チャネルオケージョン（ＰＯ）」と呼ばれることもあることが了解され得る。これらの用語は、本明細書では互換的に使用され得る。

本開示の第１の態様によれば、ユーザ機器（ＵＥ）などの端末デバイスによって実施される方法が提供される。本方法は、ネットワークノードからリソース設定情報を受信することを含み得る。本方法は、受信されたリソース設定情報に基づいて、２ステップランダムアクセスプロシージャにおけるネットワークノードからの応答メッセージへのフィードバックのためのアップリンク（ＵＬ）リソースを決定することをさらに含み得る。

いくつかの例示的な実施形態によれば、本方法は、決定されたＵＬリソース上でフィードバックを送信することをさらに含み得る。

いくつかの例示的な実施形態によれば、リソース設定情報は、ブロードキャストメッセージの少なくとも１つのパラメータと、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）の少なくとも１つのパラメータと、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）の少なくとも１つのパラメータと、応答メッセージの少なくとも１つのパラメータとのうちの少なくとも１つを含み得る。

いくつかの例示的な実施形態によれば、フィードバックはハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを含み得る。

いくつかの例示的な実施形態によれば、ＵＬリソースは物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースであり得る。

いくつかの例示的な実施形態によれば、応答メッセージは、多重化された２つまたはそれ以上の応答を含み得、２つまたはそれ以上の応答は、成功応答とフォールバック応答とのうちの少なくとも１つを含み得る。

いくつかの例示的な実施形態によれば、リソース設定情報は、ダウンリンク制御情報（ＤＣＩ）パラメータの少なくとも１つのセットを含み得る。

いくつかの例示的な実施形態によれば、ＤＣＩパラメータの各セットは、ＤＣＩパラメータのセットの存在を指示するビットに先行され得る。

いくつかの例示的な実施形態によれば、リソース設定情報は、ＤＣＩパラメータの２つまたはそれ以上のセットを含み得、ＤＣＩパラメータの第１のセット以外のＤＣＩパラメータのセットの各々は、別の端末デバイスのためのＤＣＩパラメータの前のセットに対するオフセットによって規定され得る。

いくつかの例示的な実施形態によれば、２つまたはそれ以上の応答は、それぞれ、２つまたはそれ以上の端末デバイスを対象とし得、リソース設定情報は巡回シフトインデックスのセットを指示し得、巡回シフトインデックスのセットは、１つのＰＤＳＣＨ上で多重化された２つまたはそれ以上の応答とともに２つまたはそれ以上の端末デバイスによって使用されることが可能であり得る。

いくつかの例示的な実施形態によれば、本方法は、巡回シフトインデックスのセット中の巡回シフトインデックスの量を、巡回シフトインデックスの量が端末デバイスの量よりも少ない場合、拡張することをさらに含み得る。

いくつかの例示的な実施形態によれば、２つまたはそれ以上の端末デバイスのフィードバックは、
・ 復調用参照信号、
・ 応答メッセージ中の２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
・ プリアンブル識別子（ＩＤ）、
・ 物理アップリンク共有チャネル（ＰＵＳＣＨ）リソースユニット、
・ 競合解消ＩＤ、および
・ 端末デバイスＩＤ
のうちの少なくとも１つによって識別されることが可能であり得る。

いくつかの例示的な実施形態によれば、２つまたはそれ以上の応答は、それぞれ、２つまたはそれ以上の端末デバイスを対象とし得、２つまたはそれ以上の端末デバイスは、同じＰＵＣＣＨリソース上でフィードバックを送信し得る。

いくつかの例示的な実施形態によれば、２つまたはそれ以上の端末デバイスのフィードバックは、
・ 異なる復調用参照信号、
・ 応答メッセージ中の２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
・ プリアンブルＩＤ、
・ ＰＵＳＣＨリソースユニット、
・ 競合解消ＩＤ、および
・ 端末デバイスＩＤ
のうちの少なくとも１つによって識別されることが可能であり得る。

いくつかの例示的な実施形態によれば、応答メッセージは、１つの成功応答またはフォールバック応答を含み得、リソース設定情報は、
・ 少なくとも１つのＤＣＩパラメータ、および
・ ブロードキャストメッセージの少なくとも１つのパラメータ
のうちの少なくとも１つを含み得る。

いくつかの例示的な実施形態によれば、リソース設定情報は、
・ （ａ）ＰＵＣＣＨリソースインジケータおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ、
・ （ｂ）ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータおよびｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定、
・ （ｃ）ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ情報エレメント、ならびに
・ （ｄ）応答ウィンドウサイズおよびシステムフレーム番号
のうちの少なくとも１つを含み得る。

いくつかの例示的な実施形態によれば、ＵＬリソースはＰＵＳＣＨリソースであり得る。

いくつかの例示的な実施形態によれば、応答はランダムアクセス応答であり得る。

本開示の第２の態様によれば、端末デバイスとして実装され得る装置が提供される。本装置は、１つまたは複数のプロセッサと、コンピュータプログラムコードを備える１つまたは複数のメモリとを備える。１つまたは複数のメモリおよびコンピュータプログラムコードは、１つまたは複数のプロセッサとともに、本装置に、少なくとも、本開示の第１の態様による方法の任意のステップを実施させるように設定される。

本開示の第３の態様によれば、その上に具現されたコンピュータプログラムコードを有するコンピュータ可読媒体が提供され、コンピュータプログラムコードは、コンピュータ上で実行されたとき、コンピュータに、本開示の第１の態様による方法の任意のステップを実施させる。

本開示の第４の態様によれば、端末デバイスとして実装され得る装置が提供される。本装置は、受信ユニットと決定ユニットとを備え得る。いくつかの例示的な実施形態によれば、受信ユニットは、少なくとも、本開示の第１の態様による方法における、ネットワークノードからリソース設定情報を受信するステップを行うように動作可能である。決定ユニットは、少なくとも、本開示の第１の態様による方法における、受信されたリソース設定情報に基づいて、２ステップランダムアクセスプロシージャにおけるネットワークノードからの応答メッセージへのフィードバックのためのＵＬリソースを決定するステップを行うように動作可能である。

本開示の第５の態様によれば、基地局などのネットワークノードによって実施される方法が提供される。本方法は、リソース設定情報を決定することを含み得る。リソース設定情報は、２ステップランダムアクセスプロシージャにおける応答メッセージへの端末デバイスのフィードバックのためのＵＬリソースを指示し得る。本方法は、リソース設定情報を端末デバイスに送信することをさらに含み得る。

いくつかの例示的な実施形態によれば、本開示の第５の態様による方法は、端末デバイスによって決定されたＵＬリソース上でフィードバックを受信することをさらに含み得る。

本開示の第６の態様によれば、ネットワークノードとして実装され得る装置が提供される。本装置は、１つまたは複数のプロセッサと、コンピュータプログラムコードを備える１つまたは複数のメモリとを備える。１つまたは複数のメモリおよびコンピュータプログラムコードは、１つまたは複数のプロセッサとともに、本装置に、少なくとも、本開示の第５の態様による方法の任意のステップを実施させるように設定される。

本開示の第７の態様によれば、その上に具現されたコンピュータプログラムコードを有するコンピュータ可読媒体が提供され、コンピュータプログラムコードは、コンピュータ上で実行されたとき、コンピュータに、本開示の第５の態様による方法の任意のステップを実施させる。

本開示の第８の態様によれば、ネットワークノードとして実装され得る装置が提供される。本装置は、決定ユニットと送信ユニットとを備え得る。いくつかの例示的な実施形態によれば、決定ユニットは、少なくとも、本開示の第５の態様による方法において、決定ステップを行うように動作可能である。送信ユニットは、少なくとも、本開示の第５の態様による方法において、送信ステップを行うように動作可能である。

本開示自体、好ましい使用モードおよびさらなる目的は、添付の図面とともに読まれるとき、実施形態の以下の詳細な説明を参照することによって最も良く理解される。

本開示の一実施形態による、例示的な４ステップＲＡプロシージャを示す図である。 本開示の一実施形態による、例示的な２ステップＲＡプロシージャを示す図である。 本開示のいくつかの実施形態による、ランダムアクセス応答（ＲＡＲ）を送信するためのいくつかの例示的なフォーマットを示す図である。 本開示のいくつかの実施形態による、ランダムアクセス応答（ＲＡＲ）を送信するためのいくつかの例示的なフォーマットを示す図である。 本開示のいくつかの実施形態による、ランダムアクセス応答（ＲＡＲ）を送信するためのいくつかの例示的なフォーマットを示す図である。 本開示のいくつかの実施形態による、ランダムアクセス応答（ＲＡＲ）を送信するためのいくつかの例示的なフォーマットを示す図である。 本開示のいくつかの実施形態による、専用ＰＵＣＣＨリソース設定の前の、例示的なＰＵＣＣＨリソースセットを示す図である。 本開示のいくつかの実施形態による、スロットの数へのＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータフィールド値の例示的なマッピングを示す図である。 本開示のいくつかの実施形態による、方法を示すフローチャートである。 本開示のいくつかの実施形態による、図４Ａに示されている方法のさらなるステップを示すフローチャートである。 本開示のいくつかの実施形態による、別の方法を示すフローチャートである。 本開示のいくつかの実施形態による、図５Ａに示されている方法のさらなるステップを示すフローチャートである。 本開示のいくつかの実施形態による、装置を示すブロック図である。 本開示の一実施形態による、端末デバイスを示すブロック図である。 本開示の一実施形態による、基地局を示すブロック図である。 本開示のいくつかの実施形態による、中間ネットワークを介してホストコンピュータに接続された通信ネットワークを示すブロック図である。 本開示のいくつかの実施形態による、部分的無線接続上で基地局を介してＵＥと通信するホストコンピュータを示すブロック図である。 本開示の一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。 本開示の一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。 本開示の一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。 本開示の一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。

添付の図面を参照しながら本開示の実施形態が詳細に説明される。これらの実施形態は、本開示の範囲に対する限定を示唆するのではなく、当業者が、本開示をより良く理解し、したがって実装することを可能にする目的で論じられるにすぎないことを理解されたい。本明細書全体にわたる、特徴、利点、または同様の言い回しへの言及は、本開示とともに実現され得る特徴および利点のすべてが、本開示の単一の実施形態におけるものであるべきであることまたはその実施形態におけるものであることを暗示しない。むしろ、特徴および利点に言及する言い回しは、一実施形態に関して説明される特定の特徴、利点、または特性が、本開示の少なくとも１つの実施形態に含まれることを意味すると理解されたい。さらに、本開示の説明される特徴、利点、および特性は、１つまたは複数の実施形態において任意の好適な様式で組み合わせられ得る。具体的な実施形態の特定の特徴または利点のうちの１つまたは複数なしに本開示が実践され得ることを、当業者は認識されよう。他の事例では、本開示のすべての実施形態に存在するとは限らないことがある追加の特徴および利点が、いくつかの実施形態において認識され得る。

本明細書で使用される「通信ネットワーク」という用語は、新無線（ＮＲ）、ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、ＬＴＥアドバンスト、広帯域符号分割多元接続（ＷＣＤＭＡ）、高速パケットアクセス（ＨＳＰＡ）など、任意の好適な通信規格に従うネットワークを指す。さらに、通信ネットワークにおける端末デバイスとネットワークノードとの間の通信は、限定はしないが、第１世代（１Ｇ）通信プロトコル、第２世代（２Ｇ）通信プロトコル、２．５Ｇ通信プロトコル、２．７５Ｇ通信プロトコル、第３世代（３Ｇ）通信プロトコル、４Ｇ通信プロトコル、４．５Ｇ通信プロトコル、５Ｇ通信プロトコルを含む、任意の好適な世代の通信プロトコル、および／あるいは現在知られているかまたは将来において開発されることになる任意の他のプロトコルに従って実施され得る。

「ネットワークノード」という用語は、通信ネットワークにおけるネットワークデバイスを指し、そのデバイスを介して端末デバイスが通信ネットワークにアクセスし、通信ネットワークからサービスを受信する。ネットワークノードは、無線通信ネットワークにおける基地局（ＢＳ）、アクセスポイント（ＡＰ）、マルチセル／マルチキャスト協調エンティティ（ＭＣＥ）、コントローラまたは任意の他の好適なデバイスを指し得る。ＢＳは、たとえば、ノードＢ（ノードＢまたはＮＢ）、エボルブドノードＢ（ｅノードＢまたはｅＮＢ）、次世代ノードＢ（ｇノードＢまたはｇＮＢ）、リモートラジオユニット（ＲＲＵ）、無線ヘッダ（ＲＨ）、リモート無線ヘッド（ＲＲＨ）、リレー、フェムト、ピコなどの低電力ノードなどであり得る。

ネットワークノードのまたさらなる例は、マルチスタンダード無線（ＭＳＲ）ＢＳなどのＭＳＲ無線機器、無線ネットワークコントローラ（ＲＮＣ）または基地局コントローラ（ＢＳＣ）などのネットワークコントローラ、基地トランシーバ局（ＢＴＳ）、送信ポイント、送信ノード、測位ノードなどを備える。しかしながら、より一般的には、ネットワークノードは、無線通信ネットワークへの端末デバイスアクセスを可能にし、および／または提供し、あるいは、無線通信ネットワークにアクセスした端末デバイスに何らかのサービスを提供することが可能な、そうするように設定された、構成された、および／または動作可能な任意の好適なデバイス（またはデバイスのグループ）を表し得る。

「端末デバイス」という用語は、通信ネットワークにアクセスし、通信ネットワークからサービスを受信することができる任意のエンドデバイスを指す。限定ではなく例として、端末デバイスは、モバイル端末、ユーザ機器（ＵＥ）、または他の好適なデバイスを指し得る。ＵＥは、たとえば、加入者局、ポータブル加入者局、移動局（ＭＳ）またはアクセス端末（ＡＴ）であり得る。端末デバイスは、限定はしないが、ポータブルコンピュータ、デジタルカメラなどの画像キャプチャ端末デバイス、ゲーミング端末デバイス、音楽記憶および再生器具、モバイルフォン、セルラフォン、スマートフォン、タブレット、ウェアラブルデバイス、携帯情報端末（ＰＤＡ）、車両などを含み得る。

また別の特定の例として、モノのインターネット（ＩｏＴ）シナリオでは、端末デバイスは、ＩｏＴデバイスと呼ばれることもあり、監視、検知および／または測定などを実施し、そのような監視、検知および／または測定などの結果を別の端末デバイスおよび／またはネットワーク機器に送信する、マシンまたは他のデバイスを表し得る。端末デバイスは、この場合、マシンツーマシン（Ｍ２Ｍ）デバイスであり得、Ｍ２Ｍデバイスは、第３世代パートナーシッププロジェクト（３ＧＰＰ）コンテキストではマシン型通信（ＭＴＣ）デバイスと呼ばれることがある。

１つの特定の例として、端末デバイスは、３ＧＰＰ狭帯域モノのインターネット（ＮＢ－ＩｏＴ）規格を実装するＵＥであり得る。そのようなマシンまたはデバイスの特定の例は、センサー、電力計などの計量デバイス、産業用機械類、あるいは家庭用または個人用電気器具、たとえば、冷蔵庫、テレビジョン、時計などの個人用ウェアラブルなどである。他のシナリオでは、端末デバイスは、車両または他の機器、たとえば、医療器械を表し得、これは、その動作ステータスに対する監視、検知および／または報告など、あるいはその動作に関連する他の機能が可能である。

本明細書で使用される「第１の」、「第２の」などという用語は、異なるエレメントを指す。単数形「ａ」および「ａｎ」は、コンテキストが別段に明確に示すのでなければ、複数形をも含むものとする。本明細書で使用される「備える、含む（ｃｏｍｐｒｉｓｅｓ）」、「備える、含む（ｃｏｍｐｒｉｓｉｎｇ）」、「有する（ｈａｓ）」、「有する（ｈａｖｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」および／または「含む（ｉｎｃｌｕｄｉｎｇ）」という用語は、述べられた特徴、エレメント、および／または構成要素などの存在を指定するが、１つまたは複数の他の特徴、エレメント、構成要素および／またはそれらの組合せの存在または追加を排除しない。「に基づいて」という用語は、「に少なくとも部分的に基づいて」として読み取られるべきである。「一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ）」および「一実施形態（ａｎ ｅｍｂｏｄｉｍｅｎｔ）」という用語は、「少なくとも１つの実施形態」として読み取られるべきである。「別の実施形態」という用語は、「少なくとも１つの他の実施形態」として読み取られるべきである。明示的および暗黙的な他の定義が、以下で含まれ得る。

無線通信ネットワークは、ボイス、ビデオ、データ、メッセージングおよびブロードキャストなど、様々な通信サービスを提供するために広く展開される。前に説明されたように、無線通信ネットワークにおいてｇＮＢなどのネットワークノードに接続するために、ＵＥなどの端末デバイスは、ネットワークノードとの通信リンク確立のための必須情報およびメッセージを交換するために、ＲＡプロシージャを実施する必要があり得る。

図１Ａは、本開示の一実施形態による、例示的な４ステップＲＡプロシージャを示す図である。図１Ａに示されているように、ＵＥは、１０１において、ｇＮＢから、たとえば、１次同期信号（ＰＳＳ）、２次同期信号（ＳＳＳ）、および物理ブロードキャストチャネル（ＰＢＣＨ）を含む、同期信号（ＳＳ）と物理ブロードキャストチャネルブロック（ＳＳ／ＰＢＣＨブロックまたは略してＳＳＢとしても知られる）とを受信することによって、同期信号を検出することができる。ＵＥは、１０２において、ダウンリンク（ＤＬ）においてブロードキャストされた何らかのシステム情報（たとえば、残余最小システム情報（ＲＭＳＩ）および他のシステム情報（ＯＳＩ））を復号することができる。次いで、ＵＥは、１０３において、アップリンク（ＵＬ）においてＰＲＡＣＨプリアンブル（メッセージ１／ｍｓｇ１）を送信することができる。ｇＮＢは、１０４において、ランダムアクセス応答（ＲＡＲ、メッセージ２／ｍｓｇ２）で返答することができる。ｇＮＢからのＲＡＲに応答して、ＵＥは、１０５において、ＰＵＳＣＨ上でＵＥの識別情報（メッセージ３／ｍｓｇ３）を送信することができる。次いで、ｇＮＢは、１０６において、競合解消メッセージ（ＣＲＭ、メッセージ４／ｍｓｇ４）をＵＥに送ることができる。いくつかの場合には、ＰＲＡＣＨプリアンブル（メッセージ１／ｍｓｇ１）はＵＥによって再び試みられ得、異なるプリアンブルが、初期送信および初期送信の後続の（１つまたは複数の）再送信のために選択され得る。ＰＲＥＡＭＢＬＥ＿ＴＲＡＮＳＭＩＳＳＩＯＮ＿ＣＯＵＮＴＥＲおよびＰＲＥＡＭＢＬＥ＿ＰＯＷＥＲ＿ＲＡＭＰＩＮＧ＿ＣＯＵＮＴＥＲなどのパラメータは、プリアンブルの異なる送信のためにＵＥ側で維持され得る。

図１Ａに示されている例示的なプロシージャでは、ＵＥは、ＲＡＲ中でタイミングアドバンスコマンドを受信した後に、ＰＵＳＣＨ上でメッセージ３／ｍｓｇ３を送信することができ、これは、ＰＵＳＣＨ上のメッセージ３／ｍｓｇ３がサイクリックプレフィックス（ＣＰ）内にタイミング精度で受信されることを可能にする。このタイミングアドバンスがない場合、通信システムがＵＥとｇＮＢとの間の極めて小さい距離をもつセル中で適用されない限り、ＰＵＳＣＨ上のメッセージ３／ｍｓｇ３を復調し、検出することが可能であるために、極めて大きいＣＰが必要とされ得る。ＮＲシステムはまた、ＵＥにタイミングアドバンスコマンドを提供する必要を伴うより大きいセルをサポートすることができるので、４ステップ手法は、ＲＡプロシージャのために必要とされる。

図１Ｂは、本開示の一実施形態による、例示的な２ステップＲＡプロシージャを示す図である。図１Ａに示されているプロシージャと同様に、図１Ｂに示されているプロシージャでは、ＵＥは、２０１において、ｇＮＢから、（たとえば、ＰＳＳ、ＳＳＳおよびＰＢＣＨを含む）ＳＳ／ＰＢＣＨブロックを受信することによって、ＳＳを検出し、２０２において、ＤＬにおいてブロードキャストされた（たとえば、ＲＭＳＩおよびＯＳＩを含む）システム情報を復号することができる。図１Ａに示されている４ステップＲＡプロシージャと比較して、図１Ｂ中のプロシージャを実施するＵＥは、わずか２つのステップにおいてランダムアクセスを完了することができる。第１に、ＵＥは、２０３ａ／２０３ｂにおいて、場合によってはＰＵＳＣＨ上の何らかの小さいペイロードを伴う、無線リソース制御（ＲＲＣ）接続要求などの上位レイヤデータとともにＲＡプリアンブルを含むメッセージＡ（ｍｓｇＡ）をｇＮＢに送る。第２に、ｇＮＢは、２０４において、ＵＥ識別子割り振り、タイミングアドバンス情報、競合解消メッセージなどを含む（メッセージＢまたはｍｓｇＢとも呼ばれる）ＲＡＲをＵＥに送る。さらに、メッセージＢ（ｍｓｇＢ）は、おそらく、ＲＡＲからの別個の送信において送信されることになる、上位レイヤ部分、たとえばＲＲＣメッセージを含んでいることがある。

現今では、ｍｓｇＢの定義は極めて曖昧であり、ｍｓｇＢの定義はＲＡＮ２においてさらなる変更を受け得る。ＲＡＮ２からのこのトピックに関する最新の説明は、ｍｓｇＢがｍｓｇＡに対する応答であり、その応答が、（１つまたは複数の）競合解消メッセージと、ＭＳＧ３送信をスケジュールするための（１つまたは複数の）フォールバック指示と、バックオフ指示とを含んでいることがあることである。したがって、たとえば、４ステップＲＡにおけるｍｓｇ４のコンテンツに対応する、任意の上位レイヤ情報が、（１つまたは複数の）別個のメッセージ中で送信されることになる。しかしながら、ｍｓｇＢのこの「定義」は確かに安定していると見なされ得ないので、本明細書では、本開示の説明に十分に適応される別の定義を使用し得る。しかしながら、ＲＡＮ２からの上記で説明されたｍｓｇＢの定義へのマッピングおよびその変更は、簡単であるべきである。

この目的で、以下のｍｓｇＢ専門用語、すなわち、ｍｓｇＢの最高２つの別個の部分がある、が本明細書で使用され得る。

１）ｍｓｇＡの成功受信（競合解消ＩＤとタイミングアドバンス情報とを含む「成功ＲＡＲ」）を指示するか、または４ステップＲＡへのフォールバック（「フォールバックＲＡＲ」）を指示する、ＭＡＣレイヤ部分（以下で「第１の部分」と呼ばれることがある）、

２）一般にＲＲＣメッセージからなる、上位レイヤ部分（以下で「第２の部分」と呼ばれることがある）。第１の部分が成功ＲＡＲである場合のみ、ｍｓｇＢの第２の部分は送信され、その場合でも、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある場合、第２の部分は省略され得る。

現在、ｍｓｇＢのこれらの２つの部分をどのように送信すべきかについて３ＧＰＰにおいて懸案となっている異なるオプションがある。図２Ａ～図２Ｄは、本開示のいくつかの実施形態による、ＲＡＲを送信するためのいくつかの例示的なフォーマットを示す図である。

図２Ａに示されているように、複数の成功ＲＡＲ／フォールバックＲＡＲ（すなわち、複数の第１の部分）が、１つの第１のＭＡＣ ＰＤＵ中で多重化される。第２の部分（上位レイヤ部分）が送信される場合、第２の部分のうちの１つが、この第１のＭＡＣ ＰＤＵ中に含まれ得るが、残りの第２の部分は、後続の（１つまたは複数の）ＭＡＣ ＰＤＵ中で送信されることができ、各ＭＡＣ ＰＤＵ中には単一の第２の部分のみが含まれ得る（すなわち、同じＭＡＣ ＰＤＵ中の第２の部分の多重化がない）。この場合、多重化された成功ＲＡＲ／フォールバックＲＡＲのための無線ネットワーク一時識別子（ＲＮＴＩ）は、すべてのＵＥについて共通であり得る。これの一例は、ＵＥが、同じＲＡ－ＲＮＴＩ値に対応するＰＲＡＣＨオケージョン上でプリアンブルを送信するときの、４ステップのためのリリース１５（すなわち、Ｒｅｌ－１５）ＲＡ－ＲＮＴＩであろう。

図２Ｂに示されているように、単一の成功ＲＡＲ／フォールバックＲＡＲのみが、第１のスロットまたはＭＡＣ ＰＤＵ中で送信される。第２の部分（上位レイヤ部分）が送信される場合、第２の部分は、独自の、後で送信されるスロットまたはＭＡＣ ＰＤＵ中で別個に送信される。

図２Ｃに示されているように、２つのｍｓｇＢ部分が、単一のＵＥのための単一のＭＡＣ ＰＤＵ中で一緒に送信される。この場合、ＵＥごとの多重化（ｐｅｒ ＵＥ ｍｕｌｔｉｐｌｅｘｉｎｇ）を有効にするために、異なるＵＥのためのＭＡＣ ＰＤＵが異なるＲＮＴＩにアドレス指定されることが好ましい。

図２Ｄに示されているように、ｍｓｇＢ中の複数の成功ＲＡＲ／フォールバックＲＡＲ（すなわち、複数の第１の部分）が、成功ＲＡＲおよび／またはフォールバックＲＡＲの第１の部分のみを含んでいる。第２の部分（上位レイヤ部分）が送信される場合、第２の部分は後続のスロット中でスケジュールされ得る。このフォーマットと図２Ａに示されているフォーマットとの間の違いは、図２Ａでは、ターゲットにされるＵＥのうちの１つの第２の部分（たとえばＲＲＣメッセージ）が第１のＭＡＣ ＰＤＵ中に含まれ得るが、図２Ｄのフォーマットでは、第２の部分が第１のＭＡＣ ＰＤＵ中に含まれることを可能にされない／第１のＭＡＣ ＰＤＵ中に含まれることが可能でないことである。

ＮＲリリース１５では、３ＧＰＰ ＴＳ３８．２１３ Ｖ１５．６．０セクション８．４において、ｍｓｇ４を搬送するＰＤＳＣＨへのＨＡＲＱフィードバックが記述される。

ＵＥがセルＲＮＴＩを提供されなかったとき、ＲＡＲ ＵＬグラントによってスケジュールされたＰＵＳＣＨ送信に応答して、ＵＥは、［ＴＳ３８．３２１において記述されるように］ＵＥ競合解消識別情報を含むＰＤＳＣＨをスケジュールする、対応する一時セルＲＮＴＩ（ＴＣ－ＲＮＴＩ）によってスクランブルされたＣＲＣを伴うＤＣＩフォーマット１＿０を検出することを試みる。ＵＥ競合解消識別情報を伴うＰＤＳＣＨ受信に応答して、ＵＥは、ＰＵＣＣＨ中でＨＡＲＱ－確認応答（ＡＣＫ）情報を送信する。ＰＵＣＣＨ送信は、ＰＵＳＣＨ送信と同じアクティブＵＬ帯域幅部分（ＢＷＰ）内にある。ＰＤＳＣＨ受信の最後のシンボルと、ＨＡＲＱ－ＡＣＫ情報を伴う対応するＰＵＣＣＨ送信の第１のシンボルとの間の最小時間が、Ｎ_Ｔ，１＋０．５ミリ秒に等しい。ここで、Ｎ_Ｔ，１は、追加のＰＤＳＣＨ復調用参照信号（ＤＭ－ＲＳ）が設定されるとき、ＵＥ処理能力１のためのＰＤＳＣＨ受信時間に対応する、［３ＧＰＰ ＴＳ３８．２１４ Ｖ１５．６．０において記述されるような］Ｎ_１シンボルの継続時間である。μ＝０［μは３ＧＰＰ ＴＳ３８．２１１ Ｖ１５．６．０において記述される］の場合、ＵＥは、［ＴＳ３８．２１４において記述されるように］Ｎ_１，０＝１４を仮定する。

３ＧＰＰ ＴＳ３８．２１３ Ｖ１５．６．０において、セクション９．２．１は、専用ＰＵＣＣＨリソースが利用可能でないときのＰＵＣＣＨリソースセット決定について下記のように示す。

図３Ａは、本開示のいくつかの実施形態による、専用ＰＵＣＣＨリソース設定の前の、例示的なＰＵＣＣＨリソースセットである、３ＧＰＰ ＴＳ３８．２１３ Ｖ１５．６．０における表９．２．１－１を示す図である。ＵＥが、ＰＵＣＣＨ－ＣｏｎｆｉｇにおけるＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＳｅｔによって提供される、専用ＰＵＣＣＨリソース設定を有しない場合、ＰＵＣＣＨリソースセットは、

個の物理参照ブロック（ＰＲＢ）の初期ＵＬ ＢＷＰにおけるＰＵＣＣＨ上のＨＡＲＱ－ＡＣＫ情報の送信についての図３Ａの行へのインデックスを通して、情報エレメント（ＩＥ）ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎによって提供される。

は、ＢＷＰにおけるＰＲＢの数、すなわち、ＢＷＰサイズを定義する。ＢＷＰは、１つのＵＥによって使用される帯域の部分である、帯域幅部分の省略である。ＰＵＣＣＨリソースセットは、１６個のリソースを含み、各々が、ＰＵＣＣＨ送信のための、ＰＵＣＣＨフォーマットと、第１のシンボルと、持続時間と、ＰＲＢオフセット

と、巡回シフトインデックスセットとに対応する。ＵＥは、周波数ホッピングを使用してＰＵＣＣＨを送信する。インデックス０をもつ直交カバーコードが、表９．２．１－１におけるＰＵＣＣＨフォーマット１をもつＰＵＣＣＨリソースのために使用される。ＵＥは、サブクローズ８．３において記述されるように、ＲＡＲ ＵＬグラントによってスケジュールされるＰＵＳＣＨ送信の場合と同じ空間領域送信フィルタを使用してＰＵＣＣＨを送信する。

ＩＥ ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎは、３８．３３１ Ｖ１５．６．０において下記のように規定され、セル固有ＰＵＣＣＨパラメータを設定するために使用される。

ＵＥがｐｄｓｃｈ－ＨＡＲＱ－ＡＣＫ－Ｃｏｄｅｂｏｏｋを提供されない場合、ＵＥは、多くとも１つのＨＡＲＱ－ＡＣＫ情報ビットを生成する。

ＵＥが、ＤＣＩフォーマット１＿０またはＤＣＩフォーマット１＿１を検出したことに応答してＰＵＣＣＨ送信中でＨＡＲＱ－ＡＣＫ情報を提供する場合、ＵＥは、インデックスｒ_{ＰＵＣＣＨ}をもつＰＵＣＣＨリソースを決定し、ここで、０≦ｒ_{ＰＵＣＣＨ}≦１５、および

であり、Ｎ_ＣＣＥは、サブクローズ１０．１で記述されるように、ＤＣＩフォーマット１＿０またはＤＣＩフォーマット１＿１をもつＰＤＣＣＨ受信の制御リソースセット（ＣＯＲＥＳＥＴ）における制御チャネルエレメント（ＣＣＥ）の数であり、ｎ_{ＣＣＥ，０}は、ＰＤＣＣＨ受信のための第１のＣＣＥのインデックスであり、Δ_ＰＲＩは、ＤＣＩフォーマット１＿０またはＤＣＩフォーマット１＿１におけるＰＵＣＣＨリソースインジケータフィールドの値である。

である場合（「／」は除算演算を表し、

はフロア値を選出することを表す）、

－ ＵＥは、第１のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として、および、第２のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として決定し、ここでＮ_ＣＳは、初期巡回シフトインデックスのセット中の初期巡回シフトインデックスの総数である。

－ ＵＥは、初期巡回シフトインデックスのセット中の初期巡回シフトインデックスを、ｒ_{ＰＵＣＣＨ} ｍｏｄ Ｎ_ＣＳとして決定する。ここで、「ｍｏｄ」は、モジュロ演算を表す。

である場合、

－ ＵＥは、第１のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として、および、第２のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として決定する。

－ ＵＥは、初期巡回シフトインデックスのセット中の初期巡回シフトインデックスを、（ｒ_{ＰＵＣＣＨ}－８） ｍｏｄ Ｎ_ＣＳとして決定する。

３ＧＰＰ ＴＳ３８．２１３ Ｖ１５．６．０において、セクション９．２．３は、ＰＤＳＣＨから、決定されたＰＵＣＣＨリソースセットへのスロットレベルオフセットについて下記のように示す。

ＤＣＩフォーマット１＿０では、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱタイミングインジケータフィールド値は、｛１、２、３、４、５、６、７、８｝にマッピングする。存在する場合、ＤＣＩフォーマット１＿１では、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱタイミングインジケータフィールド値は、表９．２．３－１において規定されている、ｄｌ－ＤａｔａＴｏＵＬ－ＡＣＫによって提供される、スロットの数のセットのための値にマッピングする。

図３Ｂは、本開示のいくつかの実施形態による、スロットの数へのＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータフィールド値の例示的なマッピングである、３ＧＰＰ ＴＳ３８．２１３ Ｖ１５．６．０における表９．２．３－１を示す図である。

図４Ａは、本開示のいくつかの実施形態による、方法を示すフローチャートを示す。図４Ａに示されている方法４１０は、端末デバイス、または端末デバイスに通信可能に結合された装置によって実施され得る。例示的な実施形態によれば、ＵＥなどの端末デバイスは、たとえば、ＲＡプロシージャ（たとえば、２ステップＲＡプロシージャ）を実施することによって、ｇＮＢなどのネットワークノードに接続するように設定可能であり得る。

図４Ａに示されている例示的な方法４１０によれば、端末デバイスは、ブロック４１２に示されているように、ネットワークノードからリソース設定情報を受信し得る。

いくつかの例示的な実施形態によれば、リソース設定情報は、ブロードキャストメッセージの少なくとも１つのパラメータと、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）の少なくとも１つのパラメータと、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）の少なくとも１つのパラメータと、応答メッセージの少なくとも１つのパラメータとのうちの少なくとも１つを含み得る。

ブロック４１４において、端末デバイスは、受信されたリソース設定情報に基づいて、２ステップランダムアクセスプロシージャにおけるネットワークノードからの応答メッセージへのフィードバックのためのＵＬリソースを決定し得る。フィードバックのためのＵＬリソースは、以下の例示的なやり方によって決定され得る。

アイドル／非アクティブモードにあるユーザのためのＭｓｇＢに応答して、およびＭｓｇＢが少なくとも成功ＲＡＲを含んでいるとき、オプションは、以下を含む。

オプション１：ＭｓｇＢが成功ＲＡＲを含んでいるとき、ＭｓｇＢのためのＨＡＲＱ－ＡＣＫ応答はない。

オプション２：ＭｓｇＢが、１つのＵＥの成功ＲＡＲのみを含んでいるとき、ＨＡＲＱ－ＡＣＫ応答がＭｓｇＢのためにサポートされる。
ａ） ＭｓｇＢが、２つ以上のＵＥの成功ＲＡＲを含んでいる場合、ＭｓｇＢのためのＨＡＲＱ－ＡＣＫ応答はない。
ｂ） 随意に、ＭｓｇＢが、１つのＵＥのみのための成功ＲＡＲと、（１つまたは複数の）他のＵＥのための（１つまたは複数の）フォールバックＲＡＲとを含んでいる場合、ＨＡＲＱ－ＡＣＫ応答がＭｓｇＢのためにサポートされ得る。

オプション３：ＭｓｇＢが、１つまたは複数のＵＥの成功ＲＡＲを含んでいるとき、ＨＡＲＱ－ＡＣＫ応答がＭｓｇＢのためにサポートされる。

オプション４：ＨＡＲＱ－ＡＣＫ応答が、以下を含むことができる。
ａ） ＡＣＫのみ、あるいは
ｂ） ＡＣＫまたは否定応答（ＮＡＣＫ）。

ＨＡＲＱフィードバックリソース決定の詳細に関して、下記は、ＭｓｇＢ中に成功ＲＡＲを伴う各ＵＥについて一意のＰＵＣＣＨリソースを指示するためのいくつかのオプションである。

オプション１／１ａ：ＰＵＣＣＨリソースは、以下に基づいて、ＤＣＩにおける明示的ＰＵＣＣＨリソースシグナリングによって指示され得る。
ａ） オプション１：ＤＣＩ開始ＣＣＥ、または
ｂ） オプション１ａ：再使用される１ビット「ダウンリンク割り振りインデックス（ＤＡＩ）」指示。
第１のＵＥに関して、ＰＵＣＣＨリソースは、ＭｓｇＢをスケジュールするＰＤＣＣＨ（ＰＤＣＣＨ ｓｃｈｅｄｕｌｉｎｇ ＭｓｇＢ）中の、ＰＵＣＣＨリソースインジケータ（ＰＲＩ）およびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータであり得る。
他のＵＥに関して、ＰＵＣＣＨリソースは、ＭｓｇＢをスケジュールするＰＤＣＣＨ中の、ＵＥ ＰＲＩおよび／またはＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータであり得る。
３つの代替設定があり得る。
ｉ． 代替１：ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意である、
ｉｉ． 代替２：ＰＲＩは各ＵＥに一意であり、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータはすべてのＵＥに共通である、または
ｉｉｉ． 代替３：ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意であり、ＰＲＩはすべてのＵＥに共通である。

オプション２／２ａ：ＰＵＣＣＨリソースは、以下に基づいて、ＭｓｇＢ ＰＤＳＣＨにおける明示的ＰＵＣＣＨリソースシグナリングによって指示され得る。
ａ） オプション２：ＤＣＩ開始ＣＣＥ、または
ｂ） オプション２ａ：再使用される１ビット「ＤＡＩ」指示。
第１のＵＥに関して、ＰＵＣＣＨリソースは、ＭｓｇＢをスケジュールするＰＤＣＣＨ中の、ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータであり得る。
他のＵＥに関して、ＰＵＣＣＨリソースは、ＭｓｇＢのＰＤＳＣＨ中の、ＵＥ ＰＲＩおよび／またはＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータであり得る。
３つの代替設定があり得る。
ｉ． 代替１：ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意である、
ｉｉ． 代替２：ＰＲＩは各ＵＥに一意であり、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータはすべてのＵＥに共通である、または
ｉｉｉ． 代替３：ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意であり、ＰＲＩはすべてのＵＥに共通である。

オプション３／３ａ：ＰＵＣＣＨリソースは、以下に基づいて、暗黙的ＰＵＣＣＨリソースシグナリングによって指示され得る。
ａ） オプション３：ＤＣＩ開始ＣＣＥ、または
ｂ） オプション３ａ：再使用される１ビット「ＤＡＩ」指示。
第１のＵＥに関して、ＰＵＣＣＨリソースは、ＰＤＣＣＨ中の、ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータであり得る。
他のＵＥに関して、ＰＵＣＣＨリソースは、ＭＡＣ ＰＤＵ内のＵＥの位置順序に基づく暗黙的導出であり得る。

オプションＮとＮａとの間の違い（Ｎ∈｛１，２，３｝）は、リリース１５の場合のように開始ＣＣＥに基づく１ビット暗黙的指示を使用すべきなのか、１ビットＤＡＩ指示を使用すべきなのかである。他のリソースシグナリングパラメータは、同じままである。

オプション４：ＰＵＣＣＨリソースは、ＤＣＩ開始ＣＣＥに基づいて、ＭｓｇＢ ＰＤＳＣＨにおける暗黙的ＰＵＣＣＨリソースシグナリングによって指示され得る。
ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータおよびＰＲＩは、すべてのＵＥに共通である。
ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}は各ＵＥに一意であり、ｒ_{ＰＵＣＣＨ}は、ＰＲＩと、第１のＣＣＥ（ＤＣＩ開始ＣＣＥ）のインデックスと、成功ＲＡＲ中に含まれるＣ－ＲＮＴＩとに基づいて計算される。複数のＵＥのＰＵＣＣＨリソースインデックスは、Ｃ－ＲＮＴＩによってランダム化される。

いくつかの例示的な実施形態によれば、フィードバックはＨＡＲＱフィードバックを含み得る。

いくつかの例示的な実施形態によれば、応答はＲＡＲであり得る。

いくつかの例示的な実施形態によれば、ＵＬリソースはＰＵＣＣＨリソースであり得る。

ＨＡＲＱフィードバックおよび関連するＰＵＣＣＨリソースは、成功ＲＡＲ／フォールバックＲＡＲ送信のみに関係し、ｍｓｇＢの別個に送信された第２の部分（上位レイヤ部分）を考慮しない。ｍｓｇＢの第２の部分（上位レイヤ部分）が送信される場合、ｍｓｇＢの第２の部分（上位レイヤ部分）に関するＨＡＲＱフィードバックの送信のために使用されるべきＰＵＣＣＨのＰＵＣＣＨ設定情報が、ｍｓｇＢの第２の部分（上位レイヤ部分）に含まれ得るか、または、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定が使用され得、ＨＡＲＱタイミングは、ｍｓｇＢの第２の部分（上位レイヤ部分）のためのＰＤＳＣＨスケジューリング割り当てを含んでいる、ＤＣＩ中で指示され得る。

いくつかの例示的な実施形態によれば、応答メッセージは、図２Ａおよび図２Ｄに示されているように多重化された２つまたはそれ以上の応答を含み得、２つまたはそれ以上の応答は、成功応答とフォールバック応答とのうちの少なくとも１つを含み得る。

ＵＬリソースがＰＵＣＣＨリソースである、いくつかの例示的な実施形態によれば、リソース設定情報は、以下で示されているような、ダウンリンク制御情報（ＤＣＩ）パラメータの少なくとも１つのセット（たとえば、３つのセット）を含み得る。
・ ＰＵＣＣＨリソースインジケータ１、
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ１、
・ ＰＵＣＣＨリソースインジケータ２、
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ２、
・ ＰＵＣＣＨリソースインジケータ３、および
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ３。

上記の例では、ＤＣＩパラメータの第１のセットは、ＰＵＣＣＨリソースインジケータ１とＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ１とを含み得、これは、（「ＵＥ１」と呼ばれる）第１の端末デバイスのために使用される。ＤＣＩパラメータの第２のセットは、ＰＵＣＣＨリソースインジケータ２とＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ２とを含み得、これは、（「ＵＥ２」と呼ばれる）第２の端末デバイスのために使用される。ＤＣＩパラメータの第３のセットは、ＰＵＣＣＨリソースインジケータ３とＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ３とを含み得、これは、（「ＵＥ３」と呼ばれる）第３の端末デバイスのために使用される。それぞれのＵＥは、それらの対応するＤＣＩパラメータを取得することが可能である。この手法は、ＤＣＩパラメータの１つのセットのみがある場合にも適用可能である。

一例では、ＵＥが使用するべきであるＤＣＩ中のＰＵＣＣＨ設定パラメータのセットは、１つまたは複数のパラメータ、たとえばプリアンブルＩＤ、ＰＵＳＣＨ ＲＵ、競合解消ＩＤ、または端末デバイスＩＤから、導出され得る。これらの例では、ＤＣＩ中のＰＵＣＣＨ設定パラメータのセットの量は、ＲＯのために利用可能な２ステッププリアンブルＩＤまたはＰＵＳＣＨ ＲＵの量と同じであり得ることに留意されたい。

いくつかの例示的な実施形態によれば、ＤＣＩパラメータの各セットは、ＤＣＩパラメータのセットの存在を指示するビットに先行され得る。ＤＣＩ中のビットを節約するために、ＰＵＣＣＨ設定パラメータの未使用セット（すなわち、ターゲットにされるＵＥのいずれもそれにマッピングしないもの）が、「ＰＵＣＣＨ設定パラメータの不在セット」を指示するインジケータによって置き換えられ得る。たとえば、ＤＣＩ中のＰＵＣＣＨ設定パラメータの各セットが、「ＰＵＣＣＨ設定パラメータセットが存在すること」または「ＰＵＣＣＨ設定パラメータセットが不在であること」を指示する、１ビットフラグに先行され得る。

いくつかの例示的な実施形態によれば、リソース設定情報は、ＤＣＩパラメータの２つまたはそれ以上のセットを含み得、ＤＣＩパラメータの第１のセット（すなわち、開始位置におけるセット）以外のＤＣＩパラメータのセットの各々は、別の端末デバイスのためのＤＣＩパラメータの前のセットに対するオフセットによって規定され得る。この場合、たとえば、ＤＣＩ中のＵＥ１のためのパラメータの各々に対する、後のＵＥのためのオフセットインジケータ値が導入され得る。この符号化は、ＰＵＣＣＨ設定パラメータの第１のセットのみが完全な値を含んでいなければならないことになるので、ＤＣＩ中で必要とされるビットの数を潜在的に低減することになり、ＰＵＣＣＨ設定パラメータの後続のセットは、代わりに、ＰＵＣＣＨ設定ビットの第１のセット中の対応するパラメータ値に対する、潜在的により多くのビットを節約できる（ｂｉｔ－ｅｃｏｎｏｍｉｃ）オフセット値からなることができる。代替的に、オフセット値は、シグナリングされる代わりに、単にあらかじめ決定され得る。

１つの例示的なフォーマットは、以下に示されているようなものである。
・ ＰＵＣＣＨリソースインジケータ１、
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ１、
・ ＰＵＣＣＨリソースインジケータオフセット１、
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングオフセット１、
・ ＰＵＣＣＨリソースインジケータオフセット２、および
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングオフセット２。

いくつかの例示的な実施形態によれば、２つまたはそれ以上の応答は、それぞれ、２つまたはそれ以上の端末デバイスを対象とし得、リソース設定情報は巡回シフトインデックスのセットを指示し得、巡回シフトインデックスのセットは、１つの物理ダウンリンク共有チャネル上で多重化された２つまたはそれ以上の応答とともに２つまたはそれ以上の端末デバイスによって使用されることが可能であり得る。

一例では、リソース設定情報は、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ ＩＥであり得る。前述のように、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ ＩＥは、表９．２．１－１のインデックスを指示するために使用され得る。図３Ａに示されているように、各インデックスは、巡回シフトインデックスのセットに対応する。２つまたはそれ以上の応答が１つの物理ダウンリンク共有チャネル上で多重化されるとき、巡回シフトインデックスのセットは、２つまたはそれ以上の端末デバイスによって使用されることが可能であり得る。

ＵＥは、ＵＥのそれぞれの情報レコードが成功ＲＡＲ／フォールバックＲＡＲにおいて現れる順序を使用して、ＵＥが、表９．２．１－１のどの列を使用するべきであるかを決定することができる。ＵＥは、成功ＲＡＲ／フォールバックＲＡＲの成功した受信／復号と、決定された成功した競合解消との後にのみＨＡＲＱ ＡＣＫを送信し、さもなければサイレントのままである（すなわち、ＨＡＲＱフィードバックをまったく送信しない）、ＨＡＲＱ原理を使用する。

この例では、表９．２．１－１における異なる巡回シフト（ＣＳ）インデックス値が、異なるＵＥによって使用され得る。

たとえば、（以下に示されている）第１の行が指示されるとき、２つのＣＳ値０および３は、同じｍｓｇＢ上に多重化された２つのＵＥのために使用され得る。

この実施形態の変形形態は、周波数分割多重化される（ＦＤＭされる）かまたはインターレースされる、ＰＵＣＣＨリソースセットを使用することであり得る。

いくつかの例示的な実施形態によれば、端末デバイスは、巡回シフトインデックスのセット中の巡回シフトインデックスの量を、巡回シフトインデックスの量が端末デバイスの量よりも少ない場合、拡張し得る。

巡回シフトインデックスの量が端末デバイスの量よりも少ない場合、修正／拡張されたＰＵＣＣＨリソース表セットが使用され得、これは、複数のＵＥのための別個のＰＵＣＣＨ設定を提供するように、同じ行上に複数のＰＵＣＣＨリソースを指示することができる。

一例では、Ｎ個の列が、追加のＮ個のＵＥのために、時間オフセット値とともに表において導入される。時間オフセットは、スロットレベルおよび／またはシンボルレベルのものであり得る。ここで、Ｎは自然数である。

ＣＳインデックスの量が端末デバイスの量よりも少ない場合、１つのソリューションは、表９．２．１－１における初期ＣＳインデックスのセットを拡張することである。表９．２．１－１における初期ＣＳインデックスのセットについての第１の行を考慮すると、｛０，３｝がある。たとえば、２つのＵＥは２つのグループに対応し、一方はＣＳ値０に関連し、他方はＣＳ値３に関連する。

拡張は、Ｍｓｇ Ａプロパティに基づき得る。たとえば、グループ０が０、２、４に拡張され得、グループ３が１、３、５に拡張され得、これらはＣＳインデックスとＭｓｇ Ａプロパティとの間の１対１マッピングであり得る。

ＵＬリソースがＰＵＣＣＨリソースであり、複数の端末デバイスが複数のＰＵＣＣＨリソース上でフィードバックを送信している、いくつかの例示的な実施形態によれば、２つまたはそれ以上の端末デバイスのフィードバックは、
・ 復調用参照信号、
・ 応答メッセージ中の２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
・ プリアンブル識別子（ＩＤ）、
・ 物理アップリンク共有チャネル（ＰＵＳＣＨ）リソースユニット、
・ 競合解消ＩＤ、および
・ 端末デバイスＩＤ
のうちの少なくとも１つによって識別されることが可能であり得る。

いくつかの例示的な実施形態によれば、２つまたはそれ以上の応答は、それぞれ、２つまたはそれ以上の端末デバイスを対象とし得、２つまたはそれ以上の端末デバイスは、同じＰＵＣＣＨリソース上でフィードバックを送信し得る。

複数の端末デバイスが同じＰＵＣＣＨリソース上でフィードバックを送信する、いくつかの例示的な実施形態によれば、２つまたはそれ以上の端末デバイスのフィードバックは、
・ 異なる復調用参照信号、
・ 応答メッセージ中の２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
・ プリアンブルＩＤ、
・ ＰＵＳＣＨリソースユニット、
・ 競合解消ＩＤ、および
・ 端末デバイスＩＤ
のうちの少なくとも１つによって識別されることが可能であり得る。

たとえば、ＰＵＣＣＨリソースは、ｍｓｇＢの第１の部分の送信、すなわち成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされる各ＵＥが、ＨＡＲＱフィードバック情報を報告するためのそれ自体のＰＵＣＣＨビットを得るように、複数のビットを含んでいるように設定されることになる。したがって、ターゲットにされるＵＥの各々は、ＨＡＲＱフィードバックの送信のために、そのＵＥに専用のＰＵＣＣＨビットのうちの１つを有することになる。たとえば、３つのＵＥが、成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされるとき、これらのＵＥの各々が１つのＰＵＣＣＨビットを使用し、したがって、ＰＵＣＣＨリソースにおいて合計３つのビットを必要とすることになる。これらのビットは、Ｘ、ＹおよびＺと示され得、ここで、ビットＸがＵＥ１のためのものであり、ビットＹがＵＥ２のためのものであり、ビットＺがＵＥ３のためのものである。ここで、「ＰＵＣＣＨビット」は、ＰＵＣＣＨチャネルによって搬送されるビットを意味することに留意されたい。

複数のＵＥが同じＰＵＣＣＨリソース中で送信し得るので、ｇＮＢがそれらのＵＥの相互干渉を抑制することができるように、ＵＥはＰＵＣＣＨを異なって送信するべきである。同じｍｓｇＢ ＰＤＳＣＨのための衝突するＨＡＲＱフィードバック送信を識別するための手法が、ＵＥのＰＵＣＣＨ ＤＭ－ＲＳのための異なるシーケンス初期化を使用することである。そのような場合、ＵＥは、上記で説明されたように、ランダムアクセスプロシージャの始動より前に、ＵＥに知られているＵＥ識別子の関数である初期化値を選択し得る。ｇＮＢは、次いで、ＵＥによって使用されるものを見つけるために各ＰＵＣＣＨを復号するとき、複数のＤＭ－ＲＳシーケンス初期化値を仮定することができる。

この実施形態の１つの変形態では、ＵＥが、成功ＲＡＲ／フォールバックＲＡＲにおける複数のＵＥのそれぞれの情報レコードの包含の順序に基づいて、そのＵＥのＰＵＣＣＨビットを導出する。たとえば、ＵＥの情報レコードが成功ＲＡＲ／フォールバックＲＡＲにおけるＸ番目の情報レコードである場合、ＵＥはＨＡＲＱ ＡＣＫの送信のためにＸ番目のＰＵＣＣＨビットを使用することになる（ただし、ＵＥは、成功ＲＡＲ／フォールバックＲＡＲを成功裡に受信／復号し、競合解消が有利であったと決定しない限り、サイレントのままである）。

一例では、設定されるＰＵＣＣＨビットの数は、動的であり、成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされるＵＥの数に等しくセットされ得る。代替的に、設定されるＰＵＣＣＨビットの数は、静的であり、成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされ得るＵＥの最大数に常に等しくなり得る。

パラメータの組合せが、ＰＵＣＣＨビットを導出するために使用される場合、各可能な組合せは一意のＰＵＣＣＨビットにマッピングするべきであり、したがって、ＰＵＣＣＨビットの数はＲＯのための可能な組合せの数に等しくなるべきである。

ＰＵＣＣＨビットの量は、ＮＡＣＫがサポートされているかどうかに基づいて決定され得る。

一例では、ＨＡＲＱフィードバック原理は、成功ＲＡＲ／フォールバックＲＡＲを成功裡に受信し、競合解消情報から、ＵＥが成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされると結論付けるＵＥのみが、ＨＡＲＱフィードバックを送信する（すなわち、ＨＡＲＱ ＡＣＫを送信する）というものであり得る。他の場合には、ＵＥが成功ＲＡＲ／フォールバックＲＡＲを受信することに失敗するか、または成功ＲＡＲ／フォールバックＲＡＲを受信することに成功するが、成功ＲＡＲ／フォールバックＲＡＲが別のＵＥを対象とすることを競合解消が指示する場合、ＵＥは、（ＵＥはＮＡＣＫを送ることになり、意図された受信側は、実際に成功ＲＡＲ／フォールバックＲＡＲを正しく受信し、同じＰＵＣＣＨビットを使用してＡＣＫを送信する場合）ＰＵＣＣＨ上で衝突を引き起こさないために、および、余分の再送信をトリガしないために、サイレントのままであるか、または、ｇＮＢに、（ＵＥは、成功した受信の後にＡＣＫを送ることになり、意図された受信側は、実際に成功ＲＡＲ／フォールバックＲＡＲを受信することに失敗した場合）さらなる再送信が必要とされないことを間違って指示する。

代替的に、別の例では、ＰＤＳＣＨ送信を正しく受信および復号することに失敗するＵＥは、ｇＮＢへのＨＡＲＱフィードバックとして、明示的ＮＡＣＫ指示を提供し得る。他のＨＡＲＱフィードバック原理の動機となる、上記で説明された問題は、したがって、ＨＡＲＱフィードバック中にＵＥ ＩＤを含めることまたは上位レイヤに衝突を検出および補償させることなど、他の手段を通して扱われる。明示的ＡＣＫの不在のみに依拠する代わりに、明示的ＮＡＣＫ指示を提供することは、よりリッチなフィードバック情報を提供することの利益を有し、ｇＮＢは、このことをその再送信において考慮に入れ得る。

いくつかの例示的な実施形態によれば、応答メッセージは、１つの成功応答またはフォールバック応答を含み得、リソース設定情報は、
・ 少なくとも１つのＤＣＩパラメータ、および
・ ブロードキャストメッセージの少なくとも１つのパラメータ
のうちの少なくとも１つを含み得る。

たとえば、リソース設定情報は、以下のオプション、
・ （ａ）ＰＵＣＣＨリソースインジケータおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ、
・ （ｂ）ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータおよびｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定、
・ （ｃ）ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ情報エレメント、ならびに
・ （ｄ）応答ウィンドウサイズおよびシステムフレーム番号
のうちの少なくとも１つを含み得る。

オプション（ａ）に関して、ｍｓｇＢ－ＲＮＴＩアドレス指定ＤＣＩは、それぞれスロットおよびスロットレベルリソース内でＰＵＣＣＨリソースを指示するために、以下のパラメータのうちの１つまたは複数を含み得る。下記は、２つの例示的なパラメータである。
・ ＰＵＣＣＨリソースインジケータ、および
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ。

オプション（ｂ）に関して、ｍｓｇＢ－ＲＮＴＩアドレス指定ＤＣＩは、スロットレベルリソースを決定するために以下の１つのパラメータのみを含み、スロット内でリソースを決定するためにｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定を使用し得る。下記は、１つの例示的なパラメータである。
・ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ。

いくつかの実施形態では、ＰＤＳＣＨ送信を正しく受信および復号することに失敗するＵＥは、ｇＮＢへのＨＡＲＱフィードバックとして、明示的ＮＡＣＫ指示を提供する。潜在的ＨＡＲＱフィードバック衝突問題は、したがって、ＨＡＲＱフィードバック中にＵＥ ＩＤを含めることまたは上位レイヤに衝突を検出および補償させることなど、手段を通して扱われることになる。明示的ＡＣＫの不在のみに依拠する代わりに、明示的ＮＡＣＫ指示を提供することは、よりリッチなフィードバック情報を提供することの利益を有し、ｇＮＢは、このことをその再送信において考慮に入れ得る。

ＵＥが、ｍｓｇＢを搬送するＰＤＳＣＨを復号しないとき、ＵＥは、ｍｓｇＢ中で搬送されるタイミングアドバンスの値を決定することができない。したがって、そのようなＵＥは、ＨＡＲＱフィードバックを送信するための正確なタイミングアドバンス値を有しないことがある。これは、ｍｓｇＢのためのＨＡＲＱフィードバックを搬送するＰＵＣＣＨまたはＰＵＳＣＨが、他のＰＵＣＣＨまたはＰＵＳＣＨと衝突し得ることを暗示する。そのような場合、他のＰＵＣＣＨまたはＰＵＳＣＨリソースから十分に分離された、ｍｓｇＢ ＨＡＲＱフィードバックのための異なる時間および周波数リソースを割り当てることが、衝突を緩和するために使用され得る。

したがって、一実施形態では、ＵＥは、ランダムアクセス応答を搬送するＰＤＳＣＨに応答して、物理チャネルにおいてＨＡＲＱフィードバックを送信し、ここで、ＨＡＲＱフィードバックは、肯定応答（ＡＣＫ）または否定応答（ＮＡＣＫ）のいずれかを指示することができる。

オプション（ｃ）に関して、ＤＣＩパラメータは使用されない。共通パラメータが、ＰＵＣＣＨリソースのスロットレベル指示とシンボルレベル指示の両方について、すべてのＵＥのために規定される。共通パラメータは、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ ＩＥに対する拡張として、たとえばｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ－ｒ１６と呼ばれるＩＥにおいて、たとえばリリース１６＋固有の拡張の形式で、実現され得る。

オプション（ｄ）に関して、監視されるｍｓｇＢのための拡張されたＲＡＲウィンドウに対処するために、およびＡＣＫとＮＡＣＫの両方を可能にするために、ＵＥがプリアンブルを送信したシステムフレームのための少なくともシステムフレーム番号（ＳＦＮ）が、直交ＰＵＣＣＨリソースを指示するために使用され得る。ＲＡＲウィンドウがどのくらい大きく拡張されるかに応じて、ＵＥは、自律的にＰＵＣＣＨリソースインデックスを選択し得る。

一例として、これは、下記のいずれかを通して行われ得る。
ＰＵＣＣＨリソースインジケータ＝ＳＦＮ ｍｏｄ ＲＡＲｗｉｎｄｏｗＥｘｔｅｎｓｉｏｎＦａｃｔｏｒ、または、
ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ＝ＳＦＮ ｍｏｄ ＲＡＲｗｉｎｄｏｗＥｘｔｅｎｓｉｏｎＦａｃｔｏｒ、

ここで、ＲＡＲｗｉｎｄｏｗＥｘｔｅｎｓｉｏｎＦａｃｔｏｒは、ＲＡＲウィンドウがそれによってｍｓｇＢウィンドウに拡張される、ファクタである。

いくつかの例示的な実施形態によれば、ＨＡＲＱ ＡＣＫが予想される場合、１つのＵＥのみが１つの成功ＲＡＲ／フォールバックＲＡＲにおいてターゲットにされ得ることが必要とされ、他の場合、ＨＡＲＱフィードバックは可能にされない。成功ＲＡＲ／フォールバックＲＡＲが単一のＵＥをターゲットにするのか複数のＵＥをターゲットにするのかが、成功ＲＡＲ／フォールバックＲＡＲのためのＤＬスケジューリング割り当てを伝達するＤＣＩ中で、または成功ＲＡＲ／フォールバックＲＡＲ中のヘッダ情報中で指示され得るか、あるいは、ＵＥは、成功ＲＡＲ／フォールバックＲＡＲ中に含まれる情報レコードをパースする（たとえば、（別のＵＥのための）別の情報レコードが続くか否かを指示する付録ビットを見る）とき、それを発見し得る。ＵＥが成功ＲＡＲ／フォールバックＲＡＲ中で情報を見つける代替形態が機能するために、ＵＥは、ＵＥが、成功ＲＡＲ／フォールバックＲＡＲの成功した受信／復号と、決定された成功した競合解消との後にのみＨＡＲＱ ＡＣＫを送信し、さもなければ、サイレントのままである（すなわち、ＨＡＲＱフィードバックをまったく送信しない）、ＨＡＲＱフィードバック原理を使用するべきであることに留意されたい。システム情報を介した静的設定も使用され得、または、静的設定は標準仕様によって決定されることさえある。

いくつかの例示的な実施形態によれば、ＵＬリソースはＰＵＳＣＨリソースであり得る。

一例では、成功ＲＡＲ／フォールバックＲＡＲに関するＨＡＲＱフィードバックは、ＰＵＣＣＨリソースの代わりにＰＵＳＣＨリソース上で送信され得、ここで、ＰＵＳＣＨリソースは、成功ＲＡＲ／フォールバックＲＡＲのためのスケジューリング割り当てを含んでいるＰＤＣＣＨ ＤＣＩ中で、または、上記で提供された同様の方法を用いて、成功ＲＡＲ／フォールバックＲＡＲ自体中で（すなわち、ＰＤＳＣＨ送信中で）許可され得る。

スケジューリング情報が成功ＲＡＲ／フォールバックＲＡＲ中で搬送される場合、多重化された成功ＲＡＲ／フォールバックＲＡＲのための共通ヘッダが使用され得る。スケジューリング情報は、リソースと、ＰＵＳＣＨリソース内のどの部分（ビット）が各個々の成功ＲＡＲ／フォールバックＲＡＲへのフィードバックのために使用されるべきであるかの指示との両方を含んでいる。

この例では、ＨＡＲＱフィードバックは、許可されたこのＰＵＳＣＨリソースによる、いくらかの量（一般に少量）の瞬時データ送信を可能にしながら、提供され得る。

一例では、ＰＵＳＣＨは、ｍｓｇＡ ＰＵＳＣＨの再送信であり得る。

一例では、ｍｓｇＢは、単一の成功ＲＡＲ／フォールバックＲＡＲを含んでいるものとして、ｍｓｇＢを搬送するＰＤＳＣＨを識別するＲＮＴＩを含んでいるＰＤＣＣＨによってスケジュールされ得る。ＲＮＴＩは、たとえば、セルＲＮＴＩ、あるいは、対応するｍｓｇＡまたはｍｓｇＢ ＲＮＴＩ中で搬送されたＵＥ ＩＤを使用するＲＮＴＩであり得る。この場合、ＨＡＲＱフィードバックが送信されるべきであるシンボルに対応するＵＬグラントが与えられる場合、ＵＥは、ＰＵＳＣＨ上でＵＣＩを搬送するＲｅｌ－１５プロシージャに従って、ＰＵＳＣＨ中でＨＡＲＱフィードバックを送信することになる。ＵＥはＰＤＣＣＨ中でグラントを受信するので、ＵＥは、ＵＥがＰＤＳＣＨを復号するまたは復号しないとき、ＡＣＫまたはＮＡＣＫのいずれかを送信し得る。

ＨＡＲＱのためのＰＵＳＣＨリソースがＰＤＳＣＨにおいて与えられる場合、ＨＡＲＱフィードバックのためのＰＵＳＣＨリソースを決定するために、ＰＤＳＣＨの成功した復号が必要とされ、したがって、ＵＥは、ＰＤＳＣＨからＮＡＣＫを搬送することになるリソースを決定することができないので、ＮＡＣＫを送信しないことがある。したがって、ＵＥは、ＨＡＲＱのためのＰＵＳＣＨリソースがＰＤＳＣＨにおいて与えられるとき、ＡＣＫを送信するか、またはＨＡＲＱフィードバックを送信しない。ＡＣＫのみが送信されるこれらの事例では、ｍｓｇＢが複数の成功ＲＡＲ／フォールバックＲＡＲを含んでおり、各々がＰＵＳＣＨ上で使用されるべきＨＡＲＱフィードバックリソースを識別するとき、ＲＡＲによってアドレス指定されたすべてのＵＥが、ＨＡＲＱフィードバックリソース割り当てを成功裡に復号したことになり、したがって、これらのＵＥは、それらの対応するＲＡＲが単一のＰＤＳＣＨに多重化されるとき、そのＲＡＲのための異なるＰＵＳＣＨリソース上でＨＡＲＱフィードバックを指示することができる。

図４Ｂは、本開示のいくつかの実施形態による、図４Ａに示されている方法のさらなるステップを示すフローチャートである。ブロック４１６において、端末デバイスは、決定されたＵＬリソース上でフィードバックを送信し得る。

図５Ａは、本開示のいくつかの実施形態による、方法５１０を示すフローチャートである。図５Ａに示されている方法５１０は、ネットワークノード、またはネットワークノードに通信可能に結合された装置によって実施され得る。例示的な実施形態によれば、ネットワークノードは、ｇＮＢなどの基地局を備え得る。ネットワークノードは、ＲＡプロシージャ（たとえば、２ステップＲＡプロシージャ）を実施することによってネットワークノードに接続することができるＵＥなど、１つまたは複数の端末デバイスと通信するように設定可能であり得る。

図５Ａに示されている例示的な方法５１０によれば、ネットワークノードは、ブロック５１２において、リソース設定情報を決定し得る。リソース設定情報は、２ステップランダムアクセスプロシージャにおける応答メッセージへの端末デバイスのフィードバックのためのＵＬリソースを指示し得る。ブロック５１４において、ネットワークノードは、リソース設定情報を端末デバイスに送信し得る。

図５Ｂは、本開示のいくつかの実施形態による、図５Ａに示されている方法のさらなるステップを示すフローチャートを示す。

ブロック５１６において、ネットワークノードは、端末デバイスによって決定されるＵＬリソース上でフィードバックを受信し得る。

図６Ａは、本開示の様々な実施形態による、装置６００を示すブロック図である。図６Ａに示されているように、装置６００は、プロセッサ６０１などの１つまたは複数のプロセッサと、コンピュータプログラムコード６０３を記憶するメモリ６０２などの１つまたは複数のメモリとを備え得る。メモリ６０２は、非一時的機械／プロセッサ／コンピュータ可読記憶媒体であり得る。いくつかの例示的な実施形態によれば、装置６００は、図４Ａまたは図５Ａに関して説明される端末デバイス、あるいは図４Ｂまたは図５Ｂに関して説明されるネットワークノードに、プラグ接続されまたは取り付けられ得る集積回路チップまたはモジュールとして実装され得る。そのような場合、装置６００は、図４Ａまたは図５Ａに関して説明される端末デバイス、あるいは図４Ｂまたは図５Ｂに関して説明されるネットワークノードとして実装され得る。

いくつかの実装形態では、１つまたは複数のメモリ６０２およびコンピュータプログラムコード６０３は、１つまたは複数のプロセッサ６０１とともに、装置６００に、少なくとも、図４Ａまたは図５Ａに関して説明されるような方法の任意の動作を実施させるように設定され得る。他の実装形態では、１つまたは複数のメモリ６０２およびコンピュータプログラムコード６０３は、１つまたは複数のプロセッサ６０１とともに、装置６００に、少なくとも、図４Ｂまたは図５Ｂに関して説明されるような方法の任意の動作を実施させるように設定され得る。代替または追加として、１つまたは複数のメモリ６０２およびコンピュータプログラムコード６０３は、１つまたは複数のプロセッサ６０１とともに、装置６００に、少なくとも、本開示の例示的な実施形態による提案される方法を実装するためにより多いまたはより少ない動作を実施させるように設定され得る。

本開示の様々な実施形態が、ランダムアクセスのための装置を提供する。例示的な実施形態では、装置は、ＵＥなどの端末デバイスにおいて実装され得る。図６Ｂは、本開示の一実施形態による、端末デバイスを示すブロック図である。図示のように、端末デバイス６００ｂは、受信ユニット６０２ｂと決定ユニット６０４ｂとを備える。受信ユニット６０２ｂは、ブロック４１２における動作を行うように動作可能であり得、決定ユニット６０４ｂは、ブロック４１４における動作を行うように動作可能であり得る。場合によっては、決定ユニット６０４ｂおよび／または受信ユニット６０２ｂは、本開示の例示的な実施形態による提案される方法を実装するためにより多いまたはより少ない動作を行うように動作可能であり得る。

本開示の様々な実施形態が、ランダムアクセスのための装置を提供する。例示的な実施形態では、装置は、基地局などのネットワークノードにおいて実装され得る。図６Ｃは、本開示の一実施形態による、基地局を示すブロック図である。図示のように、基地局６００ｃは、決定ユニット６０２ｃと送信ユニット６０４ｃとを備える。決定ユニット６０２ｃは、ブロック５１２における動作を行うように動作可能であり得、送信ユニット６０４ｃは、ブロック５１４における動作を行うように動作可能であり得る。場合によっては、受信ユニット６０２ｃおよび／または送信ユニット６０４ｃは、本開示の例示的な実施形態による提案される方法を実装するためにより多いまたはより少ない動作を行うように動作可能であり得る。

以下は、本開示の実施形態のいくつかのさらなる詳細であり得る。

ＮＲにおける４ステップＲＡプロシージャ
４ステップ手法が、ランダムアクセスプロシージャのために使用される。図１Ａを参照されたい。この手法では、ＵＥは、同期信号（ＳＳ）を検出し、ブロードキャストされたシステム情報を復号し、その後に、アップリンクにおいてＰＲＡＣＨプリアンブル（メッセージ１）を送信する。ｇＮＢは、ＲＡＲ（ランダムアクセス応答、メッセージ２）で返答する。ＵＥは、次いで、ＰＵＳＣＨ上でＵＥ識別情報（メッセージ３）を送信する。

ＵＥは、ＲＡＲ中でタイミングアドバンスコマンドを受信した後にＰＵＳＣＨ（メッセージ３）を送信し、これは、ＰＵＳＣＨがサイクリックプレフィックス内にタイミング精度で受信されることを可能にする。このタイミングアドバンスがない場合、システムがＵＥとｅＮＢとの間の極めて小さい距離をもつセル中で適用されない限り、ＰＵＳＣＨを復調し、検出することが可能であるために、極めて大きいＣＰが必要とされるであろう。ＮＲはまた、ＵＥにタイミングアドバンスを提供する必要を伴うより大きいセルをサポートするので、４ステップ手法は、ランダムアクセスプロシージャのために必要とされる。

３ＧＰＰにおけるリリース１６のための２ステップＲＡＣＨワークアイテム
２ステップＲＡＣＨワークアイテムが、ＲＡＮ１＃８２総会［１］において承認された。

図１Ｂに示されているような、２つのステップのみにおいて初期アクセスを完了すること。
－ ステップ１：ＵＥは、場合によってはＰＵＳＣＨ上の何らかの小さいペイロードを伴う、ＲＲＣ接続要求などの上位レイヤデータとともにランダムアクセスプリアンブルを含むメッセージＡを送る。
－ ステップ２：ｇＮＢは、ＵＥ識別子割り振り、タイミングアドバンス情報、および競合解消メッセージなどを含む（実際はメッセージＢと呼ばれる）ＲＡＲを送る。さらに、メッセージＢ（ｍｓｇＢ）は、おそらく、ＲＡＲからの別個の送信（下記参照）において送信されることになる、上位レイヤ部分、たとえばＲＲＣメッセージを含んでいることがある。

ｍｓｇＢの定義は極めて曖昧であり、ｍｓｇＢの定義はＲＡＮ２においてさらなる変更を受け得る。ＲＡＮ２からのこのトピックに関する現在の最新の言葉は、ｍｓｇＢがｍｓｇＡに対する応答であり、その応答が、（１つまたは複数の）競合解消メッセージと、ＭＳＧ３送信をスケジュールするための（１つまたは複数の）フォールバック指示と、バックオフ指示とを含んでいることがあることである。したがって、たとえば、４ステップＲＡにおけるｍｓｇ４のコンテンツに対応する、任意の上位レイヤ情報が、（１つまたは複数の）別個のメッセージ中で送信されることになる。しかしながら、このｍｓｇＢ「定義」は確かに安定していると見なされ得ないので、本明細書では、本発明の説明に十分に適応される別の定義を使用することを選定した。しかしながら、上記で説明されたＲＡＮ２ ｍｓｇＢ定義へのマッピングおよびその変更は、簡単であるべきである。

この目的で、以下のｍｓｇＢ専門用語を選定しており、すなわち、ｍｓｇＢの最高２つの別個の部分がある。

１） ｍｓｇＡ受信の成功（競合解消ＩＤとタイミングアドバンス情報とを含む「成功ＲＡＲ」）を指示するか、または４ステップＲＡへのフォールバック（「フォールバックＲＡＲ」）を指示する、ＭＡＣレイヤ部分、

２） 一般にＲＲＣメッセージからなる、上位レイヤ部分。第１の部分が成功ＲＡＲである場合のみ、ｍｓｇＢの第２の部分は送信され、その場合でも、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある場合、第２の部分は省略され得る。

現在、ｍｓｇＢのこれらの２つの部分をどのように送信すべきかについて３ＧＰＰにおいて懸案となっている異なるオプションがある。

Ａ：複数の成功ＲＡＲ／フォールバックＲＡＲ（すなわち複数の部分１）が、１つの第１のＭＡＣ ＰＤＵ中で多重化される。第２の部分（上位レイヤ部分）が送信される場合、第２の部分のうちの１つが、この第１のＭＡＣ ＰＤＵ中に含まれ得るが、残りの第２の部分は、後続の（１つまたは複数の）ＭＡＣ ＰＤＵ中で送信され、各ＭＡＣ ＰＤＵ中に単一の部分２がある（すなわち、同じＭＡＣ ＰＤＵ中の部分２の多重化がない）。一例が図２Ａに示されている。この場合、多重化された成功ＲＡＲ／フォールバックＲＡＲのためのＲＮＴＩは、すべてのＵＥについて共通である。これの一例は、ＵＥが、同じＲＡ－ＲＮＴＩ値に対応するＰＲＡＣＨオケージョン上でプリアンブルを送信するときの、４ステップのためのＲｅｌ１５ ＲＡ－ＲＮＴＩであろう。

Ｂ：単一の成功ＲＡＲ／フォールバックＲＡＲのみが、第１のＭＡＣ ＰＤＵ中で送信される。第２の部分（上位レイヤ部分）が送信される場合、第２の部分は、それ自体の、後で送信されるＭＡＣ ＰＤＵ中で別個に送信される。これは、図２Ｂに示されている。

Ｃ：２つのｍｓｇＢ部分が、単一のＵＥのための単一のＭＡＣ ＰＤＵ中で一緒に送信される。これは、図２Ｃに示されている。この場合、ＵＥごとの多重化を有効にするために、異なるＵＥのためのＭＡＣ ＰＤＵが異なるＲＮＴＩにアドレス指定されることが好ましい。

Ｄ：ｍｓｇＢ中の複数の成功ＲＡＲ／フォールバックＲＡＲ（すなわち、複数の部分１）が、競合解消成功ＲＡＲおよび／またはフォールバックＲＡＲのための第１の部分のみを含んでおり、ここで、第２の部分、たとえば、ＳＲＢ ＲＲＣメッセージが、後続のスロット中でスケジュールされた、成功の場合のみのためのものである。このオプションとオプションＡとの間の違いは、オプションＡでは、ターゲットにされるＵＥのうちの１つの部分２（たとえばＲＲＣメッセージ）が第１のＭＡＣ ＰＤＵ中に含まれ得るが、これは、このオプションでは（すなわちオプションＤでは）可能にされない／可能でないことである。

ＮＲリリース１５におけるＨＡＲＱフィードバック
アップリンクリソース決定
ＮＲリリース１５では、３ＧＰＰ ＴＳ３８．２１３セクション８．４において、ｍｓｇ４を搬送するＰＤＳＣＨへのＨＡＲＱフィードバックが下記のように記述される。

ＵＥがＣ－ＲＮＴＩを提供されなかったとき、ＲＡＲ ＵＬグラントによってスケジュールされたＰＵＳＣＨ送信に応答して、ＵＥは、ＵＥ競合解消識別情報を含むＰＤＳＣＨをスケジュールする、対応するＴＣ－ＲＮＴＩによってスクランブルされたＣＲＣを伴うＤＣＩフォーマット１＿０を検出することを試みる［１１、ＴＳ３８．３２１］。ＵＥ競合解消識別情報を伴うＰＤＳＣＨ受信に応答して、ＵＥは、ＰＵＣＣＨ中でＨＡＲＱ－ＡＣＫ情報を送信する。ＰＵＣＣＨ送信は、ＰＵＳＣＨ送信と同じアクティブＵＬ ＢＷＰ内にある。ＰＤＳＣＨ受信の最後のシンボルと、ＨＡＲＱ－ＡＣＫ情報を伴う対応するＰＵＣＣＨ送信の第１のシンボルとの間の最小時間が、Ｎ_Ｔ，１＋０．５ミリ秒に等しい。Ｎ_Ｔ，１は、追加のＰＤＳＣＨ ＤＭ－ＲＳが設定されるとき、ＵＥ処理能力１のためのＰＤＳＣＨ受信時間に対応する、Ｎ_１シンボルの継続時間である。μ＝０の場合、ＵＥは、Ｎ_１，０＝１４であると仮定する［６、ＴＳ３８．２１４］。

３ＧＰＰ ＴＳ３８．２１３ Ｖ１５．６．０において、セクション９．２．１は、専用ＰＵＣＣＨリソースが利用可能でないときのＰＵＣＣＨリソースセット決定について下記のように示す。

－－－－－－－－－－－－－－－－－－－－－－

ＵＥが、ＰＵＣＣＨ－ＣｏｎｆｉｇにおけるＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＳｅｔによって提供される、専用ＰＵＣＣＨリソース設定を有しない場合、ＰＵＣＣＨリソースセットは、

個のＰＲＢの初期ＵＬ ＢＷＰにおけるＰＵＣＣＨ上のＨＡＲＱ－ＡＣＫ情報の送信についての表９．２．１－１の行へのインデックスを通して、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎによって提供される。ＰＵＣＣＨリソースセットは、１６個のリソースを含み、各々が、ＰＵＣＣＨ送信のための、ＰＵＣＣＨフォーマットと、第１のシンボルと、持続時間と、ＰＲＢオフセット

と、巡回シフトインデックスセットとに対応する。ＵＥは、周波数ホッピングを使用してＰＵＣＣＨを送信する。インデックス０をもつ直交カバーコードが、表９．２．１－１におけるＰＵＣＣＨフォーマット１をもつＰＵＣＣＨリソースのために使用される。ＵＥは、サブクローズ８．３において記述されるように、ＲＡＲ ＵＬグラントによってスケジュールされるＰＵＳＣＨ送信の場合と同じ空間領域送信フィルタを使用してＰＵＣＣＨを送信する。

ＵＥがｐｄｓｃｈ－ＨＡＲＱ－ＡＣＫ－Ｃｏｄｅｂｏｏｋを提供されない場合、ＵＥは、多くとも１つのＨＡＲＱ－ＡＣＫ情報ビットを生成する。

ＵＥが、ＤＣＩフォーマット１＿０またはＤＣＩフォーマット１＿１を検出したことに応答してＰＵＣＣＨ送信中でＨＡＲＱ－ＡＣＫ情報を提供する場合、ＵＥは、インデックスｒ_{ＰＵＣＣＨ}、０≦ｒ_{ＰＵＣＣＨ}≦１５、をもつＰＵＣＣＨリソースを、

として決定し、ここで、Ｎ_ＣＣＥは、サブクローズ１０．１で記述されるように、ＤＣＩフォーマット１＿０またはＤＣＩフォーマット１＿１をもつＰＤＣＣＨ受信のＣＯＲＥＳＥＴにおけるＣＣＥの数であり、ｎ_{ＣＣＥ，０}は、ＰＤＣＣＨ受信のための第１のＣＣＥのインデックスであり、Δ_ＰＲＩは、ＤＣＩフォーマット１＿０またはＤＣＩフォーマット１＿１におけるＰＵＣＣＨリソースインジケータフィールドの値である。

である場合

－ ＵＥは、第１のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として、および、第２のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として決定し、ここでＮ_ＣＳは、初期巡回シフトインデックスのセット中の初期巡回シフトインデックスの総数である

－ ＵＥは、初期巡回シフトインデックスのセット中の初期巡回シフトインデックスを、ｒ_{ＰＵＣＣＨ} ｍｏｄ Ｎ_ＣＳとして決定する

である場合

－ ＵＥは、第１のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として、および、第２のホップにおけるＰＵＣＣＨ送信のＰＲＢインデックスを

として決定する

－ ＵＥは、初期巡回シフトインデックスのセット中の初期巡回シフトインデックスを、（ｒ_{ＰＵＣＣＨ}－８） ｍｏｄ Ｎ_ＣＳとして決定する

ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎは、３８．３３１ Ｖ１５．６．０において下記のように規定される。
ＰＵＣＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎ
ＩＥ ＰＵＣＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎは、セル固有ＰＵＣＣＨパラメータを設定するために使用される。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－３ＧＰＰ ＴＳ３８．２１３ Ｖ１５．６．０において、セクション９．２．３は、ＰＤＳＣＨから、決定されたＰＵＣＣＨリソースセットへのスロットレベルオフセットについて下記のように示す。

ＤＣＩフォーマット１＿０では、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱタイミングインジケータフィールド値は、｛１、２、３、４、５、６、７、８｝にマッピングする。存在する場合、ＤＣＩフォーマット１＿１では、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱタイミングインジケータフィールド値は、表９．２．３－１において規定されている、ｄｌ－ＤａｔａＴｏＵＬ－ＡＣＫによって提供される、スロットの数のセットのための値にマッピングする。

ｍｓｇＢのＨＡＲＱフィードバック
ＲＡＮ１＃９８では、ＭｓｇＢのＨＡＲＱ－ＡＣＫフィードバックに関する様々なオプションが議論された。

さらなる検討 以下を含む、アイドル／非アクティブモードにあるユーザのためのＭｓｇＢに応答した、およびＭｓｇＢが少なくとも成功ＲＡＲを含んでいるときの、ＨＡＲＱ－ＡＣＫオプション。
－ オプション１：成功ＲＡＲを含んでいるとき、ＭｓｇＢのためのＨＡＲＱ－ＡＣＫ応答はない。
－ オプション２：ＭｓｇＢが、１つのＵＥの成功ＲＡＲのみを含んでいるとき、ＨＡＲＱ－ＡＣＫ応答がＭｓｇＢのためにサポートされる
〇 ＭｓｇＢが、２つ以上のＵＥの成功ＲＡＲを含んでいる場合、ＭｓｇＢのためのＨＡＲＱ－ＡＣＫ応答はない
〇 ＦＦＳ：ＭｓｇＢが１つのＵＥのみのための成功ＲＡＲと他のＵＥのためのフォールバックとを含んでいる場合。
－ オプション３：ＭｓｇＢが、１つまたは複数のＵＥの成功ＲＡＲを含んでいるとき、ＨＡＲＱ－ＡＣＫ応答がＭｓｇＢのためにサポートされる
－ ＦＦＳ：ＨＡＲＱ－ＡＣＫ応答が、以下を含むことができる。
〇 代替１：ＡＣＫのみ
〇 代替２：ＡＣＫまたはＮＡＣＫ。

ＲＡＮ１リフレクタ（ｒｅｆｌｅｃｔｏｒ）の後半に、ｍｓｇＢ ＨＡＲＱフィードバック、ＨＡＲＱフィードバックリソース決定の詳細、ソフトコンバイニングを用いた／用いないｍｓｇＢ再送信がさらに検討される必要があるかどうかに関するメール議論が進行中である。リストされた以下のオプションを参照されたい。
ＭｓｇＢ中に成功ＲＡＲを伴う各ＵＥについて一意のＰＵＣＣＨリソースをどのように指示すべきか？
－ オプション１／１ａ：以下に基づく、ＤＣＩにおける明示的ＰＵＣＣＨリソースシグナリング。
○ オプション１：ＤＣＩ開始ＣＣＥ
○ オプション１ａ：再使用１ビット「ＤＡＩ」指示
○ 第１のＵＥ：ＭｓｇＢをスケジュールするＰＤＣＣＨ中の、ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ
○ 他のＵＥ：ＭｓｇＢをスケジュールするＰＤＣＣＨ中の、ＵＥ ＰＲＩおよび／またはＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ
・ 代替１：ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意である。
・ 代替２：ＰＲＩは各ＵＥに一意であり、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータはすべてのＵＥに共通である。
・ 代替３：ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意であり、ＰＲＩはすべてのＵＥに共通である。
－ オプション２／２ａ：以下に基づく、ＭｓｇＢ ＰＤＳＣＨにおける明示的ＰＵＣＣＨリソースシグナリング。
○ オプション２：ＤＣＩ開始ＣＣＥ
○ オプション２ａ：再使用１ビット「ＤＡＩ」指示
○ 第１のＵＥ：ＭｓｇＢをスケジュールするＰＤＣＣＨ中の、ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ
○ 他のＵＥ：ＭｓｇＢのＰＤＳＣＨ中の、ＵＥ ＰＲＩおよび／またはＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ
・ 代替１：ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意である。
・ 代替２：ＰＲＩは各ＵＥに一意であり、ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータはすべてのＵＥに共通である。
・ 代替３：ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータは各ＵＥに一意であり、ＰＲＩはすべてのＵＥに共通である。
－ オプション３／３ａ：以下に基づく、暗黙的ＰＵＣＣＨリソースシグナリング。
○ オプション３：ＤＣＩ開始ＣＣＥ
○ オプション３ａ：再使用１ビット「ＤＡＩ」指示
○ 第１のＵＥ：ＰＤＣＣＨ中の、ＰＲＩおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ
○ ＭＡＣ ＰＤＵ内のＵＥの位置順序に基づく、他のＵＥの暗黙的導出。

オプションＮとＮａとの間の違い（Ｎ∈｛１，２，３｝）は、リリース１５の場合のように開始ＣＣＥに基づく１ビット暗黙的指示を使用すべきなのか、１ビットＤＡＩ指示を使用すべきなのかである。他のリソースシグナリングパラメータは、同じままである。
－ オプション４：以下に基づく、ＭｓｇＢ ＰＤＳＣＨにおける暗黙的ＰＵＣＣＨリソースシグナリング。
〇 ＤＣＩ開始ＣＣＥ
〇 ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータおよびＰＲＩは、すべてのＵＥに共通である
〇 ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}は各ＵＥに一意であり、ｒ_{ＰＵＣＣＨ}は、ＰＲＩと、第１のＣＣＥ（ＤＣＩ開始ＣＣＥ）のインデックスと、成功ＲＡＲ中に含まれるＣ－ＲＮＴＩとに基づいて計算される。複数のＵＥのＰＵＣＣＨリソースインデックスは、Ｃ－ＲＮＴＩによってランダム化される。

下記は２つの部分を含んでおり、それらの部分のうちの一方は、成功ＲＡＲ／フォールバックＲＡＲが単一のＵＥをターゲットにする場合を扱う実施形態を含んでいるが、他方の部分は、成功ＲＡＲ／フォールバックＲＡＲが複数のＵＥをターゲットにし得る場合を扱う実施形態を含んでいる。

実施形態のすべてまたは実施形態のセットについて、１つの関連する（ただし、唯一可能なものではない）ＨＡＲＱフィードバック原理は、成功ＲＡＲ／フォールバックＲＡＲ（および、セクション２．１．２におけるｍｓｇ送信オプションＣの場合、上位レイヤｍｓｇＢ部分）を成功裡に受信するＵＥのみが、ＰＵＣＣＨリソース上で任意のＨＡＲＱフィードバックを送信し、このフィードバックがＡＣＫ（肯定応答）であることである。ＵＥが送信を受信することに失敗するか、または送信を成功裡に受信するが、送信が別のＵＥを対象とすることを競合解消情報が指示する場合、ＵＥはサイレントのままである（すなわち、ＵＥはＮＡＣＫを送信しない）。したがって、ＰＵＣＣＨリソース上でＨＡＲＱフィードバックを送信するＵＥは、成功ＲＡＲ／フォールバックＲＡＲ中に含まれるタイミングアドバンス（ＴＡ）情報を受信したことになり、したがって、正しいタイミングアドバンスを伴うＨＡＲＱ ＡＣＫを送信することが可能であり、これは、ｇＮＢが、それがｍｓｇＡ送信のために行うスケジューリングマージンを提供する必要がないことを意味する。このＨＡＲＱフィードバック原理では、ｇＮＢは、ＰＵＣＣＨ上でのＨＡＲＱフィードバックの欠如をＮＡＣＫ（否定応答）として解釈し、したがって、（再送信の最大許容数に達していない限り）成功ＲＡＲ／フォールバックＲＡＲを再送信する。

実施形態１：単一のＵＥのためのｍｓｇＢ（成功ＲＡＲ／フォールバックＲＡＲ）送信

このサブセクションにおいて記述される実施形態は、セクション２．１．２において記述されるｍｓｇＢ送信オプションＢおよびＣに適用可能である。オプションＢの場合、ＨＡＲＱフィードバックおよび関連するＰＵＣＣＨ送信リソースは、成功ＲＡＲ／フォールバックＲＡＲ部分／メッセージのみに関係する。

単一のＵＥがアドレス指定されるので、１つのＵＥのためのｍｓｇＢ ＨＡＲＱフィードバックリソースのみが必要とされる。そのようなリソースを識別することは、比較的少数のビットを必要とし、ランダムアクセス応答を搬送しないＰＤＳＣＨのために、Ｒｅｌ－１５においてすでに行われた。したがって、いくつかの実施形態では、少なくともランダムアクセス応答を搬送するＰＤＳＣＨに応答してＨＡＲＱフィードバックを搬送するために使用されるＨＡＲＱフィードバックリソースは、ＰＵＣＣＨリソースインジケータおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックのうちの１つまたは複数など、既存のＤＣＩフィールドを使用してＤＣＩ中に含まれる。２つのそのような実施形態（１ａおよび１ｂ）は、以下の通りである。

実施形態１ａ。ｍｓｇＢ－ＲＮＴＩアドレス指定ＤＣＩでは、それぞれスロットおよびスロットレベルリソース内でＰＵＣＣＨリソースを指示するために、以下のパラメータのうちの１つまたは複数を含む。
－ ＰＵＣＣＨリソースインジケータ
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ

実施形態１ｂ。ｍｓｇＢ－ＲＮＴＩアドレス指定ＤＣＩでは、スロットレベルリソースを決定するために以下の１つのパラメータのみを含み、スロット内でリソースを決定するためにｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定を使用する。
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ

いくつかの実施形態では、ＰＤＳＣＨ送信を正しく受信および復号することに失敗するＵＥは、ｇＮＢへのＨＡＲＱフィードバックとして、明示的ＮＡＣＫ指示を提供する。潜在的ＨＡＲＱフィードバック衝突問題は、したがって、ＨＡＲＱフィードバック中にＵＥ ＩＤを含めることまたは上位レイヤに衝突を検出および補償させることなど、手段を通して扱われることになる。明示的ＡＣＫの不在のみに依拠する代わりに、明示的ＮＡＣＫ指示を提供することは、よりリッチなフィードバック情報を提供することの利益を有し、ｇＮＢは、このことをその再送信において考慮に入れ得る。

ＵＥが、ｍｓｇＢを搬送するＰＤＳＣＨを復号しないとき、ＵＥは、ｍｓｇＢ中で搬送されるタイミングアドバンスの値を決定することができない。したがって、そのようなＵＥは、ＨＡＲＱフィードバックを送信するための正確なタイミングアドバンス値を有しないことがある。これは、ｍｓｇＢのためのＨＡＲＱフィードバックを搬送するＰＵＣＣＨまたはＰＵＳＣＨが、他のＰＵＣＣＨまたはＰＵＳＣＨと衝突し得ることを暗示する。そのような場合、他のＰＵＣＣＨまたはＰＵＳＣＨリソースから十分に分離された、ｍｓｇＢ ＨＡＲＱフィードバックのための異なる時間および周波数リソースを割り当てることが、衝突を緩和するために使用され得る。

したがって、一実施形態では、ＵＥは、ランダムアクセス応答を搬送するＰＤＳＣＨに応答して、物理チャネルにおいてＨＡＲＱフィードバックを送信し、ここで、ＨＡＲＱフィードバックは、肯定応答（ＡＣＫ）または否定応答（ＮＡＣＫ）のいずれかを指示することができる。

実施形態１ｃ。ＤＣＩパラメータは使用されず、ＰＵＣＣＨリソースのスロットレベル指示とシンボルレベル指示の両方について、共通パラメータをすべてのＵＥのために規定する。共通パラメータは、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ ＩＥに対する拡張として、たとえばｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ－ｒ１６と呼ばれるＩＥにおいて、たとえばリリース１６＋固有の拡張の形式で、実現され得る。

実施形態１ｄ。ｍｓｇＢ監視のための拡張されたＲＡＲウィンドウに対処するために、およびＡＣＫとＮＡＣＫの両方を可能にするために、ＵＥがプリアンブルを送信したシステムフレームのための少なくともＳＦＮが、直交ＰＵＣＣＨリソースを指示するために使用され得る。ＲＡＲウィンドウがどのくらい拡張されるかに応じて、ＵＥは、自律的にＰＵＣＣＨリソースインデックスを選択し得る。

一例として、これは、下記のいずれかを通して行われ得る。
－ ＰＵＣＣＨリソースインジケータ＝ｍｏｄ（ＳＦＮ，ＲＡＲｗｉｎｄｏｗＥｘｔｅｎｓｉｏｎＦａｃｔｏｒ）、または、
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ＝ｍｏｄ（ＳＦＮ，ＲＡＲｗｉｎｄｏｗＥｘｔｅｎｓｉｏｎＦａｃｔｏｒ）

ここで、ＲＡＲｗｉｎｄｏｗＥｘｔｅｎｓｉｏｎＦａｃｔｏｒは、ＲＡＲウィンドウがそれによってｍｓｇＢウィンドウに拡張される、ファクタである。

実施形態２：多重化された複数のＵＥによるｍｓｇＢ（成功ＲＡＲ／フォールバックＲＡＲ）送信

本明細書で説明される実施形態は、セクション２．１．２におけるｍｓｇＢ送信オプションＡおよびｍｓｇＢ送信オプションＤを扱う。ＨＡＲＱフィードバックおよび関連するＰＵＣＣＨリソースは、成功ＲＡＲ／フォールバックＲＡＲ送信のみに関係し、ｍｓｇＢの別個に送信された第２の部分（上位レイヤ部分）を考慮しない。ｍｓｇＢの第２の部分（上位レイヤ部分）が送信される場合、ｍｓｇＢの第２の部分（上位レイヤ部分）に関するＨＡＲＱフィードバックの送信のために使用されるべきＰＵＣＣＨのＰＵＣＣＨ設定情報が、ｍｓｇＢの第２の部分（上位レイヤ部分）に含まれ得るか、または、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定が使用され得、ＨＡＲＱタイミングは、ｍｓｇＢの第２の部分（上位レイヤ部分）のためのＰＤＳＣＨスケジューリング割り当てを含んでいるＤＣＩ中で指示され得る。

以下の実施形態のうちの少なくとも１つが使用され得る。

実施形態２ａ。複数のＡＣＫおよび／またはＮＡＣＫビットが、同じＰＵＣＣＨリソース上で配信される。

この実施形態では、ＰＵＣＣＨリソースは、ｍｓｇＢ部分１送信、すなわち成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされる各ＵＥが、ＨＡＲＱフィードバック情報を報告するためのそれ自体のＰＵＣＣＨビットを得るように、複数のビットを含んでいるように設定されることになる。したがって、ターゲットにされるＵＥの各々は、ＨＡＲＱフィードバックの送信のために、そのＵＥに専用のＰＵＣＣＨビットのうちの１つを有することになる。たとえば、成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされる３つのＵＥでは、これらのＵＥは各々１つのＰＵＣＣＨビットを使用し、したがって、ＰＵＣＣＨリソースにおいて合計３つのビットを必要とすることになる。これらのビットは、Ｘ、ＹおよびＺと示され得、ここで、ビットＸは第１のＵＥが使用するためのものであり、ビットＹは第２のＵＥのためのものであり、ビットＺは第３のＵＥのためのものである。このＩｖＤにおいて、「ＰＵＣＣＨビット」は、ＰＵＣＣＨチャネルによって搬送されるビットを意味することに留意されたい。

複数のＵＥが同じＰＵＣＣＨリソース中で送信し得るので、ｇＮＢがそれらのＵＥの相互干渉を抑制することができるように、ＵＥはＰＵＣＣＨを異なって送信するべきである。セクション５．１において説明されるように、同じｍｓｇＢ ＰＤＳＣＨのための衝突するＨＡＲＱフィードバック送信を識別するための手法が、ＵＥのＰＵＣＣＨ ＤＭＲＳのための異なるシーケンス初期化を使用することである。そのような場合、ＵＥは、上記で説明されたように、ランダムアクセスプロシージャの始動より前に、ＵＥに知られているＵＥ識別子の関数である初期化値を選択し得る。ｇＮＢは、次いで、ＵＥによって使用されるものを見つけるために各ＰＵＣＣＨを復号するとき、複数のＤＭＲＳシーケンス初期化値を仮定することができる。

この実施形態の１つの変形態では、ＵＥが、成功ＲＡＲ／フォールバックＲＡＲにおける複数のＵＥのそれぞれの情報レコードの包含の順序に基づいて、そのＵＥのＰＵＣＣＨビットを導出する。たとえば、ＵＥの情報レコードが成功ＲＡＲ／フォールバックＲＡＲにおけるＸ番目の情報レコードである場合、ＵＥはＨＡＲＱ ＡＣＫの送信のためにＸ番目のＰＵＣＣＨビットを使用することになる（ただし、ＵＥは、成功ＲＡＲ／フォールバックＲＡＲを成功裡に受信／復号し、競合解消が有利であったと決定しない限り、サイレントのままである）。

この実施形態の変形態では、設定されるＰＵＣＣＨビットの数は、動的であり、成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされるＵＥの数に等しくセットされ得る。代替的に、設定されるＰＵＣＣＨビットの数は、静的であり、成功ＲＡＲ／フォールバックＲＡＲによってターゲットにされ得るＵＥの最大数に常に等しくなり得る。

いくつかの実施形態では、どのビット位置がどのＵＥによって使用されるかが、以下のパラメータのうちの１つまたは複数から導出され得る。

プリアンブルＩＤ。異なるプリアンブルＩＤを選定する２つのＵＥが、使用するために同じＰＵＣＣＨビットを導出することができないように、プリアンブルＩＤからＰＵＣＣＨビットへのマッピングが一意であることを保証するために、ＰＵＣＣＨビットの数は、当該のＲＡＣＨ／ＰＲＡＣＨオケージョン（ＲＯ）において２ステップＲＡのために利用可能なプリアンブルＩＤの数に等しくなるべきである。

ＰＵＳＣＨ時間周波数リソースを含むＰＵＳＣＨリソースユニット、および／またはＰＵＳＣＨ ＤＭＲＳポート、および／またはＰＵＳＣＨ ＤＭＲＳシーケンス。異なるＰＵＳＣＨ ＲＵを選定する２つのＵＥが、使用するために同じＰＵＣＣＨビットを導出することができないように、ＰＵＳＣＨ ＲＵからＰＵＣＣＨビットへのマッピングが一意であることを保証するために、ＰＵＣＣＨビットの数は、当該のＲＡＣＨ／ＰＲＡＣＨオケージョン（ＲＯ）に関連するＰＵＳＣＨ ＲＵの数に等しくなるべきである。

パラメータの組合せが、ＰＵＣＣＨビットを導出するために使用される場合、各可能な組合せは一意のＰＵＣＣＨビットにマッピングするべきであり、したがって、ＰＵＣＣＨビットの数はＲＯのための可能な組合せの数に等しくなるべきである。

代替的に、いくつかの実施形態では、ＰＤＳＣＨ送信を正しく受信および復号することに失敗するＵＥは、ｇＮＢへのＨＡＲＱフィードバックとして、明示的ＮＡＣＫ指示を提供する。他のＨＡＲＱフィードバック原理の動機となる、上記で説明された問題は、したがって、ＨＡＲＱフィードバック中にＵＥ ＩＤを含めることまたは上位レイヤに衝突を検出および補償させることなど、他の手段を通して扱われる。明示的ＡＣＫの不在のみに依拠する代わりに、明示的ＮＡＣＫ指示を提供することは、よりリッチなフィードバック情報を提供することの利益を有し、ｇＮＢは、このことをその再送信において考慮に入れ得る。

以下の他の実施形態では、複数のＰＵＣＣＨリソースが、ＵＥに割り当てられる。

実施形態２ｂ。メール議論に基づいて、ＰＵＣＣＨ設定パラメータのセットが、成功ＲＡＲ／フォールバックＲＡＲをスケジュールするＤＣＩ中で、各ＵＥのためにシグナリングされ得、たとえば、以下がある。
－ ＰＵＣＣＨリソースインジケータ１
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ１
－ ＰＵＣＣＨリソースインジケータ２
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ２
－ ＰＵＣＣＨリソースインジケータ３
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ３

一実施形態では、ＵＥが使用するべきであるＤＣＩ中のＰＵＣＣＨ設定パラメータのセットは、１つまたは複数のパラメータ、たとえばプリアンブルＩＤまたはＰＵＳＣＨ ＲＵから、導出され得る。これらの例では、ＲＯのために利用可能な２ステッププリアンブルＩＤまたはＰＵＳＣＨ ＲＵがあるので、ＤＣＩ中にＰＵＣＣＨ設定パラメータの等しく多くのセットがなければならないことに留意されたい。場合によっては、ＤＣＩ中のビットを節約するために、ＰＵＣＣＨ設定パラメータの未使用セット（すなわち、ターゲットにされるＵＥのいずれもマッピングしないもの）が、「ＰＵＣＣＨ設定パラメータの不在セット」を指示するインジケータによって置き換えられ得る。たとえば、ＤＣＩ中のＰＵＣＣＨ設定パラメータの各セットが、「ＰＵＣＣＨ設定パラメータセット存在」または「ＰＵＣＣＨ設定パラメータセット不在」を指示する、１ビットフラグに先行され得る。

ＨＡＲＱ原理が、成功ＲＡＲ／フォールバックＲＡＲの成功した受信／復号と、決定された成功した競合解消との後にのみＨＡＲＱ ＡＣＫを送信し、さもなければ、サイレントのままである（すなわち、ＨＡＲＱフィードバックをまったく送信しない）ための、別の実施形態では、ＵＥが、成功ＲＡＲ／フォールバックＲＡＲにおける複数のＵＥのそれぞれの情報レコードの包含の順序に基づいて、ＤＣＩ中のＰＵＣＣＨ設定パラメータのＵＥのセットを導出する。たとえば、ＵＥの情報レコードが成功ＲＡＲ／フォールバックＲＡＲにおけるＸ番目の情報レコードである場合、ＵＥはＨＡＲＱ ＡＣＫの送信のためにＤＣＩ中のＰＵＣＣＨ設定パラメータのＸ番目のセットを使用することになる（ただし、ＵＥは、成功ＲＡＲ／フォールバックＲＡＲを成功裡に受信／復号し、競合解消が有利であったと決定しない限り、サイレントのままである）。

この実施形態の別の変形態は、たとえば、ＤＣＩ中の第１のＵＥのためのパラメータの各々に対する、後のＵＥのためのオフセットインジケータ値を導入することであり得る。この符号化は、ＰＵＣＣＨ設定パラメータの第１のセットのみが完全な値を含んでいなければならないことになるので、ＤＣＩ中で必要とされるビットの数を潜在的に低減することになり、ＰＵＣＣＨ設定パラメータの後続のセットは、代わりに、ＰＵＣＣＨ設定ビットの第１のセット中の対応するパラメータ値に対する、潜在的により多くのビットを節約できるオフセット値からなることができる。また別のオプションは、オフセット値が、シグナリングされる代わりに、単にあらかじめ決定され得ることである。

たとえば、
－ ＰＵＣＣＨリソースインジケータ１
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ１
－ ＰＵＣＣＨリソースインジケータオフセット
－ ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングオフセット
－ ．．．
がある。

実施形態２ｃ。複数のＵＥのための別個のＰＵＣＣＨ設定を提供するために、同じ行上に複数のＰＵＣＣＨリソースを指示することができる、修正／拡張されたＰＵＣＣＨリソース表セットを使用する。

たとえば、追加のＮ個のＵＥのための表において、時間オフセット値をもつＮ個の列を導入する。時間オフセットはスロットレベルおよび／またはシンボルレベルであり得る。

前に説明されたことと同様に、ＵＥは、ＵＥのそれぞれの情報レコードが成功ＲＡＲ／フォールバックＲＡＲにおいて現れる順序を使用して、ＵＥがどの列を使用するべきであるかを決定することができる。前に説明されたように、これは、ＵＥが、成功ＲＡＲ／フォールバックＲＡＲの成功した受信／復号と、決定された成功した競合解消との後にのみＨＡＲＱ ＡＣＫを送信し、さもなければサイレントのままである（すなわち、ＨＡＲＱフィードバックをまったく送信しない）ための、ＨＡＲＱ原理を使用することを必要とする。

この実施形態の変形形態は、ＦＤＭされるかまたはインターレースされる、ＰＵＣＣＨリソースセットを使用することであり得る。

この実施形態の別の変形態は、表９．２．１－１における異なる巡回シフト（ＣＳ）インデックス値が、異なるＵＥによって使用され得ることであり得る。

たとえば、第１の行が指示されるとき、２つのＣＳ値０および３は、同じｍｓｇＢ上に多重化された２つのＵＥのために使用され得る。

ＣＳインデックスが十分でない場合、１つのやり方は、表９．２．１－１における初期ＣＳインデックスのセットを拡張することである。

表９．２．１－１における初期ＣＳインデックスのセットについての第１の行を考慮すると、｛０，３｝を有する。ユーザが２つのグループ、ＣＳ０に関連する一方と、３に関連する他方とに属すると言うことができる。

拡張は、Ｍｓｇ Ａプロパティに基づき得る。たとえば、グループ０が０、２、４に拡張され、グループ３が１、３、５に拡張され、ここで、これらはＣＳインデックスとＭｓｇ Ａプロパティとの間の１対１マッピングである。

すべての上記の実施形態２ａ～２ｃでは、Ｎ個のＵＥおよびＮ個のリソースは、標準仕様において指定された所定のやり方でマッピングされ得る。

実施形態３。ＨＡＲＱ ＡＣＫが予想される場合、１つのＵＥのみが１つの成功ＲＡＲ／フォールバックＲＡＲにおいてターゲットにされ得ることを必要とし、他の場合、ＨＡＲＱフィードバックは可能にされない。成功ＲＡＲ／フォールバックＲＡＲが単一のＵＥをターゲットにするのか複数のＵＥをターゲットにするのかが、成功ＲＡＲ／フォールバックＲＡＲのためのＤＬスケジューリング割り当てを伝達するＤＣＩ中で、または成功ＲＡＲ／フォールバックＲＡＲ中のヘッダ情報中で指示され得るか、あるいは、ＵＥは、成功ＲＡＲ／フォールバックＲＡＲ中に含まれる情報レコードをパースする（たとえば、（別のＵＥのための）別の情報レコードが続くか否かを指示するＥビットを見る）とき、それを発見し得る。ＵＥが成功ＲＡＲ／フォールバックＲＡＲ中で情報を見つける代替形態が機能するために、ＵＥは、ＵＥが、成功ＲＡＲ／フォールバックＲＡＲの成功した受信／復号と、決定された成功した競合解消との後にのみＨＡＲＱ ＡＣＫを送信し、さもなければ、サイレントのままである（すなわち、ＨＡＲＱフィードバックをまったく送信しない）、ＨＡＲＱフィードバック原理を使用するべきであることに留意されたい。システム情報を介した静的設定も使用され得、または、静的設定は標準仕様によって決定されることさえある。

実施形態４。この実施形態では、ＵＥが、成功ＲＡＲ／フォールバックＲＡＲの成功した受信／復号と、決定された成功した競合解消との後にのみＨＡＲＱ ＡＣＫを送信し、さもなければサイレントのままである（すなわち、ＵＥはＨＡＲＱフィードバックをまったく送信しない）、前に説明されたＨＡＲＱフィードバック原理が使用されると仮定される。ＵＥが任意のＨＡＲＱフィードバックを送信する前に、成功ＲＡＲ／フォールバックＲＡＲが成功裡に受信／復号されるので、ＵＥはＴＡ情報を受信したことになり、したがって、正しいタイミングアドバンス（ＴＡ）を伴うＨＡＲＱフィードバックを送信することが可能であることになる。ｇＮＢによってフィードバックが受信されない場合、ｇＮＢは、成功ＲＡＲ／フォールバックＲＡＲが、ｇＮＢがＡＣＫビットを復号することを試みるＰＵＣＣＨリソースに対応するＵＥによって正しく復号されていないと仮定する。

この実施形態では、ＵＥが、ＰＵＣＣＨ上で任意のＨＡＲＱフィードバックを送信する前に、成功ＲＡＲ／フォールバックＲＡＲ中ですべての情報を受信したことになることを暗示する、仮定されたＨＡＲＱフィードバック原理を再び活用し、ＰＵＣＣＨリソースは、成功ＲＡＲ／フォールバックＲＡＲ情報中で、たとえばターゲットにされる各ＵＥのための情報レコード（場合によっては示されるサブＰＤＵ）中で、設定され得る。たとえば、３つの情報レコード／サブＰＤＵが、３つのＵＥのために１つの成功ＲＡＲ／フォールバックＲＡＲ中で多重化される場合、スロットおよび／またはスロットレベルオフセット内のＰＵＣＣＨリソースセット設定が、それぞれ各ＵＥのための情報レコード／サブＰＤＵ中で設定され得る。

ＰＵＳＣＨ上のＨＡＲＱフィードバック
いくつかの実施形態では、成功ＲＡＲ／フォールバックＲＡＲに関するＨＡＲＱフィードバックは、ＰＵＣＣＨリソースの代わりにＰＵＳＣＨリソース上で送信され得、ここで、ＰＵＳＣＨリソースは、成功ＲＡＲ／フォールバックＲＡＲのためのスケジューリング割り当てを含んでいるＰＤＣＣＨ ＤＣＩ中で、または、セクション５．１および５．２で提供された同様の方法を用いて、成功ＲＡＲ／フォールバックＲＡＲ自体中で（すなわち、ＰＤＳＣＨ送信中で）許可され得る。

スケジューリング情報が成功ＲＡＲ／フォールバックＲＡＲ中で搬送される場合、多重化された成功ＲＡＲ／フォールバックＲＡＲのための共通ヘッダが使用され得る。スケジューリング情報は、リソースと、ＰＵＳＣＨリソース内のどの部分（ビット）が各個々の成功ＲＡＲ／フォールバックＲＡＲのフィードバックのために使用されるべきであるかの指示との両方を含んでいる。

この方法では、ＨＡＲＱフィードバックは、許可されたこのＰＵＳＣＨリソースによる、いくらかの量（一般に少量）の瞬時データ送信を可能にしながら、提供され得る。

いくつかの実施形態では、ＰＵＳＣＨはｍｓｇＡ ＰＵＳＣＨの再送信である。

いくつかの実施形態では、ｍｓｇＢは、単一の成功ＲＡＲ／フォールバックＲＡＲを含んでいるものとして、ｍｓｇＢを搬送するＰＤＳＣＨを識別するＲＮＴＩを含んでいるＰＤＣＣＨによってスケジュールされ得る。ＲＮＴＩは、たとえば、Ｃ－ＲＮＴＩ、あるいは、対応するｍｓｇＡまたはｍｓｇＢ ＲＮＴＩ中で搬送されたＵＥ ＩＤを使用するＲＮＴＩであり得る。この場合、ＨＡＲＱフィードバックが送信されるべきであるシンボルに対応するＵＬグラントが与えられる場合、ＵＥは、ＰＵＳＣＨ上でＵＣＩを搬送するＲｅｌ－１５プロシージャに従って、ＰＵＳＣＨ中でＨＡＲＱフィードバックを送信することになる。ＵＥはＰＤＣＣＨ中でグラントを受信するので、ＵＥは、ＵＥがＰＤＳＣＨを復号するまたは復号しないときに対応する、ＡＣＫまたはＮＡＣＫのいずれかを送信し得る。

ＨＡＲＱのためのＰＵＳＣＨリソースがＰＤＳＣＨにおいて与えられる場合、ＨＡＲＱフィードバックのためのＰＵＳＣＨリソースを決定するために、ＰＤＳＣＨの成功した復号が必要とされ、したがって、ＵＥは、ＰＤＳＣＨからＮＡＣＫを搬送することになるリソースを決定することができないので、ＮＡＣＫを送信しない。したがって、ＵＥは、ＨＡＲＱのためのＰＵＳＣＨリソースがＰＤＳＣＨにおいて与えられるとき、ＡＣＫを送信するか、またはＨＡＲＱフィードバックを送信しない。ＡＣＫのみが送信されるこれらの事例では、ｍｓｇＢが複数の成功ＲＡＲ／フォールバックＲＡＲを含んでおり、各々がＰＵＳＣＨ上で使用されるべきＨＡＲＱフィードバックリソースを識別するとき、ＲＡＲによってアドレス指定されたすべてのＵＥが、ＨＡＲＱフィードバックリソース割り当てを成功裡に復号したことになり、したがって、これらのＵＥは、それらの対応するＲＡＲが単一のＰＤＳＣＨに多重化されるとき、そのＲＡＲのための異なるＰＵＳＣＨリソース上でＨＡＲＱフィードバックを指示することができる。

図７は、本開示のいくつかの実施形態による、中間ネットワークを介してホストコンピュータに接続された通信ネットワークを示すブロック図である。

図７を参照すると、一実施形態によれば、通信システムが、無線アクセスネットワークなどのアクセスネットワーク７１１とコアネットワーク７１４とを備える、３ＧＰＰタイプセルラネットワークなどの通信ネットワーク７１０を含む。アクセスネットワーク７１１は、ＮＢ、ｅＮＢ、ｇＮＢまたは他のタイプの無線アクセスポイントなど、複数の基地局７１２ａ、７１２ｂ、７１２ｃを備え、各々が、対応するカバレッジエリア７１３ａ、７１３ｂ、７１３ｃを規定する。各基地局７１２ａ、７１２ｂ、７１２ｃは、有線接続または無線接続７１５を介してコアネットワーク７１４に接続可能である。カバレッジエリア７１３ｃ中に位置する第１のＵＥ７９１が、対応する基地局７１２ｃに無線で接続するか、または対応する基地局７１２ｃによってページングされるように設定される。カバレッジエリア７１３ａ中の第２のＵＥ７９２が、対応する基地局７１２ａに無線で接続可能である。この例では複数のＵＥ７９１、７９２が示されているが、開示される実施形態は、唯一のＵＥがカバレッジエリア中にある状況、または唯一のＵＥが、対応する基地局７１２に接続している状況に等しく適用可能である。

通信ネットワーク７１０は、それ自体、ホストコンピュータ７３０に接続され、ホストコンピュータ７３０は、スタンドアロンサーバ、クラウド実装サーバ、分散サーバのハードウェアおよび／またはソフトウェアにおいて、あるいはサーバファーム中の処理リソースとして具現され得る。ホストコンピュータ７３０は、サービスプロバイダの所有または制御下にあり得るか、あるいはサービスプロバイダによってまたはサービスプロバイダの代わりに動作され得る。通信ネットワーク７１０とホストコンピュータ７３０との間の接続７２１および７２２が、コアネットワーク７１４からホストコンピュータ７３０まで直接延び得るか、または随意の中間ネットワーク７２０を介して進み得る。中間ネットワーク７２０は、公衆ネットワーク、プライベートネットワークまたはホストされたネットワークのうちの１つ、あるいはそれらのうちの２つ以上の組合せであり得、中間ネットワーク７２０は、もしあれば、バックボーンネットワークまたはインターネットであり得、特に、中間ネットワーク７２０は、２つまたはそれ以上のサブネットワーク（図示せず）を備え得る。

図７の通信システムは全体として、接続されたＵＥ７９１、７９２とホストコンピュータ７３０との間のコネクティビティを可能にする。コネクティビティは、オーバーザトップ（ＯＴＴ）接続７５０として説明され得る。ホストコンピュータ７３０および接続されたＵＥ７９１、７９２は、アクセスネットワーク７１１、コアネットワーク７１４、任意の中間ネットワーク７２０および可能なさらなるインフラストラクチャ（図示せず）を媒介として使用して、ＯＴＴ接続７５０を介して、データおよび／またはシグナリングを通信するように設定される。ＯＴＴ接続７５０は、ＯＴＴ接続７５０が通過する、参加する通信デバイスが、アップリンク通信およびダウンリンク通信のルーティングに気づいていないという意味で、透過的であり得る。たとえば、基地局７１２は、接続されたＵＥ７９１にフォワーディング（たとえば、ハンドオーバ）されるべき、ホストコンピュータ７３０から発生したデータを伴う着信ダウンリンク通信の過去のルーティングについて、知らされないことがあるかまたは知らされる必要がない。同様に、基地局７１２は、ＵＥ７９１から発生してホストコンピュータ７３０に向かう発信アップリンク通信の将来ルーティングに気づいている必要がない。

図８は、本開示のいくつかの実施形態による、部分的無線接続上で基地局を介してＵＥと通信するホストコンピュータを示すブロック図である。

次に、一実施形態による、前の段落において説明されたＵＥ、基地局およびホストコンピュータの例示的な実装形態が、図８を参照しながら説明される。通信システム８００では、ホストコンピュータ８１０が、通信システム８００の異なる通信デバイスのインターフェースとの有線接続または無線接続をセットアップおよび維持するように設定された通信インターフェース８１６を含む、ハードウェア８１５を備える。ホストコンピュータ８１０は、記憶能力および／または処理能力を有し得る、処理回路８１８をさらに備える。特に、処理回路８１８は、命令を実行するように適応された、１つまたは複数のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組合せ（図示せず）を備え得る。ホストコンピュータ８１０は、ホストコンピュータ８１０に記憶されるかまたはホストコンピュータ８１０によってアクセス可能であり、処理回路８１８によって実行可能である、ソフトウェア８１１をさらに備える。ソフトウェア８１１はホストアプリケーション８１２を含む。ホストアプリケーション８１２は、ＵＥ８３０およびホストコンピュータ８１０において終端するＯＴＴ接続８５０を介して接続するＵＥ８３０など、リモートユーザにサービスを提供するように動作可能であり得る。リモートユーザにサービスを提供する際に、ホストアプリケーション８１２は、ＯＴＴ接続８５０を使用して送信されるユーザデータを提供し得る。

通信システム８００は、通信システム中に提供される基地局８２０をさらに含み、基地局８２０は、基地局８２０がホストコンピュータ８１０およびＵＥ８３０と通信することを可能にするハードウェア８２５を備える。ハードウェア８２５は、通信システム８００の異なる通信デバイスのインターフェースとの有線接続または無線接続をセットアップおよび維持するための通信インターフェース８２６、ならびに基地局８２０によってサーブされるカバレッジエリア（図８に図示せず）中に位置するＵＥ８３０との少なくとも無線接続８７０をセットアップおよび維持するための無線インターフェース８２７を含み得る。通信インターフェース８２６は、ホストコンピュータ８１０への接続８６０を容易にするように設定され得る。接続８６０は直接であり得るか、あるいは接続８６０は、通信システムのコアネットワーク（図８に図示せず）を、および／または通信システムの外部の１つまたは複数の中間ネットワークを通過し得る。図示の実施形態では、基地局８２０のハードウェア８２５は、処理回路８２８をさらに含み、処理回路８２８は、命令を実行するように適応された、１つまたは複数のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組合せ（図示せず）を備え得る。基地局８２０は、内部的に記憶されるかまたは外部接続を介してアクセス可能なソフトウェア８２１をさらに有する。

通信システム８００は、すでに言及されたＵＥ８３０をさらに含む。ＵＥ８３０のハードウェア８３５は、ＵＥ８３０が現在位置するカバレッジエリアをサーブする基地局との無線接続８７０をセットアップおよび維持するように設定された、無線インターフェース８３７を含み得る。ＵＥ８３０のハードウェア８３５は、処理回路８３８をさらに含み、処理回路８３８は、命令を実行するように適応された、１つまたは複数のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組合せ（図示せず）を備え得る。ＵＥ８３０は、ＵＥ８３０に記憶されるかまたはＵＥ８３０によってアクセス可能であり、処理回路８３８によって実行可能である、ソフトウェア８３１をさらに備える。ソフトウェア８３１はクライアントアプリケーション８３２を含む。クライアントアプリケーション８３２は、ホストコンピュータ８１０のサポートを伴って、ＵＥ８３０を介して人間のまたは人間でないユーザにサービスを提供するように動作可能であり得る。ホストコンピュータ８１０では、実行しているホストアプリケーション８１２は、ＵＥ８３０およびホストコンピュータ８１０において終端するＯＴＴ接続８５０を介して、実行しているクライアントアプリケーション８３２と通信し得る。ユーザにサービスを提供する際に、クライアントアプリケーション８３２は、ホストアプリケーション８１２から要求データを受信し、要求データに応答してユーザデータを提供し得る。ＯＴＴ接続８５０は、要求データとユーザデータの両方を転送し得る。クライアントアプリケーション８３２は、クライアントアプリケーション８３２が提供するユーザデータを生成するためにユーザと対話し得る。

図８に示されているホストコンピュータ８１０、基地局８２０およびＵＥ８３０は、それぞれ、図７のホストコンピュータ７３０、基地局７１２ａ、７１２ｂ、７１２ｃのうちの１つ、およびＵＥ７９１、７９２のうちの１つと同様または同等であり得ることに留意されたい。つまり、これらのエンティティの内部の働きは、図８に示されているようなものであり得、別個に、周囲のネットワークトポロジーは、図７のものであり得る。

図８では、ＯＴＴ接続８５０は、仲介デバイスとこれらのデバイスを介したメッセージの正確なルーティングとへの明示的言及なしに、基地局８２０を介したホストコンピュータ８１０とＵＥ８３０との間の通信を示すために抽象的に描かれている。ネットワークインフラストラクチャが、ルーティングを決定し得、ネットワークインフラストラクチャは、ＵＥ８３０からまたはホストコンピュータ８１０を動作させるサービスプロバイダから、またはその両方からルーティングを隠すように設定され得る。ＯＴＴ接続８５０がアクティブである間、ネットワークインフラストラクチャは、さらに、ネットワークインフラストラクチャが、（たとえば、ネットワークの負荷分散考慮または再設定に基づいて）ルーティングを動的に変更する判定を行い得る。

ＵＥ８３０と基地局８２０との間の無線接続８７０は、本開示全体にわたって説明される実施形態の教示に従う。様々な実施形態のうちの１つまたは複数は、無線接続８７０が最後のセグメントを形成するＯＴＴ接続８５０を使用して、ＵＥ８３０に提供されるＯＴＴサービスの性能を改善する。より正確には、これらの実施形態の教示は、レイテンシを改善し、それにより、複雑さの低下、セルにアクセスするために必要とされる時間の低減、応答性の向上などの利益を提供し得る。

１つまたは複数の実施形態が改善する、データレート、レイテンシおよび他のファクタを監視する目的での、測定プロシージャが提供され得る。測定結果の変動に応答して、ホストコンピュータ８１０とＵＥ８３０との間のＯＴＴ接続８５０を再設定するための随意のネットワーク機能がさらにあり得る。測定プロシージャおよび／またはＯＴＴ接続８５０を再設定するためのネットワーク機能は、ホストコンピュータ８１０のソフトウェア８１１およびハードウェア８１５でまたはＵＥ８３０のソフトウェア８３１およびハードウェア８３５で、またはその両方で実装され得る。実施形態では、ＯＴＴ接続８５０が通過する通信デバイスにおいて、またはその通信デバイスに関連して、センサー（図示せず）が展開され得、センサーは、上記で例示された監視された量の値を供給すること、あるいはソフトウェア８１１、８３１が監視された量を算出または推定し得る他の物理量の値を供給することによって、測定プロシージャに参加し得る。ＯＴＴ接続８５０の再設定は、メッセージフォーマット、再送信セッティング、好ましいルーティングなどを含み得、再設定は、基地局８２０に影響を及ぼす必要がなく、再設定は、基地局８２０に知られていないかまたは知覚不可能であり得る。そのようなプロシージャおよび機能は、当技術分野において知られ、実践され得る。いくつかの実施形態では、測定は、スループット、伝搬時間、レイテンシなどのホストコンピュータ８１０の測定を容易にするプロプライエタリＵＥシグナリングを伴い得る。測定は、ソフトウェア８１１および８３１が、ソフトウェア８１１および８３１が伝搬時間、エラーなどを監視する間にＯＴＴ接続８５０を使用して、メッセージ、特に空のまたは「ダミー」メッセージが送信されることを引き起こすことにおいて、実装され得る。

図９は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図７および図８を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示の簡単のために、図９への図面参照のみがこのセクションに含まれる。ステップ９１０において、ホストコンピュータはユーザデータを提供する。ステップ９１０の（随意であり得る）サブステップ９１１において、ホストコンピュータは、ホストアプリケーションを実行することによって、ユーザデータを提供する。ステップ９２０において、ホストコンピュータは、ＵＥにユーザデータを搬送する送信を始動する。（随意であり得る）ステップ９３０において、基地局は、本開示全体にわたって説明される実施形態の教示に従って、ホストコンピュータが始動した送信において搬送されたユーザデータをＵＥに送信する。（また、随意であり得る）ステップ９４０において、ＵＥは、ホストコンピュータによって実行されるホストアプリケーションに関連するクライアントアプリケーションを実行する。

図１０は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図７および図８を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示の簡単のために、図１０への図面参照のみがこのセクションに含まれる。方法のステップ１０１０において、ホストコンピュータはユーザデータを提供する。随意のサブステップ（図示せず）において、ホストコンピュータは、ホストアプリケーションを実行することによって、ユーザデータを提供する。ステップ１０２０において、ホストコンピュータは、ＵＥにユーザデータを搬送する送信を始動する。送信は、本開示全体にわたって説明される実施形態の教示に従って、基地局を介して進み得る。（随意であり得る）ステップ１０３０において、ＵＥは、送信において搬送されたユーザデータを受信する。

図１１は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図７および図８を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示の簡単のために、図１１への図面参照のみがこのセクションに含まれる。（随意であり得る）ステップ１１１０において、ＵＥは、ホストコンピュータによって提供された入力データを受信する。追加または代替として、ステップ１１２０において、ＵＥはユーザデータを提供する。ステップ１１２０の（随意であり得る）サブステップ１１２１において、ＵＥは、クライアントアプリケーションを実行することによって、ユーザデータを提供する。ステップ１１１０の（随意であり得る）サブステップ１１１１において、ＵＥは、ホストコンピュータによって提供された受信された入力データに反応してユーザデータを提供する、クライアントアプリケーションを実行する。ユーザデータを提供する際に、実行されたクライアントアプリケーションは、ユーザから受信されたユーザ入力をさらに考慮し得る。ユーザデータが提供された特定の様式にかかわらず、ＵＥは、（随意であり得る）サブステップ１１３０において、ホストコンピュータへのユーザデータの送信を始動する。方法のステップ１１４０において、ホストコンピュータは、本開示全体にわたって説明される実施形態の教示に従って、ＵＥから送信されたユーザデータを受信する。

図１２は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図７および図８を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示の簡単のために、図１２への図面参照のみがこのセクションに含まれる。（随意であり得る）ステップ１２１０において、本開示全体にわたって説明される実施形態の教示に従って、基地局は、ＵＥからユーザデータを受信する。（随意であり得る）ステップ１２２０において、基地局は、ホストコンピュータへの、受信されたユーザデータの送信を始動する。（随意であり得る）ステップ１２３０において、ホストコンピュータは、基地局によって始動された送信において搬送されたユーザデータを受信する。

いくつかの例示的な実施形態によれば、ホストコンピュータと、基地局と、ＵＥとを含み得る通信システムにおいて実装される方法が提供される。本方法は、ホストコンピュータにおいてユーザデータを提供することを含み得る。随意に、本方法は、ホストコンピュータにおいて、図５Ａに関して説明される例示的な方法５１０の任意のステップを実施し得る基地局を備えるセルラネットワークを介してＵＥにユーザデータを搬送する送信を始動することを含み得る。

いくつかの例示的な実施形態によれば、ホストコンピュータを含む通信システムが提供される。ホストコンピュータは、ユーザデータを提供するように設定された処理回路と、ＵＥへの送信のためにユーザデータをセルラネットワークにフォワーディングするように設定された通信インターフェースとを備え得る。セルラネットワークは、無線インターフェースと処理回路とを有する基地局を備え得る。基地局の処理回路は、図５Ａに関して説明される例示的な方法５１０の任意のステップを実施するように設定され得る。

いくつかの例示的な実施形態によれば、ホストコンピュータと、基地局と、ＵＥとを含み得る通信システムにおいて実装される方法が提供される。本方法は、ホストコンピュータにおいてユーザデータを提供することを含み得る。随意に、本方法は、ホストコンピュータにおいて、基地局を備えるセルラネットワークを介してＵＥにユーザデータを搬送する送信を始動することを含み得る。ＵＥは、図４Ａに関して説明される例示的な方法４１０の任意のステップを実施し得る。

いくつかの例示的な実施形態によれば、ホストコンピュータを含む通信システムが提供される。ホストコンピュータは、ユーザデータを提供するように設定された処理回路と、ＵＥへの送信のためにユーザデータをセルラネットワークにフォワーディングするように設定された通信インターフェースとを備え得る。ＵＥは、無線インターフェースと処理回路とを備え得る。ＵＥの処理回路は、図４Ａに関して説明される例示的な方法４１０の任意のステップを実施するように設定され得る。

いくつかの例示的な実施形態によれば、ホストコンピュータと、基地局と、ＵＥとを含み得る通信システムにおいて実装される方法が提供される。本方法は、ホストコンピュータにおいて、図４Ａに関して説明される例示的な方法４１０の任意のステップを実施し得るＵＥから基地局に送信されたユーザデータを受信することを含み得る。

いくつかの例示的な実施形態によれば、ホストコンピュータを含む通信システムが提供される。ホストコンピュータは、ＵＥから基地局への送信から発生したユーザデータを受信するように設定された通信インターフェースを備え得る。ＵＥは、無線インターフェースと処理回路とを備え得る。ＵＥの処理回路は、図４Ａに関して説明される例示的な方法４１０の任意のステップを実施するように設定され得る。

いくつかの例示的な実施形態によれば、ホストコンピュータと、基地局と、ＵＥとを含み得る通信システムにおいて実装される方法が提供される。本方法は、ホストコンピュータにおいて、基地局から、基地局がＵＥから受信した送信から発生したユーザデータを受信することを含み得る。基地局は、図５Ａに関して説明される例示的な方法５１０の任意のステップを実施し得る。

いくつかの例示的な実施形態によれば、ホストコンピュータを含み得る通信システムが提供される。ホストコンピュータは、ＵＥから基地局への送信から発生したユーザデータを受信するように設定された通信インターフェースを備え得る。基地局は、無線インターフェースと処理回路とを備え得る。基地局の処理回路は、図５Ａに関して説明される例示的な方法５１０の任意のステップを実施するように設定され得る。

概して、様々な例示的な実施形態は、ハードウェアまたは専用チップ、回路、ソフトウェア、論理あるいはそれらの任意の組合せで実装され得る。たとえば、いくつかの態様は、ハードウェアで実装され得、他の態様は、コントローラ、マイクロプロセッサまたは他のコンピューティングデバイスによって実行され得るファームウェアまたはソフトウェアで実装され得るが、本開示はそれに限定されない。本開示の例示的な実施形態の様々な態様は、ブロック図、フローチャートとして、または何らかの他の図式表現を使用して、例示および説明され得るが、本明細書で説明されるこれらのブロック、装置、システム、技法または方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路または論理、汎用ハードウェアまたはコントローラまたは他のコンピューティングデバイス、あるいはそれらの何らかの組合せで実装され得ることを十分に理解されたい。

したがって、本開示の例示的な実施形態の少なくともいくつかの態様が、集積回路チップおよびモジュールなど、様々な構成要素において実践され得ることを諒解されたい。したがって、本開示の例示的な実施形態は、集積回路として具現される装置において実現され得、ここで、集積回路は、本開示の例示的な実施形態に従って動作するように設定可能である、データプロセッサ、デジタル信号プロセッサ、ベースバンド回路および無線周波数回路のうちの少なくとも１つまたは複数を具現するための回路（ならびに場合によってはファームウェア）を備え得ることを諒解されたい。

本開示の例示的な実施形態の少なくともいくつかの態様が、１つまたは複数のコンピュータまたは他のデバイスによって実行される、１つまたは複数のプログラムモジュールでなど、コンピュータ実行可能命令で具現され得ることを諒解されたい。概して、プログラムモジュールは、コンピュータまたは他のデバイス中のプロセッサによって実行されたとき、特定のタスクを実施するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。コンピュータ実行可能命令は、ハードディスク、光ディスク、リムーバブル記憶媒体、固体メモリ、ランダムアクセスメモリ（ＲＡＭ）など、コンピュータ可読媒体に記憶され得る。当業者によって諒解されるように、プログラムモジュールの機能は、様々な実施形態において必要に応じて、組み合わせられるかまたは分散され得る。さらに、機能は、集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）など、ファームウェアまたはハードウェア等価物において全体的にまたは部分的に具現され得る。

本開示は、明示的に本明細書で開示される特徴の任意の新規の特徴または組合せあるいはその任意の一般化のいずれかを含む。本開示の上記の例示的な実施形態への様々な修正および適応は、添付の図面とともに読まれるとき、上記の説明に鑑みて、当業者に明らかになり得る。しかしながら、任意のおよびすべての修正が、依然として、本開示の非限定的なおよび例示的な実施形態の範囲内に入る。

Claims (42)

1. 端末デバイスによって実施される方法（４１０）であって、
   ネットワークノードからリソース設定情報を受信すること（４１２）と、
   前記受信されたリソース設定情報に基づいて、２ステップランダムアクセスプロシージャにおける前記ネットワークノードからの応答メッセージへのフィードバックのためのアップリンク（ＵＬ）リソースを決定すること（４１４）と
   を含む、方法（４１０）。
2. 前記決定されたＵＬリソース上で前記フィードバックを送信すること（４１６）をさらに含む、請求項１に記載の方法。
3. 前記リソース設定情報が、ブロードキャストメッセージの少なくとも１つのパラメータと、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）の少なくとも１つのパラメータと、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）の少なくとも１つのパラメータと、前記応答メッセージの少なくとも１つのパラメータとのうちの少なくとも１つを含む、請求項１または２に記載の方法。
4. 前記フィードバックがハイブリッド自動再送要求（ＨＡＲＱ）フィードバックを含む、請求項１から３のいずれか一項に記載の方法。
5. 前記ＵＬリソースが物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースである、請求項１から４のいずれか一項に記載の方法。
6. 前記応答メッセージが、多重化された２つまたはそれ以上の応答を含み、前記２つまたはそれ以上の応答が、成功応答とフォールバック応答とのうちの少なくとも１つを含む、請求項５に記載の方法。
7. 前記リソース設定情報が、ダウンリンク制御情報（ＤＣＩ）パラメータの少なくとも１つのセットを含む、請求項６に記載の方法。
8. ＤＣＩパラメータの各セットが、ＤＣＩパラメータの前記セットの存在を指示するビットに先行される、請求項７に記載の方法。
9. 前記リソース設定情報が、ＤＣＩパラメータの２つまたはそれ以上のセットを含み、ＤＣＩパラメータの第１のセット以外のＤＣＩパラメータの前記セットの各々が、別の端末デバイスのためのＤＣＩパラメータの前のセットに対するオフセットによって規定される、請求項７に記載の方法。
10. 前記２つまたはそれ以上の応答が、それぞれ、２つまたはそれ以上の端末デバイスを対象とし、前記リソース設定情報が巡回シフトインデックスのセットを指示し、巡回シフトインデックスの前記セットが、１つのＰＤＳＣＨ上で多重化された前記２つまたはそれ以上の応答とともに前記２つまたはそれ以上の端末デバイスによって使用されることが可能である、請求項６に記載の方法。
11. 巡回シフトインデックスの前記セット中の巡回シフトインデックスの量を、巡回シフトインデックスの前記量が前記端末デバイスの量よりも少ないことに応答して、拡張することをさらに含む、請求項１０に記載の方法。
12. 前記２つまたはそれ以上の端末デバイスの前記フィードバックが、
    復調用参照信号、
    前記応答メッセージ中の前記２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
    プリアンブル識別子（ＩＤ）、
    物理アップリンク共有チャネル（ＰＵＳＣＨ）リソースユニット、
    競合解消ＩＤ、および
    端末デバイスＩＤ
    のうちの少なくとも１つによって識別されることが可能である、請求項６に記載の方法。
13. 前記２つまたはそれ以上の応答が、それぞれ、２つまたはそれ以上の端末デバイスを対象とし、前記２つまたはそれ以上の端末デバイスが、同じＰＵＣＣＨリソース上でフィードバックを送信する、請求項６に記載の方法。
14. 前記２つまたはそれ以上の端末デバイスの前記フィードバックが、
    異なる復調用参照信号、
    前記応答メッセージ中の前記２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
    プリアンブルＩＤ、
    ＰＵＳＣＨリソースユニット、
    競合解消ＩＤ、および
    端末デバイスＩＤ
    のうちの少なくとも１つによって識別されることが可能である、請求項１３に記載の方法。
15. 前記応答メッセージが、１つの成功応答またはフォールバック応答を含み、前記リソース設定情報が、
    少なくとも１つのＤＣＩパラメータ、および
    ブロードキャストメッセージの少なくとも１つのパラメータ
    のうちの少なくとも１つを含む、請求項５に記載の方法。
16. 前記リソース設定情報が、
    （ａ）ＰＵＣＣＨリソースインジケータおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ、
    （ｂ）ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータおよびｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定、
    （ｃ）ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ情報エレメント、ならびに
    （ｄ）応答ウィンドウサイズおよびシステムフレーム番号
    のうちの少なくとも１つを含む、請求項１５に記載の方法。
17. 前記ＵＬリソースがＰＵＳＣＨリソースである、請求項１から４のいずれか一項に記載の方法。
18. 前記応答がランダムアクセス応答である、請求項１から１７のいずれか一項に記載の方法。
19. ネットワークノードによって実施される方法（５１０）であって、
    ２ステップランダムアクセスプロシージャにおける応答メッセージへの端末デバイスのフィードバックのためのＵＬリソースを指示するリソース設定情報を決定すること（５１２）と、
    前記リソース設定情報を前記端末デバイスに送信すること（５１４）と
    を含む、方法（５１０）。
20. 前記端末デバイスによって決定された前記ＵＬリソース上でフィードバックを受信すること（５１６）をさらに含む、請求項１９に記載の方法。
21. 前記リソース設定情報が、ブロードキャストメッセージの少なくとも１つのパラメータと、ＰＤＣＣＨの少なくとも１つのパラメータと、ＰＤＳＣＨの少なくとも１つのパラメータと、前記応答メッセージの少なくとも１つのパラメータとのうちの少なくとも１つを含む、請求項１９または２０に記載の方法。
22. 前記フィードバックがＨＡＲＱフィードバックを含む、請求項１９から２１のいずれか一項に記載の方法。
23. 前記ＵＬリソースがＰＵＣＣＨリソースである、請求項１９から２２のいずれか一項に記載の方法。
24. 前記応答メッセージが、多重化された２つまたはそれ以上の応答を含み、前記２つまたはそれ以上の応答が、成功応答とフォールバック応答とのうちの少なくとも１つを含む、請求項２３に記載の方法。
25. 前記リソース設定情報が、ダウンリンク制御情報（ＤＣＩ）パラメータの少なくとも１つのセットを含む、請求項２４に記載の方法。
26. ＤＣＩパラメータの各セットが、ＤＣＩパラメータの前記セットの存在を指示するビットに先行される、請求項２５に記載の方法。
27. 前記リソース設定情報が、ＤＣＩパラメータの２つまたはそれ以上のセットを含み、ＤＣＩパラメータの第１のセット以外のＤＣＩパラメータの前記セットの各々が、別の端末デバイスのためのＤＣＩパラメータの前のセットに対するオフセットによって規定される、請求項２５に記載の方法。
28. 前記２つまたはそれ以上の応答が、それぞれ、２つまたはそれ以上の端末デバイスを対象とし、前記リソース設定情報が巡回シフトインデックスのセットを指示し、巡回シフトインデックスの前記セットが、１つのＰＤＳＣＨ上で多重化された前記２つまたはそれ以上の応答とともに前記２つまたはそれ以上の端末デバイスによって使用されることが可能である、請求項２４に記載の方法。
29. 巡回シフトインデックスの前記セット中の巡回シフトインデックスの量を、巡回シフトインデックスの前記量が前記端末デバイスの量よりも少ないことに応答して、拡張することをさらに含む、請求項２８に記載の方法。
30. 前記２つまたはそれ以上の端末デバイスの前記フィードバックが、
    復調用参照信号、
    前記応答メッセージ中の前記２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
    プリアンブルＩＤ、
    ＰＵＳＣＨリソースユニット、
    競合解消ＩＤ、および
    端末デバイスＩＤ
    のうちの少なくとも１つによって識別されることが可能である、請求項２４に記載の方法。
31. 前記２つまたはそれ以上の応答が、それぞれ、２つまたはそれ以上の端末デバイスを対象とし、前記２つまたはそれ以上の端末デバイスが、同じＰＵＣＣＨリソース上でフィードバックを送信する、請求項２４に記載の方法。
32. 前記２つまたはそれ以上の端末デバイスの前記フィードバックが、
    異なる復調用参照信号、
    前記応答メッセージ中の前記２つまたはそれ以上の端末デバイスのそれぞれの情報レコードの包含の順序、
    プリアンブルＩＤ、
    ＰＵＳＣＨリソースユニット、
    競合解消ＩＤ、および
    端末デバイスＩＤ
    のうちの少なくとも１つによって識別されることが可能である、請求項３１に記載の方法。
33. 前記応答メッセージが、１つの成功応答またはフォールバック応答を含み、前記リソース設定情報が、
    少なくとも１つのＤＣＩパラメータ、および
    ブロードキャストメッセージの少なくとも１つのパラメータ
    のうちの少なくとも１つを含む、請求項２３に記載の方法。
34. 前記リソース設定情報が、
    （ａ）ＰＵＣＣＨリソースインジケータおよびＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータ、
    （ｂ）ＰＤＳＣＨ－ｔｏ－ＨＡＲＱフィードバックタイミングインジケータおよびｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ設定、
    （ｃ）ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ情報エレメント、ならびに
    （ｄ）応答ウィンドウサイズおよびシステムフレーム番号
    のうちの少なくとも１つを含む、請求項３３に記載の方法。
35. 前記ＵＬリソースがＰＵＳＣＨリソースである、請求項１９から２２のいずれか一項に記載の方法。
36. 前記応答がランダムアクセス応答である、請求項１９から３５のいずれか一項に記載の方法。
37. 端末デバイス（６００）であって、
    １つまたは複数のプロセッサ（６０１）と、
    コンピュータプログラムコード（６０３）を備える１つまたは複数のメモリ（６０２）と
    を備え、
    前記１つまたは複数のメモリ（６０２）および前記コンピュータプログラムコード（６０３）が、前記１つまたは複数のプロセッサ（６０１）とともに、前記端末デバイス（６００）に、少なくとも、
    ネットワークノードからリソース設定情報を受信することと、
    前記受信されたリソース設定情報に基づいて、２ステップランダムアクセスプロシージャにおける前記ネットワークノードからの応答メッセージへのフィードバックのためのＵＬリソースを決定することと
    を行わせるように設定された、端末デバイス（６００）。
38. 前記１つまたは複数のメモリおよび前記コンピュータプログラムコード（６０３）が、前記１つまたは複数のプロセッサとともに、前記端末デバイスに、請求項２から１８のいずれか一項に記載の方法を実施させるように設定された、請求項３７に記載の端末デバイス。
39. その上に具現されたコンピュータプログラムコードを有するコンピュータ可読媒体であって、前記コンピュータプログラムコードが、コンピュータ上で実行されたとき、前記コンピュータに、請求項１から１８のいずれか一項に記載の方法の任意のステップを実施させる、コンピュータ可読媒体。
40. ネットワークノード（６００）であって、
    １つまたは複数のプロセッサ（６０１）と、
    コンピュータプログラムコード（６０３）を備える１つまたは複数のメモリ（６０２）と
    を備え、
    前記１つまたは複数のメモリ（６０２）および前記コンピュータプログラムコード（６０３）が、前記１つまたは複数のプロセッサ（６０１）とともに、前記ネットワークノード（６００）に、少なくとも、
    ２ステップランダムアクセスプロシージャにおける応答メッセージへの端末デバイスのフィードバックのためのＵＬリソースを指示するリソース設定情報を決定することと、
    前記リソース設定情報を前記端末デバイスに送信することと
    を行わせるように設定された、ネットワークノード（６００）。
41. 前記１つまたは複数のメモリおよび前記コンピュータプログラムコードが、前記１つまたは複数のプロセッサとともに、前記ネットワークノードに、請求項２０から３６のいずれか一項に記載の方法を実施させるように設定された、請求項４０に記載のネットワークノード。
42. その上に具現されたコンピュータプログラムコード（６０３）を有するコンピュータ可読媒体であって、前記コンピュータプログラムコードが、コンピュータ上で実行されたとき、前記コンピュータに、請求項１９から３６のいずれか一項に記載の方法の任意のステップを実施させる、コンピュータ可読媒体。
    

Images