(57)【特許請求の範囲】
【請求項１】
無線通信システムにおいて、端末が下りリンク制御情報を受信する方法であって、
基地局から少なくとも１個の制御リソースセット（ＣＯＲＥＳＥＴ）に多数のビーム（ｂｅａｍ）を設定するビーム設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報を受信するステップと、
前記多数のビームのうちの少なくとも１個を介して送信される下りリンク制御チャネルを、前記少なくとも１個のＣＯＲＥＳＥＴ上においてブラインド検出するステップと、
前記ブラインド検出された下りリンク制御チャネルから下りリンク制御情報を取得するステップと、を含み、
前記端末が実行可能なブラインド検出の総回数が、前記多数のビームに分けて割り当てられ、
前記端末は、各々のビームに割り当てられたブラインド検出の回数に応じてブラインド検出を行い、
前記多数のビームは、プライマリ（ｐｒｉｍａｒｙ）ビーム及びセカンダリ（ｓｅｃｏｎｄａｒｙ）ビームを含み、
前記端末は、前記プライマリビーム上では、第１のアグリゲーションレベル（ａｇｇｒｅｇａｔｉｏｎ  ｌｅｖｅｌ）に該当する制御チャネル候補の検出を試み、前記セカンダリビーム上では、第２のアグリゲーションレベルに該当する制御チャネル候補の検出を試みる、下りリンク制御情報の受信方法。
【請求項２】
前記多数のビームは、異なるＣＯＲＥＳＥＴ上にそれぞれ設定される、請求項１に記載の下りリンク制御情報の受信方法。
【請求項３】
前記異なるＣＯＲＥＳＥＴのそれぞれに個別に共通サーチスペース（ＣＳＳ）と端末固有サーチスペース（ＵＳＳ）のうちの少なくとも１つが設定され、
前記端末は、該当ＣＯＲＥＳＥＴに設定されたビームを用いて、前記該当ＣＯＲＥＳＥＴに設定された前記ＣＳＳ及び前記ＵＳＳのうちの少なくとも１つをモニタリングする、請求項２に記載の下りリンク制御情報の受信方法。
【請求項４】
前記プライマリビームに割り当てられた前記第１のアグリゲーションレベルは、前記セカンダリビームに割り当てられた前記第２のアグリゲーションレベルよりも低く設定される、請求項１に記載の下りリンク制御情報の受信方法。
【請求項５】
前記セカンダリビームは、前記プライマリビームを介して受信されるＭＡＣメッセージ又は下りリンク制御情報を介して活性化／非活性化される、請求項１に記載の下りリンク制御情報の受信方法。
【請求項６】
無線通信システムにおいて、下りリンク制御情報を受信する端末であって、
受信器と、
前記受信器を介して基地局から少なくとも１個の制御リソースセット（ＣＯＲＥＳＥＴ）に多数のビーム（ｂｅａｍ）を設定するビーム設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報を受信して、前記多数のビームのうちの少なくとも１個を介して送信される下りリンク制御チャネルを前記少なくとも１個のＣＯＲＥＳＥＴ上においてブラインド検出して、前記ブラインド検出された下りリンク制御チャネルから下りリンク制御情報を取得するプロセッサと、を含み、
前記プロセッサが実行可能なブラインド検出の総回数が、前記多数のビームに分けて割り当てられ、
前記プロセッサは、各々のビームに割り当てられたブラインド検出の回数に応じてブラインド検出を行い、
前記多数のビームは、プライマリ（ｐｒｉｍａｒｙ）ビーム及びセカンダリ（ｓｅｃｏｎｄａｒｙ）ビームを含み、
前記プロセッサは、前記プライマリビーム上では、第１のアグリゲーションレベル（ａｇｇｒｅｇａｔｉｏｎ  ｌｅｖｅｌ）に該当する制御チャネル候補の検出を試み、前記セカンダリビーム上では、第２のアグリゲーションレベルに該当する制御チャネル候補の検出を試みる、端末。
【請求項７】
前記多数のビームは、異なるＣＯＲＥＳＥＴ上にそれぞれ設定される、請求項６に記載の端末。
【請求項８】
前記異なるＣＯＲＥＳＥＴのそれぞれに個別に共通サーチスペース（ＣＳＳ）と端末固有サーチスペース（ＵＳＳ）のうちの少なくとも１つが設定され、
前記プロセッサは、該当ＣＯＲＥＳＥＴに設定されたビームを用いて、前記該当ＣＯＲＥＳＥＴに設定された前記ＣＳＳ及び前記ＵＳＳのうちの少なくとも１つをモニタリングする、請求項７に記載の端末。
【請求項９】
前記プライマリビームに割り当てられた前記第１のアグリゲーションレベルは、前記セカンダリビームに割り当てられた前記第２のアグリゲーションレベルよりも低く設定される、請求項６に記載の端末。
【請求項１０】
前記セカンダリビームは、前記プライマリビームを介して受信されるＭＡＣメッセージ又は下りリンク制御情報を介して活性化／非活性化される、請求項６に記載の端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関し、より具体的に、無線通信システムにおいて下りリンク制御情報を送信又は受信するための方法及びそのための装置に関する。
【背景技術】
【０００２】
多数の通信機器がより大きな通信容量を要求することにより、最近論議されている次世代通信システムでは、既存の無線アクセス技術（ｒａｄｉｏ  ａｃｃｅｓｓ  ｔｅｃｈｎｏｌｏｇｙ，ＲＡＴ）に比べて向上したモバイルブロードバンド（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ，ｅＭＢＢ）通信の必要性が高まっている。また多数の機器及びモノを連結していつでもどこでも多様なサービスを提供する大規模ＭＴＣ（ｍａｓｓｉｖｅ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，ｍＭＴＣ）も次世代通信において考慮すべき主要なイシューである。また、信頼性（ｒｅｌｉａｂｉｌｉｔｙ）及び遅延（ｌａｔｅｎｃｙ）に敏感なサービス／ＵＥを考慮して、次世代通信システムとしてＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｌｂｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が論議されている。
【０００３】
このようにｅＭＢＢ、ｍＭＴＣ及びＵＲＬＣＣなどを考慮した新しい無線アクセス技術（Ｎｅｗ  ＲＡＴ）が次世代無線通信のために論議されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明が遂げようとする技術的課題は、複数のビームを支援する無線通信システムにおいて、下りリンク制御情報をより効率的且つ正確に送信又は受信するための方法及びそのための装置に関する。
【０００５】
本発明の技術的課題は、上述した技術的課題に制限されず、他の技術的課題が本発明の実施例より類推できる。
【課題を解決するための手段】
【０００６】
上述した技術的課題を達成するための本発明の一側面による無線通信システムにおいて、端末が下りリンク制御情報を受信する方法は、基地局から少なくとも１個の制御リソースセット（ＣＯＲＥＳＥＴ）に多数のビーム（ｂｅａｍ）を設定するビーム設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報を受信するステップと、前記多数のビームのうちの少なくとも１個を介して送信される下りリンク制御チャネルを、前記少なくとも１個のＣＯＲＥＳＥＴ上においてブラインド検出するステップと、前記ブラインド検出された下りリンク制御チャネルから下りリンク制御情報を取得するステップと、を含み、前記端末が実行可能なブラインド検出の総回数が、前記多数のビームに分けて割り当てられ、前記端末は、各ビームに割り当てられたブラインド検出の回数に応じてブラインド検出を行うことができる。
【０００７】
上述した技術的課題を達成するための本発明の別の一側面による無線通信システムにおいて、下りリンク制御情報を受信する端末は、受信器と、前記受信器を介して基地局から少なくとも１個の制御リソースセット（ＣＯＲＥＳＥＴ）に多数のビーム（ｂｅａｍ）を設定するビーム設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報を受信して、前記多数のビームのうちの少なくとも１個を介して送信される下りリンク制御チャネルを前記少なくとも１個のＣＯＲＥＳＥＴ上においてブラインド検出して、前記ブラインド検出された下りリンク制御チャネルから下りリンク制御情報を取得するプロセッサと、を含み、前記プロセッサが実行可能なブラインド検出の総回数が、前記多数のビームに分けて割り当てられ、前記プロセッサは、各ビームに割り当てられたブラインド検出の回数に応じてブラインド検出を行うことができる。
【０００８】
前記多数のビームは、異なるＣＯＲＥＳＥＴ上にそれぞれ設定されることができる。
【０００９】
前記異なるＣＯＲＥＳＥＴのそれぞれに個別に共通サーチスペース（ＣＳＳ）と端末固有サーチスペース（ＵＳＳ）のうちの少なくとも１つが設定されることができる。前記端末は、該当ＣＯＲＥＳＥＴに設定されたビームを用いて、前記該当ＣＯＲＥＳＥＴに設定された前記ＣＳＳ及び前記ＵＳＳのうちの少なくとも１つをモニタリングすることができる。
【００１０】
前記多数のビームは、プライマリ（ｐｒｉｍａｒｙ）ビーム及びセカンダリ（ｓｅｃｏｎｄａｒｙ）ビームを含むことができる。
【００１１】
前記端末は、前記プライマリビーム上では、第１のアグリゲーションレベル（ａｇｇｒｅｇａｔｉｏｎ  ｌｅｖｅｌ）に該当する制御チャネル候補の検出を試み、前記セカンダリビーム上では、第２のアグリゲーションレベルに該当する制御チャネル候補の検出を試みることができる。
【００１２】
前記プライマリビームに割り当てられた前記第１のアグリゲーションレベルは、前記セカンダリビームに割り当てられた前記第２のアグリゲーションレベルよりも低く設定されることができる。
【００１３】
前記セカンダリビームは、前記プライマリビームを介して受信されるＭＡＣメッセージ又は下りリンク制御情報を介して活性化／非活性化されることができる。
【発明の効果】
【００１４】
本発明の一実施例によれば、下りリンク制御情報の送受信が可能な複数のビームが端末に設定されるため、無線チャネル環境において強健（ｒｏｂｕｓｔ）で、且つ信頼性の高い下りリンク制御情報の送受信ができると共に、端末がブラインドデコーディングを実行可能なＢＤ総回数が複数のビームに分配され、端末は各ビームに割り当てられたＢＤ回数だけＢＤを行うことで、複数のビーム設定による端末のＢＤの複雑度の問題を解決することができる。
【００１５】
本発明の技術的効果は、上述した技術的効果に制限されず、他の技術的効果が本発明の実施例より類推できる。
【図面の簡単な説明】
【００１６】
【図１】３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムに用いられる物理チャンネル及びこれらを用いる一般的な信号送信方法を例示する図である。
【図２】３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムの無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）の構造を例示する図である。
【図３】３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムの下りリンクスロットのリソースグリッドを例示する図である。
【図４】３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムにおける下りリンクサブフレームの構造を例示する図である。
【図５】３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムにおける上りリンクサブフレームの構造を例示する図である。
【図６】本発明の一実施例による下りリンク制御情報の送受信方法のフローを示す図である。
【図７】本発明の一実施例による端末と基地局を示す図である。
【発明を実施するための形態】
【００１７】
以下の技術は、ＣＤＭＡ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ  ｃａｒｒｉｅｒ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）などのような様々な無線アクセスシステムに用いることができる。ＣＤＭＡは、ＵＴＲＡ（Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ  ｔｅｃｈｎｏｌｏｇｙ）によって具現化することができる。ＴＤＭＡは、ＧＳＭ（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  Ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）のような無線技術によって具現化することができる。ＯＦＤＭＡは、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２−２０、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  ＵＴＲＡ）などのような無線技術によって具現化することができる。ＵＴＲＡは、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ＬＴＥ（ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）は、Ｅ−ＵＴＲＡを用いるＥ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ  ＵＭＴＳ）の一部であり、下りリンクでＯＦＤＭＡを採用し、上りリンクでＳＣ−ＦＤＭＡを採用する。ＬＴＥ−Ａ（Ａｄｖａｎｃｅｄ）は、３ＧＰＰ  ＬＴＥの進化したバージョンである。
【００１８】
説明を明確にするために、３ＧＰＰベースの移動通信システムを中心に記述するが、本発明の技術的思想がこれに制限されるわけではない。また、以下の説明で使われる特定の用語は、本発明の理解を助けるために提供されるものであり、このような特定の用語の使用は、本発明の技術的思想から逸脱しない範囲で他の形態に変更することもできる。
【００１９】
Ｎｅｗ  ＲＡＴを論議するに先立って、３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムに関して簡単に説明する。後述する３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａに関する説明は、Ｎｅｗ  ＲＡＴの理解を助けるために参照されてもよく、Ｎｅｗ  ＲＡＴの設計とかち合わないＬＴＥ／ＬＴＥ−Ａの動作及び設定はＮｅｗ  ＲＡＴにも適用することができる。Ｎｅｗ  ＲＡＴは便宜上５Ｇ移動通信とも称する。
【００２０】
●  ３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステム
【００２１】
図１は、３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムに用いられる物理チャンネル及びこれらを用いる一般的な信号送信方法を説明するための図である。
【００２２】
端末は、電源がオフ状態から再びオンになったり、新しくセルに進入したりした場合、ステップＳ１０１において、基地局と同期を取る等の初期セルサーチ（Ｉｎｉｔｉａｌ  ｃｅｌｌ  ｓｅａｒｃｈ）作業を行う。そのために、端末は、基地局からプライマリ同期チャネル（Ｐｒｉｍａｒｙ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｃｈａｎｎｅｌ，Ｐ−ＳＣＨ）及びセカンダリ同期チャネル（Ｓｅｃｏｎｄａｒｙ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｃｈａｎｎｅｌ，Ｓ−ＳＣＨ）を受信して基地局と同期を取り、セルＩＤ（Ｉｄｅｎｔｉｔｙ）などの情報を取得すればよい。その後、端末は、基地局から物理放送チャネル（Ｐｈｙｓｉｃａｌ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）を受信し、セル内放送情報を取得できる。一方、端末は、初期セルサーチ段階で、下りリンク参照信号（Ｄｏｗｎｌｉｎｋ  Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ，ＤＬ  ＲＳ）を受信し、下りリンクチャネル状態を確認できる。
【００２３】
初期セルサーチを終えた端末は、ステップＳ１０２において、物理下りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ，ＰＤＣＣＨ）、及び物理下りリンク制御チャネル情報による物理下りリンク共有チャネル（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ，ＰＤＳＣＨ）を受信することによって、より具体的なシステム情報を取得できる。
【００２４】
その後、端末は、基地局への接続を完了するために、ステップＳ１０３乃至ステップＳ１０６のようなランダムアクセス過程（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｒｏｃｅｄｕｒｅ）を行うことができる。このため、端末は、物理ランダムアクセスチャネル（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ，ＰＲＡＣＨ）を介してプリアンブル（ｐｒｅａｍｂｌｅ）を送信して（Ｓ１０３）、物理下りリンク制御チャネル及びそれに対応する物理下りリンク共有チャネルを介して、プリアンブルへの応答メッセージを受信することができる（Ｓ１０４）。競合ベースのランダムアクセスの場合、追加の物理ランダムアクセスチャネルの送信（Ｓ１０５）、物理下りリンク制御チャネル及びこれに対応する物理下りリンク共有チャネルの受信（Ｓ１０６）のような競合解決手順（Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅ）を行うことができる。
【００２５】
上述したような手順を行った端末は、その後、一般的な上りリンク／下りリンク信号送信手順として、物理下りリンク制御チャネル／物理下りリンク共有チャネルの受信（Ｓ１０７）、及び物理上りリンク共有チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ，ＰＵＳＣＨ）／物理上りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ，ＰＵＣＣＨ）の送信（Ｓ１０８）を行うことができる。端末が基地局へ送信する制御情報を総称して上りリンク制御情報（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ，ＵＣＩ）という。ＵＣＩは、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ｒｅＱｕｅｓｔ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｎｅｇａｔｉｖｅ−ＡＣＫ）、ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｉｏｎ）などを含む。本明細書において、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫは、単に、ＨＡＲＱ−ＡＣＫ又はＡＣＫ／ＮＡＣＫ（Ａ／Ｎ）と称する。ＨＡＲＱ−ＡＣＫは、ポジティブＡＣＫ（単に、ＡＣＫ）、ネガティブＡＣＫ（ＮＡＣＫ）、ＤＴＸ及びＮＡＣＫ／ＤＴＸのうちの少なくとも１個を含む。ＵＣＩは、一般に、ＰＵＣＣＨを介して送信されるが、制御情報とトラフィックデータが同時に送信される必要がある場合は、ＰＵＳＣＨを介して送信されてもよい。また、ネットワークの要求／指示によってＰＵＳＣＨを介してＵＣＩを非周期的に送信してもよい。
【００２６】
図２は、無線フレームの構造を例示する図である。セルラーＯＦＤＭ無線パケット通信システムにおいて、上りリンク／下りリンクデータパケット送信は、サブフレーム（ｓｕｂｆｒａｍｅ）単位で行われ、一サブフレームは、複数のＯＦＤＭシンボルを含む一定の時間区間で定義される。３ＧＰＰ  ＬＴＥ標準では、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）に適用可能なタイプ１の無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）構造と、ＴＤＤ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）に適用可能なタイプ２の無線フレーム構造を支援する。
【００２７】
図２（ａ）は、タイプ１の無線フレームの構造を例示する。下りリンク無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）は、１０個のサブフレーム（ｓｕｂｆｒａｍｅ）で構成され、サブフレームは、時間領域（ｔｉｍｅ  ｄｏｍａｉｎ）において２個のスロット（ｓｌｏｔ）で構成される。１サブフレームを送信するのにかかる時間をＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｔｉｍｅ  ｉｎｔｅｒｖａｌ）という。例えば、１サブフレームの長さは１ｍｓであり、１スロットの長さは０．５ｍｓである。１スロットは時間領域において複数のＯＦＤＭシンボルを含み、周波数領域において複数のリソースブロック（Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ，ＲＢ）を含む。３ＧＰＰ  ＬＴＥシステムでは、下りリンクでＯＦＤＭＡを用いるため、ＯＦＤＭシンボルが１シンボル区間を表す。ＯＦＤＭシンボルは、ＳＣ−ＦＤＭＡシンボル又はシンボル区間とも呼ばれる。ＲＢは１スロットにおいて複数の連続した副搬送波（ｓｕｂｃａｒｒｉｅｒ）を含んでもよい。
【００２８】
スロットに含まれるＯＦＤＭシンボルの数は、ＣＰ（Ｃｙｃｌｉｃ  Ｐｒｅｆｉｘ）の構成（ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって異なってもよい。ＣＰには、拡張ＣＰ（ｅｘｔｅｎｄｅｄ  ＣＰ）と一般ＣＰ（ｎｏｒｍａｌ  ＣＰ）とがある。例えば、ＯＦＤＭシンボルが一般ＣＰによって構成された場合、１スロットに含まれるＯＦＤＭシンボルの数は７個である。ＯＦＤＭシンボルが拡張ＣＰによって構成された場合、１ＯＦＤＭシンボルの長さが増加するため、１スロットに含まれるＯＦＤＭシンボルの数は、一般ＣＰの場合に比べて少ない。拡張ＣＰの場合、例えば、１スロットに含まれるＯＦＤＭシンボルの数は６個である。端末が速い速度で移動する場合などのようにチャネル状態が不安定な場合は、シンボル間干渉をより減らすために、拡張ＣＰを用いてもよい。
【００２９】
一般ＣＰが用いられる場合、１スロットは７個のＯＦＤＭシンボルを含み、１サブフレームは１４個のＯＦＤＭシンボルを含む。このとき、各サブフレームにおける先頭の最大３個のＯＦＤＭシンボルはＰＤＣＣＨ（ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）に割り当てられ、残りのＯＦＤＭシンボルはＰＤＳＣＨ（ｐｈｙｓｉｃａｌ  ｄｏｗｎｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）に割り当てられてもよい。
【００３０】
図２（ｂ）は、タイプ２の無線フレームの構造を例示する。タイプ２の無線フレームは、２個のハーフフレーム（ｈａｌｆ  ｆｒａｍｅ）で構成され、各ハーフフレームは、５個のサブフレームと、ＤｗＰＴＳ（Ｄｏｗｎｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）、保護区間（Ｇｕａｒｄ  Ｐｅｒｉｏｄ，ＧＰ）、ＵｐＰＴＳ（Ｕｐｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）で構成され、このうち１個のサブフレームは２個のスロットで構成される。ＤｗＰＴＳは、端末における初期セルサーチ、同期化又はチャネルの推定に用いられる。ＵｐＰＴＳは、基地局におけるチャネルの推定及び端末の上りリンク送信の同期を取るために用いられる。保護区間は、上りリンクと下りリンクとの間に下りリンク信号の多重経路の遅延によって上りリンクで生じる干渉を除去するための区間である。
【００３１】
無線フレームの構造は例示に過ぎず、無線フレームに含まれるサブフレームの数又はサブフレームに含まれるスロットの数、スロットに含まれるシンボルの数は、様々に変更することができる。
【００３２】
図３は、下りリンクスロットのリソースグリッドを例示する図である。
【００３３】
図３を参照すると、下りリンクスロットは、時間ドメインにおいて複数のＯＦＤＭシンボルを含む。１個の下りリンクスロットは、７（６）個のＯＦＤＭシンボルを含み、リソースブロックは、周波数ドメインにおいて１２個の副搬送波を含むことができる。リソースグリッド上の各要素（ｅｌｅｍｅｎｔ）は、リソースエレメント（Ｒｅｓｏｕｒｃｅ  Ｅｌｅｍｅｎｔ，ＲＥ）と呼ばれる。１個のＲＢは、１２×７（６）個のＲＥを含む。下りリンクスロットに含まれるＲＢの数ＮＲＢは、下りリンク送信帯域に依存する。上りリンクスロットの構造は、下りリンクスロットの構造と同様であり、ＯＦＤＭシンボルがＳＣ−ＦＤＭＡシンボルに切り替えられる。
【００３４】
図４は、下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）サブフレーム構造を例示する図である。
【００３５】
図４を参照すると、サブフレームの最初のスロットで先頭部に位置する最大３（４）個のＯＦＤＭシンボルは、制御チャネルが割り当てられる制御領域に対応する。残りのＯＦＤＭシンボルは、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  ＣＨａｎｃｅｌ）が割り当てられるデータ領域に該当する。ＰＤＳＣＨは、トランスポートブロック（Ｔｒａｎｓｐｏｒｔ  Ｂｌｏｃｋ，ＴＢ）又はそれに対応するコードワード（ＣｏｄｅＷｏｒｄ，ＣＷ）を運ぶために用いられる。トランスポートブロックは、送信チャネルを介してＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層からＰＨＹ（Ｐｈｙｓｉｃａｌ）層へ伝達されたデータブロックを意味する。コードワードは、トランスポートブロックの符号化したバージョンに該当する。トランスポートブロックとコードワードの対応関係は、スワッピングに応じて異なる。本明細書において、ＰＤＳＣＨ、トランスポートブロック、コードワードは互いに混用できる。ＬＴＥ（−Ａ）において用いられる下りリンク制御チャネルの例としては、ＰＣＦＩＣＨ（Ｐｈｙｓｉｃａｌ  Ｃｏｎｔｒｏｌ  Ｆｏｒｍａｔ  Ｉｎｄｉｃａｔｏｒ  Ｃｈａｎｎｅｌ）、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ  ｈｙｂｒｉｄ  ＡＲＱ  ｉｎｄｉｃａｔｏｒ  Ｃｈａｎｎｅｌ）などを含む。ＰＣＦＩＣＨは、サブフレームの最初のＯＦＤＭシンボルで送信され、サブフレームにおいて制御チャネルの送信に用いられるＯＦＤＭシンボルの個数に関する情報を運ぶ。ＰＨＩＣＨは、上りリンク送信に対する応答としてＨＡＲＱ−ＡＣＫ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ｒｅＱｕｅｓｔ  Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）信号を運ぶ。ＨＡＲＱ−ＡＣＫ応答はポジティブＡＣＫ（単に、ＡＣＫ）、ネガティブＡＣＫ（Ｎｅｇａｔｉｖｅ  ＡＣＫ，ＮＡＣＫ）、ＤＴＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ  Ｔｒａｎｓｍｉｓｓｉｏｎ）又はＮＡＣＫ／ＤＴＸを含む。ここで、ＨＡＲＱ−ＡＣＫは、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ、ＡＣＫ／ＮＡＣＫと混用できる。
【００３６】
ＰＤＣＣＨを介して送信される制御情報をＤＣＩ（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）と呼ぶ。ＤＣＩは、端末又は端末グループのためのリソース割り当て情報及び他の制御情報を含む。例えば、ＤＣＩは、上り／下りリンクスケジューリング情報、上りリンク送信（Ｔｘ）パワー制御命令などを含む。
【００３７】
図５は、上りリンクサブフレームの構造の一例を示す図である。
【００３８】
図５を参照すると、上りリンクサブフレームは、複数（例えば、２個）のスロットを含む。スロットは、ＣＰ（Ｃｙｃｌｉｃ  Ｐｒｅｆｉｘ）長に応じて互いに異なる数のＳＣ−ＦＤＭＡシンボルを含んでもよい。上りリンクサブフレームは、周波数領域においてデータ領域と制御領域とに区分できる。データ領域はＰＵＳＣＨを含み、音声などのデータ信号の送信に用いられる。制御領域はＰＵＣＣＨを含み、上りリンク制御情報（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ，ＵＣＩ）の送信に用いられる。ＰＵＣＣＨは、周波数軸においてデータ領域の両端部に位置したＲＢ対（ＲＢ  ｐａｉｒ）を含み、スロットを境界としてホッピングする。
【００３９】
ＰＵＣＣＨは、ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）、ＨＡＲＱ−ＡＣＫ及び／又はＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）の制御情報の送信に用いられる。
【００４０】
●  Ｎｅｗ  ＲＡＴ
【００４１】
先ず、ＮＲ（ｎｅｗ  ＲＡＴ）において使用可能なアナログビームフォーミングについて説明する。
【００４２】
Ａｎａｌｏｇ  Ｂｅａｍｆｏｒｍｉｎｇ
【００４３】
ミリ波（Ｍｉｌｌｉｍｅｔｅｒ  Ｗａｖｅ、ｍｍＷ）では波長が短いので、同一面積に多数のアンテナ要素の設置が可能である。即ち、３０ＧＨｚ帯域において波長は１ｃｍであるので、５＊５ｃｍのパネル（ｐａｎｅｌ）に０．５λ（波長）間隔で２次元（２−ｄｉｍｅｎｓｉｏｎ）配列する場合、全１００個のアンテナ要素を設けることができる。これにより、ミリ波（ｍｍＷ）方式では多数のアンテナ要素を使用してビームフォーミング利得を上げてカバレッジを増加させるか、或いはスループット（ｔｈｒｏｕｇｈｐｕｔ）を向上させることができる。
【００４４】
ｍｍＷ方式では、アンテナ要素毎にＴＸＲＵ（Ｔｒａｎｓｃｅｉｖｅｒ  Ｕｎｉｔ）が設けられる場合、各々のアンテナ要素は送信パワー及び位相を個別に調節することができ、よって、各々の周波数リソースは独立的なビームフォーミングが可能である。しかし、１００個余りの全てのアンテナ要素にＴＸＲＵを設けることは費用面で実効性がないという問題がある。
【００４５】
代案として、１個のＴＸＲＵに多数のアンテナ要素をマッピングし、アナログ位相シフター（ａｎａｌｏｇ  ｐｈａｓｅ  ｓｈｉｆｔｅｒ）でビーム方向を調節する方式が考えられている。しかし、このアナログビームフォーミング方式では全帯域に対して同方向にビームが形成されるため、周波数選択的なビームフォーミングが行えないという問題がある。
【００４６】
また別の代案として、デジタルビームフォーミングとアナログビームフォーミングのハイブリッド形態として、全Ｑ個のアンテナ要素に対して全Ｂ（ｗｈｅｒｅ，Ｂ＜Ｑ）個のＴＸＲＵｓをマッピングするハイブリッドビームフォーミングが考えられる。Ｂ個のＴＸＲＵｓとＱ個のアンテナ要素を相互連結する方式に応じて異なり得るが、一般に、同時に送信可能なビームの方向は、Ｂ個以下に制限される。
【００４７】
ＮＲ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ
【００４８】
ＮＲシステムにおいて、制御チャネルの送信単位は、ＮＲ−ＲＥＧ（ｒｅｓｏｕｒｃｅ  ｅｌｅｍｅｎｔ  ｇｒｏｕｐ）及び／又はＮＲ−ＣＣＥ（ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ  ｅｌｅｍｅｎｔ）などで定義できる。
【００４９】
ＮＲ−ＲＥＧは、時間ドメインでは１ＯＦＤＭシンボル、周波数ドメインでは１ＰＲＢに該当することができる。１ＰＲＢは１２サブキャリアに該当することができる。また、１ＣＣＥは６ＲＥＧに該当することができる。
【００５０】
一方、制御リソースセット（ｃｏｎｔｒｏｌ  ｒｅｓｏｕｒｃｅ  ｓｅｔ，ＣＯＲＥＳＥＴ）及びサーチスペース（ｓｅａｒｃｈ  ｓｐａｃｅ，ＳＳ）について簡単に説明すると、ＣＯＲＥＳＥＴは、制御信号送信のためのリソースのセットであり、サーチスペースは、端末がブラインド検出を行う制御チャネル候補の集合である。サーチスペースは、ＣＯＲＥＳＥＴ上に設定されてもよい。一例として、１個のＣＯＲＥＳＥＴに１個のサーチスペースが定義される場合、ＣＳＳ（ｃｏｍｍｏｎ  ｓｅａｒｃｈ  ｓｐａｃｅ）のためのＣＯＲＥＳＥＴとＵＳＳ（ＵＥ−ｓｐｅｃｉｆｉｃ  ｓｅａｒｃｈ  ｓｐａｃｅ）のためのＣＯＲＥＳＥＴがそれぞれ設定されてもよい。別の例として、１個のＣＯＲＥＳＥＴに多数のサーチスペースが定義されてもよい。例えば、ＣＳＳとＵＳＳが同一のＣＯＲＥＳＥＴに設定されてもよい。以下の例示において、ＣＳＳは、ＣＳＳが設定されるＣＯＲＥＳＥＴを意味して、ＵＳＳは、ＵＳＳが設定されるＣＯＲＥＳＥＴなどを意味してもよい。
【００５１】
基地局は、ＣＯＲＥＳＥＴに対する情報を端末にシグナリングすることができる。例えば、各々のＣＯＲＥＳＥＴのために、ＣＯＲＥＳＥＴ  Ｃｏｎｆｉｇｕｒａｔｉｏｎと該当ＣＯＲＥＳＥＴの時間の長さ（ｔｉｍｅ  ｄｕｒａｔｉｏｎ）（ｅ．ｇ．，１／２／３シンボルなど）がシグナリングされてもよい。１シンボル−ＣＯＲＥＳＥＴにＣＣＥを分散させるインターリービングが適用される場合、２又は６個のＲＥＧのバンドリングが行われてもよい。２シンボル−ＣＯＲＥＳＥＴに２又は６個のＲＥＧのバンドリングが行われ、時間優先マッピングが適用されてもよい。３シンボル−ＣＯＲＥＳＥＴに３又は６個のＲＥＧのバンドリングが行われ、時間優先マッピングが適用されてもよい。ＲＥＧバンドリングが行われる場合、端末は、該当バンドリング単位に対して、同一のプリコーディングを仮定することができる。
【００５２】
Ｍｕｌｔｉ−Ｂｅａｍ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ
【００５３】
以下、送信端（ｅ．ｇ．，ｅＮｏｄｅＢ）と受信端（ｅ．ｇ．，ＵＥ）がそれぞれ１個以上のビーム（Ｂｅａｍ）を有しているとき、ビーム対（Ｂｅａｍ  ｐａｉｒ）に対する設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）方法、及びビームをモニタリング（ｍｏｎｉｔｏｒｉｎｇ）して連結する方法を説明する。また、制御チャネルサーチスペース（ｓｅａｒｃｈ  ｓｐａｃｅ）割り当て方法、及びブラインドデコーディング（ｂｌｉｎｄ  ｄｅｃｏｄｉｎｇ，ＢＤ）をビームの設定に応じて異ならせて行う方法などについても説明する。
【００５４】
１．Ｂｅａｍ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ＆  ＲＬＭ  （Ｒａｄｉｏ  Ｌｉｎｋ  Ｍｏｎｉｔｏｒｉｎｇ）  ｏｐｅｒａｔｉｏｎ  ｆｏｒ  ＵＥ
【００５５】
端末は、多数のビームを介してＤＣＩを運ぶ制御チャネル（ｅ．ｇ．，ＮＲ−ＰＤＣＣＨ）を受信することができる。多数のビームのうち、プライマリビーム（Ｐｒｉｍａｒｙ  Ｂｅａｍ）とセカンダリビーム（Ｓｅｃｏｎｄａｒｙ  Ｂｅａｍ）が端末の側面から定義されてもよい。このように、プライマリビーム及びセカンダリビームが定義される環境と、定義されない環境とがそれぞれ考慮されてもよい。
【００５６】
一方、後述するプライマリ／セカンダリビームは、従来のＬＴＥシステムのプライマリ／セカンダリセルとは異なる概念に該当する。プライマリ／セカンダリビームは、必ずしも異なるセルに属する必要がなく、同一のセル上にも、プライマリ／セカンダリビームが設定できる。例えば、１個のキャリア帯域上にも、プライマリ／セカンダリビームがいずれも設定されてもよい。また、他のキャリア帯域上にプライマリ／セカンダリビームがそれぞれ設定されてもよい。
【００５７】
１．１  Ｐｒｉｍａｒｙ  ＢｅａｍとＳｅｃｏｎｄａｒｙ  Ｂｅａｍが定義される場合
【００５８】
プライマリビームとセカンダリビームが定義される場合、プライマリ／セカンダリビームの機能及び動作が互いに異なってもよい。
【００５９】
プライマリビームを介してセカンダリビームに対するＲＲＣ再設定（ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージが送信されてもよい。例えば、セカンダリビームを設定／再設定するための上位層シグナリングメッセージが、プライマリビームを介して送信されてもよい。
【００６０】
この場合、端末は、プライマリビームのみに対してＲＬＭ（Ｒａｄｉｏ  ｌｉｎｋ  ｍｏｎｉｔｏｒｉｎｇ）を行い、またプライマリビームに対してＲＬＦ（Ｒａｄｉｏ  ｌｉｎｋ  ｆａｉｌｕｒｅ）を宣言することができる。
【００６１】
一例として、プライマリビームのみに対してＲＬＭが行われてもよく、この場合：
【００６２】
−  （ｉ）端末のＲＬＭ測定は、プライマリビームが送信されるリソースセットのサブセットに限定されてもよい。端末は、プライマリビームのみに対してＳＩＮＲの算出及び測定を行う。このような端末のＲＬＭ動作は、ＲＬＭに必要なＲＳがＰＢＣＨでもＤＭ−ＲＳでも関わらず、同様に行うことができる。即ち、１個のビームのみに対してＲＬＭを行うことができる。
【００６３】
-  （ｉｉ）別の例として、ＲＬＭ測定のために、多数のビームに対する平均（ａｖｅｒａｇｅ）、Ｂｅｓｔ  Ｂｅａｍ  Ｓｅｌｅｃｔｉｏｎ又はＷｅｉｇｈｔｅｄ  Ａｖｅｒａｇｅ  Ｂｅａｍ  Ｓｅｌｅｃｔｉｏｎなどを用いてもよい。但し、ＲＬＦ宣言は、プライマリビームの変更が必要であるが、プライマリビームスイッチング手順が行えない場合に限って行ってもよい。即ち、ＲＬＭは多数のビームに対して行うが、ＲＬＦはプライマリビームスイッチングができない場合に（ｅ．ｇ．，セカンダリビームがプライマリビームになれない場合に）発生することができる。
【００６４】
-  （ｉｉｉ）或いは、プライマリビームの接続に失敗した場合に限ってビームリカバリー手順を行ってもよい。例えば、端末は、セカンダリビームの接続に失敗する場合は、セカンダリビームスイッチングによって他のセカンダリビームを用いることができる。
【００６５】
一方、プライマリビームの接続失敗に対するバックアップ（ｂａｃｋｕｐ）案として、プライマリビームが絶えた場合、セカンダリビームを介してプライマリビームに対するＲＲＣ再設定メッセージが送信されてもよい。
【００６６】
或いは、プライマリビームの設定は、制御サーチスペース又は制御リソースセット（ｃｏｎｔｒｏｌ  ｒｅｓｏｕｒｃｅ  ｓｅｔ，ＣＯＲＥＳＥＴ）の設定と共にシグナリングされてもよい。セカンダリビームの設定が制御サーチスペース又は制御リソースセット設定に含まれてもよい。但し、端末に設定されたセカンダリビームは、別途の活性化（ａｃｔｉｖａｔｉｏｎ）メッセージを介して活性化されてもよい。セカンダリビームの活性化メッセージは、ＤＣＩ又はＭＡＣ  ＣＥ（ｃｏｎｔｒｏｌ  ｅｌｅｍｅｎｔ）の形態であってもよい。
【００６７】
また、セカンダリビームに対する再設定は、プライマリビームに対する中断（ｉｎｔｅｒｒｕｐｔｉｏｎ）なく行われてもよい。また、後述のように、セカンダリビームがプライマリビームに切り替えられてもよい。
【００６８】
１．１．１  Ｓｗｉｔｃｈｉｎｇ  Ｓｅｃｏｎｄａｒｙ  Ｂｅａｍ  ｔｏ  Ｐｒｉｍａｒｙ  Ｂｅａｍ
【００６９】
プライマリビームとセカンダリビームに対する端末の測定は持続的に行われてもよい。或いは、端末は、非周期的なネットワークの要求に従って、各々のビームを測定報告してもよい。ネットワークは、端末の測定報告に基づき、プライマリビームを変更すべき条件を決定して、端末に指示してもよい。或いは、端末がプライマリビームとセカンダリビームに対する測定に基づいて、プライマリビームスイッチングをネットワークに要求してもよい。
【００７０】
１．１．１．１  ネットワークが端末にＰｒｉｍａｒｙ  Ｂｅａｍ  Ｓｗｉｔｃｈｉｎｇを要求
【００７１】
ネットワークは端末にプライマリビームスイッチングを要求することができる。
【００７２】
一例として、ネットワークは、プライマリビームのみを介してプライマリビームスイッチングを要求し、端末からＡＣＫが受信されるまで、プライマリビームスイッチングを行わなくてもよい。例えば、ネットワークは、ビームスイッチング要求送信に対する端末のＡＣＫを受信して、ビームスイッチングに対する確認（ｃｏｎｆｉｒｍａｔｉｏｎ）を受けると、ビームスイッチングを行うことができる。ビームスイッチング確認の場合、従来のプライマリビーム及び／又は新たなプライマリビームで送信されるか、又はセカンダリビームで送信されてもよい。或いは、別途のビームスイッチング確認なく、端末がＡＣＫを送信するとき、ビームスイッチングが行われてもよい。
【００７３】
別の例として、ネットワークは、セカンダリビームのみでプライマリビームスイッチング要求を送信してもよい。この場合、ネットワーク／端末は、通常の（ｒｅｇｕｌａｒ）ＲＲＣ手順を通じてプライマリビームスイッチングを行うことができる。
【００７４】
また、プライマリビームスイッチング要求がビームスイーピング（Ｓｗｅｅｐｉｎｇ）区間でのみ送信可能に制限されてもよい。例えば、ネットワークが端末のビーム方向を知らない可能性があるため、ビームスイーピングが行われるリソースでのみプライマリビームスイッチングが行われるように定義されてもよい。
【００７５】
また別の例として、プライマリ／セカンダリビームにおいてビームスイッチング要求が送信されてもよい。端末は、ビームスイッチングが完了していないＲＲＣ曖昧（ａｍｂｉｇｕｉｔｙ）区間の間には、Ｏｌｄ／Ｎｅｗプライマリビームに対するモニタリングを同時に行うことができ、ネットワークは、Ｎｅｗプライマリビームのモニタリングのために、別途のリソースセットを仮に端末に設定することができる。
【００７６】
例えば、新たなプライマリビームをモニタリングするためのリソースセット及びブラインド検出（ＢＤ）分配は、以下のように設定することができる。ここで、ブラインド検出分配とは、Ｏｌｄプライマリビームに対して端末が行うべきブラインド検出の回数と、Ｎｅｗプライマリビームに対して端末が行うべきブラインド検出の回数をネットワークが設定することを意味する。
【００７７】
（ｉ）一例として、Ｏｌｄ／Ｎｅｗプライマリビームのリソースセットは同様に設定されるものの、端末は各々のビームを異なるＯＦＤＭシンボルでモニタリングすることができる。例えば、端末は、１番目のＯＦＤＭシンボルでＯｌｄプライマリビームをモニタリングし、２番目のＯＦＤＭシンボルでＮｅｗプライマリビームをモニタリングするように定義されてもよい。
【００７８】
（ｉｉ）別の例として、端末は、Ｎｅｗプライマリビームに対するリソースセットを予めＲＲＣによって設定されてもよい。端末がＲＲＣを介してプライマリビームスイッチング要求を受ける場合、そのリソースセットが活性化され、ＲＲＣ設定完了（ｃｏｍｐｌｅｔｅ）が発生すると（ｅ．ｇ．，ビームスイッチング完了）、該当リソースセットが非活性化されてもよい。端末は、リソースセットが活性化された場合に限って、該当リソースセットにおいてＮｅｗプライマリビームをモニタリングすることができる。
【００７９】
（ｉｉｉ）また別の例として、従来のセカンダリビームのリソースセットがそのままＮｅｗプライマリビームのリソースセットとして用いられてもよい。この案は、Ｎｅｗプライマリビームがセカンダリビームの中から選ばれたときに有用であり得る。仮に、新たなビームのうち、Ｎｅｗプライマリビームが選択される場合、ビームスイッチングのためのＲＲＣメッセージにＮｅｗプライマリビームのための仮のリソースセット情報が含まれてもよい。
【００８０】
一方、（ｉ）〜（ｉｉｉ）方式において、ＲＲＣ完了後、Ｎｅｗプライマリビームのリソースセット／ＢＤ設定は、Ｏｌｄプライマリビームに対して設定されたリソースセット／ＢＤ設定に従ってもよい。また、Ｏｌｄプライマリビームは、セカンダリビームに切り替えられてもよく、そうではない場合、端末は、Ｏｌｄプライマリビームをこれ以上はモニタリングしなくてもよい。
【００８１】
例えば、ＲＲＣ設定又はＭＡＣ  ＣＥを介してリソースセットが定義され、曖昧（ａｍｂｉｇｕｉｔｙ）区間（ｅ．ｇ．，ビームスイッチング要求後、且つビームスイッチング完了前の区間）においてＮｅｗプライマリビームのための仮のリソースセットを別として設定されるか、ＲＲＣ再設定時に設定されてもよい。曖昧区間において端末は、Ｏｌｄ及び／又はＮｅｗプライマリビームを両方モニタリングすることができ、ネットワークは、同一のメッセージを２つのビームの両方を介して送信するか、又は２つのビームのうち１つのみで送信してもよい。
【００８２】
１．２  Ｐｒｉｍａｒｙ  ＢｅａｍとＳｅｃｏｎｄａｒｙ  Ｂｅａｍが定義されない場合
【００８３】
プライマリビーム／セカンダリビームが定義されないとは、全てのビームが同じ優先順位／機能を有するか、又は端末が１個のビームのみをモニタリングするように設定されることを意味してもよい。この場合、端末はＲＬＭを行うビームを様々な方法によって選択することができるが、一例として、ＲＬＭのために、特定のビームを指定したり、多数のビームのうちベスト（ｂｅｓｔ）なビームを選択したり、又は多数のビームのうち平均の性能を有するビームを選択したりすることができる。
【００８４】
ビーム設定のために、ＲＲＣメッセージなどの様々な方法を用いることができる。
【００８５】
本例示によれば、全てのビームに対して同一のビームリカバリー／管理（Ｍａｎａｇｅｍｅｎｔ）を適用することができる。ＲＬＦは、全てのビームの接続に失敗する場合に生じ得る。或いは、ＲＬＭ結果がＯｕｔ−ｏｆ−Ｓｙｎｃ．であり、ビームリカバリーに失敗する場合、ＲＬＦが発生する場合もある。
【００８６】
１．３  Ｍｕｌｔｉ−Ｂｅａｍ／Ｓｉｎｇｌｅ−Ｂｅａｍ動作可否がＵＥ−Ｔｒａｎｓｐａｒｅｎｔの場合
【００８７】
端末は、受信されるビームがＭｕｌｔｉ−ＢｅａｍであるかＳｉｎｇｌｅ−Ｂｅａｍであるかが分からない場合があり得る。例えば、ＤＭ−ＲＳシーケンスが各々のビームにおいて同様であるとき、ＤＭ−ＲＳとデータが同じビーム方向に送信される場合にＵＥ−Ｔｒａｎｓｐａｒｅｎｔであり得る。また、Ｍｕｌｔｉ−Ｂｅａｍに対する端末Ｒｘビームが同一の場合にＵＥ−Ｔｒａｎｓｐａｒｅｎｔであり得る。端末はビームの形態を知らないため、単一ビームに対するＲＬＭと同様にＲＬＭを行うことができる。
【００８８】
端末に多数のビームが構成される場合、ネットワークが多数のビームのうち１個を選択してＤＣＩを送信する案と、ネットワークが多数のビームを介して同一のＤＣＩを繰り返し送信すると、端末が重複するＤＣＩを自律的に処理する案とが考えられる。ネットワークは、上位層シグナリングを介して１個のＤＣＩを１個のビームにのみ送信するか、多数のビームに送信するかを指示することができる。これは、ＤＣＩだけではなく、ＵＣＩの送信にも同様に適用可能である。仮に、Ｍｕｌｔｉ−Ｂｅａｍで同一のＤＣＩが繰り返し送信されることを指示する場合、又はこのためのモードでネットワーク／端末が動作する場合、ネットワークは、同一のＤＣＩが繰り返し送信される回数を端末にシグナリングすることができる。同一のＤＣＩの識別のために、端末は、端末固有のデータ送信においてＨＡＲＱ  Ｐｒｏｃｅｓｓ  ＩＤ、ＮＤＩ（ｎｅｗ  ｄａｔａ  ｉｎｄｉｃａｔｏｒ）が同一であると、リソース割り当てなどが同一であると仮定することができる。グループ共通のデータ送信又はセル固有のデータ送信の場合、以下の（ｉ）、（ｉｉ）のような動作が可能である。
【００８９】
（ｉ）一例として、端末は、制御情報（ｅ．ｇ．，ＤＣＩ）が多数のビームを介して受信されると仮定できるが、但し、ＣＳＳでは、１個のＤＣＩが１個のビームのみを介して受信されると仮定できる。多数のビームを介して受信される各々のＤＣＩがスケジュールするデータが同一であり得る場合、端末は修正（ａｇｇｒｅｇａｔｉｏｎ）（ｅ．ｇ．，ｄａｔａ  ａｇｇｒｅｇａｔｉｏｎ）可能なビームに対する情報をネットワークから別途設定されてもよい。このように、ＣＳＳ制御情報／データとＵＳＳ制御情報／データとは互いに異なるように取り扱われてもよい。
【００９０】
（ｉｉ）別の例として、端末に多数のビームを構成する場合、端末は同じ設定がＵＳＳ／ＣＳＳのいずれにも適用可能であると仮定することができる。この場合、端末は、検出されたＤＣＩのうちの品質が最良なＤＣＩのスケジューリングに従ってデータを受信するか、又は各ＤＣＩがスケジュールしたデータを全部読み込むことができる。
【００９１】
ＵＳＳを介して送信されるＤＣＩは、データ送信のためのビームインデックスを含むことができる。制御情報とデータのビームが異なってもよいが、ネットワークが多数のビームを介してＤＣＩを重複送信する場合、制御情報とデータとの間に、端末にビームスイッチングのためのギャップ（ｇａｐ）が与えられてもよく（ｉ．ｅ．，ｃｏｎｔｒｏｌ  ｄｅｃｏｄｉｎｇ  ｌａｔｅｎｃｙ）、ネットワークはデータを各々のビームを介して送信してもよい。この場合、制御情報が重複すると、データも重複する可能性がある。１個のデータの重複は、過度なリソースの無駄をもたらすため、ネットワークはクロス−スロットスケジューリング（ｃｒｏｓｓ−ｓｌｏｔ  ｓｃｈｅｄｕｌｉｎｇ）によって他のビームをデータに設定して、１個のビームのみに対してデータを送信してもよい。
【００９２】
ＤＣＩに対する設定がＵＣＩ送信にも同様に適用できる。その設定によって繰り返し送信が設定されると、端末はＵＣＩを多数のビームを介して繰り返し送信することができる。これとは異なり、１個のビームのみで送信することを指示する設定の場合、端末はネットワーク／端末によって選択されたビームに該当するリソースでのみＵＣＩを送信してもよい。
【００９３】
或いは、ＤＣＩに対する設定とは別として、ＵＣＩのための設定を定義してもよい。
【００９４】
２．  Ｓｅａｒｃｈ  Ｓｐａｃｅ  Ａｌｌｏｃａｔｉｏｎ
【００９５】
プライマリ／セカンダリビームが定義されるか、複数のビームが定義される場合のサーチスペース（ｓｅａｒｃｈ  ｓｐａｃｅ）の割り当てについて説明する。
【００９６】
各ビームにおいて別々のリソースセットが割り当てられる場合、多数のビームの各々にＣＳＳとＵＳＳが共に配置されてもよく、ビームの状態及び用途に応じて、ＣＳＳとＵＳＳが分配されてもよい。
【００９７】
また、ＣＳＳ／ＵＳＳそのものが分配されてもよく、このサーチスペースの配置は、ビームの性能や設定されたリソースセットなどの様々な環境に応じて変更できる。
【００９８】
各々のビームにおいてリソースセットの構成が異なる場合、各々のリソースセットにおいてＣＳＳ／ＵＳＳの有無が設定されるか、ＣＳＳ／ＵＳＳのリソースセットの設定が異なってもよい。
【００９９】
ＣＳＳに多数のビームが設定された場合、端末は、該当ビームから受信されるＣＳＳデータがアグリゲーション（ａｇｇｒｅｇａｔｉｏｎ）できると仮定してもよい。この場合、端末は、多数のビームを介して受信されるデータのうちの１個のデータのみを読み取るか、複数のデータを読み取り、性能の最良なデータのみを取るか、又は受信された複数のデータをアグリゲーションするかを決定することができる。端末は該当ビームで送信されるデータが同一のものであることを仮定することができる。このような同一のデータの仮定は、少なくとも同一のスロット内のＣＳＳにおいて送信されるＤＣＩがスケジュールするデータに適用可能である。或いは、ネットワークは同一のデータであると仮定可能な期間又は時間情報を端末に知らせてもよい。そうではない場合、端末は他のデータ送信を仮定してもよい。
【０１００】
或いは、プライマリビームとセカンダリビームが設定されている場合、端末はプライマリビームでのみＣＳＳをモニタリングしてもよい。或いは、端末はセカンダリビームでもＣＳＳをモニタリングするものの、セカンダリビーム上のＣＳＳのモニタリングのために用いられるＲＮＴＩと、プライマリビーム上のＣＳＳのモニタリングのために用いられるＲＮＴＩとを異ならせて設定してもよい。一例として、プライマリビームのＣＳＳでは、全てのＲＮＴＩが用いられるが、セカンダリビームのＣＳＳでは、Ｃ−ＲＮＴＩなどの端末固有のＲＮＴＩ／グループ固有のＲＮＴＩのみが用いられてもよい。
【０１０１】
３．ＲＡＣＨ  Ｐｒｏｃｅｄｕｒｅ  ｗｉｔｈ  Ｍｕｌｔｉ−Ｂｅａｍ
【０１０２】
Ｍｕｌｔｉ−Ｂｅａｍ環境におけるランダムアクセス手順を説明する。このとき、Ｍｕｌｔｉ−Ｂｅａｍは、１個又は多数のＴＲＰｓ（ｔｒａｎｓｍｉｓｓｉｏｎ／ｒｅｃｅｐｔｉｏｎ  ｐｏｉｎｔｓ）によって形成することができる。
【０１０３】
３．１  Ｐａｇｉｎｇ
【０１０４】
３．１．１  Ｐａｇｉｎｇ  ｉｎ  ＩＤＬＥ  Ｍｏｄｅ
【０１０５】
アイドルモード（Ｉｄｌｅ  Ｍｏｄｅ）では、端末のベストビーム情報が分かり難いため、ネットワークはビームスイッチング方式によって多数のビームを介してページング情報を送信することができる。このとき、ネットワークは、各々のビームをスイープする時間及びページング情報が送信される時間に対する設定を定義してもよく、スイーピングタイミングとページング情報送信時間とを一致させてもよい。
【０１０６】
３．１．２  Ｐａｇｉｎｇ  ｉｎ  ＣＯＮＮＥＣＴＥＤ  Ｍｏｄｅ
【０１０７】
コネクテッドモード（Ｃｏｎｎｅｃｔｅｄ  Ｍｏｄｅ）においても、システム情報アップデートなどのためにページング情報を送信することができ、このための詳細な案を説明する。
【０１０８】
３．１．２．１  Ｉｄｌｅ  ＭｏｄｅにおけるページングのためのＣＳＳを同様に維持
【０１０９】
アイドルモードにおいてページングのために定義されたスロットと周波数インデックスをコネクテッドモードにおいてそのまま用いることができる。
【０１１０】
端末は、コネクテッドモードのために定義されたリソースと、アイドルモードのために定義されたリソースとを両方受信できなければならないため、端末がページング情報を読み取るためには、周波数再チューニング（ｆｒｅｑｕｅｎｃｙ  ｒｅｔｕｎｉｎｇ）が必要となるかもしれない。
【０１１１】
３．１．２．２  ＰａｇｉｎｇのためのＣＳＳをＣｏｎｎｅｃｔｅｄ  Ｍｏｄｅにおいて別として設定
【０１１２】
ページングのためのＣＳＳがアイドルモードとコネクテッドモードにおいて別々に設定されてもよい。コネクテッドモードにおいてページングのためのＣＳＳに対する情報は、ＰＤＣＣＨ又はＰＤＳＣＨを介して送信されることができる。
【０１１３】
３．１．２．３  Ｐａｇｉｎｇは常にＵＳＳで送信
【０１１４】
ＳＩアップデートのためのＤＣＩは、ページングとは別途のＲＮＴＩ又は別途のＤＣＩフォーマットを介してＣＳＳで送信され、ページングはＵＳＳを介してユニキャスト（ｕｎｉｃａｓｔ）で送信されてもよい。
【０１１５】
３．２  ＲＡＲ  ｆｏｒ  Ｍｕｌｔｉ−Ｂｅａｍ
【０１１６】
３．２．１  ＲＡＲ  ｉｎ  ＩＤＬＥ  Ｍｏｄｅ／ＲＡＲ  ｆｏｒ  Ｃｏｎｔｅｎｔｉｏｎ−ｂａｓｅｄ  ＰＲＡＣＨ
【０１１７】
３．２．１．１  Ｂｅｓｔ  ＢｅａｍでのみＲＡＲ送信
【０１１８】
ＲＡＲ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｒｅｓｐｏｎｓｅ）はベストビームでのみ送信されてもよい。ベストビームを介してＲＡＲが送信されることで、端末にベストビームインデックスを自動的に知らせることができる。ベストビームはネットワークが決定してもよい。例えば、ベストビームとは、ランダムアクセスプリアンブルが送信されるＰＲＡＣＨ（ｐｈｙｓｉｃａｌ  ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｃｈａｎｎｅｌ）ビームの対応（ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ）ビームで定義されてもよい。
【０１１９】
３．２．１．２  Ｋ個のＢｅａｍにおいてＲＡＲ送信
【０１２０】
ＲＡＲはＫ個のビームで送信されてもよい。ビームの数Ｋは、ＳＩＢ（ｓｙｓｔｅｍ  ｉｎｆｏｒｍａｔｉｏｎ  ｂｌｏｃｋ）を介して設定されてもよく、Ｋ個のビームはベストビームの隣接ビームであるか、又はＳＩＢによって設定されてもよい。例えば、各々のビームがベストビームになる場合に対して、そのベストビームと共に用いられるＫ個のビームが端末に設定されてもよい。
【０１２１】
Ｋ個のビームが選択された場合、ＲＡＲはＫ個のビームのうちの１個でのみ送信されるか、又はＫ個のビームの全部で送信されてもよい。ＲＡＲが１個のビームでのみ送信されるのか、Ｋ個のビームの全部で送信されるのかは、上位層シグナリングを介して設定できる。
【０１２２】
また、多数のビームが設定される場合、制御リソースセットは、各ビームにおいて別々に設定されるか、ＲＡＲ  Ｗｉｎｄｏｗ内において自動に設定されてもよい。一例として、制御リソースセットが自動に設定される場合、端末は設定された制御リソースセットにおいてＫ個のビームを最初から順に従ってモニタリングすることができる。
【０１２３】
３．２．２  ＲＡＲ  ｉｎ  ＣＯＮＮＥＣＴＥＤ  ｏｒ  ＲＡＲ  ｆｏｒ  Ｃｏｎｔｅｎｔｉｏｎ−Ｆｒｅｅ  ＰＲＡＣＨ
【０１２４】
ＲＡＲは、ＲＡＲのために定義されたＣＳＳ又はＵＳＳを用いて送信されてもよい。また、ＲＡＲはベストビームでのみ送信されるか、又はＫ個のビームを介して送信されてもよい。
【０１２５】
Ｃｏｎｔｅｎｔｉｏｎ−ｆｒｅｅ  ＰＲＡＣＨ送信に対するＲＡＲは、端末のＣＳＳ又はＵＳＳの設定に従って送信されてもよい。どのサーチスペースを介してＲＡＲを送信するかは、上位層シグナリングを介して指示されてもよい。
【０１２６】
ＵＳＳを介してＲＡＲを送信するためにＣ−ＲＮＴＩが用いられてもよく（ｅ．ｇ．，ＲＡＲ送信のためのＰＤＣＣＨをＣ−ＲＮＴＩでスクランブリング）、ＲＡＲコンテンツはペイロード（ｅ．ｇ．，ＰＤＳＣＨ）で送信されてもよい。この場合、端末がＲＡＲ送信を受信したか否かについては、ＰＤＳＣＨをデコードすることで確認できるため、端末の物理層ではＲＡＲ送信を確認することが難しい。よって、物理層においてＲＡＲが確認できるように、ネットワークは、ＲＡＲ送信にＣ−ＲＮＴＩ以外の他のＲＮＴＩを用いることができる。或いは、Ｃｏｎｔｅｎｔｉｏｎ−Ｆｒｅｅランダムアクセスの場合、ＲＡＲ受信を介してランダムアクセス手順が完了されると定義しなくてもよい。
【０１２７】
ＣＳＳでＲＡＲが送信される場合、ＲＡＲ  Ｂｅａｍ  ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ（ｏｆ  ＰＲＡＣＨ  Ｂｅａｍ）は、ＣＳＳで構成されたビームとは異なり得る。このとき、ネットワークは、Ｃｏｎｔｅｎｔｉｏｎ  Ｆｒｅｅ  ＰＲＡＣＨのために、時間／周波数リソースのみを設定して、端末がビームを選択してもよい。この場合、端末が選択したＰＲＡＣＨ  Ｂｅａｍに関する情報がＰＲＡＣＨにおいて共に送信されてもよい。或いは、ネットワークは多数のビームに対してＰＲＡＣＨリソースを設定して、端末がＰＲＡＣＨを選択することもできる。或いは、Ｂｅａｍ  Ｒｅｃｏｖｅｒｙ／Ｍａｉｎｔｅｎａｎｃｅ過程のみによってビームを変更して、Ｃｏｎｔｅｎｔｉｏｎ−Ｆｒｅｅ  ＰＲＡＣＨの場合、１個のビームに固定してもよい。
【０１２８】
仮に、ＰＲＡＣＨ  Ｂｅａｍに対するｃｏｒｒｅｓｐｏｎｄｅｎｃｅ  ＢｅａｍがＣＳＳモニタリングのためのビームとは異なる場合、以下のオプション（ｉ）〜（ｉｖ）を考慮してもよい。
【０１２９】
（ｉ）端末はＲＡＲが依然として設定されたＣＳＳで受信されると仮定できる。
【０１３０】
（ｉｉ）端末は同一の時間／周波数リソース（ｔｏ  ＣＳＳ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を仮定して、ビームのみをＰＲＡＣＨに対するｃｏｒｒｅｓｐｏｎｄｅｎｃｅとして仮定できる。
【０１３１】
（ｉｉｉ）各ビームにおいて仮の又はＲＡＲ  ＣＳＳ  Ｃｏｎｆｉｇｕｒａｔｉｏｎが別々に存在してもよい。即ち、各ビームにおいてＣＳＳ設定が別々に存在し、端末はＰＲＡＣＨ  ｃｏｒｒｅｓｐｏｎｄｉｎｇ  Ｂｅａｍ  ＣＳＳに対するモニタリングを行ってもよい。
【０１３２】
（ｉｖ）端末がＰＲＡＣＨを設定されたＣＳＳとは異なるビーム方向に送信する場合、ビームリカバリー手順を端末がトリガーすることができる。
【０１３３】
３．３  ＭＳＧ  ３
【０１３４】
ＭＳＧ  ３を介してＢｅａｍ  ＩＤが送信されてもよい。Ｂｅａｍ  ＩＤは、Ｍｕｌｔｉ−Ｂｅａｍを介して送信されてもよい。
【０１３５】
３．４  ＭＳＧ  ４  ＰＤＣＣＨ
【０１３６】
ＭＳＧ  ４のＰＤＣＣＨ送信のために、ＲＡＲのためのＣＳＳをそのまま使用することができる。或いは、各ビームにＭＳＧ  ４  ＰＤＣＣＨのためのサーチスペースを設定してもよい。
【０１３７】
３．５  ＳＩＢ  ｔｒａｎｓｍｉｓｓｉｏｎ
【０１３８】
ＳＩＢ  ＣＳＳのためのビームが別に定義されてもよい。
【０１３９】
３．６  Ｍｕｌｔｉ−Ｂｅａｍ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｖｉａ  ＲＲＣ
【０１４０】
３．６．１  Ｐｒｉｍａｒｙ  Ｂｅａｍ  ｓｅｌｅｃｔｉｏｎ  ｖｉａ  ＲＡＣＨ  ｐｒｏｃｅｄｕｒｅ  ＋  ＲＲＣ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｏｎ  ｓｅｃｏｎｄ  Ｂｅａｍ（ｓ）  ｖｉａ  Ｐｒｉｍａｒｙ  Ｂｅａｍ  ＳＳ
【０１４１】
プライマリビームはＲＡＣＨ手順によって設定されてもよく、セカンダリビームはプライマリビーム内のサーチスペースを用いたＲＲＣ設定によって設定されてもよい。
【０１４２】
端末は、ランダムアクセス手順において送信に成功したＲＡＣＨに対するｃｏｒｒｅｓｐｏｎｄｅｎｃｅ  ＢｅａｍをＢｅｓｔ  Ｂｅａｍとして仮定して、これをプライマリビームとして定義することができる。或いは、ＲＬＦ後のビームリカバリー過程によってベストビームを選択するとき、そのビームをプライマリビームとして定義してもよい。
【０１４３】
或いは、ネットワークは、ＲＡＣＨ手順においてＭＳＧ  ４などを介してベストビーム又はプライマリビームを端末に指示するか、又はビームリカバリー過程において設定してもよい。
【０１４４】
Ｆａｌｌｂａｃｋ  ｏｐｅｒａｔｉｏｎとして、プライマリビームは、ビームリカバリー（Ｂｅａｍ  ｒｅｃｏｖｅｒｙ）、ビームスイッチング（Ｂｅａｍ  Ｓｗｉｔｃｈｉｎｇ）又はビームペアリング（Ｂｅａｍ  ｐａｉｒｉｎｇ）の過程のみによってアップデートできるように定義されてもよい。セカンダリビームは、プライマリビームによってアップデートできる。即ち、プライマリビームの場合、ビームリカバリー、ビームスイッチング又はビームペアリングの過程が起こる前には変更しなくてもよい。或いは、制御チャネルに対するプライマリビーム変更の手順が別として定義されてもよく、該当手順は、ビームスイッチングによって処理可能である。
【０１４５】
３．６．２  Ｂｅａｍ  Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ  ｖｉａ  Ｂｅａｍ−ｓｗｅｅｐｉｎｇ  ＰＤＣＣＨ
【０１４６】
ＲＲＣメッセージなどは常にＢｅａｍ−ｓｗｅｅｐｉｎｇされるＰＤＣＣＨ領域でのみ送信すると定義されてもよい。
【０１４７】
３．７  Ｍｕｌｔｉ−Ｂｅａｍ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｖｉａ  ＭＡＣ  ＣＥ
【０１４８】
ＭＡＣ  ＣＥを介してプライマリビーム又は複数のビームが定義されてもよい。
【０１４９】
３．８  Ｍｕｌｔｉ−Ｂｅａｍ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｖｉａ  ＤＣＩ
【０１５０】
ネットワークはプライマリビームを介してＤＣＩを送信してもよく、又はＤＣＩを送信するビームをプライマリビームを介して定義してもよい。
【０１５１】
３．９  Ｕｎｉｃａｓｔ
【０１５２】
Ｍｕｌｔｉ  Ｂｅａｍを用いてＰＤＣＣＨを送信する方式には様々なオプションが考えられる。
【０１５３】
一例として、ネットワークはＰＤＣＣＨを常に１個のビームでのみ送信してもよい。
【０１５４】
別の例として、少なくともＣＳＳに対しては、各ビームが制御情報を別々に送信してもよく、多数のビームが重複するＰＤＣＣＨ／ＤＣＩを送信してもよい。
【０１５５】
また別の例として、少なくともＣＳＳに対しては、設定されたビームが重複するＰＤＣＣＨ／ＤＣＩを常に送信してもよい。
【０１５６】
４.  ＢＤ  Ｓｐｌｉｔ
【０１５７】
端末が制御情報を検出するために、ブラインドデコーディング（ＢＤ）を行う総回数が定義されてもよく、端末ＢＤの総回数がＭｕｌｔｉ−Ｂｅａｍに分配されてもよい。
【０１５８】
４．１  ＢＤ  Ｓｐｌｉｔ  ｂｅｔｗｅｅｎ  Ｐｒｉｍａｒｙ  ａｎｄ  Ｓｅｃｏｎｄａｒｙ  Ｂｅａｍｓ
【０１５９】
４．１．１  Ｐｒｉｍａｒｙ  ＢｅａｍでのみＢＤ
【０１６０】
一例として、端末は、プライマリビームでのみＢＤを行うことを基本としてもよく、セカンダリビームはプライマリビームの接続を補助する役割のみに用いられてもよい。しかし、ネットワークは特殊な状況では、端末がセカンダリビームでＢＤを行うように設定することができる。
【０１６１】
端末がプライマリビームで行えるＢＤが、行うべき全体のＢＤよりも少なく設定される場合、ネットワークは、選択的に端末がセカンダリビームにおいてＢＤを行うようにすることができる。
【０１６２】
また、プライマリビームとの接続状態が良くない場合、例えば、ＳＩＮＲ／ＣＱＩなどが低くなり、プライマリビームとの接続を持続し難い状況では、セカンダリビームへのスイッチングがトリガーされてもよい。例えば、端末がセカンダリビームを有している場合は、ネットワークは端末がセカンダリビームモニタリングを行うようにシグナリングしてもよい。
【０１６３】
４．１．２  Ｐｒｉｍａｒｙ  ＢｅａｍとＳｅｃｏｎｄａｒｙ  ＢｅａｍにおけるＢＤ
【０１６４】
４．１．２．１  ＡＬ（ａｇｇｒｅｇａｔｉｏｎ  ｌｅｖｅｌ）Ｓｅｔ及び各ＡＬにおけるＢＤ数の分配
【０１６５】
セカンダリビームよりもプライマリビームのためのリソースが多く、またセカンダリビームよりもプライマリビームの受信性能がより良い環境を仮定することができる。また、端末がプライマリビームをセカンダリビームよりも長い時間の間に受信する環境を考慮することができる。
【０１６６】
この場合、端末がプライマリビームにおいて、先に制御情報をデコードする確率が高いため、下位ＡＬへのＢＤをプライマリビームに配置することができる。例えば、プライマリビームには下位ＡＬに対するＢＤが割り当てられ、セカンダリビームには上位ＡＬに対するＢＤが割り当てられる。
【０１６７】
また、ＡＬセットの全体を１個のビームに割り当ててもよいが、各ＡＬのＢＤが複数存在するとき、１個のＡＬに対するＢＤをプライマリビームとセカンダリビームに分けて配置してもよい。例えば、ＡＬ−１に該当する制御チャネル候補に対する端末のＢＤ回数がＮである場合、プライマリビームにはｋ回のＡＬ−１  ＢＤが割り当てられ、セカンダリビームにはＮ−ｋ回のＡＬ−１  ＢＤが割り当てられる。
【０１６８】
４．１．２．２  各Ｂｅａｍへの差別的リソース分配
【０１６９】
ネットワークは、各々のビームにリソースセットを差別的に分配してもよい。一例として、全体の制御シンボルがＭ個であるとき、プライマリビームはＭ個の全部又はＮ（Ｎ＜Ｍ）個のシンボルで受信が可能であり、セカンダリビームはＰ個のシンボルで受信ができるように設定されてもよい（Ｎ＋Ｐ＝Ｍ，Ｎ≧Ｐ）。
【０１７０】
このために、ネットワークは最初からプライマリビームとセカンダリビームとにリソースを異なるように割り当ててもよい。或いは、プライマリビームは常に動作するものの、ネットワークは、端末がセカンダリビームをモニタリングしなくてもよいリソース、又はモニタリングすべきリソースを端末に指示してもよい。プライマリビームとセカンダリビームにおいて使用可能なシンボル数は、明示的（ｅｘｐｌｉｃｉｔ）又は暗示的（ｉｍｐｌｉｃｉｔ）に定義されてもよく、この場合、相対的に、プライマリビームのシンボル数をより多く定義してもよい。
【０１７１】
具体例として、プライマリビームのリソースセットにＫ１個のＢＤが割り当てられ、端末は、各スロット毎にプライマリビームをモニタリングし、セカンダリビームのリソースセットにＫ２個のＢＤが割り当てられ、端末はＮスロット毎にセカンダリビームをモニタリングすると仮定する。この場合、以下のオプション（ｉ）〜（ｖ）が考えられる。
【０１７２】
（ｉ）端末がＮ番目のスロットにおいてプライマリビームとセカンダリビームとをいずれも受信する場合、各Ｎ個のスロット毎に、端末はＫ１＋Ｋ２だけのＢＤを行うことができる。Ｋ１＋Ｋ２は、端末のＢＤキャパシティ（ｃａｐａｃｉｔｙ）より少ないか同一である必要がある。
【０１７３】
（ｉｉ）各Ｎ個のスロット内でプライマリビームを受信するスロットはＮ−１個であり、端末がセカンダリビームを受信するとき、プライマリビームの受信を中断してもよい。端末はプライマリビームに対してＫ１−Ｋ２回の（又は、ＭＡＸ−Ｋ２；ＭＡＸ：最大のＢＤ実行能力）ＢＤを行うことができ、セカンダリビームではＫ２回のＢＤを行うことができる。
【０１７４】
（ｉｉｉ）プライマリビームのリソースセットが２つに分けられてもよい（２つ以上に分ける場合も可能）。端末は、各Ｎ番目のスロットでは、プライマリビームに対してＫ３回のＢＤを行い、残りのＮ−１個のスロットではＫ１−Ｋ３回のＢＤを行うことができる。端末はセカンダリビームに対してはＫ２回のＢＤをそのまま行うことができる。
【０１７５】
（ｉｖ）端末は、各Ｎ番目のスロット毎に、プライマリビームのモニタリングを省略してもよい。
【０１７６】
（ｖ）端末のＢＤ能力をシンボル毎に定義する場合、より柔軟（ｆｌｅｘｉｂｌｅ）なＢＤ分配が可能である。このとき、各々のシンボル又は多数のシンボルに対するＢＤ数は、端末のＢＤ能力を上回ることができない。プライマリビーム／セカンダリビームが受信可能なシンボルは、単一シンボル又は多数のシンボルであってもよい。このとき、各ビームのＢＤも単一シンボル又は多数のシンボルに亘って行われることができる。
【０１７７】
４．２  Ｍｏｎｉｔｏｒｉｎｇ  Ｒｅｓｏｕｒｃｅ  Ｓｅｔ変更
【０１７８】
次に、端末がプライマリビーム／セカンダリビームをモニタリングするリソースセットが変更される場合のブラインドデコーディングについて説明する。
【０１７９】
４．２．１  同一のＢＤ比率を維持する案
【０１８０】
プライマリビームとセカンダリビームのリソースセットが変更されても、プライマリビームとセカンダリビームのリソース比率が、リソースセットの変更前と類似することがある。ビームのリソースセットの比率が類似するという判断の基準が予め定義されてもよい。
【０１８１】
この場合、端末は、各々のビームに対して、リソースセットの変更前と同一比率のＢＤを行うことができる。リソースセットが全般的に減少した場合、各々のビームに対してＢＤの実行回数は減少するものの、ＢＤの実行比率はそのまま維持可能であり、場合によっては、ＢＤが省略されるリソースがあり得る。
【０１８２】
４．２．２  Ｐｒｉｍａｒｙ  Ｂｅａｍのリソースセットが格段に大きくなった場合
【０１８３】
リソースセットの変更に従って、プライマリビームのリソースセットが全てのサーチスペースがカバーできるほどに大きくなった場合、端末はプライマリビームにおいて全てのＢＤを行うことができる。プライマリビームリソースセットが格段に大きいと判断する基準は、端末又はネットワークによって定義されてもよい。一例として、リソースセットの変更前に、最上位ＡＬのスペースサイズ（ｓｐａｃｅ  ｓｉｚｅ）に対するその他のＡＬのスペースサイズの比率が３：４であり、リソースセットの変更後、その比率が３：７であるとき、端末はその他のＡＬに該当するリソースセットが格段に大きいと仮定することができる。
【０１８４】
図６は、本発明の一実施例による下りリンク制御情報の送受信方法のフローを示す図である。上述と重なる内容は省略する。
【０１８５】
図６を参照すると、端末は基地局から少なくとも１個の制御リソースセット（ＣＯＲＥＳＥＴ）に、多数のビーム（ｂｅａｍ）を設定するビーム設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報を受信する（６０５）。
【０１８６】
端末は、多数のビームのうちの少なくとも１個を介して送信される下りリンク制御チャネルを少なくとも１個のＣＯＲＥＳＥＴ上においてブラインド検出する（６１０）。このとき、端末が実行可能なブラインド検出の総回数が、前記多数のビームに分けて割り当てられてもよい。端末は、各々のビームに割り当てられたブラインド検出の回数に応じてブラインド検出を行うことができる。
【０１８７】
端末は、ブラインド検出された下りリンク制御チャネルから下りリンク制御情報を取得する（６１５）。
【０１８８】
一例として、多数のビームは、異なるＣＯＲＥＳＥＴ上にそれぞれ設定されてもよい。異なるＣＯＲＥＳＥＴのそれぞれに個別に共通サーチスペース（ＣＳＳ）と端末固有サーチスペース（ＵＳＳ）のうちの少なくとも１つが設定されてもよい。端末は、該当ＣＯＲＥＳＥＴに設定されたビームを用いて、該当ＣＯＲＥＳＥＴに設定されたＣＳＳ及びＵＳＳのうちの少なくとも１つをモニタリングすることができる。
【０１８９】
多数のビームは、プライマリ（ｐｒｉｍａｒｙ）ビーム及びセカンダリ（ｓｅｃｏｎｄａｒｙ）ビームを含むことができる。
【０１９０】
端末は、プライマリビーム上では、第１のアグリゲーションレベル（ａｇｇｒｅｇａｔｉｏｎ  ｌｅｖｅｌ）に該当する制御チャネル候補の検出を試み、セカンダリビーム上では、第２のアグリゲーションレベルに該当する制御チャネル候補の検出を試みることができる。
【０１９１】
プライマリビームに割り当てられた前記第１のアグリゲーションレベルは、セカンダリビームに割り当てられた前記第２のアグリゲーションレベルよりも低く設定されることができる。
【０１９２】
セカンダリビームは、プライマリビームを介して受信されるＭＡＣメッセージ又は下りリンク制御情報を介して活性化／非活性化されることができる。
【０１９３】
図７は、本発明の一実施例による無線通信システム１００における基地局１０５及び端末１１０の構成を示すブロック図である。
【０１９４】
無線通信システム１００を簡略に示すために、１つの基地局１０５と１つの端末１１０を示したが、無線通信システム１００は１つ以上の基地局及び／又は１つ以上の端末を含むことができる。
【０１９５】
基地局１０５は、送信（Ｔｘ）データプロセッサ１１５、シンボル変調器１２０、送信器１２５、送受信アンテナ１３０、プロセッサ１８０、メモリ１８５、受信器１９０、シンボル復調器１９５及び受信データプロセッサ１９７を含むことができる。そして、端末１１０は、送信（Ｔｘ）データプロセッサ１６５、シンボル変調器１７０、送信器１７５、送受信アンテナ１３５、プロセッサ１５５、メモリ１６０、受信器１４０、シンボル復調器１５５及び受信データプロセッサ１５０を含むことができる。送受信アンテナ１３０、１３５はそれぞれ基地局１０５及び端末１１０に１つとして示されているが、基地局１０５及び端末１１０は複数の送受信アンテナを備えている。よって、本発明による基地局１０５及び端末１１０はＭＩＭＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）システムを支援する。また、本発明による基地局１０５はＳＵ−ＭＩＭＯ（Ｓｉｎｇｌｅ  Ｕｓｅｒ−ＭＩＭＯ）ＭＵ−ＭＩＭＯ（Ｍｕｌｔｉ  Ｕｓｅｒ−ＭＩＭＯ）方式をいずれも支援することができる。
【０１９６】
下りリンク上で、送信データプロセッサ１１５はトラフィックデータを受信し、受信したトラフィックデータをフォーマットして符号化し、符号化されたトラフィックデータをインターリーブして変調し（又はシンボルマッピングし）、変調シンボル（「データシンボル」）を提供する。シンボル変調器１２０はこのデータシンボルとパイロットシンボルを受信及び処理してシンボルのストリームを提供する。
【０１９７】
シンボル変調器１２０は、データ及びパイロットシンボルを多重化し、これを送信器１２５に送信する。ここで、それぞれの送信シンボルはデータシンボル、パイロットシンボル又はゼロの信号値であり得る。それぞれのシンボル周期で、パイロットシンボルが連続的に送信されることもできる。パイロットシンボルは周波数分割多重化（ＦＤＭ）、直交周波数分割多重化（ＯＦＤＭ）、時分割多重化（ＴＤＭ）又は符号分割多重化（ＣＤＭ）シンボルであり得る。
【０１９８】
送信器１２５はシンボルのストリームを受信し、これを１つ以上のアナログ信号に変換し、さらにこのアナログ信号を追加的に調節して（例えば、増幅、フィルタリング及び周波数アップコンバート（ｕｐｃｏｎｖｅｒｔｉｎｇ）して、無線チャネルを介した送信に適した下りリンク信号を発生させる。すると、送信アンテナ１３０は発生した下りリンク信号を端末に送信する。
【０１９９】
端末１１０の構成において、受信アンテナ１３５は基地局からの下りリンク信号を受信し、受信された信号を受信器１４０に提供する。受信器１４０は受信された信号を調整し（例えば、フィルタリング、増幅、及び周波数ダウンコンバート（ｄｏｗｎｃｏｎｖｅｒｔｉｎｇ））、調整された信号をデジタル化してサンプルを獲得する。シンボル復調器１４５は受信されたパイロットシンボルを復調し、チャネル推定のためにこれをプロセッサ１５５に提供する。
【０２００】
また、シンボル復調器１４５はプロセッサ１５５から下りリンクに対する周波数応答推定値を受信し、受信されたデータシンボルに対してデータ復調を行って（送信されたデータシンボルの推定値である）データシンボル推定値を獲得し、データシンボル推定値を受信（Ｒｘ）データプロセッサ１５０に提供する。受信データプロセッサ１５０はデータシンボル推定値を復調（すなわち、シンボルデマッピング（ｄｅｍａｐｐｉｎｇ））し、デインターリーブ（ｄｅｉｎｔｅｒｌｅａｖｉｎｇ）し、復号して、送信されたトラフィックデータをリカバリーする。
【０２０１】
シンボル復調器１４５及び受信データプロセッサ１５０による処理はそれぞれ基地局１０５でのシンボル変調器１２０及び送信データプロセッサ１１５による処理に対して相補的である。
【０２０２】
端末１１０は上りリンク上で、送信データプロセッサ１６５はトラフィックデータを処理してデータシンボルを提供する。シンボル変調器１７０はデータシンボルを受信して多重化し、変調を行い、シンボルのストリームを送信器１７５に提供することができる。送信器１７５はシンボルのストリームを受信及び処理して上りリンク信号を発生させる。そして、送信アンテナ１３５は発生した上りリンク信号を基地局１０５に送信する。端末及び基地局における送信器及び受信器は、１つのＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）ユニットからなってもよい。
【０２０３】
基地局１０５において、端末１１０から上りリンク信号が受信アンテナ１３０を介して受信され、受信器１９０は受信した上りリンク信号を処理してサンプルを取得する。ついで、シンボル復調器１９５はこのサンプルを処理し、上りリンクに対して受信されたパイロットシンボル及びデータシンボル推定値を提供する。受信データプロセッサ１９７はデータシンボル推定値を処理し、端末１１０から送信されたトラフィックデータをリカバリーする。
【０２０４】
端末１１０及び基地局１０５のそれぞれのプロセッサ１５５，１８０はそれぞれ端末１１０及び基地局１０５での動作を指示（例えば、制御、調整、管理など）する。それぞれのプロセッサ１５５，１８０はプログラムコード及びデータを記憶するメモリユニット１６０，１８５と接続されることができる。メモリ１６０，１８５はプロセッサ１８０に接続され、オペレーティングシステム、アプリケーション、及び一般ファイル（ｇｅｎｅｒａｌ  ｆｉｌｅｓ）を記憶する。
【０２０５】
プロセッサ１５５，１８０はコントローラー（ｃｏｎｔｒｏｌｌｅｒ）、マイクロコントローラー（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコンピューター（ｍｉｃｒｏｃｏｍｐｕｔｅｒ）などとも呼ばれる。一方、プロセッサ１５５，１８０はハードウェア（ｈａｒｄｗａｒｅ）又はファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア、又はこれらの組み合わせによって実現されることができる。ハードウェアを用いて本発明の実施例を実現する場合には、本発明を実行するように構成されたＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ  ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔｓ）又はＤＳＰｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ  ｌｏｇｉｃ  ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ  ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙｓ）などがプロセッサ１５５，１８０に備えられてもよい。
【０２０６】
一方、ファームウェア又はソフトウェアを用いて本発明の実施例を具現化する場合には、本発明の機能又は動作を行うモジュール、過程又は関数などを含むようにファームウェア又はソフトウェアが構成されることができ、本発明を実行するように構成されたファームウェア又はソフトウェアはプロセッサ１５５，１８０内に備えられるか、メモリ１６０，１８５に記憶されてプロセッサ１５５，１８０によって駆動されることができる。
【０２０７】
端末と基地局の無線通信システム（ネットワーク）間の無線インターフェースプロトコルのレイヤーは通信システムでよく知られたＯＳＩ（ｏｐｅｎ  ｓｙｓｔｅｍ  ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）モデルの下位３レイヤーに基づいて、第１のレイヤーＬ１、第２のレイヤーＬ２及び第３のレイヤーＬ３に分類されることができる。物理レイヤーは前記第１のレイヤーに属し、物理チャネルを介して情報送信サービスを提供する。ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤーは前記第３のレイヤーに属し、ＵＥとネットワーク間の制御無線リソースを提供する。端末、基地局は無線通信ネットワークとＲＲＣレイヤーを介してＲＲＣメッセージを交換することができる。
【０２０８】
以上説明してきた実施例は、本発明の構成要素及び特徴を所定の形態に結合したものである。各構成要素又は特徴は、別の明示的な言及がない限り、選択的なものとして考慮しなければならない。各構成要素又は特徴は、他の構成要素や特徴と結合しない形態で実施することもでき、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成することもできる。本発明の実施例で説明される動作の順序は変更されてもよい。ある実施例の一部の構成や特徴は、他の実施例に含まれてもよく、他の実施例の対応する構成又は特徴に取り換えられてもよい。特許請求の範囲において明示的な引用関係にない請求項を結合して実施例を構成したり、出願後の補正により新しい請求項として含めたりできるということは明らかである。
【０２０９】
本発明は、本発明の精神及び必須の特徴から逸脱しない範囲で、他の特定の形態に具体化することができることは通常の技術者にとって自明であろう。よって、上記の詳細な説明はいずれの面においても制限的に解釈してはならず、例示的なものとして考慮しなければならない。本発明の範囲は、添付の請求項の合理的解釈によって定められなければならず、本発明の等価的範囲内における変更はいずれも本発明の範囲に含まれる。
【産業上の利用可能性】
【０２１０】
上述のように、本発明は様々な無線通信システムに適用することができる。
【図１】
0006946451.tif 000002
【図２】
0006946451.tif 000003
【図３】
0006946451.tif 000004
【図４】
0006946451.tif 000005
【図５】
0006946451.tif 000006
【図６】
0006946451.tif 000007
【図７】
0006946451.tif 000008