(57)【要約】  基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置において、前記基地局にプリアンブルを送信する送信部と、所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視する受信部と、を備え、前記受信部は、システムフレーム番号を用いて前記所定の識別情報を算出する。
2019107361.tif 000002
【特許請求の範囲】
【請求項１】
基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、
前記基地局にプリアンブルを送信する送信部と、
所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視する受信部と、を備え、
前記受信部は、システムフレーム番号を用いて前記所定の識別情報を算出する
ことを特徴とするユーザ装置。
【請求項２】
前記受信部は、前記システムフレーム番号が奇数であるか、偶数であるかの情報を用いて前記所定の識別情報を算出する
ことを特徴とする請求項１に記載のユーザ装置。
【請求項３】
前記受信部は、前記システムフレーム番号に対する剰余演算を行うことにより前記所定の識別情報を算出する
ことを特徴とする請求項１又は２に記載のユーザ装置。
【請求項４】
基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、
前記基地局にプリアンブルを送信する送信部と、
所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視する受信部と、を備え、
前記受信部は、サブフレームインデックスを用いて前記所定の識別情報を算出し、当該サブフレームインデックスの範囲は０〜９よりも大きい
ことを特徴とするユーザ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムにおけるユーザ装置に関連するものである。
【背景技術】
【０００２】
ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）では、ユーザ装置が基地局と接続を確立する場合、あるいは再同期を行う場合等に、ランダムアクセス（ＲＡ  ：  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ）が行われる（非特許文献１）。【０００３】
また、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）では、システム容量の更なる大容量化、データ伝送速度の更なる高速化、無線区間における更なる低遅延化等を実現するために、５Ｇと呼ばれる無線通信方式の検討が進んでいる。５Ｇでは、１０Ｇｂｐｓ以上のスループットを実現しつつ無線区間の遅延を１ｍｓ以下にするという要求条件を満たすために、様々な無線技術の検討が行われている。５ＧではＬＴＥと異なる無線技術が採用される可能性が高いことから、３ＧＰＰでは、５Ｇをサポートする無線ネットワークを新たな無線ネットワーク（ＮｅｗＲＡＴ：Ｎｅｗ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）と呼ぶことで、ＬＴＥをサポートする無線ネットワークと区別している。なお、ＮｅｗＲＡＴは、ＮＲと呼んでもよい。【０００４】
５Ｇでは、ＬＴＥと同様の低い周波数帯から、ＬＴＥよりも更に高い周波数帯までの幅広い周波数を使用することが想定されている。特に、高周波数帯では伝搬ロスが増大することから、それを補うために、ビーム幅の狭いビームフォーミングを適用することが検討されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】３ＧＰＰ  ＴＳ  ３６．３２１  Ｖ１４．０．０  （２０１６−０９）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ここで、ＮＲにおいても、ＬＴＥでのランダムアクセス手順と同様のランダムアクセス手順が行われることが想定される。ＮＲでは、ユーザ装置が送信したＲＡ  ｐｒｅａｍｂｌｅに対する応答（RAR）を監視する期間であるRAR window lengthは、LTEのRAR window lengthよりも長くなることが想定される。しかし、このような長いRAR window lengthを考慮した、監視のための識別情報（例：RA-RNTI）は、従来技術では提案されていない。よって、従来技術では、ランダムアクセス手順を適切に実行できない可能性がある。【０００７】
本発明は上記の点に鑑みてなされたものであり、ユーザ装置と基地局を有する無線通信システムにおいて、ランダムアクセス手順を適切に実行することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
開示の技術によれば、基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、
前記基地局にプリアンブルを送信する送信部と、
所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視する受信部と、を備え、
前記受信部は、システムフレーム番号を用いて前記所定の識別情報を算出する
ことを特徴とするユーザ装置が提供される。
【発明の効果】
【０００９】
開示の技術によれば、ユーザ装置と基地局を有する無線通信システムにおいて、ランダムアクセス手順を適切に実行することを可能とする技術が提供される。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態に係る無線通信システムの構成図である。
【図２】ランダムアクセス手順の例を説明するための図である。
【図３】基地局２０から送信されるビームを説明するための図である。
【図４】ＲＡ  ｐｒｅａｍｂｌｅの送信方法を説明するための図である。
【図５】ユーザ装置１０が複数の基本ブロードキャスト情報／ＳＳを受信できた場合における動作例を説明するための図である。
【図６】実施例１を説明するための図である。
【図７】閾値を基地局２０からユーザ装置１０に通知する場合のシーケンス図である。
【図８】閾値の適用方法の例を説明するための図である。
【図９】再送において閾値を適用する場合の例を説明するための図である。
【図１０】実施例２においてＲＡＲ  ｗｉｎｄｏｗを時間方向で分ける場合の例を説明するための図である。
【図１１】実施例２においてＲＡＲ  ｗｉｎｄｏｗを周波数方向で分ける場合の例を説明するための図である。
【図１２】実施例２において共通のＲＡＲ  ｗｉｎｄｏｗを使用する場合の例を説明するための図である。
【図１３】ユーザ装置１０の機能構成の一例を示す図である。
【図１４】基地局２０の機能構成の一例を示す図である。
【図１５】ユーザ装置１０及び基地局２０のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
【００１２】
本実施の形態の無線通信システムが動作するにあたっては、適宜、既存技術を使用できる。ただし、当該既存技術は例えば既存のＬＴＥであるが、既存のＬＴＥに限られない。また、本明細書で使用する「ＬＴＥ」は、特に断らない限り、ＬＴＥ−Ａｄｖａｎｃｅｄ、及び、ＬＴＥ−Ａｄｖａｎｃｅｄ以降の方式（例：５Ｇ）を含む広い意味を有するものとする。
【００１３】
また、以下で説明する実施の形態では、既存のＬＴＥで使用されているランダムアクセス、ＲＡ  ｐｒｅａｍｂｌｅ、ＲＡＲ、メッセージ１〜４、ＲＡＲ  ｗｉｎｄｏｗ、ＳＩＢ、その他の用語を使用しているが、これは記載の便宜上のためであり、これらと同様の信号、機能等が他の名称で呼ばれてもよい。
【００１４】
また、本実施の形態では、ＬＴＥで規定されているランダムアクセス手順をベースとするランダムアクセス手順を例として取り挙げている。しかし、本発明の適用先は、当該ランダムアクセス手順に限らない。本発明は、ランダムアクセス手順以外の通信手順にも適用可能である。
【００１５】
また、ビームに紐付けられた基本ブロードキャスト情報／ＳＳを選択することと、当該ビームを選択することとは同義と考えてよい。
【００１６】
以下の説明において、実施例１、２、３を説明するが、実施例１、２、３の説明の前に、実施例１、２、３の前提となる技術としての基本例を説明する。実施例１、２、３は、基本例に対する改善策として説明される。ただし、実施例１、２、３はそれぞれ、基本例を前提としないこととしてもよい。また、実施例１、２、３はそれぞれ、例えば、現時点で、３ＧＰＰの仕様書に記載された技術を前提とすることとしてもよい。
【００１７】
（基本例）
＜システム全体構成＞
図１に本実施の形態に係る無線通信システムの構成図を示す。本実施の形態に係る無線通信システムは、図１に示すように、ユーザ装置１０、及び基地局２０を含む。図１には、ユーザ装置１０、及び基地局２０が１つずつ示されているが、これは例であり、それぞれ複数であってもよい。
【００１８】
ユーザ装置１０は、スマートフォン、携帯電話機、タブレット、ウェアラブル端末、Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）用通信モジュール等の無線通信機能を備えた通信装置であり、基地局２０に無線接続し、無線通信システムにより提供される各種通信サービスを利用する。基地局２０は、１つ以上のセルを提供し、ユーザ装置１０と無線通信する通信装置である。ユーザ装置１０と基地局２０はいずれも、ビームフォーミングを行って信号の送受信を行うことが可能である。
【００１９】
本実施の形態において、複信（Ｄｕｐｌｅｘ）方式は、ＴＤＤ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）方式でもよいし、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）方式でもよい。
【００２０】
また、以下の説明において、送信ビームを用いて信号を送信することは、プリコーディングベクトルが乗算された（プリコーディングベクトルでプリコードされた）信号を送信することと同義である。同様に、受信ビームを用いて信号を受信することは、所定の重みベクトルを受信した信号に乗算することと同義である。また、送信ビームを用いて信号を送信することは、特定のアンテナポートで信号を送信することと表現されてもよい。同様に、受信ビームを用いて信号を受信することは、特定のアンテナポートで信号を受信することと表現されてもよい。アンテナポートとは、３ＧＰＰの規格で定義されている論理アンテナポートを指す。なお、送信ビーム及び受信ビームの形成方法は、上記の方法に限られるわけではない。例えば、複数アンテナを備えるユーザ装置１０／基地局２０において、それぞれのアンテナの角度を変える方法を用いてもよいし、プリコーディングベクトルを用いる方法とアンテナの角度を変える方法を組み合わせる方法を用いてもよいし、その他の方法を用いてもよい。
【００２１】
以下、基地局２０からの信号送信に用いられるビームをＢＳ送信ビームと呼び、基地局２０が信号受信に用いるビームをＢＳ受信ビームと呼び、ユーザ装置１０からの信号送信に用いられるビームをＵＥ送信ビームと呼び、ユーザ装置１０が信号受信に用いるビームをＵＥ受信ビームと呼ぶ。
【００２２】
＜ランダムアクセス手順について＞
図２を参照して、本実施の形態におけるランダムアクセス手順の例を説明する。本実施の形態では、一例として、ＬＴＥでのランダムアクセス手順と同様のランダムアクセス手順（非特許文献１）を実行することとしている。ただし、ランダムアクセス手順における信号の送受信において、ユーザ装置１０と基地局２０はそれぞれ、送信ビーム及び受信ビームを適用する。なお、一部の信号送受信がオムニ送信／受信となってもよい。
【００２３】
基地局２０は、ｂｅａｍ  ｓｗｅｅｐｉｎｇを行って、ＢＳ送信ビーム毎に基本ブロードキャスト情報、及び同期信号（ＳＳ：ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｓｉｇｎａｌ、以下、ＳＳと記載する）を、それぞれの所定の周期で送信している（ステップＳ１０１）。基本ブロードキャスト情報と同期信号の送信周期は同じでもよいし、異なっていてもよい。また、後述するＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）も、ＢＳ送信ビーム毎に所定の周期で送信される。ＳＩＢを「システム情報」と称しても良い。基本例では、ＳＩＢの送信周期は、基本ブロードキャスト情報及び同期信号の送信周期よりも長く、ＳＩＢのサイズは、基本ブロードキャスト情報と同期信号のいずれのサイズよりも大きい。
【００２４】
ＢＳ送信ビームのイメージを図３に示す。図３の例では、Ａ、Ｂ、Ｃの３つのＢＳ送信ビームが示されている。３つのＢＳ送信ビームのそれぞれにおいて、基本ブロードキャスト情報、ＳＳ、ＳＩＢ等が送信される。ｂｅａｍ  ｓｗｅｅｐｉｎｇでは、例えば、時間毎（例：シンボル毎）にＢＳ送信ビームが切り替えられる。
【００２５】
基本ブロードキャスト情報は、例えば、ＰＢＣＨで送信される基本的なシステム情報（ＬＴＥでのＭＩＢに相当）である。ＳＳは、例えば、Ｐ−ＳＳとＳ−ＳＳの２種類の信号（符号系列）を有する。Ｐ−ＳＳは、例えば、シンボルタイミング同期等を目的とする信号であり、Ｓ−ＳＳは、例えば、無線フレーム同期等を目的とする信号である。
【００２６】
ユーザ装置１０は、あるＢＳ送信ビームにより、基本ブロードキャスト情報、又は、ＳＳ、又は、「基本ブロードキャスト情報及びＳＳ」を受信することにより当該ＢＳ送信ビームを識別することができる。ＢＳ送信ビームを識別するとは、例えば、当該ＢＳ送信ビームの識別子（ＩＤ）を検出することである。ＢＳ送信ビームのＩＤがアンテナポート番号であってもよい。例えば、ＢＳ送信ビームのＩＤは、基本ブロードキャスト情報に含まれることとしてもよいし、ＳＳに含まれることとしてもよい。また、ＢＳ送信ビームのＩＤが、基本ブロードキャスト情報又はＳＳが送信されるリソース（時間及び／又は周波数のリソース）に対応付けられており、ユーザ装置１０は、基本ブロードキャスト情報又はＳＳを受信したリソースによりＢＳ送信ビームを識別してもよい。
【００２７】
Ｐ−ＳＳ、Ｓ−ＳＳ、基本ブロードキャスト情報のいずれかを含んだブロックをＳＳブロック（ＳＳ−ｂｌｏｃｋ）と呼ぶこととしてもよい。ユーザ装置１０は、基地局２０から送信されるＳＳブロックを受信できたこと（ＳＳブロックの内容を把握できたこと）が、当該ＳＳブロックに紐付けられたＢＳ送信ビームを識別できたことである、としてもよい。この場合、例えば、ユーザ装置１０は、受信したＳＳブロックの内容、もしくはＳＳブロックを受信したリソースからＢＳ送信ビームのＩＤを識別する。
【００２８】
ＳＳブロックのリソースとＢＳ送信ビームとが紐付いている場合、ユーザ装置１０が識別する「ＢＳ送信ビームのＩＤ」は、ＢＳ送信ビーム用に割り当てられるＩＤ（これを「ｂｅａｍ  ＩＤ」とする）である必要はない。例えば、上記のＳＳブロックの時間位置（例：シンボルインデックス）が、ＢＳ送信ビームに紐付けられているとともに、ＲＡ  ｐｒｅａｍｂｌｅを送信するために使用するリソースであるＲＡＣＨリソースサブセットと紐付けられる。この場合、この時間位置（例：シンボルインデックス）が「ＢＳ送信ビームのＩＤ」と考えることができる。この場合、ユーザ装置１０は、上記のＳＳブロックの時間位置（例：シンボルインデックス）を認識するだけでよい。また、この場合、例えば、ｂｅａｍ  ＩＤは基本ブロードキャスト情報に含まれることとしてもよい。
【００２９】
また、ＳＳブロックのリソースとＢＳ送信ビームとが紐付いているとは、例えば、ＢＳ送信ビームＡとＢＳ送信ビームＢがある場合に、ある時間単位の周期で、毎回、シンボルＡで同じＢＳ送信ビームＡが使用され、シンボルＢで同じＢＳ送信ビームＢが使用される、ということである。
【００３０】
また、ＳＳブロックのリソースとＢＳ送信ビームとが紐付いていない場合には、例えば、基地局２０がユーザ装置１０に対して基本ブロードキャスト情報にｂｅａｍ  ＩＤを含めて送信し、ユーザ装置１０は、基本ブロードキャスト情報により送信されるｂｅａｍ  ＩＤを読み取ることで、ＢＳ送信ビームを識別する。
【００３１】
本実施の形態における技術は、上記の２パターンのどちらにも適用可能である。図２のステップＳ１０２において、ユーザ装置１０は、ステップＳ１０１において受信できた基本ブロードキャスト情報及び／又はＳＳ（これを「基本ブロードキャスト情報／ＳＳ」と表記する）のＢＳ送信ビームに対応するリソース（これをＲＡＣＨリソースサブセットと呼ぶ）を用いて、ＲＡ  ｐｒｅａｍｂｌｅ（Ｍｅｓｓａｇｅ１）を送信する。
【００３２】
基地局２０は、ＲＡ  ｐｒｅａｍｂｌｅを検出すると、その応答であるＲＡ  ｒｅｓｐｏｎｓｅ（ＲＡＲ、Ｍｅｓｓａｇｅ２）をユーザ装置１０に送信する（ステップＳ１０３）。ＲＡ  ｒｅｓｐｏｎｓｅを受信したユーザ装置１０は、所定の情報を含むＭｅｓｓａｇｅ３を基地局２０に送信する（ステップＳ１０４）。Ｍｅｓｓａｇｅ３は、例えば、ＲＲＣ  ｃｏｎｎｅｃｔｉｏｎ  ｒｅｑｕｅｓｔである。
【００３３】
Ｍｅｓｓａｇｅ３を受信した基地局２０は、Ｍｅｓｓａｇｅ４（例：ＲＲＣ  ｃｏｎｎｅｃｔｉｏｎ  ｓｅｔｕｐ）をユーザ装置１０に送信する。ユーザ装置１０は、上記の所定の情報がＭｅｓｓａｇｅ４に含まれていることを確認すると、当該Ｍｅｓｓａｇｅ４が、上記のＭｅｓｓａｇｅ３に対応する自分宛てのＭｅｓｓａｇｅ４であることを認識し、ランダムアクセス手順を完了する。一方、Ｍｅｓｓａｇｅ４においてユーザ装置１０が所定の情報を確認できなかった場合は、ランダムアクセスの失敗と見なし、再度ＲＡ  ｐｒｅａｍｂｌｅの送信から手順を実行する。
【００３４】
＜ＲＡ  ｐｒｅａｍｂｌｅの送信方法について＞
上記のステップＳ１０２におけるＲＡ  ｐｒｅａｍｂｌｅの送信方法の例をより詳細に説明する。
【００３５】
本実施の形態では、ユーザ装置１０は、基地局２０からｂｅａｍ  ｓｗｅｅｐｉｎｇを適用して送信された複数の基本ブロードキャスト情報／ＳＳのうち、受信できた基本ブロードキャスト情報／ＳＳを選択する。これは、受信できた基本ブロードキャスト情報／ＳＳを送信するＢＳ送信ビームを選択することと同じである。ここでの「受信できた」とは、例えば、良い受信品質で受信できたことであるが、これに限られない。
【００３６】
本実施の形態では、基地局２０からのＢＳ送信ビームと、ユーザ装置１０からＲＡ  ｐｒｅａｍｂｌｅを送信するための使用するリソースであるＲＡＣＨリソースサブセットとが対応付けられている。ユーザ装置１０は、選択したＢＳ送信ビームに対応するＲＡＣＨリソースサブセットを用いてＲＡ  ｐｒｅａｍｂｌｅを送信する。
【００３７】
一例として、図４には、ユーザ装置１０側のＲＡＣＨリソースサブセットとしてＡ、Ｂ、Ｃが示されている。ＲＡＣＨリソースサブセットＡ、Ｂ、Ｃはそれぞれ、例えば、図３に示したようなＢＳ送信ビームＡ、Ｂ、Ｃに対応する。なお、図４は、複数のＲＡＣＨリソースサブセットが時間方向で分けられることにより、各ＢＳ送信ビームと対応付けられているが、これは一例に過ぎない。複数のＲＡＣＨリソースサブセットが周波数方向で分けられることにより、各ＢＳ送信ビームと対応付けられてもよいし、複数のＲＡＣＨリソースサブセットが時間・周波数の単位で分けられることにより、各ＢＳ送信ビームと対応付けられてもよい。
【００３８】
図４の例では、ユーザ装置１０が、ＢＳ送信ビームＢで送信される基本ブロードキャスト情報／ＳＳを受信できた場合を示しており、ユーザ装置１０は、ＢＳ送信ビームＢに対応するＲＡＣＨリソースサブセットＢでＲＡ  ｐｒｅａｍｂｌｅを送信する。
【００３９】
基地局２０は、ユーザ装置１０から受信したＲＡ  ｐｒｅａｍｂｌｅのリソースに基づき、ユーザ装置１０において受信された基本ブロードキャスト情報／ＳＳ（ＢＳ送信ビーム）を決定できる。図４の例の場合、基地局２０は、ＲＡＣＨリソースサブセットＢによりＲＡ  ｐｒｅａｍｂｌｅを受信するので、ＲＡＣＨリソースサブセットＢに対応するＢＳ送信ビームＢが、ユーザ装置１０により受信可能な適切なＢＳ送信ビームであると判断できる。例えば、その後のユーザ装置１０への信号送信において当該ＢＳ送信ビームＢを使用することができる。なお、図４において、基地局２０側でＥ、Ｆ、Ｇで示したビームは、ＢＳ受信ビームを示すものであり、この例では、図示するように、基地局２０が受信側のｂｅａｍ  ｓｗｅｅｐｉｎｇを行っていることを示している。
【００４０】
また、図４には、ＲＡＲ  ｗｉｎｄｏｗが示される。本実施の形態では、既存のＬＴＥと同様に、ＲＡ  ｐｒｅａｍｂｌｅを送信したユーザ装置１０が、ＲＡＲ  ｗｉｎｄｏｗで示される所定時間内に、ＲＡ  ｒｅｓｐｏｎｓｅを監視し、ＲＡ  ｒｅｓｐｏｎｓｅを受信しない場合に、ランダムアクセス失敗であると判断する。ただし、これは一例であり、ＲＡ  ｒｅｓｐｏｎｓｅの受信成否判定処理として、既存のＬＴＥと異なる処理を行うこととしてもよい。
【００４１】
図４の例は、ユーザ装置１０が１つのＢＳ送信ビームにより基本ブロードキャスト情報／ＳＳを受信できた場合を示している。あるいは、図４の例は、ユーザ装置１０が複数のＢＳ送信ビームで基本ブロードキャスト情報／ＳＳを受信でき、当該複数のＢＳ送信ビームのうち、基本ブロードキャスト情報／ＳＳを最も良く受信できた（例：受信品質が最良の）１つのＢＳ送信ビームを選択した場合を示している。
【００４２】
ユーザ装置１０が複数のＢＳ送信ビームで基本ブロードキャスト情報／ＳＳを受信できた場合において、ユーザ装置１０は、複数のＢＳ送信ビームのそれぞれに対応する複数のＲＡＣＨリソースサブセットを用いてＲＡ  ｐｒｅａｍｂｌｅを送信することとしてもよい。複数のＲＡＣＨリソースサブセットを用いてＲＡ  ｐｒｅａｍｂｌｅを送信することにより、ダイバーシティ効果が得られる。
【００４３】
例えば、基本ブロードキャスト情報／ＳＳを同程度に良好な受信品質で受信できた複数のＢＳ送信ビームがある場合に、ユーザ装置１０は、これら複数のＢＳ送信ビームを選択し、当該複数のＢＳ送信ビームに対応する複数のＲＡＣＨリソースサブセットのそれぞれでＲＡ  ｐｒｅａｍｂｌｅを送信する。これにより、基地局２０は、真に最適なＢＳ送信ビームを検出できる可能性がある。また、複数のＲＡＣＨリソースサブセット間で、ＵＥ送信ビーム及び／又はＢＳ受信ビームが異なることが考えられるので、基地局２０は、最適なビームでＲＡ  ｐｒｅａｍｂｌｅを受信できる可能性がある。
【００４４】
図５は、一例として、ユーザ装置１０が、ＢＳ送信ビームＢ、Ｃに対応するＲＡＣＨリソースサブセットＢ、Ｃを用いてＲＡ  ｐｒｅａｍｂｌｅを送信する場合を示している。なお、複数のＲＡＣＨリソースサブセットのそれぞれでＲＡ  ｐｒｅａｍｂｌｅを送信する場合、ＲＡ  ｐｒｅａｍｂｌｅの内容（系列）は、複数のＲＡＣＨリソースサブセット間で同一でもよいし、異なっていてもよい。
【００４５】
＜ＲＡＣＨリソースサブセットを通知する方法について＞
本実施の形態では、基地局２０が、ユーザ装置１０に対し、ＢＳ送信ビームに対応するＲＡＣＨリソースサブセットを示す情報を送信する。ユーザ装置１０は、当該情報に基づき、受信した基本ブロードキャスト情報／ＳＳのＢＳ送信ビームに対応するＲＡＣＨリソースサブセットを知ることができる。一例として、ユーザ装置１０が、ＢＳ送信ビームＡに対応するＲＡＣＨリソースサブセットとして、ＲＡＣＨリソースサブセットＡを示す情報を基地局２０から受信した場合において、ユーザ装置１０が、ＢＳ送信ビームＡを選択してＲＡ  ｐｒｅａｍｂｌｅを送信する場合には、ユーザ装置１０は、ＲＡＣＨリソースサブセットＡを用いてＲＡ  ｐｒｅａｍｂｌｅを送信する。
【００４６】
基地局２０からユーザ装置１０に通知される「ＲＡＣＨリソースサブセットを示す情報」は、当該ＲＡＣＨリソースサブセットの時間・周波数リソースを示す情報（例：リソースインデックス）でもよいし、当該ＲＡＣＨリソースサブセットの時間リソース（時間位置）を示す情報であってもよいし、その他の情報であってもよい。
【００４７】
例えば、上記の情報は、ＢＳ送信ビーム毎に、ＢＳ送信ビームにより送信されるＳＩＢを用いて通知される。また、あるＢＳ送信ビームにより送信されるＳＩＢの中に他のＢＳ送信ビームに対応するＲＡＣＨリソースサブセットの情報が含まれていてもよい。
【００４８】
＜複数のＲＡ  ｐｒｅａｍｂｌｅを送信することについて＞
基地局２０との接続を迅速に行う観点からは、ユーザ装置１０は、検出できた複数の基本ブロードキャスト情報／ＳＳのそれぞれに紐づくＲＡＣＨリソースサブセットを用いて、自由に複数のＲＡ  ｐｒｅａｍｂｌｅを送信することが考えられる。しかし、その場合、ユーザ装置１０は、適切な受信品質で受信できていない基本ブロードキャスト情報／ＳＳに紐づけられたＲＡＣＨリソースサブセットを用いてＲＡ  ｐｒｅａｍｂｌｅを送信する可能性がある。
【００４９】
例えば、ユーザ装置１０が２つのＳＳを受信し、それらの受信品質に大幅な差がある場合、悪い受信品質のＳＳに対応するＲＡＣＨリソースサブセットで送信されるＲＡ  ｐｒｅａｍｂｌｅは、基地局２０側で受信に成功する確率が低いと考えられる。また、当該ＲＡ  ｐｒｅａｍｂｌｅは、ＵＥ送信ビーム及びＢＳ受信ビームの適切さの観点で見た場合に有用でない可能性が高い。また、このように有用でないＲＡ  ｐｒｅａｍｂｌｅ送信をすることにより、周囲に干渉をまき散らすことになる。また、仮に受信品質の悪い方に対応するＲＡ  ｐｒｅａｍｂｌｅが基地局２０により受信され、その後の処理も継続される場合、ＢＳ送信ビームが適切でない可能性が高いために、以降の通信の性能が劣化する可能性がある。
【００５０】
特にＢＳ／ＵＥ  ｂｅａｍ  ｃｏｒｒｅｓｐｏｎｄｅｎｃｅがある、つまり、ＢＳ／ＵＥ側でｃｈａｎｎｅｌ  ｒｅｃｉｐｒｏｃｉｔｙが利用可能であるケースでは影響がより顕著と考えられる。
【００５１】
（実施例の概要）
そこで、以下で説明する実施例では、ＢＳ送信ビームの受信品質に関する閾値を設け、基本的に、ユーザ装置１０は、ユーザ装置１０におけるＢＳ送信ビームの受信品質が閾値よりも良い場合に、当該ＢＳ送信ビームに対応付けられたＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを送信する。
【００５２】
上記の受信品質は特定のものに限られない。例えば、受信品質は、ユーザ装置１０が基地局２０から受信する所望信号の受信電力、干渉と受信電力との比（受信電力／干渉、いわゆるＳＮＲ）、又は、「干渉＋ノイズ」と受信電力との比（受信電力／（干渉＋ノイズ）、いわゆるＳＩＮＲ））である。また、受信品質が、該当ＢＳ送信ビームに関するパスロスであってもよい。上記の所望信号は、例えば、対象とするＢＳ送信ビームにより送信される基本ブロードキャスト情報／ＳＳ、参照信号、もしくは、データ信号である。
【００５３】
上記のように、受信品質として、受信電力、もしくは受信電力を分子にもつ値を使用する場合、受信品質の値が大きければ受信品質は良い。一方、受信品質としてパスロスを使用する場合、パスロスの値が小さければ受信品質は良い。すなわち、使用する受信品質の種類に応じて、受信品質（の値）が大きいほど受信品質が良い場合と、受信品質（の値）が小さいほど受信品質がよい場合がある。
【００５４】
なお、本実施の形態において、「より大きい」、「より小さい」をそれぞれ「以上」、「以下」に置き換えてもよい。
【００５５】
以下、説明の便宜上、受信品質は、例えば受信電力のように、その値が大きいほど良いものとして説明する。値が小さいほど良くなる受信品質については、以下の説明で「大きい」と「小さい」とを置き換えればよい。また、これらを包含する表現として、「受信品質が閾値よりも良い」という表現を用いる場合もある。
【００５６】
以下、閾値を使用する種々の例を実施例１として説明する。また、実施例１を前提とするＲＡＲ  ｗｉｎｄｏｗに関するバリエーションについて、実施例２として説明する。実施例１、２の説明においては、これまでに説明した基本例の技術に対する改善部分（つまり、変更部分）を説明している。従って、特に説明をしない場合には、基本的には基本例が適用される。また、実施例３では、ＲＡ−ＲＮＴＩの算出に関する提案がなされる。
【００５７】
（実施例１）
上記のように、本実施例では、ＢＳ送信ビームの受信品質に関する閾値を設け、基本的に、ユーザ装置１０は、ユーザ装置１０におけるＢＳ送信ビームの受信品質が所定の条件を満たす場合に、当該ＢＳ送信ビーム（基本ブロードキャスト情報／ＳＳ）に対応付けられたＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを送信する。所定の条件の具体例は以下で説明するが、所定の条件は以下の例に限られない。
【００５８】
一例として、所定の条件は、受信品質が閾値よりも大きいことである。例えば、閾値がＴＨであるとした場合において、図５に示すＢＳ送信ビームＢでの受信品質ＸがＴＨよりも大きく、ＢＳ送信ビームＣの受信品質ＹがＴＨよりも小さい場合には、ユーザ装置１０は、ＢＳ送信ビームＢに対応付けられたＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを送信する。
【００５９】
例えば、ユーザ装置１０は、上記の閾値を、検出できた全てのＢＳ送信ビームに関して適用する。また、検出できた複数のＢＳ送信ビームにおける受信品質を受信品質の良い順に並べた場合に、Ｎ番目に良い受信品質以降の受信品質のＢＳ送信ビームに関してのみ閾値を適用することとしてもよい。例えば、上述した図５の例において、Ｘ＞Ｙとし、Ｎを２とすると、ユーザ装置１０は、ＢＳ送信ビームＣにみについて閾値を適用する。つまり、２番目に良いＢＳ送信ビームＣのみについて閾値を適用する。
【００６０】
また、ＢＳ送信ビーム毎に閾値が異なっていてもよい。例えば、図５の例において、ＢＳ送信ビームＢでの受信品質Ｘに関してＴＨ１を使用し、ＢＳ送信ビームＣでの受信品質Ｘに関してＴＨ２を使用する。ＢＳ送信ビーム毎に閾値を異ならせる場合、例えば、受信品質が大きいほど、大きな閾値を使用する。
【００６１】
閾値は、上記のように受信品質との比較に直接に用いる値（これを「直接比較閾値」と呼ぶ）であってもよいし、相対値（これを「相対閾値」と呼ぶ）であってもよい。相対値としての閾値については、例えば、複数のＢＳ送信ビームにおける受信品質のうちの最大の受信品質から判断対象のＢＳ送信ビームにおける受信品質を引いた差分と相対閾値とを比較し、差分が相対閾値よりも小さい場合に、ユーザ装置１０は、判断対象のＢＳ送信ビームに対応付けられたＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを送信することができると判断する。
【００６２】
この場合の例を図６を参照して説明する。図６の例では相対閾値を３とする。例えば、ユーザ装置１０は、ＢＳ送信ビームＢにより送信される基本ブロードキャスト情報／ＳＳの受信品質をＸと測定し、ＢＳ送信ビームＣにより送信される基本ブロードキャスト情報／ＳＳの受信品質をＹと測定する。Ｘ＞Ｙであり、ＢＳ送信ビームＢにより送信される基本ブロードキャスト情報／ＳＳの受信品質が最大である。ユーザ装置１０は、ＢＳ送信ビームＢに対応付けられたＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを送信する。また、ユーザ装置１０は、（Ｘ−Ｙ）を３と比較し、（Ｘ−Ｙ）＜３であれば、ＢＳ送信ビームＣに対応付けられたＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを送信する。
【００６３】
なお、上記の例で、１つ目のＲＡ  ｐｒｅａｍｂｌｅに関して、直接比較閾値を適用してもよい。
【００６４】
また、同時に送信できるＲＡ  ｐｒｅａｍｂｌｅの数（つまり、同時に使用できるＲＡＣＨリソースサブセットの数）に上限値を設けてもよい。なお、ここでの「同時」とは、「同時」と見なせる時間幅を意味する。
【００６５】
例えば、直接比較閾値を用いる場合に、上限値として３が与えられた場合において、受信品質が直接比較閾値よりも大きなＢＳ送信ビームが４つあったとしても、同時に送信できるＲＡ  ｐｒｅａｍｂｌｅの数は３である。この場合、例えば、４つの中で最も受信品質が最悪のＢＳ送信ビームに対するＲＡ  ｐｒｅａｍｂｌｅが送信されない。
【００６６】
また、例えば、図６を参照して説明した相対閾値を使用する場合において、最大受信品質と（最大受信品質‐相対閾値）との間の受信品質を持つＢＳ送信ビームがＮ個（最大受信品質のＢＳ送信ビームを含む）あるとする。上限値が無いあるいは上限値がＮより大きければ、Ｎ個のＲＡ  ｐｒｅａｍｂｌｅが送信される。一方、例えば、上限値がＭ（＜Ｎ）であるとすると、Ｍ個のＲＡ  ｐｒｅａｍｂｌｅが送信される。
【００６７】
＜閾値について＞
上述した閾値（直接比較閾値、相対閾値）は、例えば、基地局２０からユーザ装置１０にＤＣＩ、ＭＡＣ信号、ＲＲＣ信号等により通知される。あるいは、基地局２０とユーザ装置１０において閾値が予め設定されていてもよい。
【００６８】
図７に、閾値を基地局２０からユーザ装置１０に通知する場合のシーケンス図を示す。図７に示すとおり、基地局２０はユーザ装置１０に閾値を送信する（ステップＳ２０１）。ユーザ装置１０は、当該閾値をメモリ等の記憶部に保持する。また、ユーザ装置１０は、受信できた基本ブロードキャスト情報／ＳＳ（ＢＳ送信ビーム）に対するＲＡ  ｐｒｅａｍｂｌｅの送信可否を、当該ＢＳ送信ビームにおける受信品質と当該閾値とを用いて判断し、送信可でれば送信を行う（ステップＳ２０２）。
【００６９】
＜再送に関する閾値の適用＞
本実施の形態では、既存のＬＴＥと同様に、ＲＡＲ  ｗｉｎｄｏｗ（時間ウィンドウ）が設けられる。ユーザ装置１０は、ＲＡ  ｐｒｅａｍｂｌｅを送信した後、ＲＡＲ  ｗｉｎｄｏｗでＲＡＲ（ＲＡＣＨ  ｒｅｓｐｏｎｓｅ）を監視する。具体的には、ＲＡ−ＲＮＴＩ（識別情報と称してもよい）を用いたブラインドデコーディングを実施する。つまり、基地局２０から、ＲＡ−ＲＮＴＩでスクランブルされた信号（ＰＤＣＣＨ）が送られてくるので、ユーザ装置ＵＥは、ＲＡ−ＲＮＴＩを用いてＰＤＣＣＨのデスクランブルを行うことで、ＰＤＣＣＨを読み、ＲＡＲを受信する。もしも、ユーザ装置１０が、ＲＡ  ｐｒｅａｍｂｌｅを送信した後に、当該ＲＡ  ｐｒｅａｍｂｌｅに対応するＲＡＲをＲＡＲ  ｗｉｎｄｏｗ内で受信しなければ、ユーザ装置１０は当該ＲＡ  ｐｒｅａｍｂｌｅの再送を行う。
【００７０】
既に説明した閾値に関しては、例えば、ＲＡ  ｐｒｅａｍｂｌｅの初送と再送（２回目以降の再送も含む）とで同じ方法で適用されることとしてよい。また、ユーザ装置１０は、初送時には閾値を適用せずにＲＡ  ｐｒｅａｍｂｌｅの送信を行い、再送時に閾値を適用することとしてもよい。また、ユーザ装置１０は、初送を含むＮ回目（Ｎは１以上の整数）までのＲＡ  ｐｒｅａｍｂｌｅには閾値を適用せず、（Ｎ＋１）回目以降（（Ｎ＋１）回目を含む）のＲＡ  ｐｒｅａｍｂｌｅの送信の判断の際に閾値を適用することとしてもよい。また、初送を含むＮ回目（Ｎは１以上の整数）までのＲＡ  ｐｒｅａｍｂｌｅには閾値を適用し、（Ｎ＋１）回目以降（（Ｎ＋１）回目を含む）のＲＡ  ｐｒｅａｍｂｌｅの送信の判断の際に閾値を適用しないこととしてもよい。例えば、Ｎ＝１の場合、初送で閾値を適用し、以降の再送では閾値を適用しない。
【００７１】
上記のＮは、例えば、基地局２０からユーザ装置１０にＤＣＩ、ＭＡＣ信号、ＲＲＣ信号等により通知される。あるいは、基地局２０とユーザ装置１０においてＮが予め設定されていてもよい。
【００７２】
なお、受信品質については、ＲＡ  ｐｒｅａｍｂｌｅの送信時（実際には送信の直前）のタイミングで測定された受信品質を用いてもよいし、初送（あるいは前回再送）と再送との時間間隔が短い場合には、再送時の判断に、初送（あるいは前回再送）時に測定された受信品質を使用してもよい。
【００７３】
図８に示す例はＮ＝１の場合を示す。図８に示すように、ユーザ装置１０は、初送時には閾値を適用せず、最初の再送時に閾値を適用している。
【００７４】
ユーザ装置１０は、再送の際に、初送（あるいは前回再送）時におけるＲＡＣＨリソースサブセットとは異なるＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを送信するケースがある。例えば、ユーザ装置１０は、初送時には、検出できた複数ＢＳ送信ビームの中の１つとしてのＢＳ送信ビームＡに対応するＲＡＣＨリソースサブセットでＲＡ  ｐｒｅａｍｂｌｅを送信したが、ＲＡＲを受信できなかったので、再送時には、検出できた複数ＢＳ送信ビームの中の別のビームであるＢＳ送信ビームＢに対応するＲＡＣＨリソースサブセットでＲＡ  ｐｒｅａｍｂｌｅを送信する。このようなケースにおいて、ユーザ装置１０は、あるＲＡ  ｐｒｅａｍｂｌｅ送信と、当該ＲＡ  ｐｒｅａｍｂｌｅ送信に対する再送としての次のＲＡ  ｐｒｅａｍｂｌｅ送信との間でＲＡＣＨリソースサブセットを変えるかどうかを閾値を用いても判断してもよい。
【００７５】
具体例を図９を用いて説明する。まず、直接比較閾値ＴＨを用いる場合を説明する。ユーザ装置１０は、例えば、ＢＳ送信ビームＢにおける受信品質がＴＨよりも大きいことを検知することで、ＢＳ送信ビームＢに対応付けられたＲＡＣＨリソースサブセットＢを用いてＲＡ  ｐｒｅａｍｂｌｅを送信する（初送）。
【００７６】
ユーザ装置１０は、ＲＡＣＨリソースサブセットＢを用いてＲＡ  ｐｒｅａｍｂｌｅを送信したがＲＡＲ  ｗｉｎｄｏｗ内でＲＡＲを受信しなかったので、別のＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを再送することを決定する。この場合、例えば、ユーザ装置１０は、ＢＳ送信ビームＢ以外で、受信品質がＴＨよりも大きなＢＳ送信ビームとしてＢＳ送信ビームＣを検出する。より具体的には、例えば、ユーザ装置１０は、ＢＳ送信ビームＣに紐付られた基本ブロードキャスト／ＳＳを、ＴＨよりも大きな受信品質で受信できたことを検出する。そして、ユーザ装置１０は、ＢＳ送信ビームＣに対応付けられたＲＡＣＨリソースサブセットＣを使用してＲＡ  ｐｒｅａｍｂｌｅを再送する。
【００７７】
次に、相対閾値ＲＴＨを用いる場合を説明する。ユーザ装置１０は、まず、ＢＳ送信ビームＢに対応するＲＡＣＨリソースサブセットＢを用いてＲＡ  ｐｒｅａｍｂｌｅを送信したが、ＲＡＲ  ｗｉｎｄｏｗ内でＲＡＲを受信しなかったので、別のＲＡＣＨリソースサブセットを使用してＲＡ  ｐｒｅａｍｂｌｅを再送することを決定する。
【００７８】
ここで、ＢＳ送信ビームＢにおける受信品質をＢとする。例えば、ユーザ装置１０は、受信品質が（Ｂ‐ＲＴＨ）よりも大きなＢＳ送信ビームとしてＢＳ送信ビームＣを検出する。そして、ユーザ装置１０は、ＢＳ送信ビームＣに対応付けられたＲＡＣＨリソースサブセットＣを使用してＲＡ  ｐｒｅａｍｂｌｅを再送する。
【００７９】
上記のように、本実施例では、閾値を用いてＲＡ  ｐｒｅａｍｂｌｅの送信を制限するので、受信品質の良くないＢＳ送信ビームに対応するＲＡＣＨリソースサブセットでＲＡ  ｐｒｅａｍｂｌｅを送信することにより生じ得る不適切なビーム選択の可能性を低減できるとともに、周囲への干渉を低減することができる。
【００８０】
（実施例２）
次に、実施例２を説明する。実施例２は、実施例１（閾値を用いたＲＡ  ｐｒｅａｍｂｌｅの送信制限）を前提とする。ただし、実施例１を前提とすることは必須ではなく、基本例のみを前提としてもよい。実施例２では、ＲＡＲ  ｗｉｎｄｏｗの設定例について説明する。以下、実施例２−１と実施例２−２を説明する。
【００８１】
＜実施例２−１＞
実施例２−１では、異なるＢＳ送信ビームに対応する複数のＲＡＣＨリソースサブセットのそれぞれに対してＲＡＲ  ｗｉｎｄｏｗが設定される。
【００８２】
図１０は、ＲＡＲ  ｗｉｎｄｏｗを時間方向で分けることで、複数のＲＡＣＨリソースサブセットのそれぞれに対するＲＡＲ  ｗｉｎｄｏｗが設定される場合の例を示す。図１０の場合、ＲＡ  ｐｒｅａｍｂｌｅが送信されたＲＡＣＨリソースサブセットＢに対してＲＡＲ  ｗｉｎｄｏｗ‐Ｂが設定され、ＲＡ  ｐｒｅａｍｂｌｅが送信されたＲＡＣＨリソースサブセットＣに対してＲＡＲ  ｗｉｎｄｏｗ‐Ｃが設定される。
【００８３】
例えば、ＲＡ  ｐｒｅａｍｂｌｅを送信したタイミング（時刻）から、当該ＲＡ  ｐｒｅａｍｂｌｅを送信したＲＡＣＨリソースサブセットに対応するＲＡＲ  ｗｉｎｄｏｗの開始タイミング（時刻）までの時間長（ここでは便宜上「オフセット」と呼ぶ）と、当該ＲＡＲ  ｗｉｎｄｏｗの時間長（ここでは便宜上「ｗｉｎｄｏｗ時間長」と呼ぶ）とをユーザ装置１０に設定しておくことで、ユーザ装置１０は、オフセットとｗｉｎｄｏｗ時間長とから、送信したＲＡ  ｐｒｅａｍｂｌｅに対応するＲＡＲ  ｗｉｎｄｏｗを決定できる。また、基地局２０も当該オフセットとｗｉｎｄｏｗ時間長とを保持し、ＲＡ  ｐｒｅａｍｂｌｅを受信したタイミングに基づき、ユーザ装置１０で使用されるＲＡＲ  ｗｉｎｄｏｗを特定できる。
【００８４】
上記のオフセットとｗｉｎｄｏｗ時間長は、基地局２０からユーザ装置１０に対し、ＤＣＩ、ＭＡＣ信号、ＲＲＣ信号等で設定されてもよいし、基地局２０とユーザ装置１０において予め設定されていてもよい。
【００８５】
図１１は、ＲＡＲ  ｗｉｎｄｏｗを周波数方向で分けることで、複数のＲＡＣＨリソースサブセットのそれぞれに対するＲＡＲ  ｗｉｎｄｏｗが設定される場合の例を示す。図１１の場合、ＲＡ  ｐｒｅａｍｂｌｅが送信されたＲＡＣＨリソースサブセットＢに対してＲＡＲ  ｗｉｎｄｏｗ‐Ｂが設定され、ＲＡ  ｐｒｅａｍｂｌｅが送信されたＲＡＣＨリソースサブセットＣに対してＲＡＲ  ｗｉｎｄｏｗ‐Ｃが設定される。
【００８６】
例えば、ＲＡ  ｐｒｅａｍｂｌｅ送信タイミングと周波数位置（例：中心周波数と幅）との対応関係をユーザ装置１０に設定しておくことで、ユーザ装置１０は、ＲＡ  ｐｒｅａｍｂｌｅを送信したタイミングと対応関係から、ＲＡＲ  ｗｉｎｄｏｗを決定できる。ＲＡＲ  ｗｉｎｄｏｗの時間方向の位置（開始タイミングと時間長）については、例えば、所定数個のＲＡＣＨリソースサブセット（例：図１１に示す３つのＲＡＣＨリソースサブセットＡ、Ｂ，Ｃ）に対する開始タイミングと時間長を、当該所定数個のＲＡＣＨリソースサブセットに対して共通の値として固定的に定めておき、それを使用する。もしくは、図１０を参照して説明した方法を、図１１で示す方法における時間方向に適用してもよい。
【００８７】
ＲＡ  ｐｒｅａｍｂｌｅ送信タイミングと周波数位置との対応関係を示す情報は、基地局２０からユーザ装置１０に対し、ＤＣＩ，ＭＡＣ信号、ＲＲＣ信号等で設定されてもよいし、基地局２０とユーザ装置１０において予め設定されていてもよい。
【００８８】
実施例２−１において、例えば、複数のＲＡ  ｐｒｅａｍｂｌｅ送信に対応する複数のＲＡＲ  ｗｉｎｄｏｗは重ならないように設定される。これにより、ユーザ装置１０は、ＲＡＲを受信したＲＡＲ  ｗｉｎｄｏｗに基づいて、受信したＲＡＲがどのＲＡＣＨリソースサブセット（つまり、どのＢＳ送信ビーム）に対応するＲＡＲかを判別できる。このように、複数のＲＡ  ｐｒｅａｍｂｌｅ送信に対応する複数のＲＡＲ  ｗｉｎｄｏｗを重ならないように設定することで、後述する識別子の送信が不要となり、シグナリング量を削減できる。
【００８９】
実施例２−１において、複数のＲＡ  ｐｒｅａｍｂｌｅ送信に対応する複数のＲＡＲ  ｗｉｎｄｏｗが重なることを許容してもよい。この場合には、例えば、基地局２０は、ＲＡＲ内もしくはＲＡ−ＲＮＴＩ（送信信号がＲＡＲであることを示す識別子）の中に、当該ＲＡＲが、どのＲＡＣＨリソースサブセット（つまり、どのＢＳ送信ビーム）に対応するＲＡＲであるかを識別するための識別子を含める。当該識別子は、例えば、基本ブロードキャスト情報／ＳＳを識別するインデックス、ＲＡＣＨリソースサブセットを識別するインデックスである。例えば、ＲＡＲ  ｗｉｎｄｏｗ−ＡとＲＡＲ  ｗｉｎｄｏｗ−Ｂとの間に、重複する時間幅が存在する場合において、ユーザ装置１０が当該重複する時間幅でＲＡＲを受信する場合でも、ユーザ装置１０は、上記の識別子により、当該ＲＡＲがどのＲＡＣＨリソースサブセットに対応するＲＡＲであるかを判断できる。このように重複を許容することで、全体のＲＡＲ  ｗｉｎｄｏｗの時間長を短くでき、遅延を削減できる。
【００９０】
＜実施例２−２＞
図１２に示すように、実施例２−２では、異なるＢＳ送信ビームに対応する複数のＲＡＣＨリソースサブセットに共通に１つのＲＡＲ  ｗｉｎｄｏｗが設定される。例えば、Ｎ個（Ｎは１以上の整数）のＲＡＣＨリソースサブセットに共通に１つのＲＡＲ  ｗｉｎｄｏｗが設定される。Ｎの値は、基地局２０からユーザ装置１０に対し、ＤＣＩ、ＭＡＣ信号、ＲＲＣ信号等で設定されてもよいし、基地局２０とユーザ装置１０において予め設定されていてもよいし、ある値（例：ＢＳ送信ビーム数）と同じであると定められていてもよい。
【００９１】
また、例えば、ユーザ装置１０は、Ｎ個の連続するＲＡＣＨリソースサブセットにおいて、少なくとも１つのＲＡＣＨリソースサブセットでＲＡ  ｐｒｅａｍｂｌｅを送信した場合に、当該Ｎ個のＲＡＣＨリソースサブセットに対応する（共通の）ＲＡ  ｗｉｎｄｏｗでＲＡＲを監視する。
【００９２】
Ｎ個のＲＡＣＨリソースサブセットに対応するＲＡ  ｗｉｎｄｏｗについては、例えば、Ｎ個のＲＡＣＨリソースサブセットの時間方向の末尾から、ＲＡＲ  ｗｉｎｄｏｗの開始タイミング（時刻）までの時間長（ここでは便宜上「オフセット」と呼ぶ）と、当該ＲＡＲ  ｗｉｎｄｏｗの時間長（ここでは便宜上「ｗｉｎｄｏｗ時間長」と呼ぶ）とをユーザ装置１０に設定しておくことで、ユーザ装置１０は、オフセットとｗｉｎｄｏｗ時間長とから、ＲＡＲ  ｗｉｎｄｏｗを決定できる。また、基地局２０も当該オフセットとｗｉｎｄｏｗ時間長とを保持し、ＲＡ  ｐｒｅａｍｂｌｅを受信したタイミングに基づき、ユーザ装置１０で使用されるＲＡＲ  ｗｉｎｄｏｗを特定できる。
【００９３】
上記のオフセットとｗｉｎｄｏｗ時間長は、基地局２０からユーザ装置１０に対し、ＤＣＩ、ＭＡＣ信号、ＲＲＣ信号等で設定されてもよいし、基地局２０とユーザ装置１０において予め設定されていてもよい。
【００９４】
実施例２−２では、複数のＲＡＣＨリソースサブセットに共通に１つのＲＡＲ  ｗｉｎｄｏｗを使用するので、例えば、基地局２０は、ＲＡＲ内もしくはＲＡ−ＲＮＴＩの中に、当該ＲＡＲが、どのＲＡＣＨリソースサブセット（つまり、どのＢＳ送信ビーム）に対応するＲＡＲであるかを識別するための識別子を含める。当該識別子は、例えば、基本ブロードキャスト情報／ＳＳを識別するインデックス、ＲＡＣＨリソースサブセットを識別するインデックスである。例えば、ユーザ装置１０が、複数のＲＡＣＨリソースサブセットに共通の１つのＲＡＲ  ｗｉｎｄｏｗでＲＡＲを受信する場合でも、ユーザ装置１０は、上記の識別子により、当該ＲＡＲがどのＲＡＣＨリソースサブセットに対応するＲＡＲであるかを判断できる。
【００９５】
また、ＲＡＣＨリソースサブセットの順番と、ＲＡＲ  ｗｉｎｄｏｗ内のＲＡＲの順番を対応付けてもよい。例えば、図１２に示すように、ユーザ装置１０が、ＲＡＣＨリソースサブセットＢでＲＡ  ｐｒｅａｍｂｌｅを送信し、その次に、ＲＡＣＨリソースサブセットＣでＲＡ  ｐｒｅａｍｂｌｅを送信した場合に、これらＲＡＣＨリソースサブセットに共通のＲＡＲ  ｗｉｎｄｏｗで最初に受信するＲＡＲをＲＡＣＨリソースサブセットＢに対応するＲＡＲであると判断し、次に受信するＲＡＲをＲＡＣＨリソースサブセットＣに対応するＲＡＲであると判断する。
【００９６】
実施例２−２のように、複数のＲＡＣＨリソースサブセットに共通のＲＡＲ  ｗｉｎｄｏｗを使用することで、全体のＲＡＲ  ｗｉｎｄｏｗの時間長を短くでき、遅延を削減できる。
(実施例３)
次に、実施例３を説明する。実施例３も基本例をベースとするが、ベースとするものは基本例に限られるわけではない。また、実施例３は、実施例１及び／又は実施例２と組み合わせて実施することが可能である。また、実施例３は、実施例１及び／又は実施例２と組み合わせないで実施することも可能である。
【００９７】
ランダムアクセス手順において、ユーザ装置１０は、自身が送信したＲＡＣＨ  ｐｒｅａｍｂｌｅの時間・周波数リソースの情報から算出される所定の識別情報（ここでは、ＲＡ−ＲＮＴＩ）によりＲＡＲを監視する。
【００９８】
LTEのRA-RNTIに関しては、下記のような規定がされている。
【００９９】
「RA-RNTI= 1 + t_id + 10*f_id、where t_id is the index of the first subframe of the specified PRACH (0≦ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0≦ f_id< 6) 」（3GPP spec 36.321から引用）。
【０１００】
また、RAR windowに関しては、下記のような規定がなされている。NRのRAR window は、starting timingがLTEより早まっている。
【０１０１】
「LTE： Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap or a Sidelink Discovery Gap for Transmission or a Sidelink Discovery Gap for Reception, the MAC entity shall monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize.」（3GPP spec 36.321から引用）。
【０１０２】
ＮＲについて、下記の合意がなされている。
【０１０３】
「・    For RAR, X can be supported for the timing gap between the end of MSg1 transmission and the starting position of the CORESET for RAR ・    Value of X = ceiling(D/(symbol duration))*symbol duration, where the symbol duration is based on the RAR numerology ・    Where D is to accommodate sufficient time for UE Tx-Rx switching if needed (e.g., for TDD) ・    Note: UE Tx-Rx switching latency is up to RAN4」（RAN1 NR-AH#3のchairmans noteから引用）。
【０１０４】
なお、FDDの場合では0symbolを採用する可能性がある。つまりpreamble送信直後にRAR windowが始まる可能性がある。また、TDDの場合はUE Tx-Rx switching latency（標準化上（RAN4)で決められる固定値と想定）によってRAR windowの開始タイミングが決まるが、preamble送信の1symbol後等の早いタイミングでRAR window開始となる可能性が高いと考えられる。
【０１０５】
NRのRA-RNTIに関し、上記のとおりRAR windowの開始タイミングがLTEより早まっている。ただし、基地局側のデコード等の能力によっては十分に早くRARを送信する準備が整わない可能性がある。その場合、LTE同様のレベルのRARスケジューリングの柔軟性及びユーザ容量を考慮するとLTEより大きいRAR window lengthが必要になると考えられる。
【０１０６】
また、既に説明したとおりNRではbeamformingが考えられているため、異なるbeamを持つRARは同じMAC PDUに多重することができない。特にアナログbeamformingのケースでは同じ時間タイミング上で異なるビームを持つRARを送信することができない。これらを考慮するとLTEに比べてRARスケジューリングに制約があるため、LTEより大きいRAR window lengthが必要になると考えられる。
【０１０７】
また、NRではOFDMシンボルレベルの時間長の短いpreamble formatがサポートされている。また、PRACH SCS（subcarrier spacing）としてLTEとは異なる複数のSCS（1.25, 5, 15, 30, 60, 120kHz）がサポートされており、このSCSによってslotの時間長が異なる。これらを考慮するとRA-RNTIの計算としてsubframeより小さい単位（たとえばsymbol index、もしくはRACH occasion index、もしくはslot index等）を含めることが考えられる。
【０１０８】
実施例３では、下記の提案１〜５についての例を説明する。下記の提案１〜５は適宜組み合わせて実施可能である。
【０１０９】
＜提案１＞
提案１においては、10ms以上のRAR window lengthをサポートするために、NRのRA-RNTIとして、system frame numberを考慮した計算をサポート(system frame numberは10ms単位、subframeは1ms単位）する。system frame numberは、現在のLTEで規定されたものでもよいし、system frame numberは、現在のLTEで規定されたもの以外の新たに規定されたものでもよい。例えば、ユーザ装置１０がpreambleを送信したsystem frame numberをsfnとすると、ユーザ装置１０はｆ(sfn)（ｆは所定の関数）によりRA-RNTIを算出する。
【０１１０】
なお、異なるリソースで送信されたPRACH preambleを区別するためには、RA-RNTI計算としては少なくともmax RAR window length以上の時間indexを持つ必要がある。
【０１１１】
＜提案２＞
提案２においては、RA-RNTIとしてsystem frame numberのodd/even（偶数/奇数）のfactorを含める。例えば、ユーザ装置１０がpreambleを送信したsystem frame numberのodd/even（偶数/奇数）をsfnoeとすると、ユーザ装置１０はg(sfnoe)（gは所定の関数）によりRA-RNTIを算出する。
【０１１２】
＜提案３＞
提案３においては、mod (system frame number, x )として他のxの値をサポートしても良い。なお、提案２は提案３の特別なバージョンという位置づけになる。すなわち、提案３におけるx=2の場合が提案２にあたる、つまり、x=2ということはmod(system frame number, 2)なので、odd/even（偶数/奇数）のfactorを含めていることになる。
【０１１３】
例えば、ユーザ装置１０がpreambleを送信したsystem frame numberをsfnとすると、ユーザ装置１０はh(mod (sfn, x ))（hは所定の関数）によりRA-RNTIを算出する。
【０１１４】
＜提案４＞
提案４においては、使用するsubframe indexを、LTEにおける0〜9の範囲のsubframe indexから拡張しても良い。例えば、subframe index の範囲を0〜19とする等である。同様にslot index,、symbol index,、RACH occasion index等についても、LTEにおける値よりも大きな値により同様にサポートされても良い。
【０１１５】
例えば、ユーザ装置１０がpreambleを送信したsubframe indexをsiとすると、ユーザ装置１０はj(si)（jは所定の関数）によりRA-RNTIを算出する。
【０１１６】
＜提案５＞
提案５においては、ユーザ装置１０が、RARにおける、上記の10ms以上離れたpreambleを区別するために、RA-RNTIではなく、RARの中のcontentsとして、例えば、system frame numberのodd/even等の上記提案情報を含んでも良い。
【０１１７】
例えば、ユーザ装置１０は、自身の送信したpreambleに対するRARを監視する場合に、基地局２０によりRARに含められるcontents（system frame numberのodd/even等）をサーチする。なお、このcontentsを所定の識別情報と称してもよい。
【０１１８】
（装置構成）
次に、これまでに説明した処理動作を実行するユーザ装置１０及び基地局２０の機能構成例を説明する。ユーザ装置１０及び基地局２０はそれぞれ、少なくとも実施例１と２と３を実施する機能を含む。ただし、ユーザ装置１０及び基地局２０はそれぞれ、実施例１と２と３の中の一部の機能のみを備えることとしてもよい。
【０１１９】
＜ユーザ装置＞
図１３は、ユーザ装置１０の機能構成の一例を示す図である。図１３に示すように、ユーザ装置１０は、信号送信部１０１と、信号受信部１０２と、設定情報管理部１０３と、ＲＡ制御部１０４とを有する。信号受信部１０２は、受信品質を測定する測定部１１２を含む。図１３に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。信号送信部１０１、信号受信部１０２は、それぞれ送信機、受信機と称してもよい。
【０１２０】
信号送信部１０１は、送信データから送信信号を作成し、当該送信信号を無線で送信する。信号受信部１０２は、各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する。また、信号送信部１０１は、送信側のビームフォーミングを実行するように構成され、信号受信部１０２は、受信側のビームフォーミングを実行するように構成されている。
【０１２１】
設定情報管理部１０３は、信号受信部１０２により基地局２０から受信した各種の設定情報を格納する。設定情報の内容は、例えば、これまでに説明した閾値の情報、ビームとＲＡＣＨリソースサブセットとの対応情報等である。また、設定情報管理部１０３は、ユーザ装置１０に予め設定される（ｐｒｅｃｏｎｆｉｇｕｒｅｄの）設定情報も格納する。
【０１２２】
ＲＡ制御部１０４は、基本例、及び実施例１、２において説明した、ユーザ装置１０におけるランダムアクセス手順の処理を実行する。なお、ＲＡ制御部１０４における信号送信に関する機能部を信号送信部１０１に含め、ＲＡ制御部１０４における信号受信に関する機能部を信号受信部１０２に含めてもよい。
【０１２３】
また、例えば、信号受信部１０２が、複数のビームにより送信される複数の所定の信号を受信するように構成され、信号送信部１０１が、前記複数のビームのうちの少なくとも１つのビームに対応するリソースを用いてプリアンブルを送信するように構成され、更に、信号受信部１０２が、前記複数のビームのそれぞれにおける受信品質を測定するように構成され、信号送信部１０１が、所定の条件を満たす受信品質のビームに対応するリソースを用いてプリアンブルを送信するように構成される。
【０１２４】
前記所定の条件は、例えば、前記受信品質が所定閾値よりも良いことである、又は、前記受信品質と、前記複数のビームの受信品質のうちの最良の受信品質との差分が所定相対閾値よりも小さいことである。
【０１２５】
信号送信部１０１は、受信品質が前記所定の条件を満たす全てのビームのうち、予め定めた上限数のビームに対応するリソースを用いて当該上限数のプリアンブルを送信するように構成されてもよい。
【０１２６】
信号送信部１０１は、第１のリソースで送信したプリアンブルの再送を、受信品質が前記所定の条件を満たすビームに対応する第２のリソースを使用して行うように構成されてもよい。
【０１２７】
信号受信部１０２は、信号送信部１０１によるプリアンブルの送信に使用されたリソースに対応する時間ウィンドウ内で当該プリアンブルに対する応答を監視する、又は、信号送信部１０１によるプリアンブルの送信に使用されたリソースを含む複数のリソースに共通の時間ウィンドウ内で当該プリアンブルに対する応答を監視するように構成されてもよい。
【０１２８】
また、信号送信部１０１は基地局にプリアンブルを送信し、信号受信部１０２は、所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視し、前記信号受信部１０２は、システムフレーム番号を用いて前記所定の識別情報を算出するようにしてもよい。この構成により、例えば、従来よりも長いRAR window lengthを採用する場合でも、適切にランダムアクセス手順を実施できる。なお、本実施の形態において、所定の識別情報の算出は、信号送信部１０１が行ってもよいし、ＲＡ制御部１０４が行ってもよい。
【０１２９】
前記信号受信部１０２は、前記システムフレーム番号が奇数であるか、偶数であるかの情報を用いて前記所定の識別情報を算出することとしてもよい。前記信号受信部１０２は、前記システムフレーム番号に対する剰余演算を行うことにより前記所定の識別情報を算出することとしてもよい。
【０１３０】
また、信号送信部１０１は基地局にプリアンブルを送信し、信号受信部１０２は、所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視し、信号受信部１０２は、サブフレームインデックスを用いて前記所定の識別情報を算出し、当該サブフレームインデックスの範囲は０〜９よりも大きいこととしてもよい。この構成により、例えば、従来よりも長いRAR window lengthを採用する場合でも、適切にランダムアクセス手順を実施できる。
【０１３１】
＜基地局２０＞
図１４は、基地局２０の機能構成の一例を示す図である。図１４に示すように、基地局２０は、信号送信部２０１と、信号受信部２０２と、設定情報管理部２０３と、ＲＡ制御部２０４とを有する。図１４に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。
【０１３２】
信号送信部２０１は、ユーザ装置１０側に送信する信号を生成し、当該信号を無線で送信する機能を含む。信号受信部２０２は、ユーザ装置１０から送信された各種の信号を受信し、受信した信号から、例えばより上位のレイヤの情報を取得する機能を含む。また、信号送信部２０１は、送信側のビームフォーミングを実行するように構成され、信号受信部２０２は、受信側のビームフォーミングを実行するように構成されている。
【０１３３】
設定情報管理部２０３は、ユーザ装置１０に送信する各種の設定情報を格納する。設定情報の内容、例えば、これまでに説明した閾値情報、対応情報等である。また、設定情報管理部２０３は、基地局２０に予め設定される（ｐｒｅｃｏｎｆｉｇｕｒｅｄ）設定情報も格納する。
【０１３４】
ＲＡ制御部２０４は、基本例、実施例１、２において説明した、基地局２０におけるランダムアクセス手順の処理を実行する。なお、ＲＡ制御部２０４における信号送信に関する機能部を信号送信部２０１に含め、ＲＡ制御部２０４における信号受信に関する機能部を信号受信部２０２に含めてもよい。
【０１３５】
＜ハードウェア構成＞
上記実施の形態の説明に用いたブロック図（図１３〜図１４）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に複数要素が結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。
【０１３６】
また、例えば、本発明の一実施の形態におけるユーザ装置１０と基地局２０はいずれも、本実施の形態に係る処理を行うコンピュータとして機能してもよい。図１５は、本実施の形態に係るユーザ装置１０と基地局２０のハードウェア構成の一例を示す図である。上述のユーザ装置１０と基地局２０はそれぞれ、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【０１３７】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。ユーザ装置１０と基地局２０のハードウェア構成は、図に示した１００１〜１００６で示される各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【０１３８】
ユーザ装置１０と基地局２０における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【０１３９】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）で構成されてもよい。
【０１４０】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、図１３に示したユーザ装置１０の信号送信部１０１、信号受信部１０２、設定情報管理部１０３、ＲＡ制御部１０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。また、例えば、図１４に示した基地局２０の信号送信部２０１と、信号受信部２０２と、設定情報管理部２０３、ＲＡ制御部２０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。
【０１４１】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る処理を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。
【０１４２】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ  ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。
【０１４３】
通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、ユーザ装置１０の信号送信部１０１及び信号受信部１０２は、通信装置１００４で実現されてもよい。また、基地局２０の信号送信部２０１及び信号受信部２０２は、通信装置１００４で実現されてもよい。
【０１４４】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
【０１４５】
また、プロセッサ１００１及びメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。
【０１４６】
また、ユーザ装置１０と基地局２０はそれぞれ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、ＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）、ＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。
【０１４７】
（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、前記基地局から、複数のビームにより送信される複数の所定の信号を受信する受信部と、前記複数のビームのうちの少なくとも１つのビームに対応するリソースを用いてプリアンブルを送信する送信部と、を備え、前記受信部は、前記複数のビームのそれぞれにおける受信品質を測定し、前記送信部は、所定の条件を満たす受信品質のビームに対応するリソースを用いてプリアンブルを送信することを特徴とするユーザ装置が提供される。
【０１４８】
上記の構成により、性能劣化、干渉を与えること等を回避して、ビームフォーミングが適用されるランダムアクセス手順を適切に実行することが可能となる。
【０１４９】
前記所定の条件は、例えば、前記受信品質が所定閾値よりも良いことである、又は、
前記受信品質と、前記複数のビームの受信品質のうちの最良の受信品質との差分が所定相対閾値よりも小さいことである。閾値を使用するこの構成により、正確な処理を迅速に行うことができる。
【０１５０】
前記送信部は、受信品質が前記所定の条件を満たす全てのビームのうち、予め定めた上限数のビームに対応するリソースを用いて当該上限数のプリアンブルを送信することとしてもよい。この構成により、プリアンブル数を制限できるので、例えば、無駄なリソースの使用を抑えることができる。
【０１５１】
前記送信部は、第１のリソースで送信したプリアンブルの再送を、受信品質が前記所定の条件を満たすビームに対応する第２のリソースを使用して行うこととしてもよい。この構成により、再送を適切なリソースを使用して行うことができるようになる。
【０１５２】
前記受信部は、前記送信部によるプリアンブルの送信に使用されたリソースに対応する時間ウィンドウ内で当該プリアンブルに対する応答を監視する、又は、前記送信部によるプリアンブルの送信に使用されたリソースを含む複数のリソースに共通の時間ウィンドウ内で当該プリアンブルに対する応答を監視するようにしてもよい。この構成により、プリアンブルに対する応答を適切な時間ウィンドウで監視できる。
【０１５３】
また、本実施の形態により、基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、前記基地局にプリアンブルを送信する送信部と、所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視する受信部と、を備え、前記受信部は、システムフレーム番号を用いて前記所定の識別情報を算出することを特徴とするユーザ装置が提供される。この構成により、例えば、従来よりも長いRAR window lengthを採用する場合でも、適切にランダムアクセス手順を実施できる。
【０１５４】
前記受信部は、前記システムフレーム番号が奇数であるか、偶数であるかの情報を用いて前記所定の識別情報を算出することとしてもよい。前記受信部は、前記システムフレーム番号に対する剰余演算を行うことにより前記所定の識別情報を算出することとしてもよい。
【０１５５】
また、本実施の形態により、基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、前記基地局にプリアンブルを送信する送信部と、所定の時間ウィンドウ内で、所定の識別情報を使用することにより、前記プリアンブルに対する応答を監視する受信部と、を備え、前記受信部は、サブフレームインデックスを用いて前記所定の識別情報を算出し、当該サブフレームインデックスの範囲は０〜９よりも大きいことを特徴とするユーザ装置が提供される。この構成により、例えば、従来よりも長いRAR window lengthを採用する場合でも、適切にランダムアクセス手順を実施できる。
【０１５６】
（実施形態の補足）
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べた処理手順については、矛盾の無い限り処理の順序を入れ替えてもよい。処理説明の便宜上、ユーザ装置１０と基地局２０は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置１０が有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って基地局２０が有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【０１５７】
また、情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）、ＵＣＩ（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ））、上位レイヤシグナリング（例えば、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）シグナリング、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）シグナリング、ブロードキャスト情報（ＭＩＢ（Ｍａｓｔｅｒ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）、ＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ）メッセージ、ＲＲＣ接続再構成（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージなどであってもよい。
【０１５８】
本明細書で説明した各態様／実施形態は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Ｆｕｔｕｒｅ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ｕｌｔｒａ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ｕｌｔｒａ−ＷｉｄｅＢａｎｄ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１５９】
本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１６０】
本明細書において基地局２０によって行われるとした特定動作は、場合によってはその上位ノード（ｕｐｐｅｒ  ｎｏｄｅ）によって行われることもある。基地局２０を有する１つまたは複数のネットワークノード（ｎｅｔｗｏｒｋ  ｎｏｄｅｓ）からなるネットワークにおいて、ユーザ装置１０との通信のために行われる様々な動作は、基地局２０および／または基地局２０以外の他のネットワークノード（例えば、ＭＭＥまたはＳ−ＧＷなどが考えられるが、これらに限られない）によって行われ得ることは明らかである。上記において基地局２０以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥおよびＳ−ＧＷ）であってもよい。
【０１６１】
本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。
【０１６２】
ユーザ装置１０は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。
【０１６３】
基地局２０は、当業者によって、ＮＢ（ＮｏｄｅＢ）、ｅＮＢ（ｅｎｈａｎｃｅｄ  ＮｏｄｅＢ）、ベースステーション（Ｂａｓｅ  Ｓｔａｔｉｏｎ）、またはいくつかの他の適切な用語で呼ばれる場合もある。
【０１６４】
本明細書で使用する「判断（ｄｅｔｅｒｍｉｎｉｎｇ）」、「決定（ｄｅｔｅｒｍｉｎｉｎｇ）」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定（ｊｕｄｇｉｎｇ）、計算（ｃａｌｃｕｌａｔｉｎｇ）、算出（ｃｏｍｐｕｔｉｎｇ）、処理（ｐｒｏｃｅｓｓｉｎｇ）、導出（ｄｅｒｉｖｉｎｇ）、調査（ｉｎｖｅｓｔｉｇａｔｉｎｇ）、探索（ｌｏｏｋｉｎｇ  ｕｐ）（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認（ａｓｃｅｒｔａｉｎｉｎｇ）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信（ｒｅｃｅｉｖｉｎｇ）（例えば、情報を受信すること）、送信（ｔｒａｎｓｍｉｔｔｉｎｇ）（例えば、情報を送信すること）、入力（ｉｎｐｕｔ）、出力（ｏｕｔｐｕｔ）、アクセス（ａｃｃｅｓｓｉｎｇ）（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決（ｒｅｓｏｌｖｉｎｇ）、選択（ｓｅｌｅｃｔｉｎｇ）、選定（ｃｈｏｏｓｉｎｇ）、確立（ｅｓｔａｂｌｉｓｈｉｎｇ）、比較（ｃｏｍｐａｒｉｎｇ）などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１６５】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１６６】
「含む（ｉｎｃｌｕｄｅ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（ｏｒ）」は、排他的論理和ではないことが意図される。
【０１６７】
本開示の全体において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含み得る。
【０１６８】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【０１６９】
本特許出願は２０１７年１１月２８日に出願した日本国特許出願第２０１７−２２８４５５号に基づきその優先権を主張するものであり、日本国特許出願第２０１７−２２８４５５号の全内容を本願に援用する。
【符号の説明】
【０１７０】
１０  ユーザ装置
１０１  信号送信部
１０２  信号受信部
１１２  測定部
１０３  設定情報管理部
１０４  ＲＡ制御部
２０  基地局
２０１  信号送信部
２０２  信号受信部
２０３  設定情報管理部
２０４  ＲＡ制御部
１００１  プロセッサ
１００２  メモリ
１００３  ストレージ
１００４  通信装置
１００５  入力装置
１００６  出力装置
【図１】
2019107361.tif 000003
【図２】
2019107361.tif 000004
【図３】
2019107361.tif 000005
【図４】
2019107361.tif 000006
【図５】
2019107361.tif 000007
【図６】
2019107361.tif 000008
【図７】
2019107361.tif 000009
【図８】
2019107361.tif 000010
【図９】
2019107361.tif 000011
【図１０】
2019107361.tif 000012
【図１１】
2019107361.tif 000013
【図１２】
2019107361.tif 000014
【図１３】
2019107361.tif 000015
【図１４】
2019107361.tif 000016
【図１５】
2019107361.tif 000017
【国際調査報告】
2019107361.tif 000018
2019107361.tif 000019
2019107361.tif 000020