JP2022177320A - 無線端末、基地局、無線端末における方法及び基地局における方法 - Google Patents

Abstract

【課題】ＵＥによる使用が見込まれる特定のＰＵＣＣＨリソースをＵＥが決定できるようにする方法および装置を提供する。【解決手段】基地局が、システム帯域幅を有しかつ関連付けされたセルを介してＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ機器）と通信を行う通信システムにおいて、ＵＥは、基地局から、ＰＵＣＣＨフォーマット、開始シンボル、シンボルの数、及び、ＣＳ（Ｃｙｃｌｉｃ Ｓｈｉｆｔ：巡回シフト）インデックスの１つの組を示すビット列を受信する手段と、当該ビット列に基づく前記１つの組に基づいて、ＰＵＣＣＨリソースを決定する手段と、を備える。【選択図】図６

Description

本発明は、無線端末、基地局、無線端末における方法及び基地局における方法に関する。特に、本発明は、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）規格、またはこれと同等もしくは派生の規格に従って動作する無線端末、基地局及びそれらにおける方法に関するが、これらに限定されない。特に、本発明は、いわゆる「次世代」システムにおける制御チャネルの提供およびリソース割り当てに関するが、これらに限定されない。

３ＧＰＰ規格の最新動向は、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）ネットワークおよびＥ－ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）と呼ばれ、一般に４Ｇとも呼ばれる。さらに、５ＧおよびＮＲ（Ｎｅｗ Ｒａｄｉｏ）という用語は、種々のアプリケーションおよびサービスをサポートすることが期待される発展中の通信技術を指す。５Ｇネットワークの種々の詳細は、例えば、ＮＧＭＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋｓ）アライアンスによるＮＧＭＮ ５Ｇ Ｗｈｉｔｅ Ｐａｐｅｒ Ｖ１．０に説明されており、当該文書は、ｈｔｔｐｓ：／／ｗｗｗ．ｎｇｍｎ．ｏｒｇ／５ｇ－ｗｈｉｔｅ－ｐａｐｅｒ．ｈｔｍｌから入手可能である。３ＧＰＰは、いわゆる３ＧＰＰ ＮｅｘｔＧｅｎ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ）ＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線アクセスネットワーク）および３ＧＰＰ次世代コアネットワークを介して５Ｇをサポートすることが予定されている。３ＧＰＰ ＴＳ（Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）２３．７９９ Ｖ１４．０．０には、３ＧＰＰ規格のＲｅｌｅａｓｅ１４用に検討されているＮｅｘｔＧｅｎ（５Ｇ）システムの全体的なアーキテクチャと一般的な手順とが記載されている。３ＧＰＰでは、新しい（５Ｇ）無線アクセスネットワーク用に最大１００ＧＨｚまでの周波数帯域を使用する可能性についても、検討を進めている。

３ＧＰＰ規格では、ＮｏｄｅＢ（またはＬＴＥにおける「ｅＮＢ」、５Ｇにおける「ｇＮＢ」など）は、通信デバイス（ユーザ機器、すなわち「ＵＥ」）がコアネットワークに接続し、他の通信デバイスまたはリモートサーバと通信を行うための基地局である。簡略化のため、本出願において、基地局という用語はそのような任意の基地局を指し、モバイルデバイスまたはＵＥという用語は、そのような任意の通信デバイスを指すものとする。コアネットワーク（すなわち、ＬＴＥの場合のＥＰＣ）は、加入者管理、モビリティ管理、課金、セキュリティ、および呼セッション管理（など）の機能を統括し、通信デバイスをインターネットなどの外部ネットワークに接続させる。

通信デバイスは、例えば、モバイル電話、スマートフォン、ユーザ機器、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザ、電子書籍リーダなどのモバイル通信デバイスであってもよい。このようなモバイル（または一般的には固定の）デバイスは、通常はユーザによって操作されるが、いわゆるＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ：モノのインターネット）デバイス、および同様のマシン型の通信（ＭＴＣ）デバイスをネットワークに接続することも可能である。簡略化のため、本出願は、明細書中においてモバイルデバイス（またはＵＥ）を参照するが、本明細書に記載の技術は、任意の（モバイルおよび／または一般的には固定の）通信デバイス上で実施可能であり、当該通信デバイスが、人による入力によって制御されるか、またはメモリに格納されたソフトウェア命令によって制御されるかに関わらず、通信ネットワークに接続してデータの送受信を行うことが可能であることが理解されうる。

通信の最近の発展のより、人による支援なしで通信を行い動作するように構成されたネットワークデバイスであるＭＴＣデバイスの使用が大幅に増加している。このようなデバイスの例には、測定を行い、これらの測定結果を通信ネットワークを介して他のデバイスに中継するように構成可能なスマートメーターが含まれる。ＭＴＣデバイスに関する規格は、下りリンクおよび上りリンクにおいて１．４ＭＨｚに削減された帯域幅をサポートする。このように、一部のＭＴＣデバイス（「帯域幅削減ＭＴＣデバイス」と呼ばれる）は、システム全体の帯域幅と比較して限られた帯域幅（通常１．４ＭＨｚ）のみをサポートしてもよいし、および／または、少ない／簡略化された構成要素を有してもよい。これにより、このような「帯域幅削減」ＭＴＣデバイスは、より大きな帯域幅をサポートする及び／又はより複雑な構成要素を有するＭＴＣデバイスと比較して、経済的に製造することができる。他のタイプのＭＴＣデバイスおよび／またはＵＥは、（これらのデバイスがサポートする帯域幅が１．４ＭＨｚよりも大きい場合であっても）いくつかのセルで使用されるシステム帯域幅よりも小さい異なる帯域幅をサポートしてもよいことが理解されうる。

基地局を介して通信を行うためには、通信デバイスは、基地局によって運用される制御チャネルを監視する必要がある。物理制御チャネルは、１つまたは複数の連続したＣＣＥ（Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ Ｅｌｅｍｅｎｔ：制御チャネル要素）の集合体で送信される。これらの物理制御チャネルの１つである、いわゆるＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ：物理下りリンク制御チャネル）は、下りリンク割り当てのスケジューリングと、関連する制御情報とを個々の通信デバイスに伝送する。いわゆるＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ：物理上りリンク制御チャネル）は、「ＵＣＩ（Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ：上りリンク制御情報）」と呼ばれる情報のセットを、通信デバイスからサービング基地局に伝送する。ＵＣＩは、特に、通信デバイスによって生成され、基地局から受信した下りリンクデータ送信に応じてサービング基地局に送信される、いわゆるＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ：ハイブリッド自動再送要求）フィードバックを含む。ＵＣＩは、ＣＱＩ（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｉｏｎ：チャネル品質表示）を含んでもよいが、これはオプションである。ＮｅｘｔＧｅｎシステムでは、物理上りリンク制御チャネルは、「ＮＲ－ＰＵＣＣＨ」と呼ばれてもよいことが理解されうる。

ＬＴＥでは、セルに適用される特定の構成に応じて、ＰＵＣＣＨ領域は、通常、「スロットホッピング」をサポートするために、システム帯域幅の両端を占有する（スロットホッピングは、セル帯域幅の両端間でＰＵＣＣＨ物理リソースの位置を頻繁に変更することによって周波数ダイバーシティを向上させる手法であり、ＵＥでの信号受信を向上するのに役立つ）。ただし、この既存の（ＬＴＥ固有の）設計を５ＧＮＲシステムに再利用することは容易ではない。これは、異なるアプリケーションシナリオ用に設計された異なるＵＥ（例えば、ＭＴＣデバイス）に搭載されうるトランシーバは、サポートする動作帯域幅が異なり、当該動作帯域幅がシステム帯域幅よりも小さい可能性があるためである。したがって、ほとんどのＵＥがシステム帯域幅全体（ＮＲでは最大１ＧＨｚ）での同時受信をサポートすることが見込まれる一方で、（所定のセルのシステム帯域幅と比較して）帯域幅が比較的制限されている一部のＵＥ（ＭＴＣデバイスなど）は、システム帯域幅の端部付近で送信されるＰＵＣＣＨデータをすべて正常に受信することができない。

この問題に対処するために、３ＧＰＰでは、部分帯域に対するＰＵＣＣＨリソースの割り当てとＮＲ用の新しいＰＵＣＣＨ設計に関する議論が続けられている。本コンテキストにおいて、「ＢＷＰ」（ＢａｎｄＷｉｄｔｈ Ｐａｒｔ：部分帯域）という用語は、特定のＵＥ（またはＵＥのグループ）がサポートする無線周波数帯域幅と実質的に同じ（またはよりも小さい）帯域幅を有するシステム帯域幅の（連続する）部分を指す。ＢＷＰを提供することは、例えば、所定のセル内のシステム帯域幅よりも小さい動作帯域幅を有するＭＴＣデバイスなどに特に有益となり得る。（例えば、ＵＥ固有の）ＰＵＣＣＨ領域は、所定のＢＷＰの端部付近、すなわち、当該ＢＷＰを使用するＵＥがサポートする無線周波数帯域幅内に提供されうることが理解されうる。３ＧＰＰは、ＰＵＣＣＨが設定される各サービングセルにおいて、削減されたＵＥ帯域幅能力をワイドバンドキャリア内でサポートするために、設定された各ＵＬ ＢＷＰに関連するＰＵＣＣＨリソースを含むことに合意した。３ＧＰＰは、サービングセル内において所定のＵＥに設定された下りリンク（または上りリンク）ＢＷＰが、当該セル内において設定された別の下りリンク（または上りリンク）ＢＷＰと周波数領域で重複しうることも予測している。

ただし、（システム帯域幅の端部付近のＰＵＣＣＨ領域とは異なり）ＵＥによってサポートされる無線周波数帯域幅の端部付近にＰＵＣＣＨ領域を割り当てると、基地局に利用可能な周波数スペクトルが断片的に利用されることになり、連続して上りリンクを送信することが妨害される可能性がある（一部のＵＥのＰＵＣＣＨ領域をシステム帯域幅の端部付近以外の場所に設ける必要があるため、この結果、データ送信に使用できるシステム帯域幅の一部が断片化される）。セル内に複数のＢＷＰを設けた場合、特定のＢＷＰのチャネルが、異なるＢＷＰの１つ以上のチャネルと（少なくとも部分的に）重複し、これらのチャネル間で衝突が発生する可能性があることが理解されうる。例えば、第１ＢＷＰのＰＵＣＣＨと、第２ＢＷＰのいわゆるＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ ＣＨａｎｎｅｌ：物理上りリンク共有チャネル）との間で衝突が発生する可能性がある。

図４は、ＮＲシステムにおいてＢＷＰ固有のＰＵＣＣＨを提供するためのいくつかのオプション及び潜在的な問題を概略的に示す。具体的には、「オプションＡ」は、各ＵＬ ＢＷＰのＰＵＣＣＨリソースの割り当てに既存のＬＴＥ設計を単純に再利用すると、同一スロット内の周波数領域で重複する（図４で「ＢＷＰ１」および「ＢＷＰ２」と表示される）ＢＷＰにおいてＰＵＳＣＨおよび／またはＰＵＣＣＨの衝突が引き起こされる可能性があることを示す。ＰＵＳＣＨ１／ＰＵＣＣＨ１およびＰＵＳＣＨ２／ＰＵＣＣＨ２は、それぞれＢＷＰ１およびＢＰＷ２のＰＵＳＣＨ／ＰＵＣＣＨを示す。あるいは、「オプションＢ」に示すように、基地局は、２つの重複するＢＷＰのうちの１つのＰＵＳＣＨ（例えば、ＰＵＳＣＨ誤り率の要件が緩和されたＢＷＰ）について削減された帯域幅をスケジューリングすることで、当該２つのＢＷＰ間のＰＵＳＣＨ衝突に対処するように構成されてもよい。ただし、この場合でも、チャネル「ＰＵＣＣＨ１」は「ＰＵＳＣＨ２」と衝突するため、ＢＷＰ２のリソースが断片化する。このような断片化は、上記ＰＵＣＣＨ２よりも上の領域に、対応するＰＵＣＣＨ１のリソースを設定可能な場合にのみ回避することができる。ただし、このオプションによって、システム設計が複雑になり、ＰＵＣＣＨリソースを設定および指示するための統合ソリューションの適用が妨げられる可能性がある。これは、例えば、図４の「オプションＣ」に示すように、ネットワークの観点から同一スロット内のＵＬ ＢＷＰの重複を最小限に抑えることで回避することができる。

表６は、異なるＰＵＣＣＨフォーマットのＰＵＣＣＨリソース割り当てのパラメータのセットと、これらのパラメータの取り得る値の範囲とを示す。３ＧＰＰでは、各ＵＥが、それに関連するＰＵＣＣＨリソースを識別するために、ＰＵＣＣＨがどのスロットで基地局によって送信されるかを把握すると予測している。３ＧＰＰは、ＮＲシステムにおいて上位レイヤシグナリングを介して（基地局からＵＥへ）ＰＵＣＣＨリソースセットを設定することができ、設定されたセット内においてＰＵＣＣＨリソースをＤＣＩで指示することに合意した。また、少なくともＵＥがその個別ＰＵＣＣＨリソースを把握していない場合には、適切なＰＵＣＣＨリソースを決定するためのルールを規定することも合意がされている（ただし、このようなＰＵＣＣＨリソース決定ルールの詳細は、黙示的なリソースマッピングおよび／または明示的なシグナリングを使用するかどうかなどを含め、今後の検討事項である）。

したがって、ＰＵＣＣＨリソースセットは、上位レイヤシグナリング（例えば、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ：無線リソース制御）シグナリング）を介してＵＥに設定され、ハイブリッド自動再送要求（ハイブリッドＡＲＱまたはＨＡＲＱ）フィードバック（「ＨＡＲＱ－ＡＣＫ」）を送信するための、設定されたセット内の特定のＰＵＣＣＨリソースは、ＤＣＩによってＵＥに動的に指示されることが予想される。しかしながら、ＲＲＣ設定が完了するまでは、ＵＥ側でＰＵＣＣＨリソースセットが認識されない。例えば、ＵＥは、既に、４ステップランダムアクセス手順の最後のメッセージ（「Ｍｓｇ４」）に対するＨＡＲＱ－ＡＣＫフィードバックを提供する必要がある。ただし、このメッセージは、ＲＲＣ設定が完了する前、すなわち、基地局がＵＥの上位レイヤシグナリングを実行できるようになる前、および３ＧＰＰで予測されるように、当該ＵＥのＰＵＣＣＨリソースのセットを設定できるようになる前に受信される。ＵＥが、割り当てられたＰＵＣＣＨリソース上でＨＡＲＱ－ＡＣＫを送信できるようにするために、さまざまな明示的および黙示的なアプローチが提案されているが、ＢＷＰを用いる場合のＮＲでのＰＵＣＣＨリソース割り当ての問題にどのように対処するかについては、３ＧＰＰにおいて何ら合意がされていない。

したがって、本発明の望ましい例示的な実施形態は、効率および柔軟性を確保しながら上記の問題に対処するために使用される代替方法および装置であり、ＵＥによる使用が見込まれる特定のＰＵＣＣＨリソースをＵＥが決定できるようにする代替方法および装置を提供することを目的とする。

当業者の理解を効率化するために、本発明は３ＧＰＰシステム（５Ｇネットワーク）のコンテキストで詳細に説明するが、本発明の原理は他のシステムにも適用することができる。

例示的な一態様において、本発明は、ＵＥ（ユーザ機器）によって実行される、上りリンク通信用の周波数リソースを識別する方法を提供し、上記方法は、ランダムアクセス手順を開始すること、上りリンクチャネル用の周波数リソースのセットを識別する第１の情報を取得すること、上記上りリンク通信用に、上記周波数リソースのセット内の少なくとも１つの特定の周波数リソースを識別する第２の情報を取得すること、および上記第１の情報および上記第２の情報に基づいて、上記上りリンク通信用の上記周波数リソースを識別することを含み、上記第１の情報は、ランダムアクセス手順が完了する前に取得される。

別の例示的な態様において、本発明は、ＵＥによる上りリンク通信の周波数リソースを識別する基地局によって実行される方法を提供し、上記方法は、上記ユーザ機器に対するランダムアクセス手順を開始すること、上りリンクチャネル用の周波数リソースのセットを識別する第１の情報を提供すること、および上記上りリンク通信用に、上記周波数リソースのセット内の少なくとも１つの特定の周波数リソースを識別する第２の情報を提供することを含み、上記第１の情報は、ランダムアクセス手順が完了する前に提供される。

本発明の例示的な態様は、対応する装置と、システムと、プログラム可能なプロセッサをプログラムして上記例示的な態様に記載の方法および特許請求の範囲に記載の可能性を実施させ、および／または好適に適合したコンピュータをプログラムして任意の請求項に記載の装置を提供させるように動作可能な命令を格納する、コンピュータ読取可能な記憶媒体などのコンピュータプログラムとに及ぶ。

本明細書（特許請求の範囲を含む）に開示されるおよび／または図面に示される各特徴は、他の開示されるおよび／または図示される特徴とは独立して（または組み合わせて）本発明に組み込まれてもよい。特に、特定の独立請求項に従属する請求項の特徴は、任意の組み合わせで、または個別にその独立請求項に導入することができるが、限定的ではない。

ここで、添付図面を参照して、本発明の例示的な実施形態の例を説明する。

図１は、本発明の例示的な実施形態を適用可能なセルラ通信システムを概略的に示す図である。 図２は、図１に示すシステムの一部を形成するモバイルデバイスの概略ブロック図である。 図３は、図１に示すシステムの一部を形成する基地局の概略ブロック図である。 図４は、図１に示す基地局のシステム帯域幅の一部を形成する部分帯域内で制御チャネルを提供するために使用可能ないくつかのオプションを概略的に示す図である。 図５は、図１に示す基地局のシステム帯域幅の部分帯域内のいくつかの例示的なサブバンドを概略的に示す図である。 図６は、図１に示すシステムの構成要素によって実行される方法を概略的に示す例示的なシグナリング（タイミング）図である。

＜概要＞
図１は、ユーザ機器３（携帯電話および／または他のモバイルデバイス）が適切なＲＡＴ（無線アクセス技術）を使用して基地局５（例えば、ＮＲネットワークの「ｇＮＢ」）を介して相互に通信を行うことができる（セルラ）通信ネットワーク１を概略的に示す。５Ｇシステムにおいて、基地局は１つまたは複数のＴＲＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ：送受信ポイント）を含むものとする。当業者が理解するように、図１が６つのＵＥ３と１つの基地局５を例示目的で示す一方で、システムの実装時には、通常、他の基地局およびモバイルデバイスも含まれる。

各基地局５は、基地局に位置するＴＲＰ（および／または遠隔に位置する１つまたは複数のＴＲＰ）を介して関連付けされた１つまたは複数のセルを運用する。この実施例では、説明の簡略化のため、基地局５は、関連するシステム帯域幅を有する単一のセルを運用する。基地局５は（例えば、適切なゲートウェイおよび／またはユーザプレーン／制御機能を介して）コアネットワーク７に接続され、隣接する基地局も（直接または適切な基地局ゲートウェイを介して）相互に接続される。コアネットワーク７は、特に、制御プレーン管理エンティティおよびユーザプレーン管理エンティティ、ならびに基地局５と他のネットワーク（インターネットなど）および／またはコアネットワーク外でホストされるサーバーとの間の接続を提供するための１つまたは複数のゲートウェイ（ＧＷ）を含んでもよい。

各モバイルデバイス３は（その位置に応じて、あるいは適宜信号条件、サブスクリプションデータ、能力など他の要因に応じて）適切なセルに、当該セルを運用する基地局５とＲＲＣ接続を確立することで、接続することができる。このようなＲＲＣ接続の確立のために、モバイルデバイス３は、基地局５に対していわゆるランダムアクセス手順を実行する必要があり、この手順は通常４つのメッセージ（「Ｍｓｇ１」から「Ｍｓｇ４」と呼ばれる）を含む。モバイルデバイス３および基地局５（およびネットワーク内の他の送信ポイント）は、使用されるＲＡＴに依存する適切なエアインターフェースを介して通信を行う。モバイルデバイス３は、モバイルデバイス３と適切なコアネットワークノードとの間でモバイルデバイス３のサービング基地局５／ＴＲＰによって中継される、いわゆるＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ：非アクセス層）シグナリングを使用してコアネットワークノードと通信を行う。

一部のモバイルデバイス３－１は、比較的広い帯域幅（例えば、基地局５のセルのシステム帯域幅全体）において通信を行うことができる適切なトランシーバ回路を具備するモバイル電話など（スマートフォンなど）の従来のユーザ機器を含んでもよい。他のモバイルデバイス３－２（ＭＴＣデバイスなど）は、比較的狭い帯域幅（例えば、基地局５のセルのシステム帯域幅よりも小さい帯域幅）において同時通信をサポートするトランシーバ回路を具備してもよい。

モバイルデバイス３－１および３－２の両方のタイプ（および潜在的に他のタイプのＵＥ）をサポートするために、この実施例における基地局５は、システム帯域幅内の１つまたは複数のＢＷＰを割り当て、各ＢＷＰは特定の動作帯域幅（システム帯域幅よりも小さいが、システム帯域幅を超えない）をサポートするように構成される。基地局５の観点からは、複雑なスケジューラアルゴリズム設計や、ＰＵＣＣＨリソース設定および指示メカニズムを不要とするためには、同一スロット内のＵＬ ＢＷＰの周波数領域における重複を最小化することが有益と考えられる。

さらに、基地局５は、モバイルデバイス３が、基地局５とのＲＲＣ接続が確立されていない場合であっても当該モバイル３に割り当てられたＰＵＣＣＨリソースを決定できるように、各モバイルデバイス３に適切な（ＵＥ固有の）ＰＵＣＣＨリソースを指示するように構成される。

より詳細には、基地局５は、明示的メカニズムまたは黙示的メカニズムのいずれか（または両方）を用いて、所定のＢＷＰ内におけるＰＵＣＣＨリソースの割り当てを指示してもよい。

基地局５が明示的な指示を使用する場合、基地局５は、（ＵＥ固有の）ＰＵＣＣＨリソースセットを示す適切な情報を（いわゆる残存最小システム情報などを介して）ブロードキャストするように構成されてもよい。さらに、基地局５は、ＰＵＣＣＨ送信に使用される特定のリソース（例えば、潜在的なＰＵＣＣＨリソースセットからの単一のリソース）を所定のモバイルデバイス３に示すように構成されてもよい。例えば、基地局５は、「Ｍｓｇ４」（ランダムアクセス手順の最後の４番目のメッセージ）のＤＣＩスケジューリングで適切なフィールドを使用してもよい。したがって、基地局５とのＲＲＣ接続の確立が完了する前に、モバイルデバイスにＰＵＣＣＨリソースの割り当てを示すことが可能である。

基地局５は、明示的な指示をブロードキャストする代わりに、適切にフォーマットされたランダムアクセス応答（すなわち、「Ｍｓｇ４」に先行する「Ｍｓｇ２」）でＰＵＣＣＨリソースセットを示すように構成されてもよいものとする。

基地局５が、（潜在的な）ＰＵＣＣＨリソースセットの黙示的な指示を使用する場合、適用可能な（ＵＥ固有の）ＰＵＣＣＨリソースは、いわゆるＲＭＳＩ（Ｒｅｍａｉｎｉｎｇ Ｍｉｎｉｍｕｍ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ：残存最小システム情報）を介してブロードキャストされる適切なセル固有パラメータ（例えば、Ｎ_{ｐｕｃｃｈ１}）に基づいて、モバイルデバイス３によって決定されてもよい。この場合、Ｍｓｇ４のＰＵＣＣＨリソースは、例えば、Ｎｐｕｃｃｈ１＋_{ｎＣＣＥ＿ｉｎｄｅｘ}（ｎ_{ＣＣＥ＿ｉｎｄｅｘ}は、Ｍｓｇ４をスケジューリングするＰＤＣＣＨのＣＣＥに関連付けされた最初のインデックスを示す）など、モバイルデバイス３に既知の適切な式に基づいて導出してもよい。

有利には、明示的な指示と黙示的な決定の組み合わせを使用して、ＰＵＣＣＨリソースを動的にシグナリングし、オーバーヘッドを（他の方法と比較して）削減することができる。基地局５がこの方法に従うように構成される場合、割り当てられたＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、以下の式を用いて導出してもよい：

別の実施例では、Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信用に割り当てられたＰＵＣＣＨリソース（_{ｎＰＵＣＣＨ，ＲＩ}）は、以下の式を用いて導出してもよい：

あるいは、特定のＰＲＢ内のＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、例えば、検出されたＰＤＣＣＨ ＤＣＩによって別途シグナリングされたインデックスｋによって識別してもよい。この場合、インデックスｋのシグナリングには２または３ビットあれば十分であり、それぞれＫ＝４または８である。このアプローチにより、基地局５は、例えば、衝突を回避するために、（ＰＵＣＣＨリソースに対して）リソースインデックスを柔軟に割り当ててもよい。

上記両方の代替案について、インデックスｋ（所定のＰＲＢ内の特定のＰＵＣＣＨリソースに関連付けされたインデックスを表す）は、所定のルックアップテーブルなど（モバイルデバイス３と基地局５が事前に把握している）によってＣＳ（Ｃｙｃｌｉｃ Ｓｈｉｆｔ：巡回シフト）およびＯＣＣ（Ｏｒｔｈｏｇｏｎａｌ Ｃｏｖｅｒ Ｃｏｄｅ：直交カバーコード）の少なくとも一方にマッピングされてもよい。

他の適切な式を用いてもよいし、ＢＷＰを（リソースの断片化を避けるために）複数のサブバンドに分割して、各サブバンドが連続するＰＲＢのセットを含んでもよいものとする。この場合、割り当てられたＰＵＣＣＨリソースは特定のサブバンド内で提供される。

＜モバイルデバイス＞
図２は、図１に示すモバイルデバイス３の主な構成要素（例えば、モバイル電話、他のユーザ機器など）を示す概略ブロック図である。図示されるように、モバイルデバイス３は、１つまたは複数のアンテナ３３を介して基地局５に信号を送信し、基地局５から信号を受信するように動作可能なトランシーバ回路３１を有する。モバイルデバイス３は、モバイルデバイス３の動作を制御するコントローラ３７を有する。コントローラ３７はメモリ３９に関連付けられ、トランシーバ回路３１に接続される。モバイルデバイス３は、動作に際して必ずしも必要ではないが、従来のモバイル電話３の標準的な機能（ユーザインタフェース３５など）をすべて備えてよいことは明らかであり、当該機能は、ハードウェア、ソフトウェアおよびファームウェアのいずれか１つまたはこれらの任意の組み合わせによって適宜提供されてもよい。ソフトウェアは、メモリ３９に事前にインストールしてもよいし、および／または、例えば、通信ネットワークを介して、またはＲＭＤ（リムーバブルデータ格納デバイス）からダウンロードしてもよい。

コントローラ３７は、この例では、メモリ３９内に格納されたプログラム命令またはソフトウェア命令によって、モバイルデバイス３全体の動作を制御するように構成される。図示されるように、これらのソフトウェア命令は、特に、オペレーティングシステム４１、通信制御モジュール４３、およびオプションのＭＴＣモジュール４５を含む。

通信制御モジュール４３は、モバイルデバイス３とそのサービング基地局５との間の通信（および当該基地局５に接続される、他のモバイルデバイス、コアネットワークノードなどの他の通信デバイスとの通信）を制御するように動作可能である。
通信制御モジュール４３は、関連付けされた上りリンクチャネルを介した上りリンク通信を処理するためのＰＵＣＣＨおよびＰＵＳＣＨ部分も（特に）含む。説明の簡略化のため図２には示されていないが、通信制御モジュール４３は、通常、関連付けされた下りリンクチャネルを介した下りリンク通信を処理するためのＰＤＣＣＨおよびＰＤＳＣＨ部分も含む。通信制御モジュール４３は、モバイルデバイス３が使用するリソースを決定し、どの部分帯域（サブバンド）をモバイルデバイス３に割り当てるかを（例えば、トランシーバ回路３１によってサポートされる帯域幅に基づいて）決定する役割を担う。モバイルデバイス３が使用する適切なリソースは、適宜１つまたは複数の式および／または（所定の）ルックアップテーブルに基づいて決定してもよい。トランシーバ回路３１がサポートする動作帯域幅（または現在の動作帯域幅）は、モバイルデバイス３が従来のＵＥとして動作するか、マシンタイプのデバイスとして（関連付けされたＭＴＣモジュール４５を使用して）動作するかに依存してもよいものとする。

ＭＴＣモジュール４５が存在する場合、当該ＭＴＣモジュール４５は、適切な（例えば、ソフトウェア）命令に従ってマシンタイプの通信タスクを実行する役割を担う。

＜基地局＞
図３は、図１に示す基地局５の主な構成要素を示す概略ブロック図である。図示されるように、基地局５は、１つまたは複数のアンテナ５３（例えば、アンテナアレイ／大規模アンテナ）を介して通信デバイス（モバイルデバイス３／ユーザ機器など）と信号の送受信を行うトランシーバ回路５１と、コアネットワーク７のネットワークノードと信号の送受信を行うコアネットワークインターフェース５５（ＮＲでは「Ｎ２」インターフェースと呼ばれる）とを有する。図示されていないが、基地局５は、適切なインターフェース（例えば、ＮＲのいわゆる「Ｘｎ」インターフェース）を介して他の基地局に結合してもよい。基地局５は、基地局５の動作を制御するコントローラ５７を有する。コントローラ５７はメモリ５９に関連付けられる。ソフトウェアは、メモリ５９に事前にインストールしてもよいし、例えば、通信ネットワーク１を介して、またはＲＭＤ（リムーバブルデータ格納デバイス）から、ダウンロードしてもよい。コントローラ５７は、この例では、メモリ５９内に格納されたプログラム命令またはソフトウェア命令によって基地局５の全体的な動作を制御するように構成される。図示されるように、これらのソフトウェア命令は、特に、オペレーティングシステム６１、通信制御モジュール６３、および部分帯域モジュール６５を含む。

通信制御モジュール６３は、基地局５と、モバイルデバイス３（ユーザ機器）および基地局５に接続された他のネットワークエンティティとの間の通信を制御するように動作可能である。また、通信制御モジュール６３は、当該基地局５に関連付けされた通信デバイスに（関連付けされたデータ無線ベアラを介して）送信される下りリンクユーザトラフィックおよび制御データの個別のフローを制御し、これには、例えば、特定のモバイルデバイス３が使用する適切な部分帯域（必要に応じてサブバンドを含む）と、関連付けされたＢＷＰ内（例えば、ＢＷＰおよび／またはサブバンドに関連する）の（制御／データ）チャネルを伝送する１つまたは複数のリソースの位置を決定するための制御データも含まれる。

部分帯域モジュール６５は、基地局５によってサービスが提供されるモバイルデバイス３に（複数のサブバンドを含む場合がある）適切なＢＷＰを割り当てる役割を担う。部分帯域モジュール６５は、特定のモバイルデバイス３に（そのＢＷＰ内において）割り当てられた適切なＰＵＣＣＨリソースを明示的および／または黙示的に示す役割も担う。

上の説明では、理解を容易にするため、モバイルデバイス３および基地局５が複数の個別モジュール（通信制御モジュールなど）を備えるものとして説明された。これらのモジュールは、例えば、本発明を実施するために既存のシステムに変更を加えた特定のアプリケーションについては上述のような方法で提供することができるが、例えば最初から発明の特徴を念頭に置いて設計されたシステムなどの他のアプリケーションについては、これらのモジュールをオペレーティングシステムまたはコード全体に組み込んでもよく、この場合、これらのモジュールは個別のエンティティとして認識されなくてもよい。これらのモジュールは、ソフトウェア、ハードウェア、ファームウェア、またはこれらの組み合わせで実装されてもよい。

＜オペレーション＞
上で説明したように、基地局５は、そのセル内に複数の帯域幅の部分を設けてもよく、当該帯域幅の部分はさらに複数のサブバンド（など）を含んでもよい。モバイルデバイス３は、その能力に応じて（例えば、当該モバイルデバイス３のトランシーバ回路３１の現在の／サポートする動作帯域幅に応じて）当該帯域幅の部分の１つに割り当てられてもよい。

基地局５は、関連付けされたＰＵＣＣＨリソースセット（ＲＲＣ設定の完了前であってもモバイルデバイス３が使用可能なＰＵＣＣＨリソースセット）を、モバイルデバイス３に（例えば、特定のサブバンド内において）割り当てるために、以下の方法のうちの１つ（または複数）を実行するように構成されてもよい。

方法１－明示的な指示
基地局５がこの方法に従うように構成される場合、（潜在的な）ＰＵＣＣＨリソースのセットをモバイルデバイス３に明示的に設定してもよい。例えば、基地局５は、モバイルデバイス３に設定された（ＵＥ固有の）ＰＵＣＣＨリソースセットを示す適切な情報を、例えば、ＲＭＳＩなどを介して、ブロードキャストするように構成されてもよい。別の実施例では、基地局５は、モバイルデバイス３が個別リソースを把握していない場合、適切にフォーマットされたランダムアクセス応答（ランダムアクセス手順の「ＲＡＲ」または「Ｍｓｇ２」）でＰＵＣＣＨリソースセットを示すように構成されてもよい。

基地局５は、さらに、例えば、「Ｍｓｇ４」（ランダムアクセス手順における４番目の最後のメッセージ）のＤＣＩスケジューリングにおける適切なフィールドおよび／または当該基地局５とのＲＲＣ接続の確立が完了する前にモバイルデバイス３が受信した他の任意の適切なメッセージを使用して、ＰＵＣＣＨ送信に使用される特定のリソース（例えば、潜在的なＰＵＣＣＨリソースセットからの単一のリソース）を示すように構成されてもよい。この場合、基地局５は、（Ｍｓｇ４に対する）ＨＡＲＱ－ＡＣＫフィードバックを送信するために設定したＰＵＣＣＨリソースの数が、ＰＵＣＣＨブロッキングを回避するのに十分大きいことを保証する必要がある（これは、複数のモバイルデバイス３が基地局５でランダムアクセス手順をほぼ同時に実行しようとした際に発生する可能性があり、この場合、ＰＵＣＣＨリソースセットは、これらすべてのモバイルデバイス３からのＨＡＲＱ－ＡＣＫフィードバックを伝送するのに十分ではない場合がある）。この問題は、例えば、リソースを過剰に設けることで解消できるが、場合によってはスペクトル効率に影響を及ぼす可能性もある。予め設定された共通のＰＵＣＣＨリソースを使用することによる無線リソースの非効率および／またはＰＵＣＣＨリソースのブロッキングを回避または削減するため、Ｍｓｇ４をスケジューリングするＤＣＩは、（所定のＵＥ用に）割り当てられたＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｃｅ Ｂｌｏｃｋ：物理リソースブロック）と、Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック用に割り当てられたシーケンス（例えば、ベースシーケンスの巡回シフト）とに関する情報を含むように構成することも可能であり、この場合、要求されるシグナリングオーバーヘッドは小さい。

ＰＲＢインデックスを明示的に指示する場合のシグナリングオーバーヘッドは、適切なＰＲＢ指示技術を採用することによって低減してもよい。例えば、ＢＷＰは、いくつかの仮想サブバンドに分割してもよく、各サブバンドは、それぞれ関連付けされたインデックス値を有する。図５に示す実施例では、ＢＷＰは「０」～「３」まで（「ＳＢ０」～「ＳＢ３」と表示）のインデックスが割り振られた４つのサブバンドに分割され、各サブバンドには（リソースの断片化を回避するために）連続するＰＲＢのセットが含まれる。他の実施例では、モバイルデバイス３および基地局５が、同じインデックス（予め設定されてもよいし、システム情報ブロードキャストなどを介して基地局によって示されてもよい）を使用するように構成されていれば、ＢＷＰ毎のサブバンド数は異なってもよい（例えば２、８、１６、．．．）。図５に示されるサブバンドはほぼサイズが等しいが、サイズの異なるサブバンドも適宜定義することで、さらなる柔軟性を得ることができるものとする。

図５に示される実施例では、モバイルデバイス３のＰＵＣＣＨ送信用に設定された特定のＳＢ（サブバンド）は、ＲＭＳＩの２ビットを用いて示してもよい（例えば、適切なフィールド／情報要素）。特定のサブバンド（サブバンドがＲＭＳＩで示されている場合）内のＰＲＢインデックスは、ＲＡＲ（Ｍｓｇ２）をスケジューリングするＤＣＩの［ｘ］ビットを使用して割り当ててもよいし、ＲＡＲメッセージ自体に含んでもよいものとする。例えば、Ｎ_ＰＲＢ値＝１００の場合（ここで、Ｎ_ＰＲＢはサブバンドあたりの物理リソースブロックの総数を示す）、ｘの最大ビット数（つまり、ｘ_ｍａｘ）は次のように導出することができる。

したがって、ＰＲＢ指示用に数ビットを確保できることがわかる。ただし、サブバンドの端部付近にＰＵＣＣＨリソースを割り当てる場合、ｘの値とｘｍａｘとは等しくなくてもよいため（ＰＲＢインデックスはサブバンドの端部から始まるため）、ＰＲＢシグナリングオーバーヘッドをさらに削減することができる。例えば、一番先頭のＰＲＢから始まる１６ＰＲＢを固定値として使用してもよく、この値は、初期アクセス中に割り当てる必要のあるリソース全体に対して十分である。

さらに、適切な初期ＣＳのインデックスは、２または３ビットを使用してＭｓｇ４をスケジューリングするＤＣＩにおいて示すことができる。なお、この場合、異なる巡回シフトがそれぞれ設定された複数のＵＥに同一ＰＲＢが割り当てられ、全体的なリソース使用効率の向上に貢献する。

方法２－黙示的な導出
また、基地局５は、モバイルデバイス３のための（潜在的な）ＰＵＣＣＨリソースセットを黙示的に設定してもよいものとする。基地局５が、この方法に従うように構成される場合、適用可能なＰＵＣＣＨリソースが、無線リソースを浪費することなくかつＰＵＣＣＨリソースをブロッキングすることなくモバイルデバイス３によって決定される一方で、関連付けされたＤＣＩオーバーヘッドも低減する。より詳細には、セル固有のパラメータ（例えば、Ｎ_{ｐｕｃｃｈ１}）がＲＭＳＩを介してブロードキャストされる場合、Ｍｓｇ４に対するＨＡＲＱフィードバックを送信するためのＰＵＣＣＨリソースをＮ_{ｐｕｃｃｈ１}＋ｎ_{ＣＣＥ＿ｉｎｄｅｘ}として導出してもよい（ｎ_{ＣＣＥ＿ｉｎｄｅｘ}は、Ｍｓｇ４をスケジューリングするＰＤＣＣＨのＣＣＥに関連付けされた最初のインデックスを示す）。

方法３－明示的指示と黙示的指示の組み合わせ
基地局５は、明示的な指示および黙示的な決定を組み合わせてＰＵＣＣＨリソースを動的にシグナリングするように構成されてもよく、この結果、オーバーヘッドが（他の方法と比較して）低減する可能性がある。基地局５がこの方法に従うように構成される場合、以下のオプションのいずれか１つを使用して特定のＰＵＣＣＨリソースを識別することができる：

オプション１：基地局５は、ＢＷＰの端部にＰＵＣＣＨリソースを割り当てるＬＴＥ設計の変更バージョンを使用するように構成されてもよく、この場合、リソースインデックス（ｎ_{ＰＵＣＣＨ，ＲＩ}）はｎ_{ＰＵＣＣＨ，ＲＩ}＝Ｎ_{ｐｕｃｃｈ１}＋ｎ_{ＣＣＥ＿ｉｎｄｅｘ}として導出してもよい（ｎ_{ＣＣＥ＿ｉｎｄｅｘ}は、Ｍｓｇ４をスケジューリングするＤＣＩのＣＣＥインデックスである）。したがって、この実施例では、モバイルデバイス３は、インデックスｎ_{ＰＵＣＣＨ，ＲＩ}に対応するリソース（ＰＲＢ）を介してＭｓｇ４に対するＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）を送信してもよい。有利には、Ｎ_{ｐｕｃｃｈ１}の送信に関連するオーバーヘッドを回避するために、ｎ_{ＣＣＥ＿ｉｎｄｅｘ}は、ｎ_{ＰＵＣＣＨ，ＲＩ}＝ｎ_{ＣＣＥ＿ｉｎｄｅｘ}の場合、ゼロ（または任意の固定値）に設定してもよい。

オプション２：ＢＷＰを４つのＳＢに分割することで、ＢＷＰ内の他の領域よりも干渉が少ない周波数領域にＰＵＣＣＨリソースを柔軟にスケジューリングしてもよい。ＰＵＣＣＨ送信用にスケジューリングされた特定のＳＢのインデックスは、ＲＭＳＩにおける２ビットを介して示してもよい。

この場合、所定のサブバンド内で割り当てられたＰＵＣＣＨリソースを導出する方法として、２種類の方法が考えられる：

オプション２ａ：各ＳＢのＰＵＣＣＨリソースインデックスをゼロから開始する。ＳＢインデックスは既知であるため、ＳＢ内で割り当てられたＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、ｎ_{ＰＵＣＣＨ，ＲＩ}＝ｎ_{ＣＣＥ＿ｉｎｄｅｘ}として導出してもよい。

オプション２ｂ：割り当てられたＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、以下の式により導出してもよい。

オプション２ａと２ｂの両方において、ｎ_{ＣＣＥ＿ｉｎｄｅｘ}が大きすぎる場合、初期アクセス段階のＰＵＣＣＨリソースのサイズを制限するために、Ｍｓｇ４用のＤＣＩ送信のスケジューリングを先頭の［ｙ］ＣＣＥに限定してもよい。例えば、ｙは２４としてもよい。

オプション３：異なるＤＬスロットでＭｓｇ４を受信する複数のＵＥがＵＬスロット内の同一リソースを用いてＨＡＲＱフィードバックを送信すると、オプション１とオプション２の両方においてリソースの衝突が発生する可能性がある。これは、オプション２を変更して、ＰＵＣＣＨリソースのＰＲＢインデックスを以下の式によって導出することで回避することができる。

ＵＥ間でのＰＵＣＣＨリソース衝突を回避するために、初期巡回シフトのインデックスを、Ｍｓｇ４とＨＡＲＱ－ＡＣＫフィードバック送信とのタイミング関係に黙示的にリンクさせることで、それぞれの直交シーケンスに基づいてＵＥを区別することができる。Ｍｓｇ４のＤＣＩの受信とＨＡＲＱ－ＡＣＫフィードバックとのタイミング関係は、基地局５とモバイルデバイス３の両方に既知である。このタイミング関係にインデックスが割り振られ、ＵＥのＨＡＲＱ－ＡＣＫ送信用に予め定義されたマッピングに従って巡回シフトが決定される。したがって、同一周波数リソース内の異なるモバイルデバイス３から送信されたＰＵＣＣＨを、基地局５が直交シーケンスに基づいて区別することができる。

要約すると、特定のモバイルデバイス３が使用する適切なＰＵＣＣＨリソースを、明示的メカニズムと黙示的メカニズムの両方を使用して決定することができる。好ましくは、シグナリングオーバーヘッドおよび無線リソースの浪費を（他の方法と比較して）低減することができるＭｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信のためのＰＵＣＣＨリソースを識別するため、明示的および黙示的な指示の組み合わせを使用してもよい。この場合、割り当てられるＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、以下の式を用いて導出してもよい：

別の実施例では、Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信用に割り当てられたＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、以下の式を用いて導出してもよい：

あるいは、特定のＰＲＢ内のＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、以下の式で求められるインデックスｋによって識別してもよい。

あるいは、特定のＰＲＢ内のＰＵＣＣＨリソース（ｎ_{ＰＵＣＣＨ，ＲＩ}）は、例えば、検出されたＰＤＣＣＨ ＤＣＩによって別途シグナリングされたインデックスｋによって識別してもよい。この場合、インデックスｋのシグナリングには２または３ビットあれば十分であり、それぞれＫ＝４または８である。このアプローチにより、基地局５は、例えば、衝突を回避するために、（ＰＵＣＣＨリソースに対して）リソースインデックスを柔軟に割り当ててもよい。

上記両方の代替案について、インデックスｋ（所定のＰＲＢ内の特定のＰＵＣＣＨリソースに関連付けされたインデックスを表す）は、所定のルックアップテーブルなど（モバイルデバイス３と基地局５が事前に把握している）によってＣＳおよびＯＣＣの少なくとも一方にマッピングされてもよい。

ＣＳ分離は、（ＯＣＣと比べて）遅延拡散の比較的低い環境でより効果的であり、ＯＣＣは（ＣＳ分離と比べて）比較的低いＵＥ速度においてより効果的であるため、さまざまなセルタイプに適した複数のルックアップテーブルを予め定義しておくと有利である。基地局５は、（所定のセル内で）使用されるルックアップテーブルを、ＲＡＲメッセージ（Ｍｓｇ２）において、またはＲＭＳＩの適切なフィールド（例えば、１ビット）を用いてシグナリングするように構成されてもよい。例えば、以下の表２または表３に示すルックアップテーブルのどちらを使用するかをモバイルデバイス３に示すには、１ビットで十分であるものとする（ただし、必要に応じて、複数のビットを使用することもできる）。

さらに、ＯＣＣはＰＵＣＣＨフォーマット０に適用することができないため、ＰＵＣＣＨフォーマット毎に異なるルックアップテーブルを定義することも有利である（例えば、Ｋ＝４およびＫ＝８のＰＵＣＣＨフォーマット１については、それぞれ表３および表５を参照）。モバイルデバイス３は、検出されたＰＵＣＣＨ ＤＣＩからＰＵＣＣＨフォーマットを把握するため、追加のシグナリングを必要とせずに適切なテーブルを選択することができる。

方法４－他のパラメータ指示
基地局５は、以下を含むが、これらに限定されない他のパラメータの一部をモバイルデバイス３に示すように構成されてもよい：
－ＰＵＣＣＨのフォーマットおよび長さ：明示的指示（方法１）を使用するか、あるいは黙示的／明示的指示の組み合わせ（方法３）を使用するかに関わらず、スモールセル構成では（例えば、ホーム基地局の場合）、Ｍｓｇ４に対するＨＡＲＱ－ＡＣＫフィードバックを確実に送信するには、ショートＰＵＣＣＨで十分である。ただし、潜在的なＰＵＣＣＨカバレッジ制限を回避するために、送信期間がより長いロングＰＵＣＣＨが必要な場合も考えられる。基地局５はそのセルサイズを把握しているため、ロングまたはショートＰＵＣＣＨフォーマットのどちらが使用されるかを、ＲＡＲをスケジューリングするＤＣＩで示すように構成されてもよい。別のオプションでは、Ｍｓｇ４をスケジューリングするＤＣＩのビットを介して、または初期アクセスを実行するＵＥのＲＭＳＩを介して、ＰＵＣＣＨフォーマット（ロングまたはショート）が示される。これは、セル端部に位置するモバイルデバイス３がロングＰＵＣＣＨフォーマットを必要とする一方で、セルの中心付近（比較的基地局５の近傍）に位置するモバイルデバイス３がショートＰＵＣＣＨを使用可能な、大きな（マクロ）セルにおいて特に有用である。この場合、基地局５は、例えば、（特定のモバイルデバイス３による）ＲＡＲ送信から、対応する（当該モバイルデバイス３による）Ｍｓｇ３を正常に受信するまでの経過時間に応じて、またはＴＡ（タイミングアドバンス）の情報を利用して、各モバイルデバイス３に適用可能なＰＵＣＣＨフォーマットを決定する（および示す）ように構成されてもよい。
－ＰＵＣＣＨの長さ：簡単なアプローチとして、高信頼度のＰＵＣＣＨ復号を可能にするシンボル数を、（モバイルデバイス３に割り当てられた）ＢＷＰのニューメロロジーに応じて、フォーマット毎に予め決定してもよい。
－第２ホップの周波数リソース：周波数ホッピングのために、周波数領域（ＢＷＰ内）においてリソースをミラーリングすることも可能である（ＬＴＥで採用されるスロットホッピングと同様）。ただし、基地局５においてより高度な制御および柔軟性を得るために、第２ホップ用のサブバンドは、異なってもよい（また、ＲＡＲの２ビットを使用して示してもよい）。

上記手順の概要を図６に示すが、これは、基地局５がＰＵＣＣＨリソースのセットおよび／または特定のＰＵＣＣＨリソースをモバイルデバイス３に示す例示的な方法のいくつかを概略的に示すシグナリング（タイミング）の図である。

＜ＲＲＣ接続ＵＥのＰＵＣＣＨリソース構成のパラメータ＞
３ＧＰＰでは、以下の表６に示すように、ＰＵＣＣＨリソースセットに設定するパラメータについて合意がされている。したがって、表６の各パラメータについて、ＰＵＣＣＨリソースセット用の値のセットをそれぞれ設定することができる。さらに、（ＵＥに適用可能な）ＤＣＩが、対応するＰＵＣＣＨリソースのインデックスを示す場合、各値は当該ＵＥによって決定されてもよい。あるいは（例えば、適切な黙示的リソース指示メカニズムを使用する場合）、一部のパラメータの値を黙示的に導出してもよい。ＰＵＣＣＨリソースセット内のエントリは、表６中の１つの列に対応する。このリソースは、テーブルの行に示す複数のパラメータによって定義される。

なお、表６において、「ＦＦＳ：黙示的導出のための特別な値」または「ＦＦＳ：黙示的導出も使用するか否か」を示すパラメータは、該当の３ＧＰＰワーキンググループ（例えば、ＲＡＮ１）において、ＰＵＣＣＨリソースのエントリ中の特定パラメータを決定するのに黙示的および／または明示的な方法を使用するか否かを決めるためのさらなる議論が必要であることを意味する。黙示的なメカニズムを使用する場合、対応する値の範囲が縮小したり、および／または値の範囲外の特別な値が「黙示的導出」を示すために追加されたり、設定が完全に無効化されたりすることがある。したがって、表６の内容は単なる例として解釈すべきものである。

また、３ＧＰＰにおいては、ＰＤＳＣＨマッピングタイプＡ（スロットベースの送信）およびタイプＢ（非スロットベースの送信）に対し、表６に示す同一のＰＵＣＣＨリソースセットを設定可能か、あるいは異なるＰＵＣＣＨリソースセットを設定可能かを、検討する必要がある。

表７は、準静的に設定されたパラメータの一部の例を示す図である（つまり、表７の各パラメータに適切な値を設定することができる）。

＜変形例および代替案＞
以上、例示的な実施形態を詳細に説明した。当業者が理解するように、上記例示的な実施形態については複数の変形例および代替案が可能であり、そのようにして具現化された発明の利を得ることができる。説明のため、これらの変形例および代替案の例を一部説明する。

複数の例示的なルックアップテーブルが上記のように提示された（表１～表５）。しかしながら、他の適切なルックアップテーブルを使用してもよく、その場合、ｋの値は、ＣＳ_{ｉｎｄｅｘ}および／またはＯＣＣインデックスの異なる値を用いて導出してもよい。ｋの値は、任意の適切なパラメータ（例えば、ＣＳ_{ｉｎｄｅｘ}およびＯＣＣインデックス以外のパラメータ）に基づいて適宜導出してもよい。

１つまたは複数のルックアップテーブルは、出荷時の設定であってもよいし、および／またはオペレータ固有であってもよい。その場合、モバイルデバイス３へのルックアップテーブルのシグナリングが不要な場合もある（例えば、モバイルデバイス３は、自装置の現在のオペレータおよび／またはセルに基づいて適切なルックアップテーブルを選択するように構成されてもよい）。

上記の例示的な実施形態では、基地局は、３ＧＰＰ無線通信（無線アクセス）技術を使用してモバイルデバイスと通信を行う。しかしながら、上記の例示的な実施形態に従って、基地局とモバイルデバイスとの間で他の任意の無線通信技術（すなわち、ＷＬＡＮ、Ｗｉ－Ｆｉ、ＷｉＭＡＸ、Ｂｌｕｅｔｏｏｔｈなど）を使用してもよい。上記の例示的な実施形態は、「非モバイル」または固定ユーザ機器全般に適用可能である。

上の説明では、理解を容易にするため、モバイルデバイスおよび基地局は、複数の個別モジュールを備えるものとして説明された。これらのモジュールは、例えば、本発明を実施するために既存のシステムに変更を加えた特定のアプリケーションについては上述のような方法で提供することができるが、例えば最初から本発明の特徴を念頭に置いて設計されたシステムなどの他のアプリケーションについては、これらのモジュールをオペレーティングシステムまたはコード全体に組み込んでもよく、この場合、これらのモジュールは個別のエンティティとして認識されなくてもよい。

上述の例示的な実施形態では、複数のソフトウェアモジュールを説明した。当業者が理解するように、ソフトウェアモジュールは、コンパイルされたまたはコンパイルされていない形式で提供してもよいし、コンピュータネットワークを介した信号として、または記録媒体上で、基地局、モビリティ管理エンティティ、又はモバイルデバイスに供給してもよい。さらに、このソフトウェアの一部またはすべてによって実行される機能は、１つまたは複数の専用ハードウェア回路を用いて実行してもよい。しかしながら、ソフトウェアモジュールは、基地局またはモバイルデバイスの更新を高速化するため、その使用が推奨される。

各コントローラは、以下を含むがこれらに限定されない任意の適切な形態の処理回路を含んでもよい：１つまたは複数のハードウェア実装されたコンピュータプロセッサ；マイクロプロセッサ；中央処理装置（ＣＰＵ）；算術論理ユニット（ＡＬＵ）；入出力（ＩＯ）回路；内部メモリ／キャッシュ（プログラムおよび／またはデータ）；処理レジスタ；通信バス（例えば、制御、データおよび／またはアドレスバス）；ダイレクトメモリアクセス（ＤＭＡ）機能；ハードウェアまたはソフトウェア実装されたカウンタ、ポインタ、タイマなど。

上記ランダムアクセス手順はＲＲＣ接続を確立する手順であってもよい。

上記第１の情報の取得は、ランダムアクセス手順を開始する前に上記第１の情報の少なくとも一部を、ブロードキャストされるシステム情報の一部として（例えば、システム情報のＲＭＳＩ部分で）受信することも含んでよい。上記第１の情報の取得は、ランダムアクセス手順を開始した後に（例えば、ランダムアクセス手順における２番目のメッセージ（「Ｍｓｇ２」）またはＲＡＲ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｒｅｓｐｏｎｓｅ：ランダムアクセス応答）によって）上記第１の情報の少なくとも一部を受信することを含んでもよい。上記第２の情報の取得は、上記第２の情報の少なくとも一部を上記ランダムアクセス手順の一部として（例えば、ランダムアクセス手順における４番目のメッセージ（「Ｍｓｇ４」）によって）受信することを含んでもよい。

上記第１の情報は、上記基地局のシステム帯域幅のサブバンド（例えば、部分帯域内のサブバンド）を識別する情報を含んでもよく、上記第２の情報は、上記第１の情報（例えば、前記サブバンドの端部を表すＰＲＢに対するサブバンド内の少なくとも１つのＰＲＢ）によって識別された上記サブバンド内の特定の周波数リソース（例えば、少なくとも１つのＰＲＢ）を識別する情報を含んでもよい。

上記周波数リソースのセットは、ＰＲＢのセット（例えば、上記基地局のシステム帯域幅の一部を形成する、連続するＰＲＢのセット）を含んでもよく、上記特定の周波数リソースは特定のＰＲＢを含んでもよい。

上記チャネルはＰＵＣＣＨを含んでもよい。上記上りリンク通信は、ＨＡＲＱフィードバック（例えば、ランダムアクセス手順における４番目のメッセージ（「Ｍｓｇ４」）に対するＨＡＲＱフィードバック）を上記基地局に送信することを含んでもよい。

上記少なくとも１つの特定の周波数リソースは、少なくとも１つの式を用いて識別される。例えば、上記少なくとも１つの特定の周波数リソースは、以下の式の少なくとも１つを用いて識別することができる：

上記方法は、ショートまたはロングＰＵＣＣＨフォーマットのいずれが使用されるかを識別する第３の情報を取得することをさらに含んでもよい。上記第３の情報（例えば、１ビット）は、Ｍｓｇ４をスケジューリングするＤＣＩまたはＲＭＳＩに含むことができる。

種々の他の変更は当業者にとって明らかであるため、ここでは更に詳細な説明は省略する。

上記の例示的な実施形態を、現在提案されている３ＧＰＰ規格において実装する方法について以下に詳細に説明する。さまざまな機能が必須または必要である旨が説明されるが、これが提案の３ＧＰＰ規格について該当するのは、例えば、当該規格の他の要件が課された場合のみである。したがって、これらの記述は、本発明を何ら限定するものとして解釈されるべきではない。

＜１＞イントロダクション
前回の会合で、ＲＡＮ１はＲＲＣ接続のセットアップ／初期アクセス前のＰＵＣＣＨリソースの割り当てについて議論し、以下の合意に至った：
合意事項：（ＲＡＮ１＃９１）
－ＲＲＣ接続セットアップ前におけるＨＡＲＱ－ＡＣＫのリソース割り当て：
－－ＰＵＣＣＨフォーマット０および１のみをサポートする
－－リソース割り当ては、ＲＭＳＩにおける４ビットのパラメータに基づいて導出する
－－－ＦＦＳのその他の詳細（追加のＲＲＣへの影響なし）
合意事項：
－フォールバックＤＣＩが存在する場合のＰＵＣＣＨリソースの割り当ては、－－通常のＤＣＩと同様のアプローチによって行う。
合意事項：
－ＲＲＣ接続セットアップ前にＨＡＲＱ－ＡＣＫのリソース割り当てを行う場合、ＵＥは、ＲＲＣ接続セットアップ後の場合と同様のアプローチによって、ＲＭＳＩから導出されたリソースのセットからＰＵＣＣＨリソースを識別する。

本寄稿では、初期アクセス中／ＲＲＣ接続のセットアップ前に、Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信用のＰＵＣＣＨリソースをどのように構成して割り当てるかを議論する。

＜２＞ＲＲＣ設定前におけるＰＵＣＣＨリソース割り当てＲＲＣ設定の前においては、ＤＣＩフォーマットまたはＲＭＳＩでシグナリング可能な少数のパラメータを除いて、ＰＵＣＣＨリソース割り当てを決定するパラメータの大半を仕様で規定する必要がある。この理解を前提として、表８に示すように、ＰＵＣＣＨフォーマットおよびその送信パラメータを予め定義することを提案する。

ＰＵＣＣＨフォーマットは、｛フォーマット０－１シンボル、フォーマット０－２シンボル、フォーマット１－１０シンボル、フォーマット１－１４シンボル｝のいずれか１つであり、Ｍｓｇ４をスケジューリングするＤＣＩまたはＲＡＲメッセージ（Ｍｓｇ２）で動的にシグナリングすることができる。この場合、２ビットで十分となる。

提案１：Ｍｓｇ４をスケジューリングするＤＣＩまたはＲＡＲメッセージ（Ｍｓｇ２）で１つのフォーマットを動的にシグナリングする初期アクセス用に、４つのＰＵＣＣＨフォーマット｛フォーマット０－１シンボル、フォーマット０－２シンボル、フォーマット１－１０シンボル、フォーマット１－１４シンボル｝を事前に定義する。

提案２：各ＰＵＣＣＨフォーマットのシンボル数、開始シンボル、ホッピングリソースなどの送信パラメータの値を事前に定義して固定する。

提案３：先頭周波数リソース（ＰＲＢ番号）、ＣＳインデックス、および時間領域ＯＣＣを取得する数式または方法をＰＵＣＣＨフォーマット毎に定義する。

初期アクセス用のＰＵＣＣＨリソースを定義するには、例えばＢＷＰの端部が高レベルの干渉を受けている場合など、必要に応じて、ＰＵＣＣＨリソースを部分帯域の端部から離れた位置に配置するためにオフセットを含むことが重要である。前回の会合から、初期アクセス中にＰＵＣＣＨリソースを導出するために４ビットを使用することが合意されておいるため、したがって、オフセットをセル固有の方法でシグナリングするために４ビットのうち２ビットのみを使用し、残りの２ビットは確保しておくか、あるいは他の目的に使用することを提案する。この場合、図５に示すように、各サブバンドが連続したＰＲＢを含む場合においてリソースが断片化することを回避するために、ＢＷＰを、０～３のインデックスが割り振られた４つの仮想サブバンドに分割する。これにより、ＢＷＰ内の他の領域よりも干渉が少ない周波数領域においてＰＵＣＣＨリソースを柔軟に開始することができる。

上記の説明に基づいて、Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信用のＰＵＣＣＨリソースの割り当てについて、以下の式を提案する。

パラメータＬ_ｍｉｎを数式に加える主な理由は、アグリゲーションレベルが高いほど使用密度が低下する傾向があり、ＰＲＢ内において使用可能なＰＵＣＣＨリソースの密度を増やすためである。

Ａｌｔ－１の主な懸念事項として、巡回シフトが数式自体から黙示的に導出されるため、ｇＮＢが、ＰＵＣＣＨリソースインデックスを変更するなどの柔軟なスケジューリングを行うことができないことが含まれる。

Ａｌｔ－２：１ＰＲＢ内のＰＵＣＣＨリソースを、検出されたＰＤＣＣＨ ＤＣＩでシグナリングされるインデックスｋで識別する。これには２ビットまたは３ビットで十分であり、それぞれＫ＝４または８である。

Ａｌｔ－２のメリットとしては、例えば、異なるＵＥのＡｃｋ／Ｎａｃｋフィードバックが衝突するのを回避するために、ｇＮＢはリソースインデックスを柔軟に割り当てることができる。

Ａｌｔ－１とＡｌｔ－２の両方において、１ＰＲＢ内のリソースインデックスｋは、事前に定義されたルックアップテーブルを使用して、ＣＳＳおよびＯＣＣにマッピングすることができる。

ＣＳ分離は低遅延拡散環境でより効果的であり、かつＯＣＣは低ＵＥ速度においてより効果的であるため、さまざまなセルタイプに適した複数のルックアップテーブルを事前に定義しておくことが有利である。各セルで使用するルックアップテーブルは、ＲＡＲメッセージ（Ｍｓｇ２）または残りの２ビットのうち１ビットを使用して、ＲＭＳＩでシグナリングすることができる。

提案４：Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信用のＰＵＣＣＨリソースを以下の式で定義する。

提案５：ＰＵＣＣＨフォーマット１のＣＳとＯＣＣの組み合わせについて２つの異なるルックアップテーブルを定義し、残りの２ビットの１ビットを使用してＲＭＳＩでシグナリングを行う。

＜３＞結論
本寄稿では、初期アクセス中／ＲＲＣ接続のセットアップ前に、Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信用のＰＵＣＣＨリソースを、どのように構成して割り当てるかについて議論し、以下の提案を行った。

提案１：Ｍｓｇ４をスケジューリングするＤＣＩまたはＲＡＲメッセージ（Ｍｓｇ２）で、１つのフォーマットを動的にシグナリングする初期アクセス用に、４つのＰＵＣＣＨフォーマット｛フォーマット０－１シンボル、フォーマット０－２シンボル、フォーマット１－１０シンボル、フォーマット１－１４シンボル｝を事前に定義する。

提案２：各ＰＵＣＣＨフォーマットのシンボル数、開始シンボル、ホッピングリソースなどの送信パラメータの値を事前に定義して固定する。

提案３：先頭周波数リソース（ＰＲＢ番号）、ＣＳインデックス、および時間領域ＯＣＣを取得する数式または方法をＰＵＣＣＨフォーマット毎に定義する。

提案４：Ｍｓｇ４ ＨＡＲＱ－ＡＣＫフィードバック送信用のＰＵＣＣＨリソースを以下の式で定義する。

提案５：ＰＵＣＣＨフォーマット１のＣＳとＯＣＣの組み合わせについて２つの異なるルックアップテーブルを定義し、残りの２ビットの１ビットを使用してＲＭＳＩでシグナリングを行う。

上記実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
上りリンク通信用の周波数リソースを識別するためにＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ機器）が実行する方法であって、
ランダムアクセス手順を開始すること、
上りリンクチャネル用の周波数リソースのセットを識別する第１の情報を取得すること、
上記上りリンク通信用に、上記周波数リソースのセット内の少なくとも１つの特定の周波数リソースを識別する第２の情報を取得すること、および
上記第１の情報および上記第２の情報に基づいて、上記上りリンク通信用の上記周波数リソースを識別することを含み、
上記第１の情報は、ＲＲＣ接続を確立する手順が完了する前に取得される、方法。

（付記２）
上記ランダムアクセス手順はＲＲＣ接続を確立する手順である、付記１に記載の方法。

（付記３）
上記第１の情報を取得することは、上記ランダムアクセス手順を開始する前に、上記第１の情報の少なくとも一部を、ブロードキャストされるシステム情報の一部として（例えば、システム情報のＲＭＳＩ（Ｒｅｍａｉｎｉｎｇ Ｍｉｎｉｍｕｍ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ：残存最小システム情報）部分で）、受信することを含む、付記１または２に記載の方法。

（付記４）
上記第１の情報を取得することは、ランダムアクセス手順を開始した後に（例えば、ランダムアクセス手順における２番目のメッセージ（「Ｍｓｇ２」）またはＲＡＲ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｒｅｓｐｏｎｓｅ：ランダムアクセス応答）によって）上記第１の情報の少なくとも一部を受信することを含む、付記１から３のいずれか一項に記載の方法。

（付記５）
上記第２の情報を取得することは、上記第２の情報の少なくとも一部を上記ランダムアクセス手順の一部として（例えば、ランダムアクセス手順における４番目のメッセージ（「Ｍｓｇ４」）によって）受信することを含む、付記１から４のいずれか一項に記載の方法。

（付記６）
上記周波数リソースのセットは、ＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ：物理リソースブロック）のセット（例えば、上記基地局のシステム帯域幅の一部を形成する、連続するＰＲＢのセット）を含み、上記特定の周波数リソースは特定のＰＲＢを含む、付記１から５のいずれか一項に記載の方法。

（付記７）
上記第１の情報は、上記基地局のシステム帯域幅のサブバンド（例えば、部分帯域内のサブバンド）を識別する情報を含み、
上記第２の情報は、上記第１の情報（例えば、上記サブバンドの端部を表すＰＲＢに対するサブバンド内の少なくとも１つのＰＲＢ）によって識別された上記サブバンド内の特定の周波数リソース（例えば、少なくとも１つのＰＲＢ）を識別する情報を含む、
付記１から６のいずれか一項に記載の方法。

（付記８）
上記上りリンク通信は、ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ：ハイブリッド自動再送要求）フィードバック（例えば、ランダムアクセス手順における４番目のメッセージ（「Ｍｓｇ４」）に対するＨＡＲＱフィードバック）を上記基地局に送信することを含む、付記１から７のいずれか一項に記載の方法。

（付記９）
上記少なくとも１つの特定の周波数リソースは少なくとも１つの式を用いて識別される、付記１から８のいずれか一項に記載の方法。

（付記１０）
上記チャネルは、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：物理上りリンク制御チャネル）を含む、付記１から９のいずれか一項に記載の方法。

（付記１１）
上記少なくとも１つの特定の周波数リソースは、以下の式の少なくとも１つを用いて識別される：

付記１０に記載の方法。

（付記１２）
ショートまたはロングＰＵＣＣＨフォーマットのいずれが使用されるかを識別する第３の情報を取得することをさらに含む、付記１０または１１に記載の方法。

（付記１３）
上記第３の情報（例えば、１ビット）は、Ｍｓｇ４をスケジューリングするＤＣＩまたはＲＭＳＩに含まれる、付記１２に記載の方法。

（付記１４）
ユーザ機器による上りリンク通信用の周波数リソースを識別するために基地局が実行する方法であって、
上記ユーザ機器に対するランダムアクセス手順を開始すること、
上りリンクチャネル用の周波数リソースのセットを識別する第１の情報を提供すること、および
上記上りリンク通信用に、上記周波数リソースのセット内の少なくとも１つの特定の周波数リソースを識別する第２の情報を提供することを含み、
上記第１の情報は、ランダムアクセス手順が完了する前に提供される、方法。

（付記１５）
上記ランダムアクセス手順はＲＲＣ接続を確立する手順である、付記１４に記載の方法。

（付記１６）
上記第１の情報を提供することは、上記ランダムアクセス手順の開始前に、上記第１の情報の少なくとも一部を、ブロードキャストされるシステム情報の一部として（例えば、システム情報のＲＭＳＩ部分で）、
送信することを含む、付記１４または１５に記載の方法。

（付記１７）
上記ランダムアクセス手順を開始した後に、上記第１の情報および上記第２の情報の少なくとも１つを含む少なくとも１つのメッセージを送信することを含む、付記１４から１６のいずれか一項に記載の方法。

（付記１８）
上記チャネルはＰＵＣＣＨを含み、上記特定のリソースは少なくとも１つのフォーマットを用いて識別される、付記１４から１７のいずれか一項に記載の方法。

（付記１９）
通信システムのＵＥ（Ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ：ユーザ機器）であって、上記ＵＥは、コントローラおよびトランシーバを備え、
上記コントローラは、
ランダムアクセス手順を開始し、
上りリンクチャネル用の周波数リソースのセットを識別する第１の情報を取得し、
上記上りリンク通信用に、上記周波数リソースのセット内の少なくとも１つの特定の周波数リソースを識別する第２の情報を取得し、
上記第１の情報および上記第２の情報に基づいて、上記上りリンク通信用の上記周波数リソースを識別するように動作可能であり、
上記第１の情報は、ランダムアクセス手順が完了する前に取得される、ＵＥ。

（付記２０）
ユーザ機器による上りリンク通信用の周波数リソースを識別する基地局であって、コントローラおよびトランシーバを備え、
上記コントローラは、
上記ユーザ機器に対するランダムアクセス手順を開始すること、
上りリンクチャネル用の周波数リソースのセットを識別する第１の情報を提供し、
上記上りリンク通信用に、上記周波数リソースのセット内の少なくとも１つの特定の周波数リソースを識別する第２の情報を提供するように動作可能であり、
上記第１の情報は、上記ランダムアクセス手順が完了する前に提供される、基地局。

（付記２１）
付記１９に記載の上記ＵＥと、付記２０に記載の上記基地局と、を備えるシステム。

（付記２２）
プラグラム可能な通信デバイスに付記１から１８のいずれか一項に記載の方法を実行させるためのコンピュータによって実行可能な命令を備える、コンピュータによって実行可能なプログラム。

本出願は、２０１７年１１月１６日に提出された英国特許出願第１７１８９９９．４号および２０１８年１月１０日に提出された第１８００３９３．９号からの優先権の利益に基づいており、その開示は参照により全体として本明細書に組み込まれる。

Claims (8)

1. 基地局から、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：物理上りリンク制御チャネル）フォーマット、開始シンボル、シンボルの数、及び、ＣＳ（Ｃｙｃｌｉｃ Ｓｈｉｆｔ：巡回シフト）インデックスの１つの組を示すビット列を受信する手段と、
   当該ビット列に基づく前記１つの組に基づいて、ＰＵＣＣＨリソースを決定する手段と、
   を備える無線端末。
2. 前記決定する手段は、ＲＭＳＩ（Ｒｅｍａｉｎｉｎｇ Ｍｉｎｉｍｕｍ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ）に含まれる４ビットの情報に基づいて、前記ＰＵＣＣＨリソースの、部分帯域におけるオフセットを決定するよう構成される、
   請求項１に記載の無線端末。
3. 前記受信する手段は、前記基地局から、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ：下り制御情報）を受信するよう構成され、
   前記決定する手段は、前記ＣＳインデックス及び前記ＤＣＩに基づいて、前記ＰＵＣＣＨリソースにおけるＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ：物理リソースブロック）のインデックスを決定するよう構成される、
   請求項１又は２に記載の無線端末。
4. 無線端末へ、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：物理上りリンク制御チャネル）フォーマット、開始シンボル、シンボルの数、及び、ＣＳ（Ｃｙｃｌｉｃ Ｓｈｉｆｔ：巡回シフト）インデックスの１つの組を示すビット列を送信する手段を備え、
   当該ビット列に基づく前記１つの組に基づいてＰＵＣＣＨリソースが決定される、
   基地局。
5. 前記送信する手段は、前記無線端末へ、前記ＰＵＣＣＨリソースの、部分帯域におけるオフセットを決定するための４ビットの情報を含むＲＭＳＩ（Ｒｅｍａｉｎｉｎｇ Ｍｉｎｉｍｕｍ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ）を送信するよう構成される、
   請求項４に記載の基地局。
6. 前記送信する手段は、前記無線端末へ、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ：下り制御情報）を送信するよう構成され、
   前記ＣＳインデックス及び前記ＤＣＩに基づいて、前記ＰＵＣＣＨリソースにおけるＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ：物理リソースブロック）のインデックスが決定される、
   請求項４又は５に記載の基地局。
7. 基地局から、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：物理上りリンク制御チャネル）フォーマット、開始シンボル、シンボルの数、及び、ＣＳ（Ｃｙｃｌｉｃ Ｓｈｉｆｔ：巡回シフト）インデックスの１つの組を示すビット列を受信することと、
   当該ビット列に基づく前記１つの組に基づいて、ＰＵＣＣＨリソースを決定することと、
   を含む、無線端末における方法。
8. 無線端末へ、ＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ：物理上りリンク制御チャネル）フォーマット、開始シンボル、シンボルの数、及び、ＣＳ（Ｃｙｃｌｉｃ Ｓｈｉｆｔ：巡回シフト）インデックスの１つの組を示すビット列を送信することを含み、
   当該ビット列に基づく前記１つの組に基づいてＰＵＣＣＨリソースが決定される、
   基地局における方法。
   
   

Images