(57)【要約】【課題】ランダムアクセス手順において、ユーザ装置が、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避する。【解決手段】基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置において、所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、前記選択部により選択されたランダムアクセス信号を前記基地局に装置する送信部と、を備え、前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する。【選択図】図８
2019220986.tif 000002
【特許請求の範囲】
【請求項１】
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
共通制御チャネルで送信されるRRCConnectionRequest message、RRCConnectionReestablishmentRequest message、及びRRC connection resume messageのうちのいずれか一つであるCommon Control Channel Service Data Unit（CCCH SDU）にMACヘッダとを加えたサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、
前記選択部により選択されたランダムアクセス信号を前記基地局に送信する送信部と、を備え、
前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記CCCH SDUを前記共通制御チャネルで送信する
ことを特徴とするユーザ装置。
【請求項２】
前記MACヘッダを加えたCCCH SDUのサイズが前記所定の閾値よりも大きい場合に、前記選択部は、２つのランダムアクセス信号グループのうち、前記サイズが前記所定の閾値よりも大きい場合に対応するランダムアクセス信号グループを選択する
ことを特徴とする請求項１に記載のユーザ装置。
【請求項３】
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、
共通制御チャネルで送信されるRRCConnectionRequest message、RRCConnectionReestablishmentRequest message、及びRRC connection resume messageのうちのいずれか一つであるCommon Control Channel Service Data Unit（CCCH SDU）にMACヘッダとを加えたサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択ステップと、
前記選択ステップにより選択されたランダムアクセス信号を前記基地局に送信する送信ステップと、
前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記CCCH SDUを前記共通制御チャネルで送信する送信ステップと
を備えることを特徴とするランダムアクセス方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムにおいてユーザ装置（以下、ＵＥ）と基地局（以下、ｅＮＢ）との間で実行されるランダムアクセス手順に関連するものである。
【背景技術】
【０００２】
ＬＴＥ等の無線通信システムでは、ＵＥがｅＮＢとの接続を確立する場合や、再接続（再同期）を行う場合等にランダムアクセス（以下、ＲＡと略記する場合がある）手順が実行される。ＲＡ手順には、衝突型ＲＡ手順と、非衝突側ＲＡ手順がある。衝突型ＲＡ手順は、全ての目的に使用でき、非衝突側ＲＡ手順はハンドオーバ等の特定の目的に使用される。ここでは、衝突型ＲＡ手順を対象とする。
【０００３】
ＲＡ手順では、ＵＥがｅＮＢにRA preambleを送信し、ｅＮＢがＵＥにRA responseを返す。そして、ＵＥは、RA responseの中のUL grantで割り当てられた上りリソースを用いて制御メッセージをｅＮＢに送信する。この制御メッセージはMessage 3（メッセージ３）と呼ばれる（非特許文献１）。
【０００４】
Message 3では、接続時にはRRCConnectionRequest messageが、再接続時にはRRCConnectionReestablishmentRequest messageが、logical channel（論理チャネル）であるCCCH（Common Control Channel、共通制御チャネル）で送られる。
【０００５】
RRCConnectionRequest message、RRCConnectionReestablishementRequest messageは、標準仕様上、総称してCCCH SDU（Service Data Unit）とも呼ばれる。RRCConnectionRequest message、RRCConnectionReestablishmentRequest messageのサイズは共に４８ビットであり、これにMAC headerの８ビットが付加され、MAC PDUとしては５６ビットになる。すなわち、５６ビットのデータが、物理レイヤ（PHY）で送信可能な１つのTransport Block（トランスポートブロック）となり、そのサイズ（５６ビット）がTransport Block Size (TBS)となる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】3GPP TS 36.300 V12.8.0 (2015-12)
【非特許文献２】3GPP TS 36.321 V12.8.0 (2015-12)
【非特許文献３】3GPP TR 23.720 V1.2.0(2015-11)
【非特許文献４】3GPP R2-161745
【非特許文献５】3GPP TS 36.331 V12.8.0 (2015-12)
【発明の概要】
【発明が解決しようとする課題】
【０００７】
Message 3のTBSとして５６ビットよりも大きな値を割り当てることもできる。この場合、例えばPadding BSR（Padding Buffer Status Report）などがデータに付加される。ＬＴＥでは、RA preambleをグルーピングし、グループの中から選択されたRA preambleを用いてＵＥがＲＡ手順を行うことが規定されている（非特許文献２）。ｅＮＢは、送信されたRA preambleが属するグループにより、Message 3のサイズが大きくなるか否かを判定し、該当TBSをRA responseでＵＥに通知することができる。
【０００８】
具体的には、非特許文献２に記載されているように、Preamble group A/Bが設けられる。そして、Preamble group Bが存在し、システム情報で設定されたmessage size（messageSizeGroupA in RACH-ConfigCommon）よりもMessage 3のsizeが大きく、かつパスロスが所定の値以下である場合にPreamble group Bの中からRA preambleが選択される。そうでない場合は、Preamble group Aの中からRA preambleが選択される。
【０００９】
ところで、ＵＥがアイドル状態にあるときにｅＮＢ／ＵＥでＵＥコンテクストを保存しておき、接続状態に遷移する際に、保存したＵＥコンテクストを用いることで、接続のためのシグナリング量を削減する仕組みが検討されている。例えば、非特許文献３にはsolution 18として、その例が記載されている。
【００１０】
本仕組みにおいて、保存したＵＥコンテクストを用いてRRC connectionを再開するために、ＵＥがMessage 3で再開要求メッセージを送信する。このメッセージには、接続を再開するために用いるＩＤや認証情報が加えられるため、メッセージサイズが、既存のCCCH SDUのTBSの５６ビットを超える可能性がある（例えば、非特許文献４）。
【００１１】
従って、メッセージサイズの異なる複数のCCCH SDUが規定される可能性がある。メッセージサイズの異なる複数のCCCH SDUが規定される場合、ＵＥは、手順に応じて、異なるサイズのCCCH SDUをｅＮＢに送信する。例として、ＵＥは、通常のRRC connection requestを５６ビットのTBSで送信し、RRC connection resumeを６４ビットのTBSで送信するといったことが想定される。
【００１２】
従来はCCCH SDUのメッセージサイズは１つ（TBS：５６ビット）であったが、メッセージサイズが異なるCCCH SDUが規定されると、ｅＮＢは、RA responseでMessage 3のUL grantを割当てるまでに、CCCH SDUのサイズを考慮してUL grantで割り当てるTBSを決める必要がある。しかし、従来の仕組みでは、ｅＮＢがCCCH SDUのメッセージサイズをRA responseの送信前に知ることができないため、CCCH SDUのサイズを考慮してUL grantで割り当てるTBSを決めることができない。このため、例えば、ＵＥが、再開要求メッセージを送信しようとしても、TBSが不足して、送信できないといったことが発生し得る。
【００１３】
なお、上記のような課題は、再開要求メッセージ以外の制御メッセージを送信する場合にも生じ得る課題である。
【００１４】
本発明は上記の点に鑑みてなされたものであり、ランダムアクセス手順において、ユーザ装置が、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避する技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の実施の形態によれば、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
共通制御チャネルで送信されるRRCConnectionRequest message、RRCConnectionReestablishmentRequest message、及びRRC connection resume messageのうちのいずれか一つであるCommon Control Channel Service Data Unit（CCCH SDU）にMACヘッダとを加えたサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、
前記選択部により選択されたランダムアクセス信号を前記基地局に送信する送信部と、を備え、
前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記CCCH SDUを前記共通制御チャネルで送信する
ことを特徴とするユーザ装置が提供される。
【発明の効果】
【００１６】
本発明の実施の形態によれば、ランダムアクセス手順において、ユーザ装置が、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避する技術が提供される。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施の形態における通信システムの構成図である。
【図２】ランダムアクセス手順を示す図である。
【図３】コンテクスト保持方式例１の処理シーケンスを示す図である。
【図４】コンテクスト保持方式例１の処理シーケンスを示す図である。
【図５】コンテクスト保持方式例２の処理シーケンスを示す図である。
【図６】実施例１における仕様変更例を示す図である。
【図７】実施例１における仕様変更例を示す図である。
【図８】実施例２における処理手順を示すフローチャートである。
【図９】実施例２における仕様変更例を示す図である。
【図１０】実施例２における仕様変更例を示す図である。
【図１１】実施例２における仕様変更例を示す図である。
【図１２】実施例２における仕様変更例を示す図である。
【図１３】実施例２の変形例を説明するための図である。
【図１４】実施例２の変形例における処理手順を示すフローチャートである。
【図１５】実施例２の変形例における仕様変更例を示す図である。
【図１６】実施例２の変形例における仕様変更例を示す図である。
【図１７】実施例２の変形例における仕様変更例を示す図である。
【図１８】実施例２の変形例における仕様変更例を示す図である。
【図１９】実施例３における処理手順を示すフローチャートである。
【図２０】実施例３における仕様変更例を示す図である。
【図２１】実施例３における仕様変更例を示す図である。
【図２２】実施例３における仕様変更例を示す図である。
【図２３】実施例４における処理手順を示すフローチャートである。
【図２４】ＵＥの構成図である。
【図２５】ＵＥのＨＷ構成図である。
【図２６】ｅＮＢの構成図である。
【図２７】ｅＮＢのＨＷ構成図である。
【発明を実施するための形態】
【００１８】
以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態では、ＬＴＥのシステムを対象としているが、本発明はＬＴＥに限らずに適用可能である。また、本明細書及び特許請求の範囲では、特に断らない限り、「ＬＴＥ」の用語は３ＧＰＰの特定のＲｅｌ（リリース）に限定されない。また、「ＬＴＥ」は「５Ｇ」を含むこととする。また、本実施の形態で説明する処理において、「以下」と「より小さい」は実質的に同じであり、どちらを用いても良い。
【００１９】
（システム全体構成）
図１は、本発明の実施の形態における通信システムの構成例を示す図である。図１に示すように、本実施の形態の通信システムは、ｅＮＢ１０、ｅＮＢ２０、ＭＭＥ３０、Ｓ−ＧＷ（Serving Gateway）４０、ＵＥ５０を含む。
【００２０】
ＵＥ５０は携帯電話機等のユーザ装置である。ｅＮＢ１０、２０はそれぞれ基地局である。ＭＭＥ３０は、ｅＮＢを収容し、位置登録、ページング、ハンドオーバ等のモビリティ制御、ベアラ確立／削除等を行うノード装置である。Ｓ−ＧＷ４０は、ユーザデータ（Ｕ−Ｐｌａｎｅデータ）の中継を行うノード装置である。なお、ＭＭＥ３０とＳ−ＧＷ４０からなるシステムを通信制御装置と呼ぶ。また、ＭＭＥ３０とＳ−ＧＷ４０を１つの装置で構成し、それを通信制御装置と呼ぶこととしてもよい。
【００２１】
図１に示すように、ＭＭＥ３０とｅＮＢ１０、２０間はＳ１−ＭＭＥインターフェースで接続され、Ｓ−ＧＷ４０とｅＮＢ１０、２０間はＳ１−Ｕインターフェースで接続される。点線の接続線は制御信号インターフェースを示し、実線の接続線はユーザデータ転送のインターフェースを示す。
【００２２】
本発明に係る技術は、前述したＵＥコンテクスト保持方式における接続再開時のランダムアクセスに限らずに適用可能であるが、本実施の形態では、本発明の適用例の１つとして、ＵＥコンテクスト保持方式を用いている。
【００２３】
本実施の形態では、ＵＥコンテクスト保持方式の例として、非特許文献３に記載されている方式であるRRC-Suspended（及びECM-Suspended）という新しいRRCの状態を定義する方式（コンテクスト保持方式１）と、新たなRRCの状態を定義することなくＵＥコンテクストの再利用を行う方式（コンテクスト保持方式２）を説明している。これらのシーケンスの例は後述する。
【００２４】
（ランダムアクセス手順について）
本実施の形態では、ユーザ装置（ＵＥと呼ぶ）と基地局ｅＮＢ（ｅＮＢと呼ぶ）との間のランダムアクセス手順を対象としていることから、まず、ランダムアクセス手順の基本的な処理を説明する。
【００２５】
ランダムアクセス（以下、ＲＡ）は、ＵＥが、発信時等において、ｅＮＢと接続を確立する場合に行われ、その主な目的は上り同期を確立することである。既に説明したように、ＲＡ手順には、衝突型ＲＡ手順と、非衝突側ＲＡ手順がある。衝突型ＲＡ手順は、全ての目的に使用でき、非衝突側ＲＡ手順はハンドオーバ等の特定の目的に使用される。本実施の形態では、衝突型ＲＡ手順を対象とする。
【００２６】
図２を参照して衝突型ＲＡ手順を説明する。ＵＥは、所定数のRA preamble（系列）の中から１つの系列を使用して、PRACH（Physical Random Access Channel）により、RA preamble（選択した系列）を送信する（ステップＳ１）。同時刻に同系列を使用してランダムアクセスを行う他のＵＥが存在しなければ衝突は生じない。
【００２７】
ステップＳ２において、ｅＮＢは、ＤＬ−ＳＣＨ（下り共有チャネル）を利用して、ＵＥの送信タイミングを調整するためのＴＡ（timing advance）コマンド、検出したRA preambleのインデックス、上りリソース割り当て情報（UL grant）等を含むRA response（レスポンス）をＵＥに送信する。
【００２８】
RA responseを受信したＵＥは、上りのタイミングを調整し、割り当てられたリソースを用いてCCCHにより、RRC connection request等の制御メッセージをｅＮＢに送信する（ステップＳ３）。
【００２９】
RA preambleを送信したＵＥが、RA responseを受信できなかった場合については（ランダムアクセス試行が失敗した場合）、ＵＥは、１回失敗するたびに、所定のステップサイズだけ送信電力を上げてPRACHを送信する。このような動作はPower Rampingと呼ばれる。
【００３０】
ステップＳ４において、ｅＮＢは、contention resolution（競合解決メッセージ）を送信する。contention resolutionを受信したＵＥは、自分のＩＤ（例：ＴＣ−ＲＮＴＩ、ステップＳ３でスクランブルに使用したもの）が含まれていることを確認することで、ランダムアクセス処理を完了し、以降、データの送受信を行う。
【００３１】
（コンテクスト保持方式のシーケンス例について）
次に、本実施の形態におけるシステムの動作例として、前述したコンテクスト保持方式に係る動作を説明する。以下では、コンテクスト保持方式１とコンテクスト保持方式２を説明する。
【００３２】
＜コンテクスト保持方式１＞
まず、コンテクスト保持方式１について説明する。コンテクスト保持方式１では、従来のRRC-Idle（ＲＲＣアイドル状態）とRRC-Connected（ＲＲＣ接続状態）に加えて、RRC-Suspended（ＲＲＣ保留状態と呼ぶ）という状態が追加されている。ＲＲＣ保留状態において、ＵＥとｅＮＢはそれぞれ、ＲＲＣ保留状態になる前のＲＲＣ接続状態で接続に使用したＵＥコンテクストを保持する。そして、ＲＲＣ保留状態からＲＲＣ接続状態に遷移するときに、当該保持したＵＥコンテクストを使用してＲＲＣ接続確立をする。
【００３３】
まず、コンテクスト保持方式１における通信システム全体のシーケンス例として、ＵＥ５０が、ＲＲＣアイドル状態からＲＲＣ保留状態（及びＥＣＭ保留状態）に遷移する場合の処理シーケンスを図３を参照して説明する。
【００３４】
ステップＳ１１において、ｅＮＢ１０は、ＲＲＣ接続を保留することを決定する。ステップＳ１２において、ｅＮＢ１０は、ＵＥ５０のＲＲＣ接続が保留されたことを示すメッセージをＭＭＥ３０に送信する。ＭＭＥ１０とｅＮＢ３０はＵＥコンテクストを保持する。
【００３５】
ステップＳ１３、Ｓ１４でのメッセージを経て、ステップＳ１５において、ＭＭＥ３０はステップＳ１２に対するＡｃｋを返す。ステップＳ１６で、ＭＭＥ３０はECM-SUSPENDEDの状態に入る。
【００３６】
ステップＳ１７では、ｅＮＢ１０はＵＥ５０にRRC connection suspendメッセージを送信し、ＵＥ５０をＲＲＣ保留状態にする（ステップＳ１８）。RRC connection suspendメッセージには、Resume ID（再開ＩＤ）が含まれる。Resume IDは、次にＲＲＣ接続を再開する場合に使用される識別子である。ＲＲＣ保留状態において、ＵＥ５０とｅＮＢ１０はそれぞれ、ＵＥコンテクストを格納する。
【００３７】
ここで、本実施の形態において、ＵＥ５０とｅＮＢ１０のそれぞれで保持されるＵＥコンテクストは、例えば、ＲＲＣコンフィギュレーション（RRC configuration）、ベアラコンフィギュレーション（bearer configuration： RoHC state information等を含む)、ＡＳセキュリティコンテクスト（Access Stratum Security Context）、L2/L1パラメータ（MAC、PHYのコンフィギュレーション等）等である。
【００３８】
ＵＥ１０とｅＮＢ１０はそれぞれＵＥコンテクストとして上記のような情報を保持することで、ＲＲＣ保留状態からＲＲＣ接続状態に遷移する際に、RRC Connection Setup Complete、RRC Security Mode Command、RRC Security Mode Complete、RRC Connection Reconfiguration、RRC Connection Reconfiguration Complete、等のメッセージの送受信を行うことなくＲＲＣ接続確立を行うことができる。
【００３９】
次に、ＵＥ５０が、ＲＲＣ保留状態からＲＲＣ接続状態に遷移する場合のシーケンス例を図４を参照して説明する。図４は、ＲＲＣ保留状態（ステップＳ５１）にあるＵＥ５０が着信を受ける（ステップＳ５２〜Ｓ５５）ケースを示しているが、これは例であり、ＲＲＣ保留状態にあるＵＥ５０が発信をする場合も、ＵＥコンテクストの再利用に関しては同様の処理が行われる。
【００４０】
ｅＮＢ１０からページングを受信したＵＥにおいて、ステップＳ５６では、ＥＭＭレイヤから、ＲＲＣ再開手順（resume procedure）が起動される。ステップＳ５７にてRandom Access PreambleがＵＥ５０からｅＮＢ１０に送信され、ステップＳ５８にて、Random Access ResponseがｅＮＢ１０からＵＥ１０に返される。
【００４１】
ステップＳ５９では、メッセージ３として、ＵＥ５０は、RRC Connection Resume RequestメッセージをｅＮＢ１０に送信する。
【００４２】
当該RRC Connection Resume Requestメッセージには、ＵＥ５０がＵＥコンテクストを保持することを示す情報であるResume Id（再開ＩＤ）、認証情報等が含まれる。RRC Connection Resume Requestメッセージを受信したｅＮＢ１０は、当該メッセージに含まれるResume Idに対応付けて格納されている、ＵＥ５０のＵＥコンテクストを取得し、ＵＥコンテクストの情報に基づき、ベアラの再開等を行う。ステップＳ６０では、ｅＮＢ１０は、ＵＥ５０に対してResume Idを含むRRC Connection Resume Completeメッセージを送信する。
【００４３】
ステップＳ６１では、ＵＥ５０とｅＮＢ１０は、格納したセキュリティコンテクストを再開する。そして、ステップＳ６２〜Ｓ６５において、ＭＭＥ３０に対するＵＥ５０の状態変更の通知等が行われる。
【００４４】
＜コンテクスト保持方式２＞
次に、コンテクスト保持方式２について説明する。前述したとおり、コンテクスト保持方式２は、RRC-Suspendedのような新しい状態を定義することなく、ＲＲＣアイドル状態において、ＵＥとｅＮＢがＵＥコンテクストを保持し、ＲＲＣ接続状態に遷移する際に、保持したＵＥコンテクストを再利用することで、シグナリング数削減を可能とする方式である。
【００４５】
コンテクスト保持方式２における通信システム全体のシーケンス例として、ＲＲＣアイドル状態のＵＥ５０に対する着信がある場合に、ＭＭＥ３０からページングを行う方式について説明する。より具体的には、ＵＥ５０がｅＮＢ１０に接続してＲＲＣ接続状態となり、ｅＮＢ１０の配下のセルでＲＲＣアイドル状態となり、同一セルで、その後に着信を受ける場合の処理シーケンスを図５を参照して説明する。
【００４６】
図５の処理の前提として、ＵＥ５０はｅＮＢ１０のセルにおいてＲＲＣ接続状態にあり、ＵＥ５０に関するＳ１−Ｃ／Ｕのコネクションが確立されている状態とする。図５において、Ｓ１−Ｃコネクションは、ｅＮＢ１０とＭＭＥ３０との間のコネクションとＭＭＥ３０とＳ−ＧＷ４０間のコネクションを含み、Ｓ１−Ｕコネクションは、ｅＮＢ１０とＳ−ＧＷ４０間のコネクションを含む。コネクションが確立されている場合、コネクション確立信号等のコネクションセットアップのための手順を実行することなく、該当ノード装置間でＵＥ５０に係る信号（データ）を送受信できる。
【００４７】
図５の手順の説明に入る前に、ＵＥ５０が最初にｅＮＢ１０に接続する際の手順の一例の概要を説明しておく。なお、この最初の接続に係る手順は、コンテクスト保持方式１にも適用できる。ＵＥ５０のランダムアクセス時に、ｅＮＢ１０は、RRC Connection SetupをＵＥ５０に送信し、ＵＥ５０をＲＲＣ接続状態とし、ＵＥ５０からRRC Connection Setup Completeを受信する。その後、ｅＮＢ１０は、ＭＭＥ３０からInitial Context Setup Requestを受信し、ＵＥ５０に対してRRC Security Mode Commandを送信し、ＵＥ５０からRRC Security Mode Completeを受信し、また、ＵＥ５０に対してRRC Connection Reconfigurationを送信し、ＵＥ５０からRRC Connection Reconfiguration Completeを受信し、ＭＭＥ３０に対してInitial Context Setup Responseを送信する。このような手順を経て、ＵＥ５０とｅＮＢ１０におけるＵＥコンテクストの確立、保持等がなされる。
【００４８】
図５に示すように、ＲＲＣ接続状態において、ｅＮＢ１０はＭＭＥ３０に対してコネクション維持指示信号を送信する（ステップＳ７１）。また、ＭＭＥ３０はコネクション維持指示信号をＳ−ＧＷ４０に送信する（ステップＳ７２）。
【００４９】
コネクション維持指示信号は、当該ＵＥ５０に関するＳ１−Ｃ／Ｕコネクションを維持しながら、ＵＥ５０への着信時に下りデータをＳ−ＧＷ４０に保留して、ＭＭＥ３０からページングを行うことを指示する信号である。
【００５０】
コネクション維持指示信号を受信したＳ−ＧＷ４０は、指示を確認したことを示す確認応答をＭＭＥ３０に送信し（ステップＳ７３）、ＭＭＥ３０は、確認応答をｅＮＢ１０に送信する（ステップＳ７４）。
【００５１】
ＵＥ５０に関するｅＮＢ１０からＭＭＥ３０へのコネクション維持指示信号の送信は、例えば、ｅＮＢ１０において、ＵＥ５０をＲＲＣアイドル状態に遷移させる事象が発生したことをトリガーとして行ってもよいし、ＵＥ５０が最初にｅＮＢ１０の配下でＲＲＣ接続状態になり、当該ＵＥ５０に関するＳ１−Ｃ／Ｕコネクションが確立された直後に行うこととしてもよい。
【００５２】
上記のＲＲＣアイドル状態に遷移させる事象とは、例えば、所定のタイマ（例：UE Inactivity Timer）の満了によって、ＵＥ５０との通信（上り下りのユーザデータ通信）が一定時間発生しないことを検知した場合であるが、これに限られるわけではない。
【００５３】
図５は、ＵＥ５０との通信（上り下りのユーザデータ通信）が一定時間発生しないことを検知したことをトリガーとする場合を想定しており、ステップＳ７１〜Ｓ７４の後に、ＲＲＣ接続解放（RRC Connection Release）をＵＥ５０に送信し、ＵＥ５０をＲＲＣアイドル状態に遷移させる（ステップＳ７５）。ＵＥ５０が、ＲＲＣアイドル状態に遷移する場合でも、ＵＥ５０とｅＮＢ１０のそれぞれにおいて、ＲＲＣ接続時に確立したＵＥコンテクストは保持される。
【００５４】
その後、ＵＥ５０向けの下りデータが発生し、当該下りデータがＳ−ＧＷ４０に到着する（ステップＳ７６）。ここでは、Ｓ１−Ｕコネクションは確立済みであるが、ステップＳ７２で受信したコネクション維持指示信号に基づき、Ｓ−ＧＷ４０は、当該下りデータをｅＮＢ１０に転送せずにバッファに保留しておく。
【００５５】
Ｓ−ＧＷ４０は、下りデータ着信通知をＭＭＥ３０に送信し（ステップＳ７７）、ＭＭＥ３０はＵＥ５０向けのＳ１−ＡＰページングの信号をｅＮＢ１０に送信する（ステップＳ７８）。このページング自体は、既存のページングと同様であり、ＵＥ５０のトラッキングエリアの各ｅＮＢに送信されるが、図５ではｅＮＢ１０への送信を示している。
【００５６】
Ｓ１−ＡＰページングの信号を受信したｅＮＢ１０は、配下のＵＥ５０にＲＲＣページングの信号を送信する（ステップＳ７９）。
【００５７】
ＲＲＣページング信号を受信したＵＥ５０は、ＲＲＣ接続確立手順を実行し、ＲＲＣ接続を確立させる（ステップＳ８０）。その後、ｅＮＢ１０は、ＲＲＣ接続の確立が完了したことを示す信号であるＲＲＣ接続確立完了をＭＭＥ３０に送信する（ステップＳ８１）。
【００５８】
ＭＭＥ３０はＲＲＣ接続確立完了の信号をＳ−ＧＷ４０に送信する（ステップＳ８２）。これにより、Ｓ−ＧＷ４０はＵＥ５０とｅＮＢ１０間のＲＲＣ接続が確立したと判断し、既に確立されているＵＥ５０に係るＳ１−Ｕコネクションを利用して、保留していた下りデータのｅＮＢ１０への転送を開始する（ステップＳ８３）。当該下りデータはｅＮＢ１０からＵＥ５０に届く（ステップＳ８４）。このようにしてＵＥ５０への下りデータの伝送が開始される。
【００５９】
図５のステップＳ８０のＲＲＣ接続確立手順では、ＵＥ５０とｅＮＢ１０のそれぞれで保持しておいたＵＥコンテクストが利用されるので、従来は必要であった、RRC Security Mode Command、RRC Security Mode Complete、RRC Connection Reconfiguration、RRC Connection Reconfiguration Complete、等のメッセージの送受信を行うことなくＲＲＣ接続確立を行うことができる。
【００６０】
以下、前述したランダムアクセス手順における課題を解決する方式として、実施例１〜４を説明する。つまり、ＵＥが、Message 3を送信しようとしても、TBSが不足して、送信できないといったことを回避する方式の例として、実施例１〜４を説明する。以下の各実施例における全体のランダムアクセス手順は図２に示したとおりの手順である。また、以下では、ユーザ装置をＵＥと呼び、基地局をｅＮＢと呼ぶことにする。
【００６１】
（実施例１）
まず、実施例１を説明する。実施例１では、ＵＥは、ランダムアクセス手順において、RA preamble group A/Bの中からRA preamble groupを選択する際に、既存のRA preamble group Bを選択する条件に外れる場合でも、CCCH SDUのサイズ（MACヘッダを加えたサイズ）が、messageSizeGroupAよりも大きい場合には、RA preamble group Bを選択し、RA preamble group Bの中からRA preambleを選択して送信する。
【００６２】
上記の手順はRA preamble group Bが存在する場合に行われる。つまり、ＵＥがｅＮＢからＳＩＢ２メッセージ（又はＲＲＣ個別メッセージ）を受信し、当該メッセージの中のRACH-ConfigCommonにおいて、sizeOfRA-PreamblesGroupA（GroupAのプリアンブル数）がnumberOfRA-Preambles（全プリアンブル数）と等しくなければ、ＵＥは、RA preamble group Bが存在すると判定する。messageSizeGroupAは、RACH-ConfigCommonの中のパラメータであり、RA preamble group A/Bの選択判定における、メッセージサイズ（Message 3のサイズ）との比較対象となる閾値である。
【００６３】
図６に、実施例１のＵＥの動作に対応する仕様書（3GPP TS 36.321）の記載例（抜粋）を示す。図６において、非特許文献２からの変更箇所に下線が引かれている。
【００６４】
図６に記載のとおりRA preamble group A/Bのいずれかを選択する判定条件において、RA preamble group Bを判定する条件の中に、CCCH SDU sizeがmessageSizeGroupAより大きい場合という条件をORで付け加えている。
【００６５】
すなわち、この仕様書に準拠する実施例１のＵＥは、図２に示したステップＳ１を行う前に、まず、RA preamble group Bが存在するかどうかを判定し、存在する場合に、以下の処理を行う。
【００６６】
まず、ＵＥは、Message 3として送信しようとするメッセージ（ＵＬデータ＋ＭＡＣヘッダ、必要に応じて、＋ＭＡＣ  ＣＥ）のサイズがmessageSizeGroupAより大きく、かつ、パスロスが所定の値以下であるかどうかを判定し、判定結果がＹｅｓであれば、RA preamble group Bを選択する。
【００６７】
また、ＵＥは、CCCH SDU size（MAC PDUとしてのサイズ）が、messageSizeGroupAよりも大きいか否かを判定し、判定結果がＹｅｓであれば、RA preamble group Bを選択する。なお、本実施の形態（実施例１〜４）におけるCCCH SDU sizeは、MAC header を加えたサイズであることを明示的に記載しない場合でも、MAC headerを加えたサイズを意味する。ただし、これに代えて、MAC headerを含まないCCCH SDUのサイズを用いてもよい。
【００６８】
上記のいずれの判定結果もＮｏであれば、ＵＥは、RA preamble group Aを選択する。
【００６９】
そして、ＵＥは、選択したグループの中のRA preambleからランダムに１つのRA preambleを選択してｅＮＢに送信する（図２のステップＳ１）。
【００７０】
ｅＮＢでは、例えば、RA preamble group BのRA preambleを受信したことを判別すると、RA preamble group AのRA preambleを受信する場合よりも大きなTBSをＵＬリソースとして割り当てて、UL grantを含むRA responseをＵＥに送信する（図２のステップＳ２）。これにより、ＵＥは、例えば、５６ビットよりも大きなMessage 3をｅＮＢに送信することができる。
【００７１】
図７は、実施例１のＵＥの動作に対応する仕様書（3GPP TS 36.321）の記載（抜粋）の他の例を示す。図７に示す例は、messageSizeGroupAと比較するサイズが、「CCCH SDU size＋MAC header」のサイズであることを明確に記載した例である。すなわち、当該仕様書の動作を実行するＵＥは、"ランダムアクセス手順がCCCH論理チャネルに対して開始され、かつ、「CCCH SDU size＋MAC header」が、messageSizeGroupAよりも大きい"か否かを判定し、判定結果がＹｅｓであれば、RA preamble group Bを選択する。この部分以外は、図６と同じである。なお、「ランダムアクセス手順がCCCH論理チャネルに対して開始される」とは、例えば、RRCConnectionRequest message、RRCConnectionReestablishmentRequest message、RRC connection resume message等の送信のためにランダムアクセス手順が開始される（initiated）ことに相当する。
【００７２】
なお、実施例１において、ｅＮＢからＵＥに通知するmessageSizeGroupAの値は特定の値に限定されないが、例えば、５６ビットである。
【００７３】
実施例１は、現行の５６ビットのTBSに加えて、１つだけ追加のCCCH SDU sizeが規定される場合に、特に適している。ただし、２つ以上の追加のCCCH SDU sizeが規定される場合でも、実施例１の技術を使用することは可能である。
【００７４】
（実施例２）
次に、実施例２を説明する。実施例２では、新たに追加されるCCCH SDU size用に新しくRA preamble groupを設けることとしている。例えば、１つだけCCCH SDU sizeを追加する場合、Group Cを新しく追加する。つまり、この場合、ＵＥがランダムに選択可能な複数プリアンブル（例：６４個、RACH-ConfigCommonのnumberOfRA-Preamblesで通知される値）が３つのグループ（Group C、Group B、Group C）に分けられる。
【００７５】
実施例２におけるＵＥのRA preamble選択の動作例（図２のステップＳ１の直前の動作）を図８のフローチャートを参照して説明する。このフローチャートの前提として、ＵＥは、ＳＩＢ２メッセージ（又はＲＲＣ個別メッセージ）を受信し、当該メッセージの中のRACH-ConfigCommonにより、閾値等の各パラメータを取得、保持しているものとする。また、ＵＥは、パラメータにより、Group CとGroup Bが存在することを把握しているとする。また、以下の「Group Cのmessage size」は、ｅＮＢからＵＥに通知されるパラメータの１つである。
【００７６】
ＵＥは、例えば、前述した接続再開のためのメッセージをMessage 3としてｅＮＢに送信したい場合において、ランダムアクセス手順を開始する。
【００７７】
ステップＳ１０１において、例えば、ＵＥは、RA PreambleがｅＮＢからexplicitly にシグナリングされていないことを把握して、ＭＡＣレイヤでのRA preamble選択処理を開始する。
【００７８】
ステップＳ１０２において、ＵＥは、送信しようとするmessage size (CCCH SDU + MAC header)がGroup Cのmessage sizeと等しいかどうかを判定する。判定結果がＹｅｓであれば、ステップＳ１０４に進み、Group Cを選択し、Group Cの中からRA preambleを選択する。
【００７９】
ステップＳ１０２での判定結果がＮｏである場合にはステップＳ１０３に進む。ステップＳ１０３において、ＵＥは、Potential message size（ＵＬデータ＋ＭＡＣヘッダ、必要に応じて、＋ＭＡＣ  ＣＥ）がGroup Cのmessage sizeより大きく、かつ、パスロスが所定の値以下であるかどうかを判定する。判定結果がＹｅｓであれば、ステップＳ１０５に進み、Group Bを選択し、Group Bの中からRA preambleを選択する。なお、Potential message sizeは、Message 3として送信予定のメッセージのサイズである。
【００８０】
ステップＳ１０３での判定結果がＮｏである場合にはステップＳ１０６に進み、Group Aを選択し、Group Aの中からRA preambleを選択する。
【００８１】
例えば、新たなCCCH SDU + MAC headerが６４ビットであるとした場合、ｅＮＢは、Group CのRA preambleをＵＥから受信した場合において、６４ビットのTBSをＵＥに割り当てる。また、この場合、ｅＮＢは、Group BのRA preambleをＵＥから受信した場合において、６４ビットよりも大きなTBS（例：８０ビット）をＵＥに割り当てる。また、Group AのRA preambleをＵＥから受信した場合において、６４ビットよりも小さなTBS（例：５６ビット）をＵＥに割り当てる。
【００８２】
図９に、実施例２のＵＥの動作に対応する仕様書（3GPP TS 36.321, 5.1.1）の記載例（抜粋）を示す。図９において、非特許文献２からの変更箇所に下線が引かれている。
【００８３】
図９に示すように、RA Preambles group A、RA Preambles group B、及びRA Preambles group Cに含まれるプリアンブルは、numberOfRA-Preambles、sizeOfRA-PreamblesGroupA、及びsizeOfRA-PreamblesGroupCのパラメータから計算されることが規定されている。また、RA Preambles Group Cが存在する場合に、RA Preamble Group Cのプリアンブルは、sizeOfRA-PreamblesGroupAからnumberOfRA-PreamblesC - 1 までであり、RA Preamble Group Bのプリアンブルは、sizeOfRA-PreamblesGroupCからnumberOfRA-Preambles - 1までであることが規定されている。
【００８４】
図１０に、実施例２のＵＥの動作に対応する仕様書（3GPP TS 36.321、5.1.2）の記載例（抜粋）を示す。図１０において、非特許文献２からの変更箇所に下線が引かれている。
【００８５】
図１０に示す記載例は、図８に示したフローチャートの内容に対応する。なお、図１０に示すように、Group Cが存在しない場合には、従来と同様に、potential message sizeがGroup Aのmessage size以上かつパスロスが所定の値以下でGroup Bが選択される。
【００８６】
図１１、図１２は、実施例２のＵＥの動作に対応する仕様書（3GPP TS 36.331）の記載例（抜粋）を示す。図１１、図１２において、非特許文献５からの変更箇所に下線が引かれている。
【００８７】
図１１に示すように、RACH-ConfigCommon information elementにおいて、sizeOfRA-PreamblesGroupC、messageSizeGroupC、messagePowerOffsetGroupB等のパラメータが追加されている。messageSizeGroupCは、判定で使用される閾値（GroupCのmessage size）である。図１２に示すように、sizeOfRA-PreamblesGroupCは、GroupCのサイズ（プリアンブル数）である。
【００８８】
なお、実施例２では、１つのグループが新たに追加される場合を例に説明したが、２つ以上のグループが新たに追加される場合でも同様の処理を実現できる。その場合は、図８のフローにおいて、message size (CCCH SDU + MAC header)とパラメータ（Group Cのmessage size等）とが等しいかどうかの判定が追加グループ毎に行われる。
【００８９】
（実施例２の変形例）
次に、実施例２の変形例を説明する。実施例２の変形例では、図１３に示す５つのパターンに分けられるように、４つのRA preamble groupを設けることとしている。なお、この例では、RA preamble group Aのmessage sizeを５６ビットとし、RA preamble group Cのmessage sizeを８０ビットとしているが、これは一例である。これらの値は、RACH-ConfigCommonによりパラメータとしてｅＮＢからＵＥに通知される。本例では、ＵＥがランダムに選択可能な複数プリアンブルが４つのグループ（Group D、Group C、Group B、Group C）に分けられる。
【００９０】
実施例２の変形例におけるＵＥのRA preamble選択の動作例（図２のステップＳ１の直前の動作）を図１４のフローチャートを参照して説明する。このフローチャートの前提として、ＵＥは、ＳＩＢ２メッセージ（又はＲＲＣ個別メッセージ）を受信し、当該メッセージの中のRACH-ConfigCommonにより、閾値等の各パラメータを取得、保持しているものとする。また、ＵＥは、パラメータにより、Group CとGroup Bが存在することを把握しているとする。
【００９１】
ＵＥは、例えば、前述した接続再開のためのメッセージをMessage 3としてｅＮＢに送信したい場合において、ランダムアクセス手順を開始する。
【００９２】
ステップＳ２０１において、例えば、ＵＥは、RA PreambleがｅＮＢからexplicitly にシグナリングされていないことを把握して、ＭＡＣレイヤでのRA preamble選択処理を開始する。
【００９３】
ステップＳ２０２において、ＵＥは、Potential message size（ＵＬデータ＋ＭＡＣヘッダ、必要に応じて、＋ＭＡＣ  ＣＥ）がGroup Cのmessage sizeより大きく、かつ、パスロスが所定の値以下であるかどうかを判定する。判定結果がＹｅｓであれば、ステップＳ２０４に進み、Group Bを選択し、Group Bの中からRA preambleを選択する。
【００９４】
ステップＳ２０２での判定結果がＮｏである場合にはステップＳ２０３に進む。ステップＳ２０３において、ＵＥは、送信しようとするMessage 3のmessage size (CCCH SDU + MAC header)がGroup Cのmessage size（例：８０ビット）と等しいかどうかを判定する。判定結果がＹｅｓであれば、ステップＳ２０５に進み、Group Cを選択し、Group Cの中からRA preambleを選択する。
【００９５】
ステップＳ２０３での判定結果がＮｏである場合にはステップＳ２０６に進む。ステップＳ２０６において、ＵＥは、「Potential message size（ＵＬデータ＋ＭＡＣヘッダ、必要に応じて、＋ＭＡＣ  ＣＥ）がGroup Cのmessage sizeより小さく、かつ、Potential message size（ＵＬデータ＋ＭＡＣヘッダ、必要に応じて、＋ＭＡＣ  ＣＥ）がGroup Aのmessage size（例：５６ビット）より大きく、かつ、パスロスが所定の値以下」であるかどうかを判定する。判定結果がＹｅｓであれば、ステップＳ２０７に進み、Group Dを選択し、Group Dの中からRA preambleを選択する。判定結果がＮｏであれば、ステップＳ２０８に進み、Group Aを選択し、Group Aの中からRA preambleを選択する。
【００９６】
例えば、新たなCCCH SDU + MAC headerが８０ビットであり、既存の（Group A）のメッセージサイズが５６ビットであるとした場合、ｅＮＢは、Group CのRA preambleをＵＥから受信した場合において、８０ビットのＴＢＳをＵＥに割り当てることが考えられる。また、ｅＮＢは、Group BのRA preambleをＵＥから受信した場合において、８０ビットよりも大きなＴＢＳをＵＥに割り当てる。また、Group AのRA preambleをＵＥから受信した場合において、５６ビットのTBSをＵＥに割り当てる。また、Group DのRA preambleをＵＥから受信した場合において、５６ビットよりも大きく、８０ビットよりも小さなＴＢＳ（例：６４ビット）をＵＥに割り当てる。
【００９７】
図１５に、実施例２の変形例のＵＥの動作に対応する仕様書（3GPP TS 36.321, 5.1.1）の記載例（抜粋）を示す。図１５において、非特許文献２からの変更箇所に下線が引かれている。
【００９８】
図１５に示すように、RA Preambles group A、RA Preambles group B、RA Preambles group C、及びRA Preambles group Dに含まれるプリアンブルは、numberOfRA-Preambles、sizeOfRA-PreamblesGroupA、及びsizeOfRA-PreamblesGroupCのパラメータから計算されることが規定されている。また、RA Preambles Group C、RA Preambles Group Dが存在する場合に、RA Preamble Group Cのプリアンブルは、sizeOfRA-PreamblesGroupAからnumberOfRA-PreamblesC - 1 までであり、RA Preamble Group Dのプリアンブルは、sizeOfRA-PreamblesGroupCからnumberOfRA-PreamblesD - 1までであり、RA Preamble Group Bのプリアンブルは、sizeOfRA-PreamblesGroupDからnumberOfRA-Preambles - 1までであることが規定されている。
【００９９】
図１６に、実施例２の変形例のＵＥの動作に対応する仕様書（3GPP TS 36.321、5.1.2）の記載例（抜粋）を示す。図１６において、非特許文献２からの変更箇所に下線が引かれている。
【０１００】
図１６に示す記載例は、図１４に示したフローチャートの内容に対応する。なお、図１６に示すように、Group Cが存在しない場合には、従来と同様に、potential message sizeがGroup Aのmessage size以上かつパスロスが所定の値以下でGroup Bが選択される。
【０１０１】
図１７、図１８は、実施例２の変形例のＵＥの動作に対応する仕様書（3GPP TS 36.331）の記載例（抜粋）を示す。図１７、図１８において、非特許文献５からの変更箇所に下線が引かれている。
【０１０２】
図１７に示すように、RACH-ConfigCommon information elementにおいて、sizeOfRA-PreamblesGroupC、messageSizeGroupC、messagePowerOffsetGroupB、sizeOfRA-PreamblesGroupD等のパラメータが追加されている。messageSizeGroupCは、判定で使用される閾値（GroupCのmessage size）である。図１８に示すように、sizeOfRA-PreamblesGroupCは、GroupCのサイズ（プリアンブル数）である。
【０１０３】
なお、実施例２の変形例では、２つのグループが新たに追加される場合を例に説明したが、３つ以上のグループが新たに追加される場合でも同様の処理を実現できる。
【０１０４】
（実施例３）
次に、実施例３を説明する。実施例３では、CCCH SDU size毎に異なる６４個のRA preamble resource（PRACH resource）が用意される。６４個は例である。ＵＥは、その個数を、ｅＮＢからのシステム情報又はＲＲＣ個別シグナリングに基づいて決定することができる。以下では、６４個であるとして説明する。なお、CCCH SDU sizeとRA preamble resourceとは１対１に対応している必要はなく、例えば、１対Ｎ（Ｎは２以上の整数）の対応であってもよい。
【０１０５】
ＵＥは、Zadoff-chu系列からRA preamble系列を生成する。ＵＥは、そのRA preamble系列を上記のRA preamble resourceと見なすことができる。この場合、異なる６４個のRA preamble系列がそれぞれ、CCCH SDUのサイズに対応する。例えば、ＵＥは、７２ビットのCCCH SDUのメッセージを送信する場合に、８０ビットに対応するRA preamble系列１を送信し、５６ビットのCCCH SDUのメッセージを送信する場合に、５６ビットに対応するRA preamble系列２を送信する。
【０１０６】
また、例えば、RA preamble系列は、CCCH SDU sizeに拠らずに同一として、RA preamble系列を送信する周波数・時間リソースをCCCH SDU sizeに対応付けることとしてもよい。この場合は、当該周波数・時間リソースが上記のRA preamble resourceに相当する。この場合、例えば、ＵＥは、８０ビットのCCCH SDUのメッセージを送信する場合に、８０ビットに対応する周波数・時間リソース１でRA preambleを送信し、５６ビットのCCCH SDUのメッセージを送信する場合に、５６ビットに対応する周波数・時間リソース２でRA preambleを送信する。
【０１０７】
CCCH SDU sizeとRA preamble resourceとの対応関係の情報は、ｅＮＢからＵＥに対して、システム情報又はＲＲＣ個別シグナリングにより通知される。ＵＥは当該対応関係の情報を保持し、当該対応関係と、送信しようとするMessage 3のCCCH SDU sizeとに基づいて、RA preamble resourceを決定する。
【０１０８】
ｅＮＢは、CCCH SDU sizeとRA preamble resourceとの対応関係を保持しており、ＵＥから受信するRA preamble resourceに基づき、Message 3でＵＥが送信しようとしているCCCH SDU sizeを把握できる。これにより、CCCH SDU sizeに応じたTBSの割り当てをRA responseで行うことができる。
【０１０９】
実施例３におけるＵＥのRA preamble選択の動作例（図２のステップＳ１の直前の動作）を図１９のフローチャートを参照して説明する。このフローチャートの前提として、ＵＥは、ｅＮＢから受信したシステム情報（又はＲＲＣ個別メッセージ）から、CCCH SDU sizeとRA preamble resourceとの対応関係の情報を取得し、保持しているとする。
【０１１０】
ＵＥは、例えば、前述した接続再開のためのメッセージをMessage 3としてｅＮＢに送信したい場合において、ランダムアクセス手順を開始する。
【０１１１】
ステップＳ３０１において、例えば、ＵＥは、RA PreambleがｅＮＢからexplicitly にシグナリングされていないことを把握して、ＭＡＣレイヤでのRA preamble選択処理を開始する。
【０１１２】
ステップＳ３０２において、ＵＥは、送信しようとするMessage 3のCCCH SDU sizeが、システム情報又は個別のＲＲＣシグナリング内で通知された所定のmessage sizeと等しいかどうかを判定する。つまり、システム情報又は個別のＲＲＣシグナリング内で通知された上記の対応関係の中のmessage sizeのリストの中に、CCCH SDU sizeと等しいmessage sizeがあるか否かを判定する。
【０１１３】
ステップＳ３０２の判定結果がＹｅｓの場合、ステップＳ３０３に進み、ＵＥは、CCCH SDU sizeと等しいmessage sizeに対応するPRACH resource（一般には複数のPRACH resourceがある）を使用可能なPRACH resourceとみなす。そして、ステップＳ３０５において、ＵＥは、使用可能なPRACH resourceの中からRA preambleのリソースを選択して、RA preambleを送信する。
【０１１４】
ステップＳ３０２での判定結果がＮｏの場合、ステップＳ３０４に進み、システム情報若しくは個別のＲＲＣシグナリングで通知された従来のPRACH resourceを使用可能なPRACH resourceとみなして、ステップＳ３０５に進む。
【０１１５】
図２０に、実施例３のＵＥの動作に対応する仕様書（3GPP TS 36.321, 5.1.1）の記載例（抜粋）を示す。図２０において、非特許文献２からの変更箇所に下線が引かれている。
【０１１６】
図２０に示すように、ＲＡ手順の開始にあたって、ＵＥは、Message 3の各message sizeに対応付けられた使用可能なPRACH resourceのセットを把握している。これは、prach-ConfigIndexにより示される。
【０１１７】
図２１に、実施例３のＵＥの動作に対応する仕様書（3GPP TS 36.321, 5.1.2）の記載例（抜粋）を示す。図２１において、非特許文献２からの変更箇所に下線が引かれている。
【０１１８】
図２１に示すように、Message 3にCCCH SDUが含まれ、CCCH SDU sizeがMessageSizePrachInfoList（所定のサイズのリスト）の中のMessageSizeOfMsg3に示されている場合に、ＵＥは、そのサイズに対応するリソース（PRACH-ParametersMsgSize） を使用可能なPRACH resourcesと見なす。そうでなければ、PRACH-ConfigSIB又はPRACH-Configで示されるリソースを使用可能なPRACH resourcesと見なす。
【０１１９】
図２２は、実施例３のＵＥの動作に対応する仕様書（3GPP TS 36.331）の記載例（抜粋）を示す。図２２において、非特許文献５からの変更箇所に下線が引かれている。図２２に示すように、上記のMessageSizePrachInfoList、PRACH-ParametersMsgSize等がPRACH-Config information elementsに追加されている。これらの情報が、前述したCCCH SDU sizeとRA preamble resourceとの対応関係の情報に相当する。
【０１２０】
（実施例４）
次に、実施例４を説明する。実施例４では、ＵＥが、RRC connectionを再開（resume）する場合（例：図４のステップＳ５６〜Ｓ５９、図５のステップＳ８０）、ＵＥは、ＲＲＣレイヤで再開を要求するメッセージ（従来のMsg.3より大きいサイズ）と同時に従来のMsg.3 size (56 bits TBS）のRRC Connection request message（もしくはRRC Connection reestablishment request message）も作成する。そして、ＵＥは、両方のメッセージを下位レイヤに送り出す。
【０１２１】
ＵＥは、ＭＡＣレイヤにおいて、割り当てられたTBSに応じて、従来のMsg.3より大きいサイズの再開を要求するメッセージを送るか、従来のMsg.3 sizeのRRC connection request message（もしくはRRC Connection reestablishment request message）を送るかを選択する。
【０１２２】
例えば、図４のケースでは、ステップＳ５６で、ＵＥがＲＲＣ接続再開を開始すると、ＵＥは、RRC connection resume request messageを作成するとともに、RRC Connection request messageも作成する。そして、ＵＥは、ＭＡＣレイヤにおいて、ステップＳ５８で受信するUL grantで割り当てられたTBSに応じて、RRC connection resume request messageかRRC Connection request messageのいずれかを送信するかを判断する。例えば、TBSが、RRC connection resume request messageを送信することができるサイズである場合に、RRC connection resume request messageを送信する。この場合は、以降、図４に示す手順が行われる。一方、TBSが、RRC connection resume request messageを送信することができるサイズではない場合に、RRC Connection request message（もしくはRRC Connection reestablishment request message）を送信する。この場合は、以降、従来のRRC Connection request message（もしくはRRC Connection reestablishment request message）送信時の手順と同様の手順が実行される。
【０１２３】
実施例４におけるＵＥのＲＲＣ接続再開時の動作例を図２３のフローチャートを参照して説明する。なお、図２３は、ＲＲＣ接続再開のためのメッセージとしてRRC connection resume request messageを使用する。これは、図４での新規メッセージであると考えてもよいし、既存のメッセージを拡張したもの（例：図５のステップＳ８０で使用するメッセージ）であると考えてもよい。
【０１２４】
ステップＳ４０１において、ＵＥは、ＲＲＣレイヤでRRC connection resume request messageを作成すると同時に、既存のRRC connection request messageも作成する。ステップＳ４０２において、ＵＥは、Message 3に割り当てられたTBSでRRC connection resume requestを送信可能か否かを判定する。
【０１２５】
ステップＳ４０２での判定結果がＹｅｓであれば、ステップＳ４０３でRRC connection resume request messageを送信する。Ｎｏである場合、TBSは５６ビットであることが想定され、ステップＳ４０４で既存のRRC connection request messageを送信する。
【０１２６】
実施例４では、例えば、無線品質が良い場合であれば、大きなTBSの割り当てを期待でき、その場合はRRC connection resume request messageを送信できる。また、通常のTBSの割り当てを受ける場合でも、RRC connection request messageを送信することができる。すなわち、ＲＡ手順において、ＵＥが、ｅＮＢから割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【０１２７】
実施例４では、RRC connection request messageとRRC connection resume request messageを同時に作成する例を示したが、このようなサイズの異なる複数のメッセージを同時に作成し、大きなメッセージ送信可能であればそれを送信する処理は、RRC connection request messageとRRC connection resume request messageに限らずに適用可能である。
【０１２８】
実施例１〜実施例４（実施例２の変形例を含む、以下同様）の全部又はいずれか複数は矛盾の生じない限り組み合わせて実施することができる。
【０１２９】
（装置構成例）
次に、本発明の実施の形態におけるＵＥとｅＮＢの装置構成例を説明する。以下で説明する各装置の構成は、発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した通信システムにおける装置として動作するための図示しない機能も有するものである。また、各図に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。
【０１３０】
各装置は、実施例１〜実施例４の全ての機能を備えてもよいし、実施例１〜実施例４のうちのいずれか１つの実施例の機能又は変形例の機能を備えることとしてもよいし、実施例１〜実施例４のうちのいずれか複数の機能を備えることとしてもよい。以下の説明では、各装置は実施例１〜実施例４の機能を備えるものとする。
【０１３１】
＜ユーザ装置ＵＥ＞
図２４に、ＵＥの機能構成図を示す。図２４に示すように、ＵＥは、ＤＬ信号受信部５１、ＵＬ信号送信部５２、プリアンブル選択部５３、ＲＲＣ処理部５４、ＵＥコンテクスト管理部５５を備える。なお、図２４は、ＵＥにおいて本発明に特に関連する機能部のみを示すものであり、ＵＥは、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。
【０１３２】
ＤＬ信号受信部５１は、基地局ｅＮＢから各種の下り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含み、ＵＬ信号送信部５２は、ＵＥ５０から送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、基地局ｅＮＢに対して送信する機能を含む。
【０１３３】
プリアンブル選択部５３は、実施例１〜２で説明したロジックでＭＡＣレイヤでのプリアンブルの選択を行う。なお、プリアンブル選択部５３は、ＵＬ信号送信部５２の中に備えられていてもよい。また、プリアンブル選択部５３は、実施例３におけるRA preamble送信のためのリソース選択を行う。
【０１３４】
ＲＲＣ処理部５４は、ＲＲＣメッセージの生成・送信（送信はＵＬ信号送信部５２を介した送信）、ＤＬ信号受信部５１により受信したＲＲＣメッセージの解釈等を行う。実施例３において、ＲＲＣ処理部５４は、対応関係の情報を取得・保持する。実施例４において、ＲＲＣ処理部５４は、RRC connection request messageとRRC connection resume request messageを同時に作成する。また、実施例４において、TBSに基づき、RRC connection request messageとRRC connection resume request messageのいずれを送信するかを判定する機能は、ＵＬ信号送信部５２に含まれている。
【０１３５】
ＵＥコンテクスト管理部５５は、メモリ等の記憶手段を含み、ＲＲＣ保留状態／ＲＲＣアイドル状態においてＵＥコンテクストを保持する。
【０１３６】
図２４に示すＵＥの構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。
【０１３７】
図２５は、ＵＥのハードウェア（ＨＷ）構成の例を示す図である。図２５は、図２４よりも実装例に近い構成を示している。図２５に示すように、ＵＥは、無線信号に関する処理を行うＲＥ（Ｒａｄｉｏ  Ｅｑｕｉｐｍｅｎｔ）モジュール１５１と、ベースバンド信号処理を行うＢＢ（Ｂａｓｅ  Ｂａｎｄ）処理モジュール１５２と、上位レイヤ等の処理を行う装置制御モジュール１５３と、ＵＳＩＭカードにアクセスするインタフェースであるＵＳＩＭスロット１５４とを有する。
【０１３８】
ＲＥモジュール１５１は、ＢＢ処理モジュール１５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ（Ｄｉｇｉｔａｌ−ｔｏ−Ａｎａｌｏｇ）変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ（Ａｎａｌｏｇ  ｔｏ  Ｄｉｇｉｔａｌ）変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール１５２に渡す。ＲＥモジュール１５１は、例えば、図２４のＤＬ信号受信部５１及びＵＬ信号送信部５２における物理レイヤ等の機能を含む。
【０１３９】
ＢＢ処理モジュール１５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）１６２は、ＢＢ処理モジュール１５２における信号処理を行うプロセッサである。メモリ１７２は、ＤＳＰ１６２のワークエリアとして使用される。ＢＢ処理モジュール１５２は、例えば、図２４のＤＬ信号受信部５１及びＵＬ信号送信部５２におけるレイヤ２等の機能、プリアンブル選択部５３、ＲＲＣ処理部５４及びＵＥコンテクスト管理部５４を含む。なお、プリアンブル選択部５３、ＲＲＣ処理部５４及びＵＥコンテクスト管理部５４の機能の全部又は一部を装置制御モジュール１５３に含めることとしてもよい。
【０１４０】
装置制御モジュール１５３は、ＩＰレイヤのプロトコル処理、各種アプリケーションの処理等を行う。プロセッサ１６３は、装置制御モジュール１５３が行う処理を行うプロセッサである。メモリ１７３は、プロセッサ１６３のワークエリアとして使用される。また、プロセッサ１６３は、ＵＳＩＭスロット１５４を介してＵＳＩＭとの間でデータの読出し及び書込みを行う。
【０１４１】
＜基地局ｅＮＢ＞
図２６に、ｅＮＢの機能構成図を示す。図２６に示すように、ｅＮＢは、ＤＬ信号送信部１１、ＵＬ信号受信部１２、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４、ＮＷ通信部１５を備える。なお、図２６は、ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、ｅＮＢは、少なくともＬＴＥ方式に準拠した動作を行うための図示しない機能も有するものである。
【０１４２】
ＤＬ信号送信部１１は、ｅＮＢから送信されるべき上位のレイヤの情報から、物理レイヤの各種信号を生成し、送信する機能を含む。ＵＬ信号受信部１２は、ＵＥから各種の上り信号を受信し、受信した物理レイヤの信号からより上位のレイヤの情報を取得する機能を含む。
【０１４３】
ＲＲＣ処理部１３は、ＲＲＣメッセージ及びシステム情報の生成・送信（送信はＤＬ信号送信部１１を介した送信）、ＵＬ信号受信部１２により受信したＲＲＣメッセージの解釈、動作等を行う。またＲＲＣ処理部１３は、ＵＥコンテクスト管理部１４に保持しておいたＵＥコンテクストを利用してＲＲＣ接続を再開する機能等も含む。
【０１４４】
ＵＥコンテクスト管理部１４は、メモリ等の記憶手段を含み、ＲＲＣ保留状態／ＲＲＣアイドル状態においてＵＥコンテクストを保持する。
【０１４５】
ＮＷ通信部１５は、Ｓ１−ＭＭＥインターフェースでＭＭＥとの間で制御信号を送受信する機能、及び、Ｓ１−ＵインターフェースでＳ−ＧＷとの間でデータを送受信する機能、コネクション維持指示信号の送信機能、ＲＲＣ接続確立完了の送信の送信機能等を含む。
【０１４６】
図２６に示すｅＮＢの構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。
【０１４７】
図２７は、ｅＮＢのハードウェア（ＨＷ）構成の例を示す図である。図２７は、図２６よりも実装例に近い構成を示している。図２７に示すように、ｅＮＢは、無線信号に関する処理を行うＲＥモジュール２５１と、ベースバンド信号処理を行うＢＢ処理モジュール２５２と、上位レイヤ等の処理を行う装置制御モジュール２５３と、ネットワークと接続するためのインタフェースである通信ＩＦ２５４とを有する。
【０１４８】
ＲＥモジュール２５１は、ＢＢ処理モジュール２５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール２５２に渡す。ＲＥモジュール２５１は、例えば、図２６のＤＬ信号送信部１１及びＵＬ信号受信部１２における物理レイヤ等の機能を含む。
【０１４９】
ＢＢ処理モジュール２５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ２６２は、ＢＢ処理モジュール２５２における信号処理を行うプロセッサである。メモリ２７２は、ＤＳＰ２５２のワークエリアとして使用される。ＢＢ処理モジュール２５２は、例えば、図２５のＤＬ信号送信部１１及びＵＬ信号受信部１２におけるレイヤ２等の機能、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４を含む。なお、ＲＲＣ処理部１３、ＵＥコンテクスト管理部１４の機能の全部又は一部を装置制御モジュール２５３に含めることとしてもよい。
【０１５０】
装置制御モジュール２５３は、ＩＰレイヤのプロトコル処理、ＯＡＭ処理等を行う。プロセッサ２６３は、装置制御モジュール２５３が行う処理を行うプロセッサである。メモリ２７３は、プロセッサ２６３のワークエリアとして使用される。補助記憶装置２８３は、例えばＨＤＤ等であり、基地局ｅＮＢ自身が動作するための各種設定情報等が格納される。
【０１５１】
なお、図２４〜図２７に示す装置の構成（機能区分）は、本実施の形態で説明する処理を実現する構成の一例に過ぎない。本実施の形態で説明する処理を実現できるのであれば、その実装方法（具体的な機能部の配置、名称等）は、特定の実装方法に限定されない。
【０１５２】
（実施の形態のまとめ）
以上、説明したように、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、前記選択部により選択されたランダムアクセス信号を前記基地局に装置する送信部と、を備え、前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信することを特徴とするユーザ装置が提供される。
【０１５３】
上記の構成により、例えば、基地局は、ユーザ装置が送信しようとするメッセージのサイズをRA responseを送信する前に把握することができ、適切なTBSをRA responseのUL grantで割り当てることができる。従って、ユーザ装置において、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【０１５４】
前記メッセージのサイズが前記所定の閾値よりも大きい場合に、前記選択部は、２つのランダムアクセス信号グループのうち、前記所定の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、既存のGroup Bを用いて、ユーザ装置が新たなCCCH SDU sizeを使用することを基地局に通知できる。
【０１５５】
また、前記メッセージのサイズが前記所定の閾値と等しい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、新たなGroupであるGroup Cを用いて、ユーザ装置が新たなCCCH SDU sizeを使用することを基地局に通知できる。前記所定の閾値に対応するランダムアクセス信号グループは、例えば、messageSizeGroupCである。
【０１５６】
また、上記の例において、前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループとは異なる所定のランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、既存のGroup Bを用いて、ユーザ装置がmessageSizeGroupCよりも大きなメッセージを使用することを基地局に通知できる。
【０１５７】
前記選択部は、前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第１条件が満たされるか否かを判定し、前記第１条件が満たされない場合に、前記メッセージのサイズが前記所定の閾値と等しいという第２条件が満たされるか否かを判定し、当該第２条件が満たされる場合に、前記所定の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、新たなGroupであるGroup Cを用いて、ユーザ装置が新たなCCCH SDU sizeを使用することを基地局に通知できる。
【０１５８】
上記の例において、前記第２条件が満たされない場合に、前記選択部は、前記メッセージのサイズが前記所定の閾値よりも小さく、かつ、前記メッセージのサイズが所定の第２の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第３条件が満たされるか否かを判定し、前記第３条件が満たされる場合に、前記選択部は、前記所定の第２の閾値と前記所定の閾値との間のサイズに対応するランダムアクセス信号グループを選択し、前記第３条件が満たされない場合に、前記選択部は、前記所定の第２の閾値に対応するランダムアクセス信号グループを選択することとしてもよい。この構成により、例えば、図１２に示したように、メッセージサイズを複数パターンに分けて、パターン毎に基地局への通知を行うことができる。
【０１５９】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信部と、前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択部と、前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信部とを備えるユーザ装置が提供される。
【０１６０】
上記の構成により、例えば、基地局は、ユーザ装置が送信しようとするメッセージのサイズをRA responseを送信する前に把握することができ、適切なTBSをRA responseのUL grantで割り当てることができる。従って、ユーザ装置において、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【０１６１】
前記リソースは、例えば、ランダムアクセス信号の系列、又はランダムアクセス信号の送信に使用する時間と周波数のリソースである。このように、リソースとして種々の情報を使用することで、柔軟なリソース制御が可能となる。
【０１６２】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択ステップと、前記選択ステップにより選択されたランダムアクセス信号を前記基地局に装置する送信ステップと、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する送信ステップとを備えるランダムアクセス方法が提供される。
【０１６３】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信ステップと、前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択ステップと、前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信ステップとを備えるランダムアクセス方法が提供される。
【０１６４】
また、本実施の形態により、基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、第１のメッセージと、当該第１のメッセージよりもサイズの小さい第２のメッセージを生成する生成部と、前記基地局に送信されたランダムアクセス信号に対する当該基地局からの応答により割り当てられるリソースの量に応じて、前記第１のメッセージを送信できる場合に当該第１のメッセージを前記基地局に送信し、前記第１のメッセージを送信できない場合に前記第２のメッセージを前記基地局に送信する送信部とを備えるユーザ装置が提供される。
【０１６５】
上記の構成により、ユーザ装置において、基地局から割り当てられる上りリソースの不足により制御メッセージの送信ができなくなることを回避することができる。
【０１６６】
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、各装置は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従って当該装置が有するプロセッサにより動作するソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【０１６７】
また、本明細書で説明した各態様／実施形態は、ＬＴＥ（Long  Term  Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１６８】
また、本明細書で説明した各実施例／変形例の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１６９】
また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。上述したパラメータに使用する名称はいかなる点においても限定的なものではない。
【０１７０】
本明細書には下記の事項が開示されている。
（第１項）
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択部と、
前記選択部により選択されたランダムアクセス信号を前記基地局に装置する送信部と、を備え、
前記送信部は、前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する
ことを特徴とするユーザ装置。
（第２項）
前記メッセージのサイズが前記所定の閾値よりも大きい場合に、前記選択部は、２つのランダムアクセス信号グループのうち、前記所定の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第１項に記載のユーザ装置。
（第３項）
前記メッセージのサイズが前記所定の閾値と等しい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第１項に記載のユーザ装置。
（第４項）
前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さい場合に、前記選択部は、複数のランダムアクセス信号グループの中から、前記所定の閾値に対応するランダムアクセス信号グループとは異なる所定のランダムアクセス信号グループを選択する
ことを特徴とする第３項に記載のユーザ装置。
（第５項）
前記選択部は、
前記メッセージのサイズが前記所定の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第１条件が満たされるか否かを判定し、
前記第１条件が満たされない場合に、前記メッセージのサイズが前記所定の閾値と等しいという第２条件が満たされるか否かを判定し、当該第２条件が満たされる場合に、前記所定の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第１項に記載のユーザ装置。
（第６項）
前記第２条件が満たされない場合に、前記選択部は、前記メッセージのサイズが前記所定の閾値よりも小さく、かつ、前記メッセージのサイズが所定の第２の閾値よりも大きく、かつ、パスロスが所定の値よりも小さいという第３条件が満たされるか否かを判定し、
前記第３条件が満たされる場合に、前記選択部は、前記所定の第２の閾値と前記所定の閾値との間のサイズに対応するランダムアクセス信号グループを選択し、前記第３条件が満たされない場合に、前記選択部は、前記所定の第２の閾値に対応するランダムアクセス信号グループを選択する
ことを特徴とする第５項に記載のユーザ装置。
（第７項）
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置であって、
所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信部と、
前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択部と、
前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信部と
を備えることを特徴とするユーザ装置。
（第８項）
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、
所定の論理チャネルで送信されるメッセージのサイズと所定の閾値とを比較することにより、複数のランダムアクセス信号グループの中から、ランダムアクセス信号グループを選択し、当該ランダムアクセス信号グループからランダムアクセス信号を選択する選択ステップと、
前記選択ステップにより選択されたランダムアクセス信号を前記基地局に装置する送信ステップと、
前記ランダムアクセス信号に対する前記基地局からの応答により割り当てられるリソースを用いて、前記メッセージを前記所定の論理チャネルで送信する送信ステップと
を備えることを特徴とするランダムアクセス方法。
（第９項）
基地局とユーザ装置とを備える無線通信システムにおいて前記基地局と通信を行う前記ユーザ装置が実行するランダムアクセス方法であって、
所定の論理チャネルで送信されるメッセージのサイズと、ランダムアクセス信号のリソースとの間の対応関係の情報を前記基地局から受信する受信ステップと、
前記所定の論理チャネルで送信されるメッセージのサイズに対応するリソースを、前記対応関係の情報から選択する選択ステップと、
前記選択されたリソースを用いて、ランダムアクセス信号を前記基地局に送信する送信ステップと
を備えることを特徴とするランダムアクセス方法。
【０１７１】
本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。
【符号の説明】
【０１７２】
１０、２０  ｅＮＢ
１１  ＤＬ信号送信部
１２  ＵＬ信号受信部
１３  ＲＲＣ処理部
１４  ＵＥコンテクスト管理部
１５  ＮＷ通信部
３０  ＭＭＥ
４０  Ｓ−ＧＷ
５０  ＵＥ
５１  ＤＬ信号受信部
５２  ＵＬ信号送信部
５３  プリアンブル選択部
５４  ＲＲＣ処理部
５５  ＵＥコンテクスト管理部
１５１  ＲＥモジュール
１５２  ＢＢ処理モジュール
１５３  装置制御モジュール
１５４  ＵＳＩＭスロット
２５１  ＲＥモジュール
２５２  ＢＢ処理モジュール
２５３  装置制御モジュール
２５４  通信ＩＦ
【図１】
2019220986.tif 000003
【図２】
2019220986.tif 000004
【図３】
2019220986.tif 000005
【図４】
2019220986.tif 000006
【図５】
2019220986.tif 000007
【図６】
2019220986.tif 000008
【図７】
2019220986.tif 000009
【図８】
2019220986.tif 000010
【図９】
2019220986.tif 000011
【図１０】
2019220986.tif 000012
【図１１】
2019220986.tif 000013
【図１２】
2019220986.tif 000014
【図１３】
2019220986.tif 000015
【図１４】
2019220986.tif 000016
【図１５】
2019220986.tif 000017
【図１６】
2019220986.tif 000018
【図１７】
2019220986.tif 000019
【図１８】
2019220986.tif 000020
【図１９】
2019220986.tif 000021
【図２０】
2019220986.tif 000022
【図２１】
2019220986.tif 000023
【図２２】
2019220986.tif 000024
【図２３】
2019220986.tif 000025
【図２４】
2019220986.tif 000026
【図２５】
2019220986.tif 000027
【図２６】
2019220986.tif 000028
【図２７】
2019220986.tif 000029