(57)【要約】本明細書は、フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を送信する方法を提供する。具体的に、端末により行われる上記方法は、アップリンク−ダウンリンク構成（uplink-downlink configuration）に関する制御情報を基地局から受信するステップと、前記受信した制御情報と関連したＮＰＲＡＣＨプリアンブル送信に関するパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信するステップとを含むことを特徴とする。【選択図】図５２
2020526148.tif 000002
【特許請求の範囲】
【請求項１】
フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を送信する方法であって、端末により行われる方法は、
アップリンク−ダウンリンク構成（uplink-downlink configuration）に関する制御情報を基地局から受信するステップと、
前記受信した制御情報と関連したＮＰＲＡＣＨプリアンブル送信に関するパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信するステップとを含み、
前記ＮＰＲＡＣＨプリアンブルは、１つ又はそれ以上のシンボルグループ（symbol group）を含み、
１つのシンボルグループは、１つのＣＰ（Cyclic Prefix）と少なくとも１つのシンボルを含み、
前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのシンボルグループに含まれるシンボルの数を示す第１パラメータ及び１つのシンボルグループに含まれるＣＰ（cyclic prefix）の長さを示す第２パラメータを含み、
前記第１パラメータ及び前記第２パラメータは、前記第１パラメータ及び前記第２パラメータにそれぞれ対応する第３パラメータ及び第４パラメータと異なるように設定され、
前記第３パラメータ及び前記第４パラメータは、フレーム構造タイプ（frame structure type）１においてサポートされるＮＰＲＡＣＨプリアンブル送信に関するパラメータであることを特徴とする方法。
【請求項２】
前記基地局においてサポートされるアップリンク−ダウンリンク構成情報に応じて前記ＮＰＲＡＣＨプリアンブルに関するパラメータは異なるように設定されることを特徴とする請求項１に記載の方法。
【請求項３】
前記第１パラメータ及び前記第２パラメータは、それぞれ前記第３パラメータ及び前記第４パラメータより小さい値を有することを特徴とする請求項１に記載の方法。
【請求項４】
前記第１パラメータの値は、５より小さい自然数であることを特徴とする請求項３に記載の方法。
【請求項５】
前記シンボルグループは、第１周波数ホッピング（frequency hopping）及び第２周波数ホッピングにより送信されることを特徴とする請求項１に記載の方法。
【請求項６】
前記第２周波数ホッピングの値は前記第１周波数ホッピングの値の６倍であることを特徴とする請求項５に記載の方法。
【請求項７】
前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのプリアンブル（preamble）に含まれる連続するシンボルグループ（symbol group）の数を示す第５パラメータ及び１つのプリアンブル（preamble）に含まれるシンボルグループ（symbol group）の全体数を示す第６パラメータをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記第５パラメータの値は２であり、前記第６パラメータの値は４であることを特徴とする請求項７に記載の方法。
【請求項９】
フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を送信する端末であって、
無線信号を送受信するためのＲＦ（Radio Frequency）モジュールと、
前記ＲＦモジュールを制御するプロセッサとを含み、前記プロセッサは、
アップリンク−ダウンリンク構成（uplink-downlink configuration）に関する制御情報を基地局から受信し、
前記受信した制御情報と関連したＮＰＲＡＣＨプリアンブル送信に関するパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信するように設定され、
前記ＮＰＲＡＣＨプリアンブルは、１つ又はそれ以上のシンボルグループ（symbol group）を含み、
１つのシンボルグループは、１つのＣＰ（Cyclic Prefix）と少なくとも１つのシンボルを含み、
前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのシンボルグループに含まれるシンボルの数を示す第１パラメータ及び１つのシンボルグループに含まれるＣＰ（cyclic prefix）の長さを示す第２パラメータを含み、
前記第１パラメータ及び前記第２パラメータは、前記第１パラメータ及び前記第２パラメータにそれぞれ対応する第３パラメータ及び第４パラメータと異なるように設定され、
前記第３パラメータ及び前記第４パラメータは、フレーム構造タイプ（frame structure type）１においてサポートされるＮＰＲＡＣＨプリアンブル送信に関するパラメータであることを特徴とする端末。
【請求項１０】
前記基地局においてサポートされるアップリンク−ダウンリンク構成情報に応じて前記ＮＰＲＡＣＨプリアンブルに関するパラメータは異なるように設定されることを特徴とする請求項９に記載の端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、狭帯域ＩｏＴシステムに関し、より詳細には、フレーム構造タイプ２（frame structure type 2）をサポートする狭帯域ＩｏＴシステムにおいてＮＰＲＡＣＨプリアンブル（preamble）を送信する方法及びそのための装置に関する。
【背景技術】
【０００２】
移動通信システムは、ユーザの活動性を保障しながら音声サービスを提供するために開発された。しかしながら、移動通信システムは、音声だけでなくデータサービスまで領域を拡張し、現在では、爆発的なトラフィックの増加によって資源の不足現象が引き起こされ、ユーザがより高速のサービスを要求するので、より発展した移動通信システムが要求されている。
【０００３】
次世代移動通信システムの要求条件は、大きく爆発的なデータトラフィックの収容、ユーザ当たりの送信率の画期的な増加、大幅増加した接続デバイス数の収容、非常に低いエンドツーエンド遅延（Ｅｎｄ-ｔｏ-Ｅｎｄ  Ｌａｔｅｎｃｙ）、高エネルギー効率を支援できなければならない。このために、多重続性（Ｄｕａｌ  Ｃｏｎｎｅｃｔｉｖｉｔｙ）、大規模多重入出力（Ｍａｓｓｉｖｅ  ＭＩＭＯ：Ｍａｓｓｉｖｅ  Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）、全二重（Ｉｎ-ｂａｎｄ  Ｆｕｌｌ  Ｄｕｐｌｅｘ）、非直交多重接続（ＮＯＭＡ：Ｎｏｎ-Ｏｒｔｈｏｇｏｎａｌ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）、超広帯域（Ｓｕｐｅｒ  ｗｉｄｅｂａｎｄ）支援、端末ネットワーキング（Ｄｅｖｉｃｅ  Ｎｅｔｗｏｒｋｉｎｇ）等、多様な技術が研究されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本明細書は、ＮＢ−ＩｏＴシステムにおいてＴＤＤをサポートする場合、レガシー（legacy）ＬＴＥのＵＬ／ＤＬ構成（UL/DL configuration）を用いてＮＰＲＡＣＨプリアンブルを送信するためのＮＰＲＡＣＨプリアンブル設定方法を提供することに目的がある。
【０００５】
本発明で達成しようとする技術的課題は以上で言及した技術的課題に制限されず、言及しない更に他の技術的課題は以下の記載から本発明が属する技術分野で通常の知識を有する者に明確に理解できるはずである。
【課題を解決するための手段】
【０００６】
本明細書は、フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を送信する方法であって、端末により行われる方法は、アップリンク−ダウンリンク構成（uplink-downlink configuration）に関する制御情報を基地局から受信するステップと、前記受信した制御情報と関連したＮＰＲＡＣＨプリアンブル送信に関するパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信するステップとを含み、前記ＮＰＲＡＣＨプリアンブルは、１つ又はそれ以上のシンボルグループ（symbol group）を含み、１つのシンボルグループは、１つのＣＰ（Cyclic Prefix）と少なくとも１つのシンボルを含み、前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのシンボルグループに含まれるシンボルの数を示す第１パラメータ及び１つのシンボルグループに含まれるＣＰ（cyclic prefix）の長さを示す第２パラメータを含み、前記第１パラメータ及び前記第２パラメータは、前記第１パラメータ及び前記第２パラメータにそれぞれ対応する第３パラメータ及び第４パラメータと異なるように設定され、及び前記第３パラメータ及び前記第４パラメータは、フレーム構造タイプ（frame structure type）１においてサポートされるＮＰＲＡＣＨプリアンブル送信に関するパラメータであることを特徴とする。
【０００７】
また、本明細書において、前記基地局においてサポートされるアップリンク−ダウンリンク構成情報に応じて前記ＮＰＲＡＣＨプリアンブルに関するパラメータは異なるように設定されることを特徴とする。
【０００８】
さらに、本明細書において、前記第１パラメータ及び前記第２パラメータは、それぞれ前記第３パラメータ及び前記第４パラメータより小さい値を有することを特徴とする。
【０００９】
さらに、本明細書において、前記第１パラメータの値は５より小さい自然数であることを特徴とする。
【００１０】
さらに、本明細書において、前記シンボルグループは第１周波数ホッピング（frequency hopping）及び第２周波数ホッピングにより送信されることを特徴とする。
【００１１】
さらに、本明細書において、前記第２周波数ホッピングの値は前記第１周波数ホッピングの値の６倍であることを特徴とする。
【００１２】
さらに、本明細書において、前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのプリアンブル（preamble）に含まれる連続するシンボルグループ（symbol group）の数を示す第５パラメータ及び１つのプリアンブル（preamble）に含まれるシンボルグループ（symbol group）の全体数を示す第６パラメータをさらに含むことを特徴とする。
【００１３】
さらに、本明細書において、前記第５パラメータの値は２であり、前記第６パラメータの値は４であることを特徴とする。
【００１４】
さらに、本明細書は、フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を送信する端末であって、無線信号を送受信するためのＲＦ（Radio Frequency）モジュールと、前記ＲＦモジュールを制御するプロセッサとを含み、前記プロセッサは、アップリンク−ダウンリンク構成（uplink-downlink configuration）に関する制御情報を基地局から受信し、及び前記受信した制御情報と関連したＮＰＲＡＣＨプリアンブル送信に関するパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信するように設定され、前記ＮＰＲＡＣＨプリアンブルは、１つ又はそれ以上のシンボルグループ（symbol group）を含み、１つのシンボルグループは、１つのＣＰ（Cyclic Prefix）と少なくとも１つのシンボルを含み、前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのシンボルグループに含まれるシンボルの数を示す第１パラメータ及び１つのシンボルグループに含まれるＣＰ（cyclic prefix）の長さを示す第２パラメータを含み、前記第１パラメータ及び前記第２パラメータは、前記第１パラメータ及び前記第２パラメータにそれぞれ対応する第３パラメータ及び第４パラメータと異なるように設定され、及び前記第３パラメータ及び前記第４パラメータは、フレーム構造タイプ（frame structure type）１においてサポートされるＮＰＲＡＣＨプリアンブル送信に関するパラメータであることを特徴とする。
【発明の効果】
【００１５】
本明細書は、ＮＢ−ＩｏＴシステムにおいてＴＤＤをサポートする場合、新しいＮＰＲＡＣＨプリアンブルフォーマットを定義することにより、レガシー（legacy）ＬＴＥのＵＬ／ＤＬ構成（UL/DL configuration）を利用できるという効果がある。
【００１６】
本発明で得ることができる効果は、以上で言及した効果に制限されず、言及しない更に他の効果は以下の記載から本発明が属する技術分野で通常の知識を有する者に明確に理解できるはずである。
【図面の簡単な説明】
【００１７】
本発明に関する理解を助けるために詳細な説明の一部に含まれる、添付図は、本発明に対する実施例を提供し、詳細な説明と共に本発明の技術的特徴を説明する。
【００１８】
【図１】本発明が適用できる無線通信システムにおいて無線フレームの構造を示す図である。
【図２】本発明が適用できる無線通信システムにおいて１つのダウンリンクスロットに対するリソースグリッド（resource grid）を例示した図である。
【図３】本発明が適用できる線通信システムにおいてダウンリンクサブフレームの構造を示す図である。
【図４】本発明が適用できる線通信システムにおいてアップリンクサブフレームの構造を示す図である。
【図５】本発明が適用できる無線通信システムにおいてコンポーネントキャリア及びキャリア併合の一例を示す図である。
【図６】キャリア併合をサポートするシステムのセルの区分を例示した図である。
【図７】ＮＰＲＡＣＨプリアンブルのシンボルグループの一例を示す図である。
【図８】ＮＢ−ＩｏＴシステムにおけるＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【図９】ＮＰＲＡＣＨプリアンブルの繰り返しとランダムホッピング方法の一例を示す図である。
【図１０】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【図１１】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンの一例を示す図である。
【図１２】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【図１３】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図１４】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットの他の一例を示す図である。
【図１５】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図１６】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【図１７】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図１８】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図１９】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【図２０】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図２１】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【図２２】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図２３】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【図２４】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図２５】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【図２６】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図２７】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【図２８】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図２９】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図３０】本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【図３１】本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信の一例を示す図である。
【図３２】本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図３３】本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図３４】本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【図３５】本明細書で提案するショート（short）ＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【図３６】本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図３７】本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図３８】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図３９】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４０】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４１】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４２】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４３】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４４】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４５】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４６】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４７】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４８】本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【図４９】図４８によるシンボルグループ形態の一例を示す図である。
【図５０】本明細書で提案するＮＰＲＡＣＨプリアンブルのシンボルグループ間に送信する順序を交換する方法の一例を示す図である。
【図５１】ＮＰＲＡＣＨプリアンブルのマルチトーン送信に対する位相事前補償方法の一例を示す図である。
【図５２】本明細書で提案するＮＰＲＡＣＨプリアンブルを送信するための端末の動作を示すフローチャートである。
【図５３】本明細書で提案する方法が適用できる無線通信装置のブロック構成図を例示する図である。
【図５４】本発明の一実施形態による通信装置のブロック構成図を例示する図である。
【図５５】本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールの一例を示す図である。
【図５６】本明細書で提案する方法が適用できる無線通信装置のＲＦモジュールのまた他の一例を示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明にかかる好ましい実施の形態を添付された図面を参照して詳細に説明する。添付された図面と共に以下に開示する詳細な説明は、本発明の例示的な実施の形態を説明するためのものであり、本発明が実施されうる唯一の実施の形態を示すためのものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的細部事項を含む。しかしながら、当業者は、本発明がこのような具体的細部事項がなくても実施できることを理解すべきである。
【００２０】
いくつかの場合、本発明の概念が曖昧になることを避けるために、公知の構造及び装置は省略されるか、または各構造及び装置の核心機能を重心にしたブロック図形式で示されることができる。
【００２１】
本明細書において基地局は、端末と直接的に通信を行うネットワークの終端ノード（ｔｅｒｍｉｎａｌ  ｎｏｄｅ）としての意味を有する。本文書において基地局により行われると説明された特定動作は、場合によっては、基地局の上位ノード（ｕｐｐｅｒ  ｎｏｄｅ）により行われても良い。
【００２２】
すなわち、基地局を含む多数のネットワークノード（ｎｅｔｗｏｒｋ  ｎｏｄｅｓ）からなるネットワークにおいて端末との通信のために行われる多様な動作は、基地局または基地局以外の他のネットワークノードにより行われうることは明らかである。「基地局（ＢＳ：Ｂａｓｅ  Ｓｔａｔｉｏｎ）」は、固定局（ｆｉｘｅｄ  ｓｔａｔｉｏｎ）、Ｎｏｄｅ  Ｂ、ｅＮＢ（ｅｖｏｌｖｅｄ-ＮｏｄｅＢ）、ＢＴＳ（ｂａｓｅ  ｔｒａｎｓｃｅｉｖｅｒ  ｓｙｓｔｅｍ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ  Ｐｏｉｎｔ）などの用語により代替されることができる。また、「端末（Ｔｅｒｍｉｎａｌ）」は、固定されるか、または移動性を有することができ、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）、ＵＴ（ｕｓｅｒ  ｔｅｒｍｉｎａｌ）、ＭＳＳ（Ｍｏｂｉｌｅ  ｓｕｂｓｃｒｉｂｅｒ  Ｓｔａｔｉｏｎ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ  Ｓｔａｔｉｏｎ）、ＡＭＳ（Ａｄｖａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ）、ＷＴ（Ｗｉｒｅｌｅｓｓ  ｔｅｒｍｉｎａｌ）、ＭＴＣ（Ｍａｃｈｉｎｅ-Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）装置、Ｍ２Ｍ（Ｍａｃｈｉｎｅ-ｔｏ-Ｍａｃｈｉｎｅ）装置、Ｄ２Ｄ（Ｄｅｖｉｃｅ-ｔｏ-Ｄｅｖｉｃｅ）装置などの用語に代替されることができる。
【００２３】
以下、ダウンリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）は、基地局から端末への通信を意味し、アップリンク（ＵＬ：ｕｐｌｉｎｋ）は、端末から基地局への通信を意味する。ダウンリンクにおける送信機は、基地局の一部で、受信機は、端末の一部でありうる。アップリンクにおける送信機は、端末の一部で、受信機は、基地局の一部でありうる。
【００２４】
以下の説明において用いられる特定用語は、本発明の理解に役立つために提供されたものであり、このような特定用語の使用は、本発明の技術的思想から外れない範囲内で他の形態に変更されることができる。
【００２５】
以下の技術は、ＣＤＭＡ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＳＣ-ＦＤＭＡ（ｓｉｎｇｌｅ  ｃａｒｒｉｅｒ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＮＯＭＡ（ｎｏｎ-ｏｒｔｈｏｇｏｎａｌ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）などのような多様な無線接続システムに利用されることができる。ＣＤＭＡは、ＵＴＲＡ（ｕｎｉｖｅｒｓａｌ  ｔｅｒｒｅｓｔｒｉａｌ  ｒａｄｉｏ  ａｃｃｅｓｓ）またはＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ  ｔｅｃｈｎｏｌｏｇｙ）により具現化されることができる。ＴＤＭＡは、ＧＳＭ（ｇｌｏｂａｌ  ｓｙｓｔｅｍ  ｆｏｒ  ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（ｇｅｎｅｒａｌ  ｐａｃｋｅｔ  ｒａｄｉｏ  ｓｅｒｖｉｃｅ）／ＥＤＧＥ（ｅｎｈａｎｃｅｄ  ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  ｅｖｏｌｕｔｉｏｎ）のような無線技術により具現化されることができる。ＯＦＤＭＡは、ＩＥＥＥ  ８０２．１１（Ｗｉ-Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２-２０、Ｅ-ＵＴＲＡ（ｅｖｏｌｖｅｄ  ＵＴＲＡ）などのような無線技術により具現化されることができる。ＵＴＲＡは、ＵＭＴＳ（ｕｎｉｖｅｒｓａｌ  ｍｏｂｉｌｅ  ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ  ｇｅｎｅｒａｔｉｏｎ  ｐａｒｔｎｅｒｓｈｉｐ  ｐｒｏｊｅｃｔ）ＬＴＥ（ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）は、Ｅ-ＵＴＲＡを使用するＥ-ＵＭＴＳ（ｅｖｏｌｖｅｄ  ＵＭＴＳ）の一部であり、ダウンリンクにおいてＯＦＤＭＡを採用し、アップリンクにおいてＳＣ-ＦＤＭＡを採用する。ＬＴＥ-Ａ（ａｄｖａｎｃｅｄ）は、３ＧＰＰ  ＬＴＥの進化である。
【００２６】
本発明の実施の形態は、無線接続システムであるＩＥＥＥ  ８０２、３ＧＰＰ及び３ＧＰＰ２のうち、少なくとも一つに開示された標準文書により裏付けられることができる。すなわち、本発明の実施の形態のうち、本発明の技術的思想を明確にあらわすために、説明しないステップまたは部分は、前記文書により裏付けられることができる。また、本文書に開示しているすべての用語は、前記標準文書により説明されることができる。
【００２７】
説明を明確にするために、３ＧＰＰ  ＬＴＥ／ＬＴＥ-Ａを中心に述べるが、本発明の技術的特徴がこれに制限されることではない。
【００２８】
システム一般
【００２９】
図１は、本発明が適用されることができる無線通信システムにおける無線フレームの構造を示す。
【００３０】
３ＧＰＰ  ＬＴＥ／ＬＴＥ-Ａでは、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）に適用可能なタイプ１無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）構造とＴＤＤ（Ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）に適用可能なタイプ２の無線フレーム構造を支援する。
【００３１】
図１（ａ）は、タイプ１無線フレームの構造を例示する。無線フレーム（ｒａｄｉｏ  ｆｒａｍｅ）は、１０個のサブフレーム（ｓｕｂｆｒａｍｅ）から構成される。一つのサブフレームは、時間領域（ｔｉｍｅ  ｄｏｍａｉｎ）において２個のスロット（ｓｌｏｔ）から構成される。一つのサブフレームを送信するのにかかる時間をＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｔｉｍｅ  ｉｎｔｅｒｖａｌ）という。例えば、一つのサブフレームの長さは１ｍｓで、一つのスロットの長さは、０．５ｍｓでありうる。
一つのスロットは、時間領域において複数のＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）シンボルを含み、周波数領域において多数の資源ブロック（ＲＢ：Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）を含む。３ＧＰＰ  ＬＴＥは、ダウンリンクにおいてＯＦＤＭＡを使用するから、ＯＦＤＭシンボルは、一つのシンボル区間（ｓｙｍｂｏｌ  ｐｅｒｉｏｄ）を表現するためのものである。ＯＦＤＭシンボルは、一つのＳＣ-ＦＤＭＡシンボルまたはシンボル区間ということができる。資源ブロック（ｒｅｓｏｕｒｃｅ  ｂｌｏｃｋ）は、資源割り当て単位で、一つのスロットにおいて複数の連続的な副搬送波（ｓｕｂｃａｒｒｉｅｒ）を含む。
【００３２】
図１の（ｂ）は、タイプ２フレーム構造（ｆｒａｍｅ  ｓｔｒｕｃｔｕｒｅ  ｔｙｐｅ  ２）を示す。タイプ２無線フレームは、２個のハーフフレーム（ｈａｌｆ  ｆｒａｍｅ）から構成され、各ハーフフレームは、５個のサブフレームとＤｗＰＴＳ（Ｄｏｗｎｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）、保護区間（ＧＰ：Ｇｕａｒｄ  Ｐｅｒｉｏｄ）、ＵｐＰＴＳ（Ｕｐｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）から構成され、この中で１個のサブフレームは、２個のスロットから構成される。ＤｗＰＴＳは、端末での初期セルサーチ、同期化またはチャネル推定に使用される。ＵｐＰＴＳは、基地局でのチャネル推定と端末のアップリンク送信同期とを合せるのに使用される。保護区間は、アップリンクとダウンリンクとの間にダウンリンク信号の多重経路遅延によりアップリンクにおいて生じる干渉を除去するための区間である。
【００３３】
ＴＤＤシステムのタイプ２フレーム構造においてアップリンク-ダウンリンク構成（ｕｐｌｉｎｋ-ｄｏｗｎｌｉｎｋ  ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、すべてのサブフレームに対してアップリンクとダウンリンクが割り当て（または予約）されるかどうかを表す規則である。表１は、アップリンク-ダウンリンク構成を示す。
【００３４】
【表１】
2020526148.tif 000003
【００３５】
表１に示すように、無線フレームの各サブフレーム別に、「Ｄ」は、下向きリンク送信のためのサブフレームを表し、「Ｕ」は、上向きリンク送信のためのサブフレームを表し、「Ｓ」は、ＤｗＰＴＳ（Ｄｏｗｎｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）、保護区間（ＧＰ：Ｇｕａｒｄ  Ｐｅｒｉｏｄ）、ＵｐＰＴＳ（Ｕｐｌｉｎｋ  Ｐｉｌｏｔ  Ｔｉｍｅ  Ｓｌｏｔ）の３つのフィールドで構成されるスペシャルサブフレーム（ｓｐｅｃｉａｌ  ｓｕｂｆｒａｍｅ）を表す。
【００３６】
ＤｗＰＴＳは、端末での初期セル探索、同期化、またはチャネル推定に使用される。ＵｐＰＴＳは、基地局でのチャネル推定と端末の上向きリンク送信同期とを合わせるのに使用される。ＧＰは、上向きリンクと下向きリンクとの間に下向きリンク信号の多重経路遅延のため、上向きリンクで生じる干渉を除去するための区間である。
【００３７】
各サブフレームｉは、各Ｔ＿ｓｌｏｔ＝１５３６０＊Ｔ＿ｓ＝０．５ｍｓ長さのスロット２ｉ及びスロット２ｉ＋１で構成される。
【００３８】
上向きリンク−下向きリンク構成は、７つに区分されることができ、各構成別に下向きリンクサブフレーム、スペシャルサブフレーム、上向きリンクサブフレームの位置及び／又は個数が異なる。
【００３９】
下向きリンクから上向きリンクに変更される時点または上向きリンクから下向きリンクに切り換えられる時点を切換時点（ｓｗｉｔｃｈｉｎｇ  ｐｏｉｎｔ）という。切換時点の周期性（Ｓｗｉｔｃｈ−ｐｏｉｎｔ  ｐｅｒｉｏｄｉｃｉｔｙ）は、上向きリンクサブフレームと下向きリンクサブフレームとが切り換えられる様子が同様に繰り返される周期を意味し、５ｍｓまたは１０ｍｓが全て支援される。５ｍｓ下向きリンク−上向きリンク切換時点の周期を有する場合には、スペシャルサブフレーム（Ｓ）は、ハーフ−フレーム毎に存在し、５ｍｓ下向きリンク−上向きリンク切換時点の周期を有する場合には、１番目のハーフ−フレームのみに存在する。
【００４０】
全ての構成において、０番、５番サブフレーム、及びＤｗＰＴＳは、下向きリンク送信のみのための区間である。ＵｐＰＴＳ及びサブフレームにまっすぐ繋がるサブフレームは、常に上向きリンク送信のための区間である。
【００４１】
このような、上向きリンク−下向きリンク構成はシステム情報であって、基地局と端末とが共に知っていることができる。基地局は、上向きリンク−下向きリンク構成情報が変わる度に構成情報のインデックスのみを送信することにより、無線フレームの上向きリンク−下向きリンク割当状態の変更を端末に知らせることができる。また、構成情報は、一種の下向きリンク制御情報であって、他のスケジューリング情報と同様に、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）を介して送信されることができ、放送情報としてブロードキャストチャネル（ｂｒｏａｄｃａｓｔ  ｃｈａｎｎｅｌ）を介してセル内の全ての端末に共通に送信されることもできる。
【００４２】
表２は、スペシャルサブフレームの構成（ＤｗＰＴＳ／ＧＰ／ＵｐＰＴＳの長さ）を表す。
【００４３】
【表２】
2020526148.tif 000004
【００４４】
図１の例示による無線フレームの構造は、１つの例示に過ぎず、無線フレームに含まれる副搬送波の数、またはサブフレームに含まれるスロットの数、スロットに含まれるＯＦＤＭシンボルの数は、様々に変更されることができる。
【００４５】
図２は、本発明が適用されることができる無線通信システムにおける一つのダウンリンクスロットに対する資源グリッド（ｒｅｓｏｕｒｃｅ  ｇｒｉｄ）を示した図である。
【００４６】
図２に示すように、一つのダウンリンクスロットは、時間領域において複数のＯＦＤＭシンボルを含む。ここで、一つのダウンリンクスロットは、７個のＯＦＤＭシンボルを含み、一つの資源ブロックは、周波数領域において１２個の副搬送波を含むことを例示的に述べるが、これに限定されるものではない。
【００４７】
資源グリッド上において各要素（ｅｌｅｍｅｎｔ）を資源要素（ｒｅｓｏｕｒｃｅ  ｅｌｅｍｅｎｔ）とし、一つの資源ブロック（ＲＢ：ｒｅｓｏｕｒｃｅ  ｂｌｏｃｋ）は、１２×７個の資源要素を含む。ダウンリンクスロットに含まれる資源ブロックの数ＮＤＬは、ダウンリンク送信帯域幅（ｂａｎｄｗｉｄｔｈ）に従属する。
【００４８】
アップリンクスロットの構造は、ダウンリンクスロットの構造と同一でありうる。
【００４９】
図３は、本発明が適用されることができる無線通信システムにおけるダウンリンクサブフレームの構造を示す。
【００５０】
図３を参照すると、サブフレーム内の第１番目のスロットにおいて前の最大３個のＯＦＤＭシンボルが制御チャネルが割り当てられる制御領域（ｃｏｎｔｒｏｌ  ｒｅｇｉｏｎ）であり、残りのＯＦＤＭシンボルは、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）が割り当てられるデータ領域（ｄａｔａ  ｒｅｇｉｏｎ）である。３ＧＰＰ  ＬＴＥで使用されるダウンリンク制御チャネルの一例にＰＣＦＩＣＨ（Ｐｈｙｓｉｃａｌ  Ｃｏｎｔｒｏｌ  Ｆｏｒｍａｔ  Ｉｎｄｉｃａｔｏｒ  Ｃｈａｎｎｅｌ）、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ    ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＰＨＩＣＨ（Ｐｈｙｓｉｃａｌ  Ｈｙｂｒｉｄ-ＡＲＱ  Ｉｎｄｉｃａｔｏｒ  Ｃｈａｎｎｅｌ）などがある。
【００５１】
ＰＣＦＩＣＨは、サブフレームの第１番目のＯＦＤＭシンボルにおいて送信され、サブフレーム内に制御チャネルの送信のために使用されるＯＦＤＭシンボルの数（すなわち、制御領域の大きさ）に関する情報を運ぶ。ＰＨＩＣＨは、アップリンクに対する応答チャネルで、ＨＡＲＱ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）に対するＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）／ＮＡＣＫ（Ｎｏｔ-Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）信号を運ぶ。ＰＤＣＣＨを介して送信される制御情報をダウンリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｉｎｆｏｒｍａｔｉｏｎ）という。ダウンリンク制御情報は、アップリンク資源割り当て情報、ダウンリンク資源割り当て情報または任意の端末グループに対するアップリンク送信（Ｔｘ）パワー制御命令を含む。
【００５２】
ＰＤＣＣＨは、ＤＬ-ＳＣＨ（Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）の資源割り当て及び送信フォーマット（これをダウンリンクグラントともいう）、ＵＬ-ＳＣＨ（Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）の資源割り当て情報（これをアップリンクグラントともいう）、ＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）でのページング（ｐａｇｉｎｇ）情報、ＤＬ-ＳＣＨでのシステム情報、ＰＤＳＣＨから送信されるランダムアクセス応答（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｒｅｓｐｏｎｓｅ）のような上位階層（ｕｐｐｅｒ-ｌａｙｅｒ）制御メッセージに対する資源割り当て、任意の端末グループ内の個別端末に対する送信パワー制御命令の集合、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ）の活性化などを運ぶことができる。複数のＰＤＣＣＨは、制御領域内で送信されることができ、端末は、複数のＰＤＣＣＨをモニタリングできる。ＰＤＣＣＨは、一つまたは複数の連続的なＣＣＥ（ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ  ｅｌｅｍｅｎｔｓ）の集合から構成される。ＣＣＥは、無線チャネルの状態に応じる符号化率（ｃｏｄｉｎｇ  ｒａｔｅ）をＰＤＣＣＨに提供するために使用される論理的割り当て単位である。ＣＣＥは、複数の資源要素グループ（ｒｅｓｏｕｒｃｅ  ｅｌｅｍｅｎｔ  ｇｒｏｕｐ）に対応する。ＰＤＣＣＨのフォーマット及び使用可能なＰＤＣＣＨのビット数は、ＣＣＥの数とＣＣＥにより提供される符号化率間の関連関係によって決定される。
【００５３】
基地局は、端末に送信しようとするＤＣＩに応じてＰＤＣＣＨフォーマットを決定し、制御情報にＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）を付ける。ＣＲＣには、ＰＤＣＣＨの所有者（ｏｗｎｅｒ）または用途に応じて、固有の識別子（これをＲＮＴＩ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ）という。）がマスキングされる。特定の端末のためのＰＤＣＣＨであれば、端末の固有の識別子、例えばＣ-ＲＮＴＩ（Ｃｅｌｌ-ＲＮＴＩ）がＣＲＣにマスキングされることができる。またはページングメッセージのためのＰＤＣＣＨであれば、ページング指示識別子、例えばＰ-ＲＮＴＩ（Ｐａｇｉｎｇ-ＲＮＴＩ）がＣＲＣにマスキングされることができる。システム情報、さらに具体的にシステム情報ブロック（ＳＩＢ：ｓｙｓｔｅｍ  ｉｎｆｏｒｍａｔｉｏｎ  ｂｌｏｃｋ）のためのＰＤＣＣＨであれば、システム情報識別子、ＳＩ-ＲＮＴＩ（ｓｙｓｔｅｍ  ｉｎｆｏｒｍａｔｉｏｎ  ＲＮＴＩ）がＣＲＣにマスキングされることができる。端末のランダムアクセスプリアンブルの送信に対する応答であるランダムアクセス応答を指示するために、ＲＡ-ＲＮＴＩ（ｒａｎｄｏｍ  ａｃｃｅｓｓ-ＲＮＴＩ）がＣＲＣにマスキングされることができる。
【００５４】
図４は、本発明が適用されることができる無線通信システムにおけるアップリンクサブフレームの構造を示す。
【００５５】
図４に示すように、アップリンクサブフレームは、周波数領域において制御領域とデータ領域とに分けられる。制御領域には、アップリンク制御情報を運ぶＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）が割り当てられる。データ領域は、ユーザデータを運ぶＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）が割り当てられる。単一搬送波特性を維持するために、一つの端末は、ＰＵＣＣＨとＰＵＳＣＨを同時に送信しない。
【００５６】
一つの端末に対するＰＵＣＣＨには、サブフレーム内に資源ブロック（ＲＢ：Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）対が割り当てられる。ＲＢ対に属するＲＢは、２個のスロットの各々で互いに異なる副搬送波を占める。これをＰＵＣＣＨに割り当てられたＲＢ対は、スロット境界（ｓｌｏｔ  ｂｏｕｎｄａｒｙ）から周波数跳躍（ｆｒｅｑｕｅｎｃｙ  ｈｏｐｐｉｎｇ）されるという。
【００５７】
キャリア併合一般
【００５８】
本発明の実施形態において考慮する通信環境は、マルチキャリア（Multi-carrier）サポート環境を全て含む。すなわち、本発明で使用されるマルチキャリアシステム又はキャリア併合（ＣＡ：Carrier Aggregation）システムとは、広帯域をサポートするために、目標とする広帯域を構成するときに目標帯域より小さい帯域幅（bandwidth）を有する１つ以上のコンポーネントキャリア（ＣＣ：Component Carrier）を併合（aggregation）して使用するシステムをいう。
【００５９】
本発明においてマルチキャリアは、キャリアの併合（又は、搬送波集成）を意味し、ここで、キャリアの併合は、隣接した（contiguous）キャリア間の併合だけでなく、非隣接した（non-contiguous）キャリア間の併合の両方ともを意味する。また、ダウンリンクとアップリンク間に集成されるコンポーネントキャリアの数は異なるように設定されることができる。ダウンリンクコンポーネントキャリア（以下、「ＤＬ ＣＣ」という。）の数とアップリンクコンポーネントキャリア（以下、「ＵＬ ＣＣ」という。）の数が同一である場合を対称的（symmetric）集成といい、その数が異なる場合を非対称的（asymmetric）集成という。このようなキャリア併合は、搬送波集成、帯域幅集成（bandwidth aggregation）、スペクトル集成（spectrum aggregation）などの用語と混用して使用されることができる。
【００６０】
２つ以上のコンポーネントキャリアが結合されて構成されるキャリア併合は、ＬＴＥ−Ａ（LTE-advanced）システムでは１００ＭＨｚ帯域幅までサポートすることを目標とする。目標帯域より小さい帯域幅を有する１つ以上のキャリアを結合するとき、結合するキャリアの帯域幅は、既存のＩＭＴシステムとの互換性（backward compatibility）の維持のために既存のシステムで使用する帯域幅に制限することができる。例えば、既存の３ＧＰＰ ＬＴＥシステムにおいては、｛１．４，３，５，１０，１５，２０｝ＭＨｚ帯域幅をサポートし、３ＧＰＰ ＬＴＥ−Ａシステムにおいては、既存のシステムとの互換のために前記帯域幅のみを利用して２０ＭＨｚより大きい帯域幅をサポートするようにすることができる。また、本発明で使用されるキャリア併合システムは、既存のシステムで使用する帯域幅と関係なく新たな帯域幅を定義してキャリア併合をサポートするようにすることもできる。
【００６１】
ＬＴＥ−Ａシステムは、無線リソースを管理するためにセル（cell）の概念を使用する。
【００６２】
前述したキャリア併合環境は、多重セル（multiple cells）環境ということができる。セルは、ダウンリンクリソース（ＤＬ ＣＣ）とアップリンクリソース（ＵＬ ＣＣ）の一対の組み合わせで定義されるが、アップリンクリソースは必須要素ではない。従って、セルは、ダウンリンクリソース単独、またはダウンリンクリソースとアップリンクリソースで構成されることができる。特定端末がただ１つの設定されたサービングセル（configured serving cell）を有する場合、１つのＤＬ ＣＣと１つのＵＬ ＣＣを有することができるが、特定端末が２つ以上の設定されたサービングセルを有する場合は、セルの数だけのＤＬ ＣＣを有し、ＵＬ ＣＣの数は、それと等しいかより小さい。
【００６３】
また、その逆にＤＬ ＣＣとＵＬ ＣＣが構成されることもできる。すなわち、特定端末が複数の設定されたサービングセルを有する場合、ＤＬ ＣＣの数よりＵＬ ＣＣがさらに多いキャリア併合環境もサポートされることができる。すなわち、キャリア併合（carrier aggregation）は、それぞれキャリア周波数（セルの中心周波数）が相異なる２つ以上のセルの併合として理解されることができる。ここで言う「セル（Cell）」は、一般的に使用される基地局がカバーする領域としての「セル」とは区別されるべきである。
【００６４】
ＬＴＥ−Ａシステムで使用されるセルは、プライマリセル（ＰＣｅｌｌ：Primary Cell）及びセカンダリセル（ＳＣｅｌｌ：Secondary Cell）を含む。ＰセルとＳセルは、サービングセル（Serving Cell）として用いられることができる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるが、キャリア併合が設定されていないか、キャリア併合をサポートしない端末の場合、Ｐセルのみで構成されたサービングセルがただ１つ存在する。それに対して、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあり、キャリア併合が設定された端末の場合、１つ以上のサービングセルが存在することができ、全体のセルにはＰセルと１つ以上のＳセルが含まれる。
【００６５】
サービングセル（ＰセルとＳセル）は、ＲＲＣパラメータにより設定されることができる。ＰｈｙｓＣｅｌｌＩｄは、セルの物理層識別子として０から５０３までの整数値を有する。ＳＣｅｌｌＩｎｄｅｘは、Ｓセルを識別するために使用される簡略な（short）識別子として１から７までの整数値を有する。ＳｅｒｖＣｅｌｌＩｎｄｅｘは、サービングセル（ＰセルまたはＳセル）を識別するために使用される簡略な（short）識別子として０から７までの整数値を有する。０値はＰセルに適用され、ＳＣｅｌｌＩｎｄｅｘは、Ｓセルに適用するために予め付与される。すなわち、ＳｅｒｖＣｅｌｌＩｎｄｅｘにおいて最小のセルＩＤ（又は、セルインデックス）を有するセルがＰセルとなる。
【００６６】
Ｐセルは、プライマリ周波数（又は、primary CC）上で動作するセルを意味する。端末が初期接続設定（initial connection establishment）過程を行うか、接続再設定過程を行うのに使用されることができ、ハンドオーバー過程で指示されたセルを称することもできる。また、Ｐセルは、キャリア併合環境で設定されたサービングセルのうち制御関連通信の中心となるセルを意味する。すなわち、端末は、自分のＰセルにおいてのみＰＵＣＣＨを割り当てを受けて送信することができ、システムの情報を取得するか、モニタリングする手順を変更するのにＰセルのみを利用することができる。Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access）は、キャリア併合環境をサポートする端末に移動性制御情報（ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏ）を含む上位層のＲＲＣ接続再設定（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｔａｉｏｎ）メッセージを利用して、ハンドオーバー手順のためにＰセルのみを変更することもできる。
【００６７】
Ｓセルは、セカンダリ周波数（又は、Secondary CC）上で動作するセルを意味することができる。特定端末にＰセルは１つのみが割り当てられ、Ｓセルは、１つ以上が割り当てられることができる。Ｓセルは、ＲＲＣ接続の設定が行われた後に構成可能であり、追加的な無線リソースを提供するのに使用されることができる。キャリア併合環境で設定されたサービングセルのうちＰセルを除いた残りのセル、すなわち、ＳセルにはＰＵＣＣＨが存在しない。Ｅ−ＵＴＲＡＮは、Ｓセルをキャリア併合環境をサポートする端末に追加するとき、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にある関連セルの動作と関連した全てのシステム情報を特定シグナル（dedicated signal）により提供することができる。システム情報の変更は、関連したＳセルの解除及び追加により制御されることができ、ここで、上位層のＲＲＣ接続再設定（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｔａｉｏｎ）メッセージを利用することができる。Ｅ−ＵＴＲＡＮは、関連したＳセル内においてブロードキャストするよりは端末別に相異なるパラメータを有する特定シグナリング（dedicated signaling）をすることができる。
【００６８】
初期保安活性化の過程が開始された後、Ｅ−ＵＴＲＡＮは、接続設定過程で、初期に構成されるＰセルに付加して１つ以上のＳセルを含むネットワークを構成することができる。キャリア併合環境でＰセル及びＳセルは、それぞれのコンポーネントキャリアとして動作することができる。以下の実施形態では、プライマリコンポーネントキャリア（ＰＣＣ）はＰセルと同一の意味で用いられることができ、セカンダリコンポーネントキャリア（ＳＣＣ）はＳセルと同一の意味で用いられることができる。
【００６９】
図５は、本発明が適用できる無線通信システムにおけるコンポーネントキャリア及びキャリア併合の一例を示す。
【００７０】
図５の（ａ）は、ＬＴＥシステムで使用される単一キャリア構造を示す。コンポーネントキャリアにはＤＬ ＣＣとＵＬ ＣＣがある。１つのコンポーネントキャリアは、２０ＭＨｚの周波数範囲を有することができる。
【００７１】
図５の（ｂ）は、ＬＴＥ−Ａシステムで使用されるキャリア併合構造を示す。図５の（ｂ）の場合、２０ＭＨｚの周波数サイズを有する３つのコンポーネントキャリアが結合された場合を示す。ＤＬ ＣＣとＵＬ ＣＣがそれぞれ３つずつあるが、ＤＬ ＣＣとＵＬ ＣＣの個数に制限があることではない。キャリア併合の場合、端末は、３つのＣＣを同時にモニタリングすることができ、ダウンリンク信号／データを受信することができ、アップリンク信号／データを送信することができる。
【００７２】
特定のセルにおいてＮ個のＤＬ ＣＣが管理される場合、ネットワークは、端末にＭ（Ｍ≦Ｎ）個のＤＬ ＣＣを割り当てることができる。ここで、端末は、Ｍ個の制限されたＤＬ ＣＣのみをモニタリングし、ＤＬ信号を受信することができる。また、ネットワークは、Ｌ（Ｌ≦Ｍ≦Ｎ）個のＤＬ ＣＣに優先順位を与え、主なＤＬ ＣＣを端末に割り当てることができ、このような場合、ＵＥは、Ｌ個のＤＬ ＣＣを必ずモニタリングしなければならない。このような方式は、アップリンクの送信にも同様に適用されることができる。
【００７３】
ダウンリンクリソースの搬送波周波数（又は、ＤＬ ＣＣ）とアップリンクリソースの搬送波周波数（又は、ＵＬ ＣＣ）の間のリンケージ（linkage）は、ＲＲＣメッセージのような上位層メッセージやシステム情報により指示されることができる。例えば、ＳＩＢ２（System Information Block Type2）により定義されるリンケージによりＤＬリソースとＵＬリソースの組み合わせが構成されることができる。具体的に、リンケージは、ＵＬグラントを運ぶＰＤＣＣＨが送信されるＤＬ ＣＣと、前記ＵＬグラントを使用するＵＬ ＣＣとの間のマッピング関係を意味することができ、ＨＡＲＱのためのデータが送信されるＤＬ ＣＣ（又は、ＵＬ ＣＣ）とＨＡＲＱ ＡＣＫ／ＮＡＣＫ信号が送信されるＵＬ ＣＣ（又は、ＤＬ ＣＣ）との間のマッピング関係を意味することもできる。
【００７４】
図６は、キャリア併合をサポートするシステムのセルの区分を例示した図である。
【００７５】
図６に示すように、設定されたセル（configured cell）は、図５のように、基地局のセルのうち測定報告に基づいてキャリア併合できるようにしたセルであり、端末別に設定される。設定されたセルは、ＰＤＳＣＨの送信に対するａｃｋ／ｎａｃｋ送信のためのリソースを予め予約しておくことができる。活性化されたセル（activated cell）は、設定されたセルのうち実際にＰＤＳＣＨ／ＰＵＳＣＨを送信するように設定されたセルであり、ＰＤＳＣＨ／ＰＵＳＣＨ送信のためのＣＳＩ（Channel State Information）報告とＳＲＳ（Sounding Reference Signal）送信を行う。非活性化されたセル（de-activated cell）は、基地局の命令又はタイマー動作によりＰＤＳＣＨ／ＰＵＳＣＨの送信をしないようにするセルであり、ＣＳＩ報告及びＳＲＳ送信も中断することができる。
【００７６】
以下、狭帯域物理ランダムアクセスチャネル（narrowband physical random access channel）について説明する。
【００７７】
物理層ランダムアクセスプリアンブルは、単一サブキャリア周波数ホッピングシンボルグループに基づく。
【００７８】
前記シンボルグループは図７に示され、長さ
2020526148.tif 000005
の１つのＣＰ（cyclic prefix）と全体長さ
2020526148.tif 000006
を有する５つの同一のシンボルのシーケンスを含む。
【００７９】
前記物理層ランダムアクセスプリアンブルのパラメータは、下記の表３に示す。
【００８０】
すなわち、図７は、ＮＰＲＡＣＨプリアンブルのシンボルグループの一例を示す図であり、表３は、ランダムアクセスプリアンブルパラメータ（random access preamble parameters）の一例を示す表である。
【００８１】
【表３】
2020526148.tif 000007
【００８２】
ギャップ（gap）なしに送信される４シンボルグループを含むＮＰＲＡＣＨプリアンブルは
2020526148.tif 000008
送信される。
【００８３】
ランダムアクセスプリアンブルの送信は、ＭＡＣレイヤ（layer）によりトリガされる場合、特定時間及び周波数リソースに制限される。
【００８４】
上位層により提供されるＮＰＲＡＣＨ構成（configuration）は次のパラメータを含む。
【００８５】
−ＮＰＲＡＣＨリソース周期（resource periodicity）
2020526148.tif 000009
（ｎｐｒａｃｈ−Ｐｅｒｉｏｄｉｃｉｔｙ）、
【００８６】
−ＮＰＲＡＣＨに割り当てられる１番目のサブキャリアの周波数位置
2020526148.tif 000010
（ｎｐｒａｃｈ−ＳｕｂｃａｒｒｉｅｒＯｆｆｓｅｔ）、
【００８７】
−ＮＰＲＡＣＨに割り当てられるサブキャリアの数
2020526148.tif 000011
（ｎｐｒａｃｈ−ＮｕｍＳｕｂｃａｒｒｉｅｒｓ）、
【００８８】
−競争基盤（contention based）ＮＰＲＡＣＨランダムアクセスに割り当てられる開始サブキャリア（starting sub-carriers）の数
2020526148.tif 000012
（ｎｐｒａｃｈ−ＮｕｍＣＢＲＡ−ＳｔａｒｔＳｕｂｃａｒｒｉｅｒｓ）、
【００８９】
−試み（attempt）別のＮＰＲＡＣＨ繰り返し数
2020526148.tif 000013
（ｎｕｍＲｅｐｅｔｉｔｉｏｎｓＰｅｒＰｒｅａｍｂｌｅＡｔｔｅｍｐｔ）、
【００９０】
−ＮＰＲＡＣＨ開始時間（starting time）
2020526148.tif 000014
（ｎｐｒａｃｈ−ＳｔａｒｔＴｉｍｅ）、
【００９１】
−マルチトーンｍｓｇ３送信のためのＵＥサポートの指示（indication）のために予約されたＮＰＲＡＣＨサブキャリア範囲に対する開始サブキャリアインデックスを計算するための比率
2020526148.tif 000015
（ｎｐｒａｃｈ−ＳｕｂｃａｒｒｉｅｒＭＳＧ３−ＲａｎｇｅＳｔａｒｔ）。
【００９２】
ＮＰＲＡＣＨ送信は、
2020526148.tif 000016
を満足する無線フレームの開始以後時間
2020526148.tif 000017
単位（time unit）でのみ開始することができる。
【００９３】
2020526148.tif 000018
時間単位の送信後に、
2020526148.tif 000019
時間単位のギャップ（gap）は挿入される。
【００９４】
2020526148.tif 000020
であるＮＰＲＡＣＨ構成（NPRACH configurations）は有効でない（invalid）。
【００９５】
競争基盤ランダムアクセスに割り当てられるＮＰＲＡＣＨ開始サブキャリアはサブキャリアの２セット、すなわち、
2020526148.tif 000021
及び
2020526148.tif 000022
に割れる。
【００９６】
ここで、２番目のセットが存在する場合、２番目のセットはマルチトーンｍｓｇ３送信に対するＵＥサポートを示す。
【００９７】
ＮＰＲＡＣＨ送信の周波数位置は
2020526148.tif 000023
サブキャリア内において制限される。周波数ホッピングは１２サブキャリア内において用いられ、ｉ番目のシンボルグループ（symbol group）の周波数位置は
2020526148.tif 000024
により与えられ、
2020526148.tif 000025
であり、数式１に従う。
【００９８】
【数１】
2020526148.tif 000026
【００９９】
ここで、
2020526148.tif 000027
は、
2020526148.tif 000028
からＭＡＣレイヤにより選択されるサブキャリアである。また、疑似ランダム生成器（psedo random generator）は
2020526148.tif 000029
に初期化される。
【０１００】
ベースバンド信号生成（Baseband signal generation）
【０１０１】
シンボルグループ（symbol group）ｉに対する時間連続した（time-continuous）ランダムアクセス信号
2020526148.tif 000030
は、下記の数式２により定義される。
【０１０２】
【数２】
2020526148.tif 000031
【０１０３】
ここで、
2020526148.tif 000032
であり、
2020526148.tif 000033
は送信パワー
2020526148.tif 000034
に従うための振幅スケーリング要素（amplitude scaling factor）であり、
2020526148.tif 000035
2020526148.tif 000036
はランダムアクセスプリアンブルとアップリンクデータ送信との間のサブキャリア間隔において差を説明する。
【０１０４】
また、周波数領域においての位置はパラメータ
2020526148.tif 000037
により調節される。
【０１０５】
変数
2020526148.tif 000038
は、下記の表４に示す。
【０１０６】
すなわち、表４はランダムアクセスベースバンドパラメータ（random access baseband parameters）の一例を示す表である。
【０１０７】
【表４】
2020526148.tif 000039
【０１０８】
ＰＵＳＣＨ−Ｃｏｎｆｉｇ
【０１０９】
ＩＥ ＰＵＳＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎは、ＰＵＳＣＨ及びＰＵＣＣＨに対する共通ＰＵＳＣＨ構成及び参照信号構成を指定するのに用いられる。ＩＥ ＰＵＳＣＨ−ＣｏｎｆｉｇＤｅｄｉｃａｔｅｄは、ＵＥ特定ＰＵＳＣＨ構成を指定するのに用いられる。
【０１１０】
【表５】
2020526148.tif 000040
【０１１１】
表５において、ｓｙｍＰＵＳＣＨ−ＵｐＰＴＳは、ＵｐＰＴＳにおいてＰＵＳＣＨ送信のために設定されたデータシンボルの数を示す。
【０１１２】
ｓｙｍ２、ｓｙｍ３、ｓｙｍ４、ｓｙｍ５及びｓｙｍ６値は、一般ＣＰ（normal cyclic prefix）のために用いられ、ｓｙｍ１、ｓｙｍ２、ｓｙｍ３、ｓｙｍ４及びｓｙｍ５値は、拡張ＣＰ（extended cyclic prefix）のために用いられる。
【０１１３】
物理リソースマッピング（Mapping to physical resources）
【０１１４】
ＵｐＰＴＳに対して、ｄｍｒｓＬｅｓｓ−ＵｐＰｔｓが「ｔｒｕｅ」に設定されると、物理リソースマッピングはスペシャルサブフレーム（special subframe）の２番目のスロットの
2020526148.tif 000041
シンボルから開始し、そうでないと、前記物理リソースマッピングはスペシャルサブフレーム（special subframe）の２番目のスロットの
2020526148.tif 000042
から開始する。
【０１１５】
以下、本明細書で提案するセルラー（cellular）ＩｏＴ（Internet of Things）をサポートするＮＢ（NarrowBand）−ＩｏＴシステムにおいて、フレーム構造タイプ２（frame structure type 2, TDD）をサポートするとき、ＮＲＡＣＨ（Narrowband Random Access Channel）プリアンブル（preamble）の設計（design）方法について説明する。
【０１１６】
まず、狭帯域（narrowband：ＮＢ）−ＬＴＥは、ＬＴＥシステムの１ＰＲＢ（Physical Resource Block）に該当するシステム帯域幅（system BW）を有する低い複雑度（complexity）、低いパワー消費（power consumption）をサポートするシステムをいう。
【０１１７】
これは、主にＭＴＣ（machine-type communication）などのデバイス（device）をセルラーシステム（cellular system）においてサポートしてＩｏＴ（internet of things）を実現するための通信方式として用いられる。
【０１１８】
ＮＢ−ＩｏＴシステムは、サブキャリア間隔（subcarrier spacing）などのＯＦＤＭパラメータをＬＴＥシステムにおいてのものと同一のものを用いることにより、追加的な帯域（band）割り当てなしにレガシーＬＴＥバンド（legacy LTE band）に１ＰＲＢをＮＢ−ＬＴＥ用として割り当てて周波数を効率的に利用できるという利点がある。
【０１１９】
ＮＢ−ＬＴＥの物理チャネル（physical channel）は、ダウンリンクの場合、ＮＰＳＳ／ＮＳＳＳ、ＮＰＢＣＨ、ＮＰＤＣＣＨ／ＮＥＰＤＣＣＨ、ＮＰＤＳＣＨなどと定義し、ＬＴＥと区別するためにＮを加えて呼ぶことにする。
【０１２０】
Ｒｅｌ．１４までのＦＤＤ（Frequency Division Duplex） ＮＢ−ＩｏＴにおいて用いているＮＰＲＡＣＨプリアンブル（preamble）は、２種類フォーマットがあり、より具体的な形状は図８のようである。
【０１２１】
すなわち、図８は、ＮＢ−ＩｏＴシステムにおけるＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【０１２２】
図８に示すように、ＮＰＲＡＣＨプリアンブルは、単一トーン送信（single tone transmission）を行い、３．７５ｋＨｚのサブキャリア間隔（subcarrier spacing）を有し、５つのシンボルと１つのＣＰが結合して１つのシンボルグループ（symbol group）を形成する。
【０１２３】
ここで、ＮＰＲＡＣＨプリアンブルフォーマット０（NPRACH preamble format 0）は６６．６６μｓのＣＰと５つの連続した２６６．６６μｓのシンボル（symbol）で形成されており、ＮＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は２６６．６６μｓのＣＰと５つの連続した２６６．６６μｓのシンボル（symbol）で形成されている。
【０１２４】
ここで、ＮＰＲＡＣＨプリアンブルフォーマット０（NPRACH preamble format 0）のシンボルグループの長さは１．４ｍｓとなり、ＮＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）のシンボルグループ（symbol group）の長さは１．６ｍｓとなる。
【０１２５】
また、繰り返し（repetition）のための基本単位は、４つのシンボルグループが集まって１つの繰り返しを形成する。
【０１２６】
従って、１つの繰り返しを構成している４つの連続したシンボルグループの長さはｆｏｒｍａｔ ０を用いると５．６ｍｓになり、ｆｏｒｍａｔ １は６．４ｍｓになる。
【０１２７】
また、図９に示すように、ＮＰＲＡＣＨプリアンブルは、サブキャリア間隔（subcarrier spacing）の分だけの間隔を有する１番目のホッピング（1st hopping）とサブキャリア間隔 （subcarrier spacing）の６倍の分だけの間隔を有する２番目のホッピング（2nd hopping）をするよう設定される。
【０１２８】
図９は、ＮＰＲＡＣＨプリアンブルの繰り返しとランダムホッピング方法の一例を示す図である。
【０１２９】
一方、Ｒｅｌ．１５ ＮＢ−ＩｏＴシステムで導入しようとするフレーム構造タイプ２（frame structure type 2, TDD）において、レガシーＬＴＥ（legacy LTE）のＵＬ／ＤＬ構成（UL/DL configuration）を考慮すると、レガシーＮＢ−ＩｏＴ（Ｒｅｌ．１４） ＮＰＲＡＣＨプリアンブルフォーマットをそのまま用いることは容易ではない。
【０１３０】
但し、ＴＤＤスタンドアローンモード（TDD standalone mode）は、新しいＵＬ／ＤＬ構成（UL/DL configuration）を導入してレガシーＮＢ−ＩｏＴ ＮＰＲＡＣＨプリアンブルフォーマット（legacy NB-IoT NPRACH preamble format）を用いるように設定することはできるが、一般的に考慮しているインバンドモード（in-band mode）又はガードバンドモード（guard band mode）は、レガシーＮＢ−ＩｏＴ ＮＰＲＡＣＨプリアンブルフォーマットをそのまま用いることは容易ではない。
【０１３１】
従って、本明細書においては、フレーム構造タイプ２（frame structure type 2）がＮＢ−ＩｏＴシステムに適用されるとき、ＮＲＡＣＨプリアンブルの設計方法を提供する。
【０１３２】
後述する実施形態にもかかわらず、本発明の思想は、ＰＲＡＣＨ以外の他のチャネル（channel）にも適用され、単一トーン（single-tone）方式だけでなく、マルチトーン（multi-tone）方式にも拡張が可能である。
【０１３３】
また、本明細書においては、ＴＤＤインバンドモード（TDD in-band mode）又はガードバンドモード（guard band mode）を中心に説明しているが、スタンドアローンモード（standalone mode）においても本明細書で提案する方法が利用できることは言うまでもない。
【０１３４】
フレーム構造タイプ２（Frame structure type 2）（ＴＤＤ）に対する進化したＮＰＲＡＣＨプリアンブル（enhanced NPRACH preamble）
【０１３５】
図９において説明したように、前記１番目のホッピング（1st hopping）と前記２番目のホッピング（2nd hopping）は連続的なＵＬサブフレームにおいて送信されるように設定することが性能面で有利である。
【０１３６】
しかしながら、レガシーＮＰＲＡＣＨプリアンブルフォーマット（legacy NPRACH preamble format）をＴＤＤにおいても用いる場合、４つのシンボルグループを連続的に送信できるＵＬ／ＤＬ構成（UL/DL configuration）（表１を参照）が存在しない。
【０１３７】
従って、ＴＤＤの場合、ＮＰＲＡＣＨプリアンブルを設計（design）するとき、（１）１つのシンボルグループに含まれるシンボルの数を減らすことを考慮するか、又は（２）サブフレーム間隔を増加させると共にシンボル長さ（symbol length）を減らす方法を考慮するか、又は（３）ＣＰ長さを減らすことを考慮することができる。
【０１３８】
また、前記（１）ないし（３）の方式を組み合わせてＮＰＲＡＣＨプリアンブルを設計してもよい。
【０１３９】
表６は、表２のＵＬ／ＤＬ構成（UL/DL configuration）に構成別に連続するＵＬサブフレームを表示したことを示す。
【０１４０】
【表６】
2020526148.tif 000043
【０１４１】
表６を参照して、レガシーＵＬ／ＤＬ構成（UL/DL configuration）に連続的に利用できるＵＬ ＳＦ（subframe）が個数を確認すると、ｃｏｎｆｉｇｕｒａｔｉｏｎ＃２とｃｏｎｆｉｇｕｒａｔｉｏｎ＃５を除いたｃｏｎｆｉｇｕｒａｔｉｏｎ＃０、＃１、＃３、＃４、＃６は最小２つのＵＬ ＳＦを連続的に含む。
【０１４２】
また、スペシャルサブフレーム（special subframe）のＵｐＰＴＳまで考慮すると（最大６つのシンボルまで構成（configure）可能）最大４２８μｓ（７１．３３μｓ＊６）をもっと用いることができる。
【０１４３】
ここで、レガシーＬＴＥ／ＭＴＣシステムは、各端末にｓｙｍＰＵＳＣＨ−ＵｐＰＴＳという専用シグナリング（dedicated signaling）で構成（configuration）した。
【０１４４】
一方、ＴＤＤ ＮＰＲＡＣＨプリアンブルをＵｐＰＴＳにおいて利用できると仮定すると、前記ＵｐＰＴＳに含まれるシンボルの数はＳＩＢ（System Information Block）を介してセル特定（cell-specific）に、半統計的 （semi-statistic）に構成（configure）することができる。
【０１４５】
追加的に、ＵｐＰＴＳは、スペシャルサブフレーム構成（special subframe configuration）値に応じて何個のシンボルが利用できるかが決定されるので、ＳＩＢを介して半統計的（semi-statistic）に構成（configure）されるＴＤＤ ＮＰＲＡＣＨプリアンブル用のＵｐＰＴＳシンボルの数はスペシャルサブフレーム構成（special subframe configuration）に基礎（又は、依存）するといえる。
【０１４６】
すなわち、予め約束されたスペシャルサブフレーム構成（special subframe configuration）（例えば、＃０、♯５）においてのみＵｐＰＴＳをＮＰＡＲＣＨプリアンブル送信に用いると設定することができる。
【０１４７】
また、ＮＰＲＡＣＨリソース割り当て（resource allocation）情報を端末に伝達するとき、ＮＰＲＡＣＨ送信のためにＵｐＰＴＳを使用することができるかに対して明示的に（explicit）通知することができる。
【０１４８】
さらに、ＴＤＤ ＮＰＲＡＣＨプリアンブル用のＵｐＰＴＳシンボルパラメータ（symbol parameter）を送信することにより、暗示的に（implicit）ＵｐＰＴＳを使用するか否かを指示できると設定することができる。
【０１４９】
この場合、ＵｐＰＴＳを用いると設定する場合、端末は、基地局から構成（configure）されたＵｐＰＴＳシンボルの最初からＮＰＲＡＣＨプリアンブル（NPRACH preamble）を送信すると設定することができる。
【０１５０】
また、ＵｐＰＴＳを使用しないと設定する場合、端末は、スペシャルサブフレーム（special subframe）の直後に位置するＵＬサブフレームの開始点にＮＰＲＡＣＨプリアンブルを送信すると設定することができる。
【０１５１】
追加的に、ＮＰＲＡＣＨプリアンブルのためにＵｐＰＴＳシンボルを利用できると端末に通知した場合、又は、そうでない場合も、基地局がＮＰＲＡＣＨプリアンブル送信開始時点を別途に構成（configure）すると、端末は、基地局が構成（configure）した所でＮＰＲＡＣＨプリアンブル送信を開始すると設定することができる。
【０１５２】
また、基地局においてＣＥレベル（level）別及び／又はＮＰＲＡＣＨフォーマット（シンボルグループ内の繰り返し数(repetition number within symbol group)）別にＴＡ（ダウンリンク時間同期（downlink time synchronization）時点からＮＰＲＡＣＨを予め送信する時点までの時間）を構成（configure）して、暗示的なガード時間（implicit guard time）を確保する方法を考慮することができる。
【０１５３】
ここで、適用するデフォルト（default）ＴＡは、ＮＰＲＡＣＨを送信するＮＰＲＡＣＨリソースに従うことではなく、ＮＰＲＡＣＨを最小送信したリソースのデフォルトＴＡに従うと設定することができる。
【０１５４】
追加的に、基地局がＵｐＰＴＳにおいてＮＰＲＡＣＨプリアンブルを送信しても問題ないと端末に通知した場合、又は、ＵｐＰＴＳにおいてＮＰＲＡＣＨプリアンブルの送信が端末と基地局間に事前に約束された場合、次の方法が考慮されることができる。
【０１５５】
第１に、スモールギャップホッピング（small gap hopping）（例えば、サブキャリア間隔などのギャップでホッピング、例えば、３．７５ｋＨｚ）は、スペシャルＳＦのＵｐＰＴＳと前記スペシャルＳＦの直ぐ次に続くＵＬ ＳＦまでわたって送信するＮＰＲＡＣＨプリアンブル内において行われると設定することができる。
【０１５６】
特徴的に、ＰＲＡＣＨプリアンブルのシンボルグループ内のＣＰ（Cyclic Prefix）を長くして用いると設定されることができる。
【０１５７】
第２に、連続したＵＬサブフレーム（subframe）の数が１０ｍｓｅｃ内で同一でない場合（例えば、３つの連続したＵＬサブキャリアサブフレームと２つの連続したＵＬサブフレームから構成されているＵＬ／ＤＬ ｃｏｎｆｉｇｕｒａｔｉｏｎ♯６）、連続的に現れるＵＬサブフレームがより長い区間でシンボルグループ内のＣＰを増加させ、スモールギャップホッピング（small gap hopping）すると設定することができる。
【０１５８】
最後に、ＮＰＲＡＣＨプリアンブルを送信できるＵｐＰＴＳシンボルの長さが変化するに従ってシンボルグループ内のＣＰ長さが変化し得ると設定することができる。
【０１５９】
また、ＮＰＲＡＣＨプリアンブルを送信できるＵｐＰＴＳシンボルの長さに応じてシンボルグループ内のシンボル数が変化し得ると設定することができる。
【０１６０】
追加的に、セル（cell）が端末に構成（configure）したＵＬ／ＤＬ構成（UL/DL configuration）に応じて端末がＮＰＲＡＣＨプリアンブルフォーマットを選択して送信することを考慮することができる。
【０１６１】
特徴的に、ＵＬ／ＤＬ構成（UL/DL configuration）中に連続的に現れるＵＬサブフレームの数の最小値に応じて端末がＮＰＲＡＣＨプリアンブルフォーマットを選択すると設定することもできる。
【０１６２】
ケース１の場合、ＵＬ／ＤＬ構成（UL/DL configuration）＃０と＃３は連続的に現れるＵＬサブフレーム数の最小値が３ＳＦｓであり、ケース２の場合、ＵＬ／ＤＬ構成（UL/DL configuration）＃１、＃４、＃６は連続的に現れるＵＬサブフレーム数の最小値が２ＳＦｓであり、ケース３の場合、ＵＬ／ＤＬ構成（UL/DL configuration）＃２と＃５は連続的に現れるＵＬサブフレーム数の最小値が１ＳＦであると区分することができる。
【０１６３】
前記端末は、各３つのケース別に相異なるＮＰＲＡＣＨプリアンブルフォーマット（NPRACH preamble format）を選択すると設定することができる。
【０１６４】
以下、より具体的に、フレーム構造タイプ２（frame structure type 2）がＮＢ−ＩｏＴシステムに適用されるとき、ＮＲＡＣＨプリアンブルの設計と関連した様々な方法について説明する。
【０１６５】
（方法１）
【０１６６】
方法１は、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔（subcarrier spacing）を既存に比べてＮ倍増加（すなわち、シンボル区間（symbol duration）は既存に比べて１／Ｎ倍減少）させ、ＣＰ長さ（CP length）を既存に比べて１／Ｔの分だけ減少させる方法である。
【０１６７】
すなわち、方法１は、シンボルグループ内のシンボルの数は変化することなく、シンボルの区間（duration）をＮ倍ダウンスケール（down scale）する方法である。
【０１６８】
方法１は、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔をレガシーＮＰＲＡＣＨプリアンブルのサブキャリア間隔値に比べてＮ倍増加させることである。
【０１６９】
ここで、シンボル長さ（symbol length）は１／Ｎ倍に減少し、考慮するＣＰ長さ（CP length）は１／Ｔの分だけ減少すると設定することができる。（Ｎは正の整数、Ｔは実数）
【０１７０】
例を挙げてより具体的に説明する。下記の例においてＮとＴは相異なる値を有してもよい。
【０１７１】
（実施形態１）
【０１７２】
実施形態１は、Ｎ＝２であり、Ｔ＝２の場合である。
【０１７３】
Ｎ値が２であると、新しいＮＰＲＡＣＨプリアンブルのサブキャリア間隔は３．７５ｋＨｚの２倍である７．５ｋＨｚとなる。
【０１７４】
それと同時に、シンボル区間（symbol duration）は２６６．６６μｓから１３３．３３μｓに１／２倍に減少する。
【０１７５】
また、Ｔが２であるので、ＣＰ長さは１／２倍に減少する。この場合も２つの相異なる長さのＣＰをサポートし、１つのシンボルグループに入るシンボル数がレガシーＮＰＲＡＣＨプリアンブル構造（legacy NPRACH preamble configuration）と同じであるとする場合、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は図１０のように設定される。
【０１７６】
図１０は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【０１７７】
図１０に示すように、ＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）をなすシンボルグループの長さは０．７ｍｓとなり、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）をなすシンボルグループの長さは０．８ｍｓとなる。
【０１７８】
これは、すなわち、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）を用いても２つの連続したシンボルグループの長さが２ｍｓより小さいので、２つのシンボルグループを連続的に送信することができる。
【０１７９】
従って、この場合は、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、１番目のホッピング（1st hopping）をなしている２つのシンボルグループは２つのＵＬ ＳＦに連続的に送信するように設定し、２番目のホッピング（2nd hopping）は２つの連続的なＵＬ ＳＦの間で送信されるように設定することができる。
【０１８０】
これを図示すると、図１１のようである。
【０１８１】
図１１は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンの一例を示す図である。
【０１８２】
図１１に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソース（frequency resource）としてサブキャリア（subcarrier）ｎからサブキャリア（subcarrier）ｎ＋ｋ−１までトータルｋ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成＃１（UL/DL configuration #1）の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０１８３】
このような方式で送信する場合、４つのシンボルグループを連続的に送信することに比べてチャネルの変化による性能劣化が発生する可能性がある。
【０１８４】
しかしながら、１番目のホッピングをなしている２つのシンボルグループが連続的に送信されているため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０１８５】
ただし、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔が増加したため、周波数リソース（frequency resource）が既存に比べて減少するという欠点がある。
【０１８６】
すなわち、既存に３．７５ｋＨｚのサブキャリア間隔である場合、４８個の周波数リソースが使用可能であったが、７．５ｋＨｚのサブキャリア間隔である場合、２４個の周波数リソースが使用可能である。
【０１８７】
また、ＣＰ長さが短くなるにつれて該当セルがサービング（serving）できるセルカバレッジ（cell coverage）が短くなるという欠点があり得る。
【０１８８】
（実施形態２）
【０１８９】
実施形態２はＮ＝４であり、Ｔ＝４の場合である。
【０１９０】
Ｎ値が４である場合、新しいＮＰＲＡＣＨプリアンブルのサブキャリア間隔は３．７５ｋＨｚの４倍である１５ｋＨｚとなる。
【０１９１】
それと同時に、シンボル区間（symbol duration）は２６６．６６μｓから６６．６６μｓに１／４倍に減少する。また、Ｔが４であるので、ＣＰ長さも図１／４倍に減少する。
【０１９２】
この場合も２つの相異なる長さのＣＰをサポートし、１つのシンボルグループに入るシンボル数がレガシーＮＰＲＡＣＨプリアンブル構造と同じであるとする場合は、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は図１２のように設定される。
【０１９３】
図１２は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【０１９４】
図１２に示すように、ＮＰＲＡＣＨプリアンブルフォーマット０（NPRACH preamble format 0）をなすシンボルグループ（symbol group）の長さは０．３５ｍｓとなり、ＮＰＲＡＣＨプリアンブルフォーマット１（NPRACH preamble format 1）をなすシンボルグループの長さは０．４ｍｓとなる。
【０１９５】
これは、すなわち、ＮＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）を用いても４つの連続したシンボルグループの長さが２ｍｓより小さいので、４つのシンボルグループを連続的に送信することができる。
【０１９６】
従って、この場合は、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、既存の方法と類似して１番目のホッピングと２番目のホッピングをなしている４つのシンボルグループは２つのＵＬ ＳＦに連続的に送信するように設定することができる。
【０１９７】
これを図示すると、図１３のようである。
【０１９８】
図１３は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０１９９】
図１３に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソース（frequency resource）としてサブキャリア（subcarrier）ｎからサブキャリア（subcarrier）ｎ＋ｊ−１までトータルｊ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０２００】
このような方式で送信する場合、４つのシンボルグループを連続的に送信するため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０２０１】
ただし、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔が増加したため、周波数リソースが既存に比べて減少するという欠点がある。
【０２０２】
すなわち、既存にの３．７５ｋＨｚのサブキャリア間隔である場合、４８個の周波数リソースを使用可能であったが、１５ｋＨｚのサブキャリア間隔である場合、１２個の周波数リソースを使用できる。
【０２０３】
また、ＣＰ長さが短くなるにつれて該当セル（cell）がサービング（serving）できるセルカバレッジ（cell coverage）が短くなるという欠点があり得る。
【０２０４】
（実施形態３）
【０２０５】
実施形態３はＮ＝２であり、Ｔ＝１の場合である。
【０２０６】
Ｎ値が２である場合、新しいＮＰＲＡＣＨプリアンブルのサブキャリア間隔は３．７５ｋＨｚの２倍である７．５ｋＨｚとなる。
【０２０７】
それと同時に、シンボル区間（symbol duration）は、２６６．６６μｓから１３３．３３μｓに１／２倍に減少する。ただし、Ｔが１であるので、ＣＰ長さは変化しなくなる。
【０２０８】
この場合も２つの相異なる長さのＣＰをサポートし、１つのシンボルグループに入るシンボル数がレガシーＮＰＲＡＣＨプリアンブル構造と同じであるとする場合、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は図１４のように設定される。
【０２０９】
図１４は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０２１０】
図１４に示すように、ＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）をなすシンボルグループの長さは０．７３３ｍｓとなり、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）をなすシンボルグループの長さは０．９３３ｍｓとなる。
【０２１１】
これは、すなわち、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）を用いても２つの連続したシンボルグループの長さが２．２１４ｍｓ（2 UL SF+3 symbols for UpPTS）より小さいので、２つのシンボルグループを連続的に送信することができる。
【０２１２】
従って、この場合、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、１番目のホッピング（1st hopping）をなしている２つのシンボルグループはＵｐＰＴＳと２つのＵＬ ＳＦに連続的に送信するように設定し、２番目のホッピング（2nd hopping）はＵｐＰＴＳと２つの連続的なＵＬ ＳＦ間に現れるように送信するように設定することができる。これを図示すると図１５の通りである。
【０２１３】
図１５は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０２１４】
図１５に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリア（subcarrier）ｎからサブキャリア（subcarrier）ｎ＋ｋ−１までトータルｋ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０２１５】
このような方式で送信する場合、４つのシンボルグループを連続的に送信することに比べてチャネルの変化による性能劣化が発生する可能性がある。
【０２１６】
しかしながら、１番目のホッピング（1st hopping）をなしている２つのシンボルグループが連続的に送信されているため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０２１７】
また、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔が増加したため、周波数リソースが既存に比べて減少するという欠点がある。すなわち、既存に３．７５ｋＨｚのサブキャリア間隔である場合は４８個の周波数リソースを使用可能であったが、７．５ｋＨｚのサブキャリア間隔である場合は２４個の周波数リソースを使用できる。ただし、ＣＰ長さが変化しないので、セルカバレッジ（cell coverage）はＦＤＤセルのカバレッジと同様の水準を維持できるという利点がある。
【０２１８】
（実施形態４）
【０２１９】
実施形態４はＮ＝４であり、Ｔ＝１の場合である。
【０２２０】
Ｎ値が４である場合、新しいＮＰＲＡＣＨプリアンブルのサブキャリア間隔は３．７５ｋＨｚの４倍である１５ｋＨｚとなる。それと同時に、シンボル区間（symbol duration）は２６６．６６μｓから６６．６６μｓに１／４倍に減少する。
【０２２１】
ただし、Ｔが１であるので、ＣＰ長さは変わらなくなる。この場合も２つの相異なる長さのＣＰをサポートし、１つのシンボルグループに入るシンボル数がレガシーＮＰＲＡＣＨプリアンブル構造と同じであるとする場合は、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は図１６のように設定される。
【０２２２】
図１６は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０２２３】
図１６によると、ｆｏｒｍａｔ ０をなすシンボルグループの長さは０．４ｍｓとなり、ｆｏｒｍａｔ １をなすシンボルグループの長さは０．６ｍｓとなる。
【０２２４】
一般に、ＵＬ／ＤＬ構成（UL/DL configuration）＃２を用いるセルはカバレッジが大きくないという仮定下でｆｏｒｍａｔ ０を主に利用できると設定することができる。
【０２２５】
従って、ｆｏｒｍａｔ ０を用いる場合に２つの連続したシンボルグループの長さが１ｍｓより小さいので、２つのシンボルグループを連続的に送信することができる。
【０２２６】
従って、この場合、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、１番目のホッピング（1st hopping）をなしている２つのシンボルグループは１つのＵＬ ＳＦに連続的に送信するように設定し、２番目の（2nd hopping）をなしている２つのシンボルグループも１つのＵＬ ＳＦに連続的に送信するように設定することができる。
【０２２７】
これを図示すると、図１７及び図１８のようである。
【０２２８】
図１７及び図１８は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０２２９】
図１７及び図１８に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリアｎからサブキャリアｎ＋ｊ−１までトータルｊ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃２の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０２３０】
また、単一繰り返し（single repetition）内にＧ個のシンボルグループが入ることができる。
【０２３１】
図１７は、単一繰り返し（single repetition）内にシンボルグループが４回入ったことを考慮した例であり、図１８は、単一繰り返し（single repetition）内にシンボルグループ８回入ったことを考慮した例である。
【０２３２】
特徴的に、サブキャリア間隔が１５ｋＨｚである場合、１番目のホッピング（1st hopping）は単一トーン（single tone）（例えば、１５ｋＨｚ）の差の分だけホップするように設定することができ、２番目のホッピング（2nd hopping）は２つのトーン（例えば、３０ｋＨｚ）の差の分だけホップするように設定することができる。
【０２３３】
このような方式で送信する場合、４つのシンボルグループを連続的に送信することに比べてチャネルの変化による性能劣化が発生する可能性があるが、１番目のホッピング（1st hopping）をなしている２つのシンボルグループと２番目のホッピング（2nd hopping）をなしている２つのシンボルグループがそれぞれ連続的に送信されているため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０２３４】
ただし、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔が増加したため、周波数リソースが既存に比べて減少するという欠点がある。
【０２３５】
すなわち、既存に３．７５ｋＨｚサブキャリア間隔である場合は、４８個の周波数リソースを使用可能であったが、１５ｋＨｚサブキャリア間隔である場合は、１２個の周波数リソースを使用できる。
【０２３６】
ただし、ＣＰ長さが変化していないため、セルカバレッジ（cell coverage）はＦＤＤセルのカバレッジと同様の水準を維持できるという利点がある。
【０２３７】
追加的に、同一の状況でＵＬ／ＤＬ構成（UL/DL configuration）＃１を用いるセルの一例を図示すると図１３のようである。
【０２３８】
（方法２）
【０２３９】
方法２は、ＮＰＲＡＣＨプリアンブルのシンボルグループ（symbol group）をなしているシンボル数をＭ個に変更する方法である。
【０２４０】
ここで、ＭはＭ＜５の自然数であり、方法２は、サブキャリア間隔（subcarrier spacing）、シンボル区間（symbol duration）及びＣＰ長さが変更されない。
【０２４１】
すなわち、方法２は、ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を既存の５つから５つより小さいＭ個に変更する方法である。
【０２４２】
以下、例を挙げてより具体的に説明する。
【０２４３】
（実施形態１）
【０２４４】
実施形態１はＭ＝３の場合である。
【０２４５】
Ｍが３である場合、１つのシンボルグループをなしているシンボルの数が３であるという意味であり、サブキャリア間隔が変わらないので、相異なる２つのＣＰ長さをそのまま用いる場合、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は図１９のように設定される。
【０２４６】
図１９は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０２４７】
図１９によれば、ＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）をなすシンボルグループの長さは０．８６６ｍｓとなり、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）をなすシンボルグループの長さは１．０６６ｍｓとなる。
【０２４８】
これは、すなわち、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）を用いても２つの連続したシンボルグループの長さが２．４２８ｍｓ（2 UL SFs+6 symbols for UpPTS）より小さいので、２つのシンボルグループを連続的に送信することができる。
【０２４９】
従って、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、１番目のホッピング（1st hopping）をなしている２つのシンボルグループはＵｐＰＴＳと２つのＵＬ ＳＦｓに連続的に送信するように設定し、２番目のホッピング（2nd hopping）はＵｐＰＴＳと２つの連続的なＵＬ ＳＦｓ間に現れるように設定することができる。
【０２５０】
これを図示すると、図２０のようである。図２０に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソース（frequency resource）としてサブキャリアｎからサブキャリアｎ＋１１までトータル１２個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを示す。
【０２５１】
このような方式で送信する場合、４つのシンボルグループを連続的に送信することに比べてチャネルの変化による性能劣化が発生する可能性があるが、１番目のホッピング（1st hopping）をなしている２つのシンボルグループが連続的に送信されているため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０２５２】
また、サブキャリア間隔（subcarrier spacing）が変化していないため、周波数リソース（frequency resource）が変化しなく、ＣＰ長さ（CP length）も変化していないため、セルカバレッジ（cell coverage）も維持できるという利点がある。
【０２５３】
ただし、既存のプリアンブルに比べてシンボルの数が減少したため、エネルギー（energy）が減少するので、同一の性能を出すために必要な繰り返し数（repetition number）が増加する可能性がある。
【０２５４】
また、ＣＰ長さによるセルカバレッジを維持するために暗示的ガード時間（implicit guard time）をＣＰ長さより長く設定することができる。
【０２５５】
従って、図２０の例において、ＵｐＰＴＳ ６ ｓｙｍｂｏｌを構成（configure）すると、暗示的ガード時間（implicit guard time）（すなわち、２９４．６６μｓ、２４２８−２１３３．３３＝２９４．６６(μｓ)）がＣＰ（すなわち、６６．６６μｓ又は２６６．６６μｓ）長さより長く設定されるので、セルカバレッジを維持することができる。
【０２５６】
図２０は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０２５７】
（実施形態２）
【０２５８】
実施形態２はＭ＝２の場合である。
【０２５９】
Ｍが２である場合、１つのシンボルグループをなすシンボルの数は２つであり、サブキャリア間隔が変化しないので、相異なる２つのＣＰ長さをそのまま用いる場合、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は図２１のように設定される。
【０２６０】
図２１は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０２６１】
図２１に示すように、ＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）をなすシンボルグループの長さは０．６ｍｓとなり、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）をなすシンボルグループの長さは０．８ｍｓとなる。
【０２６２】
これは、すなわち、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）を用いても２つの連続したシンボルグループの長さが２ｍｓより小さいので、２つのシンボルグループ連続的に送信することができる。
【０２６３】
従って、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、１番目のホッピング（1st hopping）をなしている２つのシンボルグループは２つのＵＬ ＳＦに連続的に送信するように設定し、２番目のホッピング（2nd hopping）は２つの連続的なＵＬ ＳＦの間で現れるように送信するように設定することができる。
【０２６４】
これを図示すると、図２２のようである。
【０２６５】
図２２は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０２６６】
図２２に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソース（frequency resource）としてサブキャリアｎからサブキャリアｎ＋１１までトータル１２個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０２６７】
このような方式で送信する場合、４つのシンボルグループ（symbol group）を連続的に送信することに比べてシャネル（channel）の変化による性能劣化が発生し得るが、１番目のホッピング（1st hopping）をなしている２つのシンボルグループが連続的に送信されているため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０２６８】
また、サブキャリア間隔が変換していないため、周波数リソースが変化せず、ＣＰ長さも変化していないため、セルカバレッジも維持できるという利点がある。
【０２６９】
ただし、既存のＰＲＡＣＨプリアンブルに比べて対応シンボルの数が減少したため、エネルギー（energy）が減少するので、同じ性能を出すために必要な繰り返し数（repetition number）が増加する可能性がある。また、本実施形態は、前述したＭ＝３の例示に比べてＵｐＰＴＳを追加に構成（configure）しなくてもセルカバレッジを維持できるという利点がある。
【０２７０】
（方法３）
【０２７１】
方法３は、ＮＰＲＡＣＨプリアンブル（preamble）のシンボルグループ（symbol group）をなしているシンボル数をＭ個に変更し、ＣＰ長さ（length）も変更する方法である。
【０２７２】
ここで、ＭはＭ＜５の自然数である。
【０２７３】
方法３の場合、サブキャリア間隔及びシンボル区間（symbol duration）は変更されない。
【０２７４】
すなわち、方法３は、ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を既存の５つから５つより小さいＭ個に変更し、ＣＰ長さまで変更する方法である。
【０２７５】
以下、例を挙げて具体的に説明する。
【０２７６】
（実施形態１）
【０２７７】
実施形態１は、Ｍ＝３の場合である。
【０２７８】
Ｍが３である場合、１つのシンボルグループをなすシンボルの数は３であり、（サブキャリア間隔が変化しないため）ＣＰ長さ値を６６．６６μｓ、１３３．３３μｓ、２００μｓとして用いることを考慮すると、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）、 ＰＲＡＣＨプリアンブルフォーマット２（ＰＲＡＣＨプリアンブルフォーマット２（PRACH preamble format 2））は、図２３のように設定される。
【０２７９】
図２３は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０２８０】
ここで、ＦＤＤの特性のように相異なるＣＰ長さは２つのみを用いる場合、ＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）はデフォルト（default）として用い、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）とＰＲＡＣＨプリアンブルフォーマット２（PRACH preamble format 2）のうち１つのみを使用すると設定することができる。
【０２８１】
図２３に示すように、ＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）をなすシンボルグループの長さは０．８６６ｍｓとなり、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）をなすシンボルグループの長さは０．９３３ｍｓとなり、ＰＲＡＣＨプリアンブルフォーマット２（PRACH preamble format 2）をなすシンボルグループの長さは１ｍｓとなる。
【０２８２】
これは、すなわち、ＰＲＡＣＨプリアンブルフォーマット２（PRACH preamble format 2）を使用しても２つの連続したシンボルグループの長さが２．２１４ｍｓ（2 UL SFs+3 symbols for UpPTS）より小さいので、２つのシンボルグループを連続的に送信することができる。
【０２８３】
従って、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、１番目のホッピング（1st hopping）をなしている２つのシンボルグループはＵｐＰＴＳと２つのＵＬ ＳＦｓに連続的に送信するように設定し、２番目のホッピング（2nd  hopping）はＵｐＰＴＳと２つの連続的なＵＬ ＳＦ間で現れるように送信するように設定することができる。
【０２８４】
これを図示すると、図２４のようである。
【０２８５】
図２４は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０２８６】
図２４に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソース（frequency resource）にサブキャリアｎからサブキャリアｎ＋１１までトータル１２個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０２８７】
図２４の方法でＰＲＡＣＨプリアンブルを送信する場合、４つのシンボルグループを連続的に送信することに比べてチャネルの変化による性能劣化が発生する可能性がある。
【０２８８】
１番目のホッピング（1st hopping）をなしている２つのシンボルグループが連続的に送信されているため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０２８９】
また、サブキャリア間隔（subcarrier spacing）が変化していないため、周波数リソース（frequency resource）が変化せず、ＣＰ長さも変化していないため、セルカバレッジも維持できるという利点がある。
【０２９０】
ただし、既存のＰＲＡＣＨプリアンブルに比べてシンボルの数が減少しため、エネルギー（energy）が減少するので、同じ性能を出すために必要な繰り返し数が増加する可能性がある。
【０２９１】
また、ＣＰ長さによるセルカバレッジを維持するために暗示的ガード時間（implicit guard time）をＣＰ長さより長く設定することができる。
【０２９２】
従って、図２４の例においては、ＵｐＰＴＳ ３ ｓｙｍｂｏｌを構成（configure）すると、暗示的ガード時間（implicit guard time）（例えば、２１４μｓ、２２１４−２０００＝２１４(μｓ)）がＣＰ（例えば、６６．６６μｓ又は１３３．３３μｓ又は２００μｓ）長さより長く設定されるため、セルカバレッジを維持することができる。
【０２９３】
（方法４）
【０２９４】
方法４は、方法１及び方法２の組み合わせであって、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔を既存に比べてＮ倍増加（例えば、シンボル区間（symbol duration）及びＣＰ長さ（CP length）は既存に比べて１／Ｎ倍減少）させ、ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数をＭ個に変更する方法である。
【０２９５】
ここで、ＭはＭ＜５の自然数である。
【０２９６】
すなわち、方法４は、前述した方法１のＮＰＲＡＣＨプリアンブルのサブキャリア間隔をレガシーＮＰＲＡＣＨプリアンブルのサブキャリア間隔値に比べてＮ倍増加させる方法と、方法２のＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を既存の５つから５つより小さいＭ個に変更する方法とを組み合わせる方法であり得る。
【０２９７】
ここで、シンボル長さ（symbol length）は１／Ｎ倍に減少し、考慮するＣＰ長さ（CP length）も１／Ｎ倍に減少すると設定することができる。
【０２９８】
ここで、Ｎは正の整数であり、Ｍは５より小さい自然数である。
【０２９９】
以下、例を挙げて具体的に説明する。
【０３００】
（実施形態１）
【０３０１】
実施形態１はＮ＝２で、Ｍ＝４の場合である。
【０３０２】
Ｎ値が２である場合、新しいＮＰＲＡＣＨプリアンブルのサブキャリア間隔は３．７５ｋＨｚの２倍である７．５ kHzとなる。それと同時に、シンボル区間（symbol duration）は２６６．６６μｓから１３３．３３μｓに１／２倍に減少する。また、ＣＰ長さも１／２倍に減少する。
【０３０３】
追加的に、Ｍが４である場合、１つのシンボルグループをなすシンボルの数が４つであるという意味であるので、この場合も２つの相異なる長さのＣＰをサポートすると、新しいＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）と新しいＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）は図２５のように設定される。
【０３０４】
図２５は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０３０５】
図２５に示すように、ＰＲＡＣＨプリアンブルフォーマット０（PRACH preamble format 0）をなすシンボルグループの長さは０．５６６ｍｓとなり、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）をなすシンボルグループの長さは０．６６６ｍｓとなる。
【０３０６】
すなわち、ＰＲＡＣＨプリアンブルフォーマット１（PRACH preamble format 1）を使用しても２つの連続したシンボルグループの長さが２ｍｓより小さいので、２つのシンボルグループを連続的に送信することができる。
【０３０７】
従って、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、１番目のホッピング（1st hopping）をなしている２つのシンボルグループは２つのＵＬ ＳＦに連続的に送信するように設定し、２番目のホッピング（2nd hopping）は２つの連続的なＵＬ ＳＦの間で現れるように送信するように設定することができる。
【０３０８】
これを図示すると、図２６のようである。
【０３０９】
図２６は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０３１０】
図２６に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリアｎからサブキャリアｎ＋ｋ−１までトータルｋ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０３１１】
このような方式で送信する場合、４つのシンボルグループを連続的に送信することに比べてチャネルの変化による性能劣化が発生する可能性があるが、１番目のホッピング（1st hopping）をなしている２つのシンボルグループが連続的に送信されているため、基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０３１２】
また、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔が増加したため、周波数リソースが既存に比べて減少するという欠点がある。
【０３１３】
すなわち、既存に３．７５ｋＨｚのサブキャリア間隔である場合、４８個の周波数リソースを使用可能であったが、７．５ｋＨｚサブキャリア間隔である場合、２４個の周波数リソースを使用できる。
【０３１４】
また、ＣＰ長さが短くなるにつれて該当セルがサービングできるセルカバレッジが短くなるという欠点がある。さらに、既存のプリアンブルに比べてシンボル数が減少したため、エネルギーが減少するので、同じ性能を出すために必要な繰り返し数が増加する可能性がある。
【０３１５】
（実施形態２）
【０３１６】
実施形態２はＮ＝２、Ｍ＝３の場合である。
【０３１７】
Ｎ値が２である場合、新しいＮＰＲＡＣＨプリアンブルのサブキャリア間隔は３．７５ｋＨｚの２倍である７．５ｋＨｚとなる。
【０３１８】
それと同時に、シンボル区間（symbol duration）は２６６．６６μｓから１３３．３３μｓに１／２倍に減少する。また、ＣＰ長さも１／２倍に減少する。
【０３１９】
追加的に、Ｍが３である場合、１つのシンボルグループをなすシンボルの数が３つであるので、この場合も２つの相異なる長さのＣＰをサポートすると、新しいｆｏｒｍａｔ ０と新しいｆｏｒｍａｔ １は図２７のように設定される。
【０３２０】
図２７は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０３２１】
図２７に示すように、ｆｏｒｍａｔ ０をなすシンボルグループの長さは０．４３３ｍｓとなり、ｆｏｒｍａｔ １をなすシンボルグループの長さは０．５３３ｍｓとなる。
【０３２２】
これは、すなわち、ｆｏｒｍａｔ １を使用しても４つの連続したシンボルグループの長さが２．２８５３３ｍｓ（2 UL SF+4 symbols for UpPTS）より小さいので、４つのシンボルグループを連続的に送信することができる。
【０３２３】
従って、この場合は、各端末がＮＰＲＡＣＨプリアンブルを送信するとき、既存の方法と類似して１番目のホッピング（1st hopping）と２番目のホッピング（2nd hopping）をなしている４つのシンボルグループは、ＵｐＰＴＳと２つのＵＬ ＳＦｓに連続的に送信するように設定することができる。
【０３２４】
これを図示すると、図２８のようである。
【０３２５】
図２８は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０３２６】
図２８に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリアｎからサブキャリアｎ＋ｋ−１までトータルｋ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０３２７】
このような方式で送信すると、４つのシンボルグループを連続的に送信するために基地局端において端末別のＴＡ推定（estimation）は大きな問題なく行われる。
【０３２８】
また、ＮＰＲＡＣＨプリアンブルのサブキャリア間隔が増加したため、周波数リソースが既存に比べて減少するという欠点がある。すなわち、既存に３．７５ｋＨｚのサブキャリア間隔である場合、４８個の周波数リソースを使用可能であったが、７．５ｋＨｚサブキャリア間隔である場合、２４個の周波数リソースを使用できる。
【０３２９】
また、ＣＰ長さが短くなるにつれて該当セルがサービングできるセルカバレッジが短くなるという欠点がある。さらに、既存のプリアンブルに比べてシンボル数が減少したため、エネルギーが減少するので、同じ性能を出すために必要な繰り返し数が増加する可能性がある。
【０３３０】
さらに、ＣＰ長さによるセルカバレッジを維持するために暗示的ガード時間（implicit guard time）をＣＰ長さより長く設定することができる。
【０３３１】
従って、該当例においては、ＵｐＰＴＳ ４ ｓｙｍｂｏｌを構成（configure）すると、暗示的ガード時間（implicit guard time）（例えば、１５２μｓ、２２８５．３３−２１３３．３３＝１５２(μｓ)）がＣＰ（例えば、６６．６６μｓ又は１３３．３３μｓ）より長く設定されるので、セルカバレッジを維持することができる。
【０３３２】
（方法５）
【０３３３】
方法５は、ＴＤＤ ＮＢ−ＩｏＴシステムに対するマルチトーン（Multi tone）ＮＰＲＡＣＨ送信に関する。
【０３３４】
前述した方法１ないし方法４は、ＰＲＡＣＨ送信に単一トーン（single tone）を考慮したが、ＴＤＤ ＮＰＲＡＣＨでは前述に提案した方法（方法１ないし方法４）をマルチトーンで送信するように設定することもできる。
【０３３５】
ここで、マルチトーンは連続的（contiguous）である場合もあり、非連続的（non-contiguous）である場合もある。
【０３３６】
追加的に、マルチトーン構成は連続的と非連続的が共存する形態である場合もある。以下、例を挙げてより具体的に説明する。
【０３３７】
（実施形態１）
【０３３８】
実施形態１は、非連続的（non-contiguous）デュアルトーン（dual tone）送信に関する。
【０３３９】
デュアルトーン（dual tone）が非連続的に送信される場合を考慮すると、次の通りである。
【０３４０】
１番目のトーンが送信される開始サブキャリアリソース（starting subcarrier resource）はＳＩ（System Information）で構成（configure）された領域のうち１つを選択するように設定することができ、２番目のトーンは、予め約束した、又はＳＩで構成（configure）された一定の周波数間隔（例えば、６サブキャリア間隔）の分だけ１番目のトーンから離れて送信すると設定することができる。
【０３４１】
すなわち、レガシーＮＰＲＡＣＨの１番目のホッピング（1st hopping）はそのまま維持され、２番目のホッピング（2nd hopping）がデュアルトーン（dual tone）で現れると考えられる。
【０３４２】
この場合、繰り返しの単位も２つの連続したシンボルグループのデュアルトーンに設定することができ、疑似ランダムホッピング（Pseudo random hopping）により１番目のトーンが移るトーンを決定し、２番目のトーンは１番目のトーンと前述したように一定の周波数間隔の分だけで離れて送信すると設定することができる。
【０３４３】
もし、構成（configure）された周波数リソース領域を越える場合は、周波数リソース領域内にラップアラウンド（wrap-around）すると設定することができる。
【０３４４】
前述した方法２の実施形態２の場合（ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を２つに変更する方法）、非連続的デュアルトーン（non-contiguous dual tone）送信について例を挙げると、図２９のようである。
【０３４５】
図２９は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０３４６】
図２９に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソースにサブキャリアｎからサブキャリアｎ＋１１までトータル１２個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０３４７】
この方法を用いてＮＰＲＡＣＨプリアンブルを送信すると、ＰＡＰＲ側面及びリソース割り当て（resource allocation）側面で欠点はあるが、単一トーンのみで不足したシンボルをデュアルトーンで追加送信することによりプリアンブル受信（preamble reception）に対する性能向上が期待される。
【０３４８】
また、単一繰り返し（single repetition）の長さが減少して遅延減少（latency reduction）の効果も得られる。
【０３４９】
（実施形態２）
【０３５０】
実施形態２は連続した３つのトーン（contiguous triple tone）送信に関する。
【０３５１】
３つのトーン（Triple tone）が連続的に送信される場合を考慮すると、次の通りである。
【０３５２】
１番目のトーンが送信される開始サブキャリアリソース（starting subcarrier resource）は、ＳＩで構成（configure）された領域のうち１つを選択するように設定することができ、２番目のトーンと３番目のトーンは１番目のトーンから１トーンずつ増加して連続的に送信すると設定することができる。
【０３５３】
もし、構成（configure）された周波数リソース領域を越える場合は周波数リソース領域内にラップアラウンド（wrap-around）すると設定することができる。
【０３５４】
連続的なマルチトーン（Contiguous multi-tone）の場合、１番目のホッピング（1st hopping）をなしている２つのシンボルグループのマルチトーンプリアンブル（multi-tone preamble）は２つのＵＬ ＳＦに連続的に送信するように設定し、２番目のホッピング（2nd hopping）は２つの連続的なＵＬ ＳＦの間で現れるように送信するように設定することができる。
【０３５５】
前述した方法２の実施形態２の場合（ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を２つに変更する方法）に対する連続的なマルチトーン（contiguous multi-tone）方式を図示すると、図３０のようである。
【０３５６】
図３０は、本明細書で提案するＮＰＲＡＣＨプリアンブルシンボルグループに対するホッピングパターンのまた他の一例を示す図である。
【０３５７】
図３０に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリアｎからサブキャリアｎ＋１１までトータル１２個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０３５８】
この方法を用いて送信すると、ＰＡＰＲ側面及びリソース割り当て（resource allocation）側面で欠点はあるが、単一トーン（single tone）のみで不足したシンボルをマルチトーン（multi-tone）で追加に送信することによりプリアンブル受信（preamble reception）に対する性能向上が期待される。
【０３５９】
追加的に、マルチトーンＮＰＲＡＣＨプリアンブルが定義される場合、マルチトーンＮＲＰＡＣＨプリアンブルを送信できる端末の動作がより明確に定義される必要がある。
【０３６０】
現在、Ｒｅｌ．１４ ＮＢ−ＩｏＴシステムに既にｍｅｓｓａｇｅ３（ｍｓｇ．３、ＵＥ→ｅＮＢに送信）においてマルチトーン送信をサポートしており、マルチトーン送信が可能な端末は前記ｍｓｇ．３をマルチトーンで送信できると予め約束されているＮＰＲＡＣＨプリアンブルリソースを選択して単一トーンプリアンブル（single tone preamble）を送信している。
【０３６１】
もし、Ｒｅｌ．１５ ＮＢ−ＩｏＴにマルチトーンプリアンブル（multi-tone preamble）送信をサポートする場合、基地局では後方互換性（backward compatibility）のために、（Ａ）ｍｓｇ．３を単一トーンで送信できると予め約束されているＮＰＲＡＣＨプリアンブルリソース 、（Ｂ）ｍｓｇ．３をマルチトーンで送信できると予め約束されているＮＰＲＡＣＨプリアンブルリソース、さらに、（Ｃ）ｍｓｇ．３をマルチトーンで送信できると予め約束されているマルチトーンＮＰＲＡＣＨプリアンブルリソースまで構成（configure）すると設定することができる。
【０３６２】
従って、このような場合、マルチトーン送信が可能であり、リソース（Ｃ）に構成（configuration）された繰り返し数の閾値（threshold）を満足する端末は、リソース（Ｃ）においてＮＰＲＡＣＨプリアンブル送信を開始すると設定することができる。
【０３６３】
もし、端末が基地局からＲＡＲ（Radom Access Response）やｍｓｇ．４を受信していない場合、次の繰り返し数に該当するリソース（Ｃ）に移動してＮＰＲＡＣＨプリアンブルを送信すると設定することができる。
【０３６４】
ただし、次の繰り返し数に該当するリソース（Ｃ）がない場合、リソース（Ｂ）に移してＮＰＲＡＣＨプリアンブルを送信すると設定することができる。
【０３６５】
もし、リソース（Ｂ）がないか、リソース（Ｂ）の繰り返し数の閾値（threshold）が満足されない場合、リソース（Ａ）においてＮＰＲＡＣＨプリアンブルを送信すると設定することができる。
【０３６６】
その後の動作は、既存のＲｅｌ．１３のＲＡＣＨ動作と同一である。
【０３６７】
また、リソース（Ｃ）を用いる端末は、ｍｓｇ．３においてマルチトーン送信が可能であることは明白である。
【０３６８】
追加的に、 コンテンションフリー（contention free：ＣＦ）ＮＰＲＡＣＨ送信のように予め確保されているリソースを用いてプリアンブルを送信できる場合、該当リソースが利用できる全てのマルチトーンを連続的に送信することを考慮するこができる。
【０３６９】
例えば、ＮＰＤＣＣＨオーター（order）によりコンテンションフリー（contention free）ＮＰＲＡＣＨ送信をする端末に予め確保されているＮＰＲＡＣＨリソースがＫ サブキャリアであるとすると、端末は、連続したＫ個のマルチトーンを用いて１つのＵＬ ＳＦに送信すると設定することができる。
【０３７０】
特徴的に、Ｋ値は１２、２４、３６、４８などであり得る。
【０３７１】
このような送信を図示すると、図３１のようである。
【０３７２】
図３１は、本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信の一例を示す図である。
【０３７３】
ここで、Ｋトーン（K tone）に用いられたＮＰＲＡＣＨプリアンブルは長さＫ（length K）の特定シーケンス（sequence）形態を有することができる。
【０３７４】
例えば、長さＫであるＺＣシーケンスなどのＰＡＰＲ性能のよいシーケンスが選択されることができる。
【０３７５】
追加的に、特定シーケンスに他のスクランブリングシーケンス（scrambling sequence）が要素ごと（element wise）に乗じられて相異なるシーケンスを示すと設定することができる。
【０３７６】
特徴的に、スクランブリングシーケンス（scrambling sequence）はＰＮシーケンスなどのシーケンスが選択される。この方法を用いると、 コンテンションフリー（contention free）送信であるので、予め確保されているリソースを全て用いて既存に比べてより少ない繰り返し数を用いてアップリンク同期（uplink sync）を合わせることができるという利点がある。
【０３７７】
（実施形態３）
【０３７８】
実施形態３は、連続的及び非連続的（contiguous and non-contiguous）な３つのトーンを用いたＮＰＲＡＣＨ送信に関する。
【０３７９】
３つのトーン（Triple tone）の連続と非連続が共存する形態で送信される場合を考慮すると、次のようである。１番目のトーンが送信される開始サブキャリアリソース（starting subcarrier resource）は、ＳＩで構成（configure）された領域のうち１つを選択するように設定することができ、２番目のトーンは、１番目のトーンから１トーン増加して連続的に送信すると設定し、３番目のトーンは、２番目のトーンから予め約束した、又はＳＩで構成（configure）された一定の周波数間隔（例えば、６サブキャリア間隔）の分だけ離れて送信すると設定することができる。
【０３８０】
もし、構成（configure）された周波数リソース領域を越える場合は周波数リソース領域内にラップアラウンド（wrap-around）すると設定することができる。
【０３８１】
連続的／非連続的マルチトーン（Contiguous/non-contiguous multi-tone）の場合、１番目のホッピング（1st hopping）と２番目のホッピング（2nd hopping）をなしているシンボルグループのマルチトーンプリアンブル（multi-tone preamble）は１つのＵＬ ＳＦに送信するように設定することができる。
【０３８２】
方法２の実施形態２の場合（ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を２つに変更する方法）に対する連続的／非連続的マルチトーン（Contiguous/non-contiguous multi-tone）方式を図示すると、図３２のようである。
【０３８３】
図３２は、本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０３８４】
図３２に示すように、ＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリアｎからサブキャリアｎ＋１１までトータル１２個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃２の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０３８５】
この方法を用いてＮＰＲＡＣＨプリアンブルを送信する場合、ＰＡＰＲ側面及びリソース割り当て（resource allocation）側面で欠点はあるが、単一トーン（single tone）のみで不足したＮＰＲＡＣＨシンボルをマルチトーン（multi-tone）で追加に送信することによりプリアンブル受信（preamble reception）に対する性能向上が期待される。
【０３８６】
（実施形態４）
【０３８７】
実施形態４は、マルチトーンＮＰＲＡＣＨプリアンブル送信に対する相異なるヌメロロジー（numerology）に関する。
【０３８８】
追加的に、マルチトーンがそれぞれ連続的、不連続的に送信される場合を考慮すると、次のようである。
【０３８９】
最初連続的にマルチトーン（例えば、デュアルトーン）を送信するタイミングでは、相対的に小さいサブキャリア間隔（subcarrier spacing）（すなわち、ＳＣＳ）を用いて送信するが、１番目のトーンが送信される開始サブキャリアリソース（starting subcarrier resource）はＳＩで構成（configure）された領域のうち１つを選択するように設定することができ、２番目のトーンは１番目のトーンから１つのトーン（１つのトーン基準はＳＣＳに設定）増加して連続的に送信すると設定することができる。
【０３９０】
次に、マルチトーンを（例えば、デュアルトーン）送信するタイミングでは、相対的に大きいサブキャリア間隔（すなわち、ＳＣＬ）を用いて送信するが、１番目のトーンが送信される開始サブキャリアリソース（starting subcarrier resource）はＳＩで構成（configure）された領域のうち１つを選択するように設定することができ、２番目のトーンは１番目のトーンから１つのトーン（１つのトーン基準はＳＣＬに設定）増加して連続的に送信すると設定することができる。
【０３９１】
特徴的に、ＳＣＬはＳＣＳのＭ倍となり、例えば、ＳＣＳは３．７５ｋＨｚとなり、ＳＣＬはＳＣＳの６倍である２２．５ｋＨｚとなり得る。また、ＳＣＬを用いて送信するときは、フラクショナルオフセット（fractional offset）を適用して送信すると設定することができる。
【０３９２】
ここで、フラクショナルオフセット（fractional offset）は、Ｍ＝（ＳＣＬ／ＳＣＳ）個のうち１つを選択することができ、Ｍ個は、Ｍが偶数の場合は、次の｛−（０．５＋（Ｍ／２−１））＊ＳＣＳ, −（０．５＋（Ｍ／２−２））＊ＳＣＳ, …, −（０．５＋２）＊ＳＣＳ, −（０．５＋１）＊ＳＣＳ、−（０．５＋０）＊ＳＣＳ, ＋（０．５＋０）＊ＳＣＳ, ＋（０．５＋１）＊ＳＣＳ, ＋（０．５＋２）＊ＳＣＳ, …, ＋（０．５＋（Ｍ／２−２））＊ＳＣＳ, ＋（０．５＋（Ｍ／２−１））＊ＳＣＳ｝に決定される。
【０３９３】
また、Ｍが奇数の場合は、また、Ｍが奇数の場合は、｛−（floor（Ｍ／２）＊ＳＣＳ, −（floor（Ｍ／２）−１）＊ＳＣＳ, −（floor（Ｍ／２）−２）＊ＳＣＳ, …, −２＊ＳＣＳ, −ＳＣＳ, ０, ＋ＳＣＳ, ＋２＊ＳＣＳ, …, ＋（floor（Ｍ／２）−２）＊ＳＣＳ, ＋（floor（Ｍ／２）−１）＊ＳＣＳ, ＋（floor（Ｍ／２））＊ＳＣＳ）に決定される。
【０３９４】
具体的な例を挙げて説明すると、ＳＣＳは３．７５ｋＨｚであり、ＳＣＬは２２．５ｋＨｚであるとすると、２２．５ｋＨｚサブキャリア間隔に３．７５ｋＨｚサブキャリア間隔が６回入ることができるので、Ｍは６となり、２２．５ｋＨｚサブキャリア中心から｛−９．３７５ｋＨｚ, −５．６２５ｋＨｚ, −１．８７５ｋＨｚ, ＋１．８７５ｋＨｚ, ＋５．６２５ｋＨｚ, ＋９．３７５ｋＨｚ｝のうち１つの値を選択してフラクショナルオフセット（fractional offset）と決定してサブキャリアの中心からフラクショナルオフセット（fractional offset）の分だけ移動して送信すると設定することができる。
【０３９５】
ここで、フラクショナルオフセット（fractional offset）選択は、ＳＣＳを用いてマルチトーンを送信するとき、１番目のトーンが送信される開始サブキャリアリソース（starting subcarrier resource）と同一の位置となるように選択すると設定することができる。このような送信方式を図示すると、図３３のようである。
【０３９６】
図３３は、本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０３９７】
さらに、相異なるヌメロロジー（different numerology）を用いた場合に該当するシンボルグループを図示すると、図３４のようである。
【０３９８】
図３４は、本明細書で提案するＮＰＲＡＣＨプリアンブルフォーマットのまた他の一例を示す図である。
【０３９９】
図３４に示すように、３．７５ｋＨｚのサブキャリア間隔（3.75 kHz subcarrier spacing）を用いるとき、シンボルグループをなすシンボルは２つであり、１つのＣＰが入る。
【０４００】
また、各フォーマット別にプリアンブルの総長さを合わせるために、２２．５ｋＨｚのサブキャリア間隔（22.5 kHz subcarrier spacing）を用いるとき、シンボルグループをなすシンボル数はＭ倍が大きい１２個となり、前のプリアンブルに用いられた同一の長さのＣＰが入る。
【０４０１】
特徴的に、該当ＣＰは複数のシンボルからなると設定することができる。
【０４０２】
（方法６）
【０４０３】
方法６は、ＴＤＤ ＮＢ−ＩｏＴシステムに対するショート（short）ＮＰＲＡＣＨプリアンブル送信に関する。
【０４０４】
さらに、レガシーＬＴＥのＴＤＤにおいてＮＰＲＡＣＨショートフォーマット（short format）を実現したことと類似した理由で、ＮＢ−ＩｏＴのＴＤＤにおいてもＮＰＲＡＣＨショートフォーマットを考慮すると、次のようである。
【０４０５】
ＮＰＲＡＣＨショートフォーマットはカバレッジ（coverage）が非常に小さいＴＤＤセルのために考慮することができ、ＵｐＰＴＳをなすシンボル（すなわち、ＳＩＢを介して構成（configure）されたＵｐＰＴＳシンボル数）内に、又は１つのＵＬサブフレーム内に送信されると設定することができる。ここで、該当プリアンブルは、単一トーン（single-tone）で送信されるか、マルチトーン（multi-tone）で送信される。以下、実施形態により具体的に説明する。
【０４０６】
（実施形態１）
【０４０７】
例えば、ＵｐＰＴＳ ３ ｓｙｍｂｏｌｓ内に送信できるＮＰＲＡＣＨフォーマットを考慮すると、図３５のように１５ｋＨｚのサブキャリア間隔 （15 kHz subcarrier spacing）を有し、６６．６６μｓのシンボル２つと３３．３３μｓのＣＰからなると設定することができる。
【０４０８】
図３５は、本明細書で提案するショートＮＰＲＡＣＨプリアンブルフォーマットの一例を示す図である。
【０４０９】
この場合も、前述した方法と類似して、ＣＰ長さによるセルカバレッジ（cell coverage）を維持するために暗示的ガード時間（implicit guard time）をＣＰ長さより長く設定することができる。
【０４１０】
すなわち、シンボルグループとＣＰの長さの合計が１６６．６５μｓ（すなわち、６６．６６×２＋３３．３３(μｓ)）となり、ＵｐＰＴＳ ３ ｓｙｍｂｏｌｓの長さは２１４μｓ（すなわち、７１．３３×３(μｓ)）となるため、暗示的ガード時間（implicit guard time）が４７．３３μｓとなり、ＣＰ長さによるセルカバレッジは維持されるといえる。
【０４１１】
もし、前記ショートＮＰＲＡＣＨプリアンブル（short NPRACH preamble）がマルチトーン（例えば、デュアルトーン）で送信され、連続的／不連続的デュアルトーン（continuous/discontinuous dual tone）方式であると仮定すると、図３６のように示すことができる。
【０４１２】
図３６は、本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０４１３】
図３６に示すように、ショートＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリアｎからサブキャリアｎ＋ｋ−１までトータルｋ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０４１４】
１番目の周波数ギャップ（1st frequency gap）は、連続的デュアルトーン（continuous dual tone）方式でサブキャリア間隔（subcarrier spacing）の分だけの周波数ギャップを有し、２番目の周波数ギャップ（2nd frequency gap）は不連続的デュアルトーン（discontinuous dual tone）方式で６＊サブキャリア間隔の分だけの周波数ギャップを有する。
【０４１５】
この方法を用いて送信すると、ＰＡＰＲ側面で欠点はあるが、該当基地局が管轄するセルカバレッジが小さい所に含まれる端末や、基地局から近くにある端末のアップリンク同期（uplink synchronization）に対する遅延（latency）を減らすことができるという利点がある。
【０４１６】
また、このように短い長さを有するプリアンブルを基地局から近くにある端末がスペシャルサブフレーム（special subframe）に利用できるように設定することにより、連続したＵＬサブフレームを他の端末のＮＰＲＡＣＨプリアンブル送信のために割り当て（allocation）できるという面で利点がある。
【０４１７】
（実施形態２）
【０４１８】
追加的に、前述した図３５のようなショートＮＰＲＡＣＨプリアンブルフォーマット（short NPRACH preamble format）をＵｐＰＴＳ ６ ｓｙｍｂｏｌｓ内に送信することを考慮すると、図３７のようである。
【０４１９】
この場合も、前述した方法と類似して、ＣＰ長さによるセルカバレッジを維持するために暗示的ガード時間（implicit guard time）をＣＰ長さより長く設定することができる。
【０４２０】
すなわち、シンボルグループ及びＣＰの長さの合計が１６６．６６μｓ（すなわち、６６．６６×２＋３３．３３(μｓ)）であり、２つのシンボルグループ及びＣＰが連続的に送信されるとすると、３３３．３３ｕｓとなり、ＵｐＰＴＳ ６ ｓｙｍｂｏｌｓの長さは４２８μｓ（すなわち、７１．３３×６(μｓ)）となるため、暗示的ガード時間（implicit guard time）が９４．６６μｓとなり、ＣＰ長さによるセルカバレッジは維持されるといえる。
【０４２１】
図３７に示すように、ショートＮＰＲＡＣＨプリアンブルのための周波数リソースとしてサブキャリアｎからサブキャリアｎ＋ｋ−１までトータルｋ個のサブキャリアが割り当てられ、レガシーＬＴＥ ＴＤＤのＵＬ／ＤＬ構成（UL/DL configuration）＃１の状況に応じてＮＰＲＡＣＨプリアンブルをどのように送信するかを表現している。
【０４２２】
図３７は、本明細書で提案するマルチトーンＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０４２３】
前述した方法５の実施形態１と類似して、レガシーＮＰＲＡＣＨの１番目のホッピング（1st hopping）はそのまま維持され、２番目のホッピング（2nd hopping）がデュアルトーンで現れると考えられる。
【０４２４】
そうなると、繰り返し（repetition）の単位も２つの連続したシンボルグループのデュアルトーンに設定することができ、疑似ランダムホッピング（Pseudo random hopping）により１番目のトーンが移るトーンを決定し、２番目のトーンは１番目のトーンと前述したような一定の周波数間隔の分だけ離れて送信すると設定することができ、もし、構成（configure）された周波数リソース領域を越える場合は、周波数リソース領域内にラップアラウンド（wrap-around）すると設定することができる。
【０４２５】
この方法を用いてＮＰＲＡＣＨプリアンブルを送信すると、ＰＡＰＲ側面で欠点はあるが、該当基地局が管轄するセルカバレッジが小さい所に含まれる端末や、基地局から近くにある端末のアップリンク同期（uplink synchronization）に対する遅延（latency）を大幅に減らすことができるという利点がある。
【０４２６】
また、このように短い長さのプリアンブルを基地局から近くにある端末がスペシャルサブフレーム（special subframe）に利用できるように設定することにより、連続したＵＬサブフレームを他の端末のＮＰＲＡＣＨプリアンブル送信のために割り当て（allocation）できるという面で利点がある。
【０４２７】
この実施形態は、非連続（non-contiguous）を例に挙げているが、これと類似した概念を連続的マルチトーンＮＰＲＡＣＨプリアンブル（contiguous multi-tone NPRACH preamble）送信にも適用できることは言うまでもない。
【０４２８】
（方法７）
【０４２９】
方法７は、ＴＤＤ ＮＢ−ＩｏＴシステムにおいてＦＤＤ ＮＰＲＡＣＨプリアンブルフォーマット（FDD NPRACH preamble format）を再使用することである。
【０４３０】
ＦＤＤにおいて用いたＮＰＲＡＣＨプリアンブルの形状は前述した図９のようである。
【０４３１】
ＦＤＤでのＮＰＲＡＣＨプリアンブルをそのまま用いるものの、特定部分（例えば、シンボル境界（symbol boundary））を切って各ＵＬサブフレームに送信することを考慮することができる。
【０４３２】
ここで、ｆｏｒｍａｔ１に該当するプリアンブル（preamble）を用いてＵ／Ｄ構成（configuration）によって（すなわち、連続したＵＬサブフレーム数と組み合わせによって）送信する方法を異なるように設定することができ、これを図示すると、図３８〜図４１のようである。
【０４３３】
すなわち、図３８〜図４１のそれぞれは、本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０４３４】
この方法を用いると、同じトーン（same tone）にさらに多くのエネルギーが送信されているため、プリアンブルに対する検出（detection）が容易になり、ＣＰ長さとサブキャリア間隔などのヌメロロジー（numerology）がＦＤＤプリアンブルと同じであるため、セルカバレッジ側面で利得であり得る。
【０４３５】
しかしながら、単一繰り返し（single repetition）単位が大きくなることによる遅延（latency）問題があるが、固定的な端末が多いＮＢ−ＩｏＴシステム特性上、遅延側面で損害があっても該当方法を用いることが適切であり得る。
【０４３６】
Ｆｏｒｍａｔ０を用いても同じ効果が得られるが、ＣＰ長さが長いＦｏｒｍａｔ１を用いることがこの方法にはさらに好ましいことであり得る
【０４３７】
特徴的に、図４２〜図４５に示すように、Ｘμｓ（例えば、２６６．６６μｓ）ずつ遅延（delay）させて端末が送信するように設定することができる。
【０４３８】
ここで、特徴的に特定時間区間（time duration）（Ｘ）値は、ＮＰＲＡＣＨプリアンブルを構成する各シンボル長さの整数倍となり得る。
【０４３９】
図４２〜図４５のそれぞれは、本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０４４０】
追加的に、連続したＵＬ ＳＦが存在するＵ／Ｄ構成（U/D configuration）でも連続したＵＬ ＳＦが１つである場合に該当する送信形態をそのまま送信する方法も考慮することができる。
【０４４１】
すなわち、図３８を基準に連続したＵＬ ＳＦが２つである場合を図示すると、図４６のよう示すことができる。
【０４４２】
図４６は、本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０４４３】
この方法を用いるときも、特定時間区間（time duration）の分だけ遅延（delay）させて送信することもでき、ここで、Ｘ値はＮＰＲＡＣＨプリアンブルを構成する各シンボル長さの整数倍となり得る。
【０４４４】
さらに、この方法の原理（principle）をＦＤＤ ＮＰＲＡＣＨプリアンブルと異なるサブキャリア間隔, シンボルグループ内に異なるシンボル数、異なるシンボル区間（symbol duration）、異なるＣＰ長さであるときも使用可能であることは言うまでもない。
【０４４５】
（方法８）
【０４４６】
方法８は、ＮＰＲＡＣＨプリアンブル送信関連マルチトーン（Multi tone）と単一トーン（single tone）を結合して送信する方法に関する。
【０４４７】
すなわち、方法８は、前記提案した方法を組み合わせる方法の１つであり、マルチトーン送信（multi-tone transmission）と単一トーン送信（single tone transmission）を繰り返して送信する方法である。
【０４４８】
特徴的に、マルチトーン送信（multi-tone transmission）のときは連続的なマルチトーンを用いることを考慮する。これは、ＰＡＰＲ観点から連続的なトーンを用いることが有利であるためである。
【０４４９】
この方式を用いる場合、単一トーンのみを用いるときに比べて単一繰り返し区間（single repetition duration）が短いため、遅延（latency）側面で利点がある。
【０４５０】
前述した方法２の実施形態２の場合（ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を２つに変更する方法）に対するマルチトーン送信と単一トーン送信の結合（multi-tone+single tone）送信方式に対して図示すると、図４７のようである。
【０４５１】
図４７は、本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０４５２】
追加的に、この方法の原理（principle）をＦＤＤ ＮＰＲＡＣＨプリアンブルと異なるサブキャリア間隔、シンボルグループ内に異なるシンボル数、異なるシンボル区間（symbol duration）、異なるＣＰ長さであるときも使用可能であることは言うまでもない。
【０４５３】
（方法９）
【０４５４】
方法９は、ＮＰＲＡＣＨプリアンブルのコームタイプマルチトーン（Comb type multi-tone）に関し、１つのシンボルグループはＫシンボルを含む。
【０４５５】
すなわち、方法９は、マルチトーンをＫトーン間隔からなるコームタイプ（comb type）に配列してシンボルグループ内にＫ個の同じ形態が繰り返されることを考慮することができる。
【０４５６】
この方法は、同一のサブキャリア間隔を用いるが、異なるヌメロロジー（different numerology）を用いることと類似した様態を示すため、２つのトーン（two tone）以上の周波数ギャップ（frequency gap）があるマルチトーンケース（multi-tone case）において利点がある。
【０４５７】
前述した方法２の実施形態２の場合（ＮＰＲＡＣＨプリアンブルのシンボルグループをなしているシンボル数を２つに変更する方法）に対するコームタイプマルチトーン（comb type multi-tone）方法に関して図示すると、図４８のように示すことができる。
【０４５８】
図４８は、本明細書で提案するＮＰＲＡＣＨプリアンブル送信のまた他の一例を示す図である。
【０４５９】
ここで、シンボルグループの形状を図示すると、図４９のように示すことができる。
【０４６０】
図４９は、図４８によるシンボルグループ形態の一例を示す図である。
【０４６１】
追加的に、前述した方法のうちサブキャリア間隔を変更する方法は、１番目のホッピング（1st hopping）間隔と２番目のホッピング（2nd hopping）間隔も増えたことと考慮している。
【０４６２】
このときに発生する周波数リソース不足現象を克服するために、１番目のホッピング（1st hopping）間隔は変更されても、２番目のホッピング（2nd hopping）間隔は変更されない方法を導入してもよい。
【０４６３】
具体的に説明すると、レガシーＮＰＲＡＣＨプリアンブルのサブキャリア間隔は３．７５ｋＨｚであり、１番目のホッピング（1st hopping）間隔は３．７５ｋＨｚ、２番目のホッピング（2nd hopping）間隔は２２．５ｋＨｚ（６×３．７５ｋＨｚ）となっている。
【０４６４】
ここで、サブキャリア間隔値を７．５ｋＨｚに２倍増やす場合、１番目のホッピング（1st hopping）間隔は７．５ｋＨｚになるとしても、２番目のホッピング（2nd hopping）間隔は２２．５ｋＨｚ（３×７．５ｋＨｚ）に維持すると設定することができる。
【０４６５】
さらに、１番目のホッピング（1st hopping）間隔（又は、１番目の周波数ギャップ（1st frequency gap））が常にサブキャリア間隔と同一である必要はなく、１番目のホッピング（1st hopping）間隔がサブキャリア間隔より小さいいずれの特定部分的サブキャリア間隔（partial subcarrier spacing）の分だけの間隔を有することもあり、又は１番目のホッピング（1st hopping）間隔がサブキャリア間隔より大きいこともある。
【０４６６】
また、２番目のホッピング（2nd hopping）間隔（又は、２番目の周波数ギャップ（2nd frequency gap））も常にサブキャリア間隔の６倍又は２２．５ｋＨｚを維持する必要はなく、該当値より大きくても小さくてもいいことは言うまでもない。
【０４６７】
追加的に、前述した方法に１番目のホッピング（1st hopping）間隔と２番目のホッピング（2nd hopping）間隔を互いに変える方法を考慮することもできる。
【０４６８】
１つの繰り返し（repetition）単位に４つのシンボルグループが含まれており、それぞれをＴ１、Ｔ２、Ｔ３、Ｔ４とすると、図５０に示すように、シンボルグループ間に送信する順序（すなわち、周波数リソース位置）を変える方法を考慮することができる。
【０４６９】
前述に提示した方法のうちＴ２とＴ３がＴＤＤであるため、連続したＵＬ ＳＦが足りなくて、やむを得ず離れて送信される場合が発生する。
【０４７０】
このような方法を用いるとき、連続的に送信するシンボルグループ間に２番目のホッピング（2nd hopping）間隔（例えば、６＊サブキャリア間隔）の差があり得るし、不連続的に送信するシンボルグループ間に１番目のホッピング（1st hopping）間隔（例えば、サブキャリア間隔）の差があり得る。
【０４７１】
１番目のホッピング（1st hopping）に比べて２番目のホッピング（2nd hopping）が正確度（accuracy）に影響を与えるため、連続的に送信する場合、性能側面で有利であり得る。
【０４７２】
図５０は、本明細書で提案するＮＰＲＡＣＨプリアンブルのシンボルグループ間で送信する順序を交換する方法の一例を示す図である。
【０４７３】
図５０において、オプションＡ（option A）は、Ｔ２とＴ３を交換する方法であり、オプションＢ（option B）はＴ１とＴ３を交換する方法であり、オプションＣはＴ１とＴ４を交換する方法である。
【０４７４】
追加的に、レガシーＮＢ−ＩｏＴのように２種類以上のＮＰＲＡＣＨプリアンブルフォーマットを作っておき、基地局においてＣＥレベル別に構成（configure）することができるが、基地局においてＣＥレベルによってＮＰＲＡＣＨプリアンブルのヌメロロジー及びＣＰ長さ、シンボルグループ内のシンボルの数（# of symbols in symbol group）などを独立的に構成（configure）すると設定することができる。
【０４７５】
すなわち、基地局が前述に提示した方法のうち１つずつを端末に各ＣＥレベル別に構成（configure）して端末にとって端末本人のＣＥレベルに合うようにＮＰＲＡＣＨプリアンブルを選択して送信すると設定することができる。
【０４７６】
また、ＣＥレベル別に（又は、ＮＰＲＡＣＨフォーマット別に）基地局において周波数リソースも互いに重ならないように構成（configure）すると設定することができる。
【０４７７】
追加的に、マルチトーン（multi-tone）ＮＰＲＡＣＨプリアンブルを送信できるマルチトーンリソース（multi-tone resource）は他のマルチトーンリソースと１つのトーンも重ならないように定義して基地局においてＮＰＲＡＣＨプリアンブル検出（detection）を行うとき、曖昧さ（ambiguity）がないように設定することができる。
【０４７８】
追加的に、マルチトーンＮＰＲＡＣＨプリアンブルを考慮すると、各トーンに相異なる値をスクランブリング（scrambling）して端末間ＣＤＭ（code division multiplexing）を考慮する必要があり、ここで利用できるシーケンス（sequence）はＵＬ ＤＭＲＳ（Demodulation Reference Signal）と類似した形態で入ると設定することができる。
【０４７９】
また、前記スクランブリングシーケンス（scrambling sequence）はＰＮシーケンスも可能であり得る。
【０４８０】
追加的に、単一トーン（single tone）ＮＰＲＡＣＨプリアンブルを検出（detection）するのに用いた基地局受信機アルゴリズム（receiver algorithm）を再使用する目的で（すなわち、受信機複雑度（receiver complexity）減少側面）、次のような位相事前補償（phase pre-compensation）方法を考慮することができる。
【０４８１】
図５１に示すように、ＮＰＲＡＣＨプリアンブルをマルチトーンで送信するとき、Ｎ番目のシンボルグループにおいてＫ＋１番目のトーンに送信するシンボルグループの位相（phase）は、単一トーンでＮ＋１番目のシンボルグループにおいてＫ＋１番目のトーンに送信しようとした位相と同一になるように事前補償する方法である。
【０４８２】
このようにすると、基地局は、既存に用いた単一トーンＮＰＲＡＣＨプリアンブル検出アルゴリズム（single tone NPRACH preamble detection algorithm）をそのまま用いても問題ないという利点がある。
【０４８３】
図５１は、ＮＰＲＡＣＨプリアンブルのマルチトーン送信に対する位相事前補償方法の一例を示す図である。
【０４８４】
図５２は、本明細書で提案するＮＰＲＡＣＨプリアンブルを送信するための端末の動作を示すフローチャートである。
【０４８５】
具体的には、図５２は、フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を送信する端末の動作を示す図である。
【０４８６】
本明細書において用いるＮＰＲＡＣＨプリアンブルは少なくとも１つのプリアンブルを含み、１つのプリアンブルは、特定区間（duration）に含まれるシンボルグループ（ら）（symbol group(s)）を意味する。
【０４８７】
ここで、前記特定区間は、１つの繰り返し単位（repetition unit）を示す。
【０４８８】
また、前記１つのプリアンブルは、ＮＢ−ＩｏＴ ＴＤＤシステムにおいて４つ又は６つのシンボルグループを含んでもよい。
【０４８９】
まず、前記端末は、アップリンク−ダウンリンク構成（uplink-downlink configuration）に関する制御情報を基地局から受信する（Ｓ５２１０）。
【０４９０】
前記ＵＬ／ＤＬ構成（UL/DL configuration）に関する制御情報は、前記基地局においてサポートされるＵＬ／ＤＬ構成（ら）（UL/DL configuration(s)）に関する情報を含む。
【０４９１】
前記ＵＬ／ＤＬ構成（UL/DL configuration）に関する事項は、表１及び関連説明を参照する。
【０４９２】
その後、前記端末は、前記受信した制御情報と関連したＮＰＲＡＣＨプリアンブル送信に関するパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信する（Ｓ５２２０）。
【０４９３】
ここで、前記ＮＰＲＡＣＨプリアンブルは、１つ又はそれ以上のシンボルグループ（symbol group）を含んでもよい。
【０４９４】
また、１つのシンボルグループは、１つのＣＰ（Cyclic Prefix）と少なくとも１つのシンボルを含んでもよい。
【０４９５】
前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのシンボルグループに含まれるシンボルの数を示す第１パラメータ及び１つのシンボルグループに含まれるＣＰ（cyclic prefix）の長さを示す第２パラメータを含んでもよい。
【０４９６】
前記第１パラメータ及び前記第２パラメータは、前記第１パラメータ及び前記第２パラメータにそれぞれ対応する第３パラメータ及び第４パラメータと異なるように設定される。
【０４９７】
ここで、前記第３パラメータ及び前記第４パラメータは、フレーム構造タイプ（frame structure type）１においてサポートされるＮＰＲＡＣＨプリアンブル送信に関するパラメータを意味する。
【０４９８】
すなわち、前記第３パラメータは、ＦＤＤ（又は、フレーム構造タイプ（frame structure type）１）においてサポートされる１つのシンボルグループに含まれるシンボルの数を示し、前記第４パラメータは、ＦＤＤにおいてサポートされる１つのシンボルグループに含まれるＣＰ（cyclic prefix）の長さを示す。
【０４９９】
また、前記基地局においてサポートされるアップリンク−ダウンリンク構成情報に応じて前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは異なるように設定される。
【０５００】
前記アップリンク−ダウンリンク構成情報は、表１に示すＵＬ／ＤＬ構成（UL/DL configuration）（ｉｎｄｅｘ０〜ｉｎｄｅｘ６）のうち少なくとも１つのＵＬ／ＤＬ構成（UL/DL configuration）を含んでもよい。
【０５０１】
前記第３パラメータ及び前記第４パラメータは、それぞれ前記第１パラメータ及び前記第２パラメータより小さい値を有してもよい。
【０５０２】
特に、前記第３パラメータの値は、５より小さい自然数であり得る。
【０５０３】
前記シンボルグループは、第１周波数ホッピング（frequency hopping）及び第２周波数ホッピング（frequency hopping）により送信されることができる。
【０５０４】
前記第２周波数ホッピングの値は、前記第１周波数ホッピングの値の６倍であり得る。
【０５０５】
例えば、前記第１周波数ホッピングの値は１であり、前記第２周波数ホッピングの値は６であり得る。
【０５０６】
また、前記ＮＰＲＡＣＨプリアンブル送信に関するパラメータは、１つのプリアンブル（preamble）に含まれる連続するシンボルグループ（symbol group）の数を示す第５パラメータ及び１つのプリアンブル（preamble）に含まれるシンボルグループ（symbol group）の全体数を示す第６パラメータをさらに含んでもよい。
【０５０７】
ここで、前記１つのプリアンブルは特定区間に含まれるシンボルグループ（symbol group）を含み、４つ又は６つのシンボルグループを含んでもよい。
【０５０８】
前記特定区間は、繰り返しユニット（repetition unit）、プリアンブル繰り返しユニット（preamble repetition unit）などで表される。
【０５０９】
例えば、前記第５パラメータの値は２であり、前記第６パラメータの値は４であり得る。
【０５１０】
これに関するより具体的な説明は前述した方法３を参照する。
【０５１１】
本発明が適用できる装置一般
【０５１２】
図５３は、本明細書で提案する方法が適用される無線通信装置のブロック構成図を例示する。
【０５１３】
図５３に示すように、無線通信システムは、基地局５３１０と、基地局領域内に位置する複数の端末５３２０とを含む。
【０５１４】
前記基地局と端末は、それぞれ無線装置で表現されることもできる。
【０５１５】
基地局５３１０は、プロセッサ（processor）５３１１、メモリ（memory）５３１２、及びＲＦモジュール（radio frequency module）５３１３を含む。プロセッサ５３１１は、図１〜図５２において提案された機能、過程及び／又は方法を実現する。無線インタフェースプロトコルの階層は、プロセッサにより実現されることができる。メモリ５３１２は、プロセッサに接続されて、プロセッサを駆動するための様々な情報を保存する。ＲＦモジュール５３１３は、プロセッサに接続されて、無線信号を送信及び／又は受信する。
【０５１６】
端末は、プロセッサ５３２１、メモリ５３２２、及びＲＦモジュール５３２３を含む。
【０５１７】
プロセッサは、図１〜図５２において提案された機能、過程及び／又は方法を実現する。無線インタフェースプロトコルの階層は、プロセッサにより実現されることもできる。メモリは、プロセッサに接続されて、プロセッサを駆動するための様々な情報を保存する。ＲＦモジュール５３２３は、プロセッサに接続されて、無線信号を送信及び／又は受信する。
【０５１８】
メモリ５３１２、５３２２は、プロセッサ５３１１、５３２１の内部又は外部に位置し、周知の様々な手段でプロセッサに接続される。
【０５１９】
また、基地局及び／又は端末は、１つのアンテナ（single antenna）又は多重アンテナ（multiple antenna）を有することができる。
【０５２０】
図５４は、本発明の一実施形態によると通信装置のブロック構成図を例示する。
【０５２１】
特に、図５４では、図５３の端末をより詳細に例示する。
【０５２２】
図５４に示すように、端末は、プロセッサ（又は、デジタル信号プロセッサ（ＤＳＰ：digital signal processor）５４１０、ＲＦモジュール（RF module）（又は、ＲＦユニット）５４３５、パワー管理モジュール（power management module）５４０５、アンテナ（antenna）５４４０、バッテリ（battery）５４５５、ディスプレイ（display）５４１５、キーパッド（keypad）５４２０、メモリ（memory）５４３０、ＳＩＭカード（SIM(Subscriber Identification Module) card）５４２５（この構成は選択的である）、スピーカ（speaker）５４４５、及びマイクロホン（microphone）５４５０を含んでもよい。端末は、また、単一のアンテナ又は多重のアンテナを含むことができる。
【０５２３】
プロセッサ５４１０は、図１〜図５２において提案された機能、過程及び／又は方法を実現する。無線インタフェースプロトコルの階層はプロセッサにより実現されることができる。
【０５２４】
メモリ５４３０は、プロセッサに接続され、プロセッサの動作に関する情報を保存する。メモリ５４３０は、プロセッサの内部又は外部に位置し、周知の様々な手段でプロセッサに接続される。
【０５２５】
ユーザは、例えば、キーパッド５４２０のボタンを押すか（又は、タッチするか）、又はマイクロホン５４５０を用いた音声駆動（voice activation）により電話番号などの命令情報を入力する。プロセッサは、このような命令情報を受信し、電話番号で電話をかけるなどの適切な機能を行うように処理する。駆動上のデータ（operational data）はＳＩＭカード５４２５又はメモリ５４３０から抽出することができる。また、プロセッサは、ユーザの認知及び便宜のために命令情報又は駆動情報をディスプレイ５４１５上に表示する。
【０５２６】
ＲＦモジュール５４３５は、プロセッサに接続されて、ＲＦ信号を送信及び／又は受信する。プロセッサは、通信を開始するために、例えば、音声通信データを構成する無線信号を送信するように命令情報をＲＦモジュールに伝達する。ＲＦモジュールは、無線信号を受信及び送信するために受信機（receiver）及び送信機（transmitter）から構成される。アンテナ５４４０は、無線信号を送信及び受信する機能を有する。無線信号を受信するとき、ＲＦモジュールは、プロセッサにより処理するために信号を伝達し、ベースバンドに信号を変換することができる。処理された信号は、スピーカ５４４５を介して出力される可聴又は可読情報に変換されることができる。
【０５２７】
図５５は、本明細書で提案する方法が適用される無線通信装置のＲＦモジュールの一例を示す図である。
【０５２８】
具体的に、図５５は、ＦＤＤ（Frequency Division Duplex）システムにおいて実現できるＲＦモジュールの一例を示す図である。
【０５２９】
まず、送信経路において、図５３及び図５４において記述されたプロセッサは、送信されるデータをプロセシングしてアナログ出力信号を送信機５５１０に提供する。
【０５３０】
送信機５５１０内において、アナログ出力信号は、デジタル−対−アナログ変換（ＡＤＣ）により発生するイメージを除去するためにローパスフィルタ（Low Pass Filter：ＬＰＦ）５５１１によりフィルタリングされ、アップコンバータ（Mixer）５５１２によりベースバンドからＲＦにアップコンバートされ、可変利得増幅器（Variable Gain Amplifier：ＶＧＡ）５５１３により増幅され、増幅された信号はフィルタ５５１４によりフィルタリングされ、電力増幅器（Power Amplifier：ＰＡ）５５１５により追加で増幅され、デュプレクサ（ら）５５５０／アンテナスイッチ（ら）５５６０を介してルーティングされ、アンテナ５５７０を介して送信される。
【０５３１】
また、受信経路において、アンテナ５５７０は、外部から信号を受信して受信した信号を提供し、この信号はアンテナスイッチ（ら）５５６０／デュプレクサ５５５０を介してルーティングされ、受信機５５２０に提供される。
【０５３２】
受信機５５２０内において、受信された信号は低雑音増幅器（Low Noise Amplifier：ＬＮＡ）５５２３により増幅され、バンドパスフィルタ５５２４によりフィルタリングされ、ダウンコンバータ（Mixer）５５２５によりＲＦからベースバンドにダウンコンバートされる。
【０５３３】
前記ダウンコンバートされた信号は、ローパスフィルタ（ＬＰＦ）５５２６によりフィルタリングされ、ＶＧＡ５５２７により増幅されてアナログ入力信号を取得し、これは、図５３及び図５４に記述されたプロセッサに提供される。
【０５３４】
また、ローカルオシレータ（local oscillator：ＬＯ）発生器５５４０は、送信及び受信ＬＯ信号を発生及びアップコンバータ５５１２及びダウンコンバータ５５２５にそれぞれ提供する。
【０５３５】
また、位相固定ループ（Phase Locked Loop：ＰＬＬ）５５３０は、適切な周波数において送信及び受信ＬＯ信号を生成するためにプロセッサから制御情報を受信し、制御信号をＬＯ発生器５５４０に提供する。
【０５３６】
また、図５５に示す回路は、図５５に示す構成と異なるように配列されてもよい。
【０５３７】
図５６は、本明細書で提案する方法が適用される無線通信装置のＲＦモジュールのまた他の一例を示す図である。
【０５３８】
具体的には、図５６は、ＴＤＤ（Time Division Duplex）システムにおいて実現できるＲＦモジュールの一例を示す図である。
【０５３９】
ＴＤＤシステムにおけるＲＦモジュールの送信機５６１０及び受信機５６２０は、ＦＤＤシステムにおけるＲＦモジュールの送信機及び受信機の構造と同一である。
【０５４０】
以下、ＴＤＤシステムのＲＦモジュールは、ＦＤＤシステムのＲＦモジュールと異なる構造についてのみ説明し、同一の構造については図５５の説明を参照する。
【０５４１】
送信機の電力増幅器（Power Amplifier：ＰＡ）５６１５により増幅された信号は、バンド選択スイッチ（Band Select Switch）５６５０、バンドパスフィルタ（ＢＰＦ）５６６０、及びアンテナスイッチ（ら）５６７０を介してルーティングされ、アンテナ５６８０を介して送信される。
【０５４２】
また、受信経路において、アンテナ５６８０は、外部から信号を受信して受信した信号を提供し、この信号は、アンテナスイッチ（ら）５６７０、バンドパスフィルタ５６６０、及びバンド選択スイッチ５６５０を介してルーティングされ、受信機５６２０に提供される。
【０５４３】
以上で説明された実施形態は本発明の構成要素と特徴が所定の形態に結合されたものである。各構成要素または特徴は別途の明示的な言及がない限り、選択的なものとして考慮されなければならない。各構成要素または特徴は他の構成要素や特徴と結合されない形態に実施できる。また、一部の構成要素及び／又は特徴を結合して本発明の実施形態を構成することも可能である。本発明の実施形態で説明される動作の順序は変更できる。ある実施形態の一部の構成や特徴は他の実施形態に含まれることができ、または他の実施形態の対応する構成または特徴と取替できる。特許請求範囲で明示的な引用関係がない請求項を結合して実施形態を構成するか、または出願後の補正により新たな請求項に含めることができることは自明である。
【０５４４】
本発明に従う実施形態は、多様な手段、例えば、ハードウェア、ファームウエア（firmware）、ソフトウェア、またはそれらの結合などにより具現できる。ハードウェアによる具現の場合、本発明の一実施形態は１つまたはその以上のＡＳＩＣｓ（application specific integrated circuits）、ＤＳＰｓ（digital signal processors）、ＤＳＰＤｓ（digital signal processing devices）、ＰＬＤｓ（programmable logic devices）、ＦＰＧＡｓ（field programmable gate arrays）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより具現できる。
【０５４５】
ファームウエアやソフトウェアによる具現の場合、本発明の一実施形態は以上で説明された機能または動作を実行するモジュール、手続、関数などの形態に具現できる。ソフトウェアコードはメモリに格納されてプロセッサにより駆動できる。前記メモリは前記プロセッサの内部または外部に位置し、既に公知された多様な手段により前記プロセッサとデータをやり取りすることができる。
【０５４６】
本発明は本発明の必須的な特徴を逸脱しない範囲で他の特定の形態に具体化できることは通常の技術者に自明である。したがって、前述した詳細な説明は全ての面で制限的に解釈されてはならず、例示的なものとして考慮されなければならない。本発明の範囲は添付した請求項の合理的な解釈により決定されなければならず、本発明の等価的な範囲内での全ての変更は本発明の範囲に含まれる。
【産業上の利用可能性】
【０５４７】
本発明は、３ＧＰＰ ＬＴＥ／ＬＴＥ−Ａシステムに適用される例を中心に説明したが、３ＧＰＰ ＬＴＥ／ＬＴＥ−Ａシステム以外にも様々な無線通信システムに適用することができる。
【図１】
2020526148.tif 000044
【図２】
2020526148.tif 000045
【図３】
2020526148.tif 000046
【図４】
2020526148.tif 000047
【図５】
2020526148.tif 000048
【図６】
2020526148.tif 000049
【図７】
2020526148.tif 000050
【図８】
2020526148.tif 000051
【図９】
2020526148.tif 000052
【図１０】
2020526148.tif 000053
【図１１】
2020526148.tif 000054
【図１２】
2020526148.tif 000055
【図１３】
2020526148.tif 000056
【図１４】
2020526148.tif 000057
【図１５】
2020526148.tif 000058
【図１６】
2020526148.tif 000059
【図１７】
2020526148.tif 000060
【図１８】
2020526148.tif 000061
【図１９】
2020526148.tif 000062
【図２０】
2020526148.tif 000063
【図２１】
2020526148.tif 000064
【図２２】
2020526148.tif 000065
【図２３】
2020526148.tif 000066
【図２４】
2020526148.tif 000067
【図２５】
2020526148.tif 000068
【図２６】
2020526148.tif 000069
【図２７】
2020526148.tif 000070
【図２８】
2020526148.tif 000071
【図２９】
2020526148.tif 000072
【図３０】
2020526148.tif 000073
【図３１】
2020526148.tif 000074
【図３２】
2020526148.tif 000075
【図３３】
2020526148.tif 000076
【図３４】
2020526148.tif 000077
【図３５】
2020526148.tif 000078
【図３６】
2020526148.tif 000079
【図３７】
2020526148.tif 000080
【図３８】
2020526148.tif 000081
【図３９】
2020526148.tif 000082
【図４０】
2020526148.tif 000083
【図４１】
2020526148.tif 000084
【図４２】
2020526148.tif 000085
【図４３】
2020526148.tif 000086
【図４４】
2020526148.tif 000087
【図４５】
2020526148.tif 000088
【図４６】
2020526148.tif 000089
【図４７】
2020526148.tif 000090
【図４８】
2020526148.tif 000091
【図４９】
2020526148.tif 000092
【図５０】
2020526148.tif 000093
【図５１】
2020526148.tif 000094
【図５２】
2020526148.tif 000095
【図５３】
2020526148.tif 000096
【図５４】
2020526148.tif 000097
【図５５】
2020526148.tif 000098
【図５６】
2020526148.tif 000099
【手続補正書】
【提出日】令和2年1月27日(2020.1.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を端末が送信する方法であって、
アップリンク−ダウンリンク構成（uplink-downlink configuration）に関連した制御情報を基地局から受信するステップと、
前記受信した制御情報に関連した１つ又はそれ以上のパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信するステップとを含み、
前記ＮＰＲＡＣＨプリアンブルは、１つ又はそれ以上のシンボルグループ（symbol group）を含み、
１つのシンボルグループは、１つのＣＰ（Cyclic Prefix）と少なくとも１つのシンボルを含み、
前記１つ又はそれ以上のパラメータは、前記１つのシンボルグループに含まれるシンボルの数を示す第１パラメータと、前記１つのシンボルグループに含まれる前記ＣＰ（cyclic prefix）の長さを示す第２パラメータを含み、
前記第１パラメータ及び前記第２パラメータは、前記第１パラメータ及び前記第２パラメータにそれぞれ対応する第３パラメータ及び第４パラメータと異なるように設定され、
前記第３パラメータ及び前記第４パラメータは、フレーム構造タイプ（frame structure type）１においてサポートされるＮＰＲＡＣＨプリアンブル送信に関連したパラメータである、方法。
【請求項２】
前記１つ又はそれ以上のパラメータは、前記基地局によりサポートされるアップリンク−ダウンリンク構成情報にしたがって異なるように設定される、請求項１に記載の方法。
【請求項３】
前記第１パラメータ及び前記第２パラメータは、それぞれ前記第３パラメータ及び前記第４パラメータより小さい値を有する、請求項１に記載の方法。
【請求項４】
前記第１パラメータの値は、５より小さい自然数である、請求項３に記載の方法。
【請求項５】
前記シンボルグループは、第１周波数ホッピング（frequency hopping）及び第２周波数ホッピングを介して送信される、請求項１に記載の方法。
【請求項６】
前記第２周波数ホッピングの値は前記第１周波数ホッピングの値の６倍である、請求項５に記載の方法。
【請求項７】
前記１つ又はそれ以上のパラメータは、１つのプリアンブル（preamble）に含まれる連続するシンボルグループ（symbol group）の数を示す第５パラメータと、前記１つのプリアンブル（preamble）に含まれるシンボルグループ（symbol group）の全体数を示す第６パラメータをさらに含む、請求項１に記載の方法。
【請求項８】
前記第５パラメータの値は２であり、前記第６パラメータの値は４である、請求項７に記載の方法。
【請求項９】
フレーム構造タイプ（frame structure type）２をサポートするＮＢ（Narrow Band）−ＩｏＴ（Internet of Things）システムにおいてＮＰＲＡＣＨ（Narrowband Physical Random Access Channel）プリアンブル（preamble）を送信する端末であって、
無線信号を送受信するためのＲＦ（Radio Frequency）モジュールと、
前記ＲＦモジュールを制御するプロセッサとを含み、前記プロセッサは、
アップリンク−ダウンリンク構成（uplink-downlink configuration）に関連した制御情報を基地局から受信し、
前記受信した制御情報と関連した１つ又はそれ以上のパラメータに基づいて前記ＮＰＲＡＣＨプリアンブルを前記基地局に送信するように設定され、
前記ＮＰＲＡＣＨプリアンブルは、１つ又はそれ以上のシンボルグループ（symbol group）を含み、
１つのシンボルグループは、１つのＣＰ（Cyclic Prefix）と少なくとも１つのシンボルを含み、
前記１つ又はそれ以上のパラメータは、前記１つのシンボルグループに含まれるシンボルの数を示す第１パラメータと、前記１つのシンボルグループに含まれるＣＰ（cyclic prefix）の長さを示す第２パラメータを含み、
前記第１パラメータ及び前記第２パラメータは、前記第１パラメータ及び前記第２パラメータにそれぞれ対応する第３パラメータ及び第４パラメータと異なるように設定され、
前記第３パラメータ及び前記第４パラメータは、フレーム構造タイプ（frame structure type）１においてサポートされるＮＰＲＡＣＨプリアンブル送信に関連したパラメータである、端末。
【請求項１０】
前記１つ又はそれ以上のパラメータは、前記基地局によりサポートされるアップリンク−ダウンリンク構成情報にしたがって異なるように設定される、請求項９に記載の端末。
【国際調査報告】
2020526148.tif 000100
2020526148.tif 000101
2020526148.tif 000102
2020526148.tif 000103