JP7031644B2 - 無線端末及びその方法 - Google Patents

Description

本開示は、無線通信システムに関し、特にランダムアクセス手順に関する。

3rd Generation Partnership Project (3GPP)ではCellular Internet of Things（CIoT）の標準化が行われている。3GPPが対象としているCIoTは、Long Term Evolution enhanced Machine to Machine（LTE eMTC）及びNarrowband IoT（NB-IoT）を含む。LTE eMTC及びNB-IoTは、極めて低いUser Equipment（UE）消費電力（Ultra low UE power consumption）、セルあたりの多数のデバイス、狭帯域スペクトラム、拡張されたカバレッジ等の特徴を含む。LTE eMTC（Category M）では、UEの受信無線周波数（Radio Frequency（RF））帯域は1.4 MHzと定められている。これに対して、NB-IoTでは、更なるコスト最適化、低消費電力、及びカバレッジ拡張のために、ダウンリンク及びアップリンクのピークレートが200 kbps又は144 kbpsであり、UEの受信RF帯域は、アップリンク及びダウンリンクともに200 kHz程度（実効180 kHz）であることが想定されている。

非特許文献１は、NB-IoTにおける頻繁でないスモールデータ送信（infrequent small data transmission）のための幾つかの通信アーキテクチャ・ソリューションを記載している。これらのソリューションは、コントロールプレーンでのデータ送信アーキテクチャ（ソリューション２）と、Radio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う ユーザプレーンでのデータ送信アーキテクチャ（ソリューション１８）を含む。非特許文献１では、ソリューション２のサポートがUE及びネットワークの両方に必須とされており、ソリューション１８のサポートがUE及びネットワークの両方にオプションとされている。

ソリューション２及びソリューション１８はそれぞれ“Data over NAS （DoNAS）”及び“AS context caching”と呼ばれることもある。あるいは、ソリューション２及びソリューション１８はそれぞれ“Control Plane CIoT EPS optimisation”及び“User Plane CIoT EPS optimisation”と呼ばれることもある。

ソリューション１８に係るアーキテクチャは、頻繁でないスモールデータのユーザプレーン上での送信を提供する。ただし、UEのRadio Resource Control（RRC）状態遷移に伴うシグナリングを削減するために、ソリューション１８に係るアーキテクチャは、以前の（previous）RRCコネクションからの情報を後の（subsequent）のRRCコネクション・セットアップのために再利用することを特徴とする。

具体的には、UEは、RRC-ConnectedからRRC-Idleモードに遷移し、RRC-IdleモードにおいてRRCコネクションに関する情報、e.g., Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを保持（retain）する。同様に、eNBも、当該UEのRRCコネクションに関する情報、e.g., Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを保持する。さらに、eNB及びMobility Management Entity（MME）は、S1AP UE Contextsを保持する。さらにまた、eNBは、S1-U tunnel addressesを保持する。

RRC-Connectedモードに戻るとき、UEは、RRC Connection Resume RequestをeNBに送る。eNBは、保持していたRRCコネクションに関する情報に基づいて、DRB、セキュリティコンテキスト、S1APコネクション、S1-Uトンネルを復元する。さらに、eNBは、新たなS1APメッセージ（e.g., S1AP: UE Context Resume Request）を用いて、UE 状態変更（state change）をMMEに知らせる。MMEは、当該UEのEvolved Packet System（EPS）Connection Management（ECM）状態をECM-Connected 状態に戻し、Modify Bearer RequestメッセージをS-GWに送る。これにより、Serving Gateway（S-GW）は、UE が Connected状態にあると認識し、当該UEに向けたダウンリンクデータを送信できる状態となる。

ソリューション１８では、UEは、NASメッセージ（i.e., Service Request）を送信せずに、RRC-ConnectedかつECM-Connected に戻ることができる。また、既存の（legacy）RRCコネクション・セットアップ手順に比べて、以下のRRCメッセージを削減できる：
・RRC Connection Setup Complete；
・RRC Security Mode Command；
・RRC Security Mode Complete；
・RRC Connection Reconfiguration；及び
・RRC Connection Reconfiguration Complete。

RRCコネクションの休止（suspension）及び再開（resumption）を可能とするためにResume IDが使用される。Resume IDは、休止されている複数のUE、RRCコネクション、又はUEコンテキストを区別するために使用される。eNBは、RRCコネクションの休止をUEに指示するためのダウンリンクRRCメッセージ（e.g., RRC Connection Release）にResume IDを含める。UEはRRCコネクションを再開する際に、Resume IDを包含するRRC Connection Resume Requestメッセージを送信する。

なお、UEがRRC-Idle中にセル再選択（cell reselection）を行い、他のeNBのセルに移動した後、RRC Connection Resume Requestを当該セルで行うことが想定される。この場合、当該他のeNB（ターゲットeNB）は、Resume IDを基に、UEがRRCコネクションを休止したセルを管理するeNB（ソースeNB）を特定する。ターゲットeNBは、ソースeNBにUE contextの送信を要求するために、Resume ID, Short MAC-I, 及びE-UTRAN Cell Identifier (ECGI)を含むRETRIEVE UE CONTEXT REQUESTメッセージを送信する。ソースeNBは、それに応答してUE Contextが合致するか否か（つまりresumeが成功するか否か）を判定する。UE Contextが合致した（resumeが成功した）場合には、ソースeNBはRETRIEVE UE CONTEXT RESPONSEメッセージでUE contextをターゲットeNBに送信する。ターゲットeNBは、さらにMMEにUE CONTEXT RESUME REQUESTメッセージを送信する。MMEは、ベアラの再確立（修正）をS-GW/Packet Data Network Gateway(P-GW)に指示し、ターゲットeNBへUE CONTEXT RESUME RESPONSEメッセージを送信する。これにより、ターゲットeNBおよびUEは、データ送信および受信を再開することができる。

現時点では、Resume IDは、20ビット長のeNB ID及び20ビット長のUE IDから構成され、40ビット長を持つことが想定されている。40ビットのResume IDを含む最初のアップリンクRRCメッセージ（i.e., RRC Connection Resume Requestメッセージ）をランダムアクセスの第３メッセージ（Msg3）で送信する場合、Msg3のサイズは、最小の56ビットでは不十分であり、80ビット又は88ビットが必要とされる。

さらに、3GPPは、NB-IoTに関する上述のシグナリング拡張（i.e., ソリューション２及びソリューション１８）を非NB-IoT（non-NB-IoT）システム（e.g., LTE）にも適用することを検討している。Non-NB-IoTのUEsは、例えば、LTE eMTC（Category M）UEsである。

Non-NB-IoT UEsの場合、もし40ビットのResume IDが使用されると、eNBは、ランダムアクセスの第２メッセージ（Msg2）、つまりランダムアクセス・レスポンス内のアップリンク（UL）グラントによって、第３メッセージ（Msg3）の送信のために80ビット又は88ビットのアップリンク・リソース（i.e., Physical Uplink Shared Channel（PUSCH）リソース）を割り当てなければならない。また、non-NB-IoT UEsは、Msg3の用途、すなわちRRC Connection Resume Request, RRC Connection Request, 又はRRC Connection Reestablishment Requestに関わらず、常に80ビット又は88ビットのMsg3を送信しなければならない。つまり、RRC Connection Request、又はRRC Connection Reestablishment Requestでは、余分な（padding）ビットを送信することになり、無線リソースの無駄な使用につながる。

加えて述べると、ランダムアクセス手順の第３メッセージ（Msg3）のサイズが増加された場合、従来LTEで保障されていたカバレッジが保障されないかもしれない。つまり、Msg3サイズの増加は、non-NB-IoT (e.g., LTE) UEs に関してLTE ULカバレッジを制限する要因となり得る。

非特許文献２は、40ビットResume IDを常にnon-NB-IoT UEsのために使用することに起因するULカバレッジへのインパクトを回避するために、40ビットResume IDの一部のみを使用することを提案している。具体的には、非特許文献２は、non-NB-IoT UEs がRRC resume のためのMsg3を用いてtruncated Resume ID（i.e., 40ビットResume IDの25 least significant bits（LSB））を送信することを提案している。さらに、非特許文献２は、non-NB-IoT UEsがfull resume ID及びtruncated resume IDのどちらをRRC resume のためのMsg3で送信するべきかを示すResume ID type indicationをnon-NB-IoT UEsのためのシステム情報（System Information）に導入することを提案している。

さらにまた、3GPPは、受信したPRACH preambleが80（又は88）ビットのMsg3（i.e., full resume IDを包含するRRC Connection Resume Request）を送信するためであるか又は56ビットのMsg3（i.e., RRC Connection Request、RRC Connection Reestablishment Request、又はtruncated resume IDを包含するRRC Connection Resume Request）を送信するためであるかを区別することをeNBに可能とするために、既存のPRACHパーティショニングを再利用することを検討している。

具体的には、non-NB-IoT UEsは、full resume IDを包含するRRCメッセージを運ぶMsg3の送信を予定している場合に、80ビット又はそれ以上のMsg3 サイズに関連付けられたRandom Access Preambles groupを選択し、選択されたPreambles groupの中からプリアンブルを選択する。一方、non-NB-IoT UEsは、truncated resume IDを運ぶRRCメッセージ、又は既存のRRC Connection Requestメッセージ若しくはRRC Connection Reestablishment Requestメッセージを運ぶ56ビット以下のMsg3の送信を予定している場合に、56ビットのMsg3 サイズに関連付けられた別のRandom Access Preambles groupを選択し、選択されたPreambles groupの中からプリアンブルを選択する。eNBは、受信したPRACHプリアンブルに基づいて、56ビットMsg3又は80ビット Msg3のいずれに対応したPUSCHリソースを割り当てるべきかを判断できる。

3GPP TR 23.720 V1.2.0 (2015-11), "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for Cellular Internet of Things (Release 13)", November 2015 3GPP R2-162269, Huawei, HiSilicon, "Resume ID for non-NB-IoT UEs", 3GPP TSG- RAN WG2 Meeting #93bis, Dubrovnik, Croatia, 11-15 April 2016

しかしながら、既存のPRACHパーティショニングは、eMTC（Category M） UEsに適用されていないことに留意するべきである。Category M UEsは、Coverage Enhancement（CE）レベルに基づくPRACHリソース選択を行う。3GPPは、eMTC（Category M） UEsのためのカバレッジ向上（Coverage Enhancement（CE））技術を規定している。

例えば、カバレッジ向上技術は、通常のカバレッジ（normal coverage, zero coverage extension）に加えて、３つのCEレベルを提供する。複数のCEレベルは、互いに異なる送信繰り返し回数及び受信繰り返し回数に対応付けられる。高いCEレベルで使用される送信繰り返し回数及び受信繰り返し回数は、低いCEレベルで使用されるそれらに比べて大きい。各Category M UEは、当該Category M UEとeNBとの間の伝搬損失が大きくなるほど、高いCEレベルに割り当てられる。幾つかの実装において、各Category M UEは、eNBからの参照信号の受信電力（Reference Signal Received Power（RSRP））又はMTC UEとeNBの間の推定される伝搬損失を計測し、計測されたRSRP又は伝搬損失とシステム情報（System Information Block（SIB））で送信されるCEレベルの判定閾値とに基づいて、必要とされるCEレベルを決定（推定）する。そして、各Category M UEは、決定されたCEレベルに対応付けられたランダムアクセスのリソース（Physical Random Access Channel (PRACH) resource）（e.g., RACH preamble index, time, frequency）を選択し、決定されたCEレベルに対応付けられた最大送信繰り返し回数に従ってRACHプリアンブルを送信する。

したがって、特にカバレッジ向上をサポートするUEs（i.e., Category M UEs）のために、UEsが希望するMsg3サイズとeNB からのMsg2内のULグラントによるMsg3送信に対するアップリンク・リソース割り当てを関連付ける新たな仕組みが必要である。本明細書に開示される実施形態が達成しようとする目的の１つは、無線端末（e.g., Category M UEs）によって希望されているMsg3サイズを容易に知ることを基地局（e.g., eNB）に可能にすることに寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、無線端末は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、（ａ）前記無線端末と基地局との間のパスロス・レベル、（ｂ）前記パスロス・レベルに基づくカバレッジ向上レベル、又は（ｃ）前記無線端末に設定されているカバレッジ向上モードを判定するよう構成されている。さらに、前記少なくとも１つのプロセッサは、前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちどちらか一方をランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含めるために選択するよう構成されている。

第２の態様では、無線端末における方法は、
（ａ）前記無線端末と基地局との間のパスロス・レベル、（ｂ）前記パスロス・レベルに基づくカバレッジ向上レベル、又は（ｃ）前記無線端末に設定されているカバレッジ向上モードを判定すること、及び
前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちのどちらか一方をランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含めるために選択すること、
を含む。

第３の態様では、基地局は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、報知情報を送信するセル内に送信するよう構成されている。前記報知情報は、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちのどちらがランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含まれるべきかを、（ａ）無線端末と前記基地局との間のパスロス・レベルごと、（ｂ）カバレッジ向上レベルごと、又は（ｃ）カバレッジ向上モードごと、に特定する。

第４の態様では、基地局における方法は、報知情報を生成すること、及び報知情報を送信するセル内に送信することを含む。前記報知情報は、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちのどちらがランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含まれるべきかを、（ａ）無線端末と前記基地局との間のパスロス・レベルごと、（ｂ）カバレッジ向上レベルごと、又は（ｃ）カバレッジ向上モードごと、に特定する。

第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第２又は第４の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

上述の態様によれば、無線端末（e.g., Category M UEs）によって希望されているMsg3サイズを容易に知ることを基地局（e.g., eNB）に可能にすることに寄与する装置、方法、及びプログラムを提供できる。

いくつかの実施形態に係る無線通信ネットワークの構成例を示す図である。 第１の実施形態に係る無線端末の動作の一例を示すフローチャートである。 第１の実施形態に係る通信手順の一例を示すシーケンス図である。 第１の実施形態に係る無線端末の動作を定める記述の一例を示す図である。 ランダムアクセスの第３メッセージ（Msg3）で送信されるresume IDのサイズをカバレッジ向上レベルごとに特定する情報要素の一例を示す図である。 ランダムアクセスの第３メッセージ（Msg3）で送信されるresume IDのサイズをカバレッジ向上レベルごとに特定する情報要素の一例を示す図である。 ランダムアクセスの第３メッセージ（Msg3）で送信されるresume IDのサイズをカバレッジ向上レベルごとに特定する情報要素の一例を示す図である。 その他の実施形態に係る無線端末の動作を定める記述の一例を示す図である。 いくつかの実施形態に係る無線端末の構成例を示すブロック図である。 いくつかの実施形態に係る基地局の構成例を示すブロック図である。

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。

以下に説明される複数の実施形態は、LTE eMTCのための無線通信ネットワークを主な対象として説明される。しかしながら、これらの実施形態は、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEの通信に適用されてもよい。つまり、これらの実施形態は、LTE、LTE-Advanced及びこれらの改良に係るその他のUEの通信のための無線ネットワークを対象としてもよい。さらにまた、上述の実施形態は、LTE、LTE-Advanced 及びこれらの改良に限定されるものではなく、その他の無線通信ネットワークに適用されてもよい。

＜第１の実施形態＞
図１は、本実施形態を含むいくつかの実施形態に係る無線通信ネットワークの構成例を示している。図１の例では、無線通信ネットワークは、１又は複数の無線端末（UE）１及び基地局（eNB）２を含む。各UE１は、少なくとも１つの無線トランシーバを有し、eNB２とのセルラー通信を行うよう構成されている。eNB２は、セル２１を管理し、セルラー通信技術（e.g., Evolved Universal Terrestrial Radio Access (E-UTRA) technology）を用いて複数のUE１の各々とセルラー通信を行うよう構成されている。

図１に示されたeNB２は、Centralized Radio Access Network（C-RAN）アーキテクチャで使用されるBaseband Unit（BBU）であってもよい。言い換えると、図１に示されたeNB２は、１又は複数のRemote Radio Head（RRH）に接続されるRANノードであってもよい。いくつかの実装において、BBUとしてのeNB２は、コントロールプレーン処理とユーザプレーンのデジタルベースバンド信号処理を担当する。一方、RRHは、アナログRadio Frequency（RF）信号処理（e.g., 周波数変換および信号増幅）を担当する。なお、C-RANは、Cloud RANと呼ばれることもある。また、BBUは、Radio Equipment Controller（REC）又はData Unit（DU）と呼ばれることもある。RRHは、Radio Equipment（RE）、Radio Unit（RU）、又はRemote Radio Unit（RRU）と呼ばれることもある。

図１の例では、各UE１は、eMTC (Category M）UEである。図１の例では、UE１Ａは、UE１Ｂに比べeNB２からの距離が離れているために、伝搬損失が大きく無線品質が劣化することが想定される。UE１Ｃは建物（例えばビル）内に設置されており、屋外に設置される場合に比べて無線品質が劣化することが想定される。また、仮にUEs１が、音声通話及びwebブラウジング等のヒューマンタイプ通信を行うUEs、例えば、スマートフォン及びタブレットコンピュータ、に比べて限られた能力又は機能のみを持つ場合、無線品質の劣化が更に顕著になると予想される。したがって、本実施形態に係るUEs１は、上述したカバレッジ向上技術をサポートする。ダウリンク（DL）セルカバレッジを向上するためには、DL送信の繰り返し、例えばシステム情報、MTC-Physical Downlink Control Channel（M-PDCCH）、及びPhysical Downlink Shared Channel（PDSCH）の繰り返し送信が用いられることができる。アップリンク（UL）セルカバレッジを向上するためには、UL送信の繰り返し、例えばRACHプリアンブル、Physical Uplink Control Channel（PUCCH）、及びPUSCHの繰り返し送信が用いられることができる。

UE１は、複数のカバレッジ向上モード（Coverage Enhancement （CE）Modes）をサポートしてもよい。幾つかの実装において、UE１は、RRC_CONNECTED状態のためのCE modesとRRC_IDLE状態のための別のCE modesをサポートしてもよい。さらに又はこれに代えて、UE１は、RRC_CONNECTED状態のための複数のCE modes（e.g., CE mode A及びCE mode B）をサポートしてもよいし、RRC_IDLE状態のための複数のCE modesをサポートしてもよい。幾つかの実装において、各CE modeに複数のバレッジ向上レベルが定義される。幾つかの実装において、複数のCE modesは、互いに異なるカバレッジ向上レベル（levels）を提供する。

続いて以下では、各UE１によって希望されているMsg3サイズを容易に知ることをeNB２に可能にするための各UE１の動作について説明する。なお、LTEでよく知られているように、Msg3は、ランダムアクセス手順内で送信される最初の（initial）アップリンクレイヤ２／レイヤ３メッセージである。より具体的には、一例において、Msg3は、Common Control Channel Service Data Unit（CCCH SDU）を包含する。CCCH は、RRCコネクションが存在しない場合に使用される論理チャネルである。CCCH SDUは、コンテンション・レゾリューション（contention resolution）のためのUE Identity（e.g., random value, S-TMSI）を包含する最初のアップリンクRRCメッセージを包含する。最初のアップリンクRRCメッセージは、例えば、RRC Connection Request、RRC Connection Reestablishment Request、又はRRC Connection Resume Requestである。既に説明したように、RRC Connection Resume Requestメッセージは、AS Context Caching（ソリューション１８）をサポートするNB-IoT UEs及びnon-NB-IoT UEsによってRRCコネクションの再開を要求するために送信される。

図２は、UE１の動作の一例を示すフローチャートである。図２の手順は、AS Context Caching（ソリューション１８）をサポートし、且つRRCコネクションを休止（suspend）しているUE１によって実行される。

ステップ２０１では、UE１のRRCレイヤは、カバレッジ向上（CE）レベルを判定する。具体的には、UE１は、eNB２からの信号の受信品質（e.g., RSRP）の計測値、又はUE１とeNB２の間の伝搬損失の計測値（推定値）に基づいて必要とされるCEレベルを判定（推定）する。一例において、通常のカバレッジ（normal coverage, zero coverage extension）に加えて、３つのCEレベルが使用されてもよい。すなわち、UE１は、４つのCEレベルの中から１つのCEレベルを選択してもよい。複数のCEレベルは、互いに異なる送信繰り返し回数及び受信繰り返し回数に対応付けられる。高いCEレベルで使用される送信繰り返し回数及び受信繰り返し回数は、低いCEレベルで使用されるそれらに比べて大きい。

ステップ２０２では、UE１のRRCレイヤは、判定されたCEレベルに基づいて、full resume IDとtruncated resume IDのどちらか一方をRRC Connection Resume Requestメッセージに含めるために選択する。言い換えると、UE１は、full resume ID及びtruncated resume IDのどちらをRRC Connection Resume Requestメッセージで送信するかを、当該UE１に必要とされるCEレベルに基づいて決定する。既に説明したように、Resume ID（full resume ID）は、RRCコネクションの休止（suspension）のためにreleaseCauseがrrcSuspendに設定されたRRC Connection ReleaseメッセージでeNB２からUE１に送られる識別情報であり、例えば40ビット長を持つ。これに対して、truncated resume IDは、full resume IDより小さいビット長を持つ短縮された（shortened）resume IDである。Truncated resume IDは、full resume IDから導かれる。例えば、Truncated resume IDは、40bits full resume IDの25 LSBであってもよい。

具体的には、UE１は、複数のCEレベルのうちの１又はそれ以上の特定のCEレベルのいずれかを選択した場合に、full resume IDに代えてtruncated resume IDをRRC Connection Resume Requestメッセージで送信する。これに対して、UE１は、残りの１又はそれ以上のCEレベルのいずれかを選択した場合に、full resume IDをRRC Connection Resume Requestメッセージで送信する。

ステップ２０３では、UE１のRRCレイヤは、RRC Connection Resume Requestメッセージを包含するCCCH SDUの送信を、Medium Access Control（MAC）レイヤを含む下位レイヤに指示する。当該RRC Connection Resume Requestメッセージ又はCCCH SDUは、ステップ２で選択されたfull resume ID又はtruncated resume IDのうちいずれか一方を包含する。

ステップ２０４では、UE１のMACレイヤは、RRCレイヤからのRRC Connection Resume Requestメッセージ又はCCCH SDUの送信の要求に応答して、ランダムアクセス手順を実行する。当該ランダムアクセス手順は、例えば、以下のステップ（ａ）～（ｄ）を含む：
（ａ）ステップ２０１で判定されたCEレベルに基づいてランダムアクセスのリソースを選択すること、
（ｂ）選択されたランダムアクセスのリソースに従って、ランダムアクセス・プリアンブルをeNB２に送信すること、
（ｃ）ステップ（ｂ）で送信されたランダムアクセス・プリアンブルに対するランダムアクセス・レスポンスをeNB２から受信すること、及び
（ｄ）当該ランダムアクセス・レスポンスによって指定されたアップリンク・リソースを用いて、最初のアップリンクRRCメッセージ（i.e., full resume ID又はtruncated resume IDのうちいずれか一方を包含するRRC Connection Resume Requestメッセージ）を送信すること。

図３は、本実施形態に係るランダムアクセス手順の一例（処理３００）を示すシーケンス図である。ステップ３０１では、UE１は、AS Context Caching（ソリューション１８）のための休止（suspension）動作を実行している。すなわち、UE１は、RRCアイドル状態において、以前のRRCコネクションに関するコンテキスト（UE context）を保持する。例えば、UE１は、UE contextの一部としてresume IDを保持してもよいし、UE contextをresume IDと関連付けて保持してもよい。

ステップ３０２では、UE１（RRCレイヤ）は、RRC_IDLE 状態からのイニシャル・アクセスのためにRRC Connection Resume手順を開始する。具体的には、UE１は、必要とされるCEレベルを判定する。ステップ３０３では、UE１は、決定されたCEレベルに対応するカバレッジ向上技術（e.g., システム情報（System Information Block（SIB））の繰り返し送信）を適用しながら、eNB２から送信されるシステム情報を受信する。当該システム情報は、CEレベル毎のランダムアクセス設定（PRACH config, RACH config）を含む。CEレベル毎のランダムアクセス設定は、例えば、以下に関する情報を含む：
・RACHプリアンブルのインデックス、
・PRACHアテンプトの最大回数、
・PRACHアテンプト当たりのプリアンブル送信の繰り返し回数、
・ランダムアクセス（RA）・レスポンス・ウインドウの継続時間（duration）、
・MACコンテンション・レゾリューション・タイマの値、及び
・ランダムアクセス・レスポンス（RAR）メッセージの送信に使用されるM-PDCCH送信の繰り返し回数。

ステップ３０４では、UE１（RRCレイヤ）は、ステップ３０２で判定されたCEレベルに基づいて、full resume IDとtruncated resume IDのどちらか一方をRRC Connection Resume Requestメッセージに含めるために選択する。そして、UE１のRRCレイヤは、MACレイヤを含む下位レイヤに、RRC Connection Resume Requestメッセージの送信を要求する。

ステップ３０５では、UE１のMACレイヤは、ランダムアクセス手順を開始する。すなわち、UE１（MACレイヤ）は、ステップ３０２で判定されたCEレベルに基づいてランダムアクセス（RA）プリアンブルを選択する。ステップ３０６では、UE１は、ランダムアクセス・プリアンブルを送信する。ステップ３０６でのプリアンブル送信は、ステップ３０１で判定されたCEレベルに関するプリアンブル送信設定（e.g., PRACHアテンプトの最大回数、及びPRACHアテンプト当たりのプリアンブル送信の繰り返し回数）に従って行われてもよい。

ステップ３０７では、eNB２は、UE１から送信されたランダムアクセス・プリアンブルを検出する。例えば、eNB２は、ランダムアクセス・プリアンブルが検出された無線リソースに基づいてUE１のCEレベルを判定する。そして、eNB２は、判定されたUE１のCEレベルに従って、ランダムアクセス・レスポンスの繰り返し送信（ステップ３０８）を含むカバレッジ向上のための動作を実行する。

ステップ３０８のランダムアクセス・レスポンスは、Msg3送信（ステップ３０９）のためのUE１へのPUSCHリソース割り当てを示すULグラントを包含する。なお、本実施形態では、eNB２は、UE１が送信を希望しているMsg3のサイズを、当該UEのCEレベルによって知ることができる。したがって、eNB２は、UE１のCEレベルに基づいて、ULグラントのサイズ、つまりMsg3送信（ステップ３０９）のためにUE１に割り当てるPUSCHリソースのサイズを決定すればよい。

ステップ３０９では、UE１は、ステップ３０８のランダムアクセス・レスポンス内のULグラントに従って、RRC Connection Resume Requestメッセージを包含するMsg3をeNB２に送信する。

ステップ３１０では、eNB２は、休止されていたRRCコネクション（suspended RRC connection）を再開（resume）することが可能な場合、RRC Connection ResumeメッセージをUE１に送信する。当該メッセージは、例えば無線リソース設定情報（RadioResourceConfigDedicated IE）、AS layerのセキュリティを有効にするために必要なNextHopChainingCountなどのセキュリティ設定情報を含んでもよい。なお、RRCコネクションの再開の成否の判定は、RRC Connection Resume Requestメッセージに含まれるResume IDとShort MAC-Iによって行われる。

ステップ３１１では、UE１のAccess Stratum（AS）レイヤは、保持していたUE contextを基にLayer 2の再確立（e.g., MAC reset, RLC reestablishment, PDCP reestablishment）、セキュリティ鍵の更新などを行い、上位レイヤ（NAS）にRRCコネクションの再開（resume）を通知する。そして、UE１は、RRC Connection Resume CompleteメッセージをeNB２に送信する。

なお、図２に示されたCEレベルに基づくfull resume ID又はtruncated resume IDの選択、及び図３に示されたランダムアクセス手順は、本実施形態に係るUE１及びeNB２の動作の一例であり、例えば以下に示すように適宜変形されることができる。例えば、UE１は、RRCコネクション再開時のCEレベルをfull resume ID又はtruncated resume IDの選択のために使用してもよい。これに代えて、UE１は、RRCコネクション休止時のCEレベルをfull resume ID又はtruncated resume IDの選択のために使用してもよい。

以上の説明から理解されるように、本実施形態では、UE１によるfull resume ID又はtruncated resume IDの選択が当該UE１のCEレベルに関連付けられる。以下では、当該関連付けを定めるためのいくつかの手法が説明される。

第１の例では、full resume ID及びtruncated resume IDのいずれか一方と各CEレベルとの関連付けが予めUE１及びeNB２に設定される。例えば、RRCプロトコルに関する3GPP仕様書に図４に示すUE動作が規定され、UE１は規定されたUE動作に従って動作してもよい。

図４の例では、もしUE１がBandwidth reduced Low complexity（BL）UEであるか又はCoverage Enhancement（CE）であり（４０１）、且つ “fullResumeID”がシステム情報（SIB Type 1）内の所定の情報要素（e.g., Resume ID type indication IE）に含まれているとき（４０２）、UE１は以下のように動作する。なお、システム情報内の“fullResumeID”は、UE１によるfull resume IDのMsg3での送信をeNB２がセル２１内で許可していることを示す。UE１は、UE１のCEレベルが最高CEレベルであるとき（alt. 1）又はUE１のCEレベルがCEレベルXかそれ以上であるとき（alt. 2）（４０３）、“resumeIdentity”に“TruncatedResumeIdentiy”（e.g., 25 bits LSB of Resume ID）をセットし（４０４）、そうでない場合（４０５）、UE１は、“resumeIdentity”に“FullResumeIdentiy”（e.g., 40 bit Resume ID）をセットする（４０６）。一方、そうでなければ（つまり”fullResumeID”がシステム情報に含まれていない場合）（４０７）、UE１は“resumeIdentity”を“TruncatedResumeIdentiy”にセットする（４０８）。

言い換えると、UE１は、UE１のCEレベルが最高CEレベルであるとき（alt. 1）又はUE１のCEレベルがCEレベルXかそれ以上であるとき（alt. 2）（４０３）、truncated resume IDをRRC Connection Resume Requestメッセージに含める（４０４）。一方、UE１は、UE１のCEレベルが最高CEレベルでない（alt. 1）又はUE１のCEレベルがCEレベルXより低いとき（alt. 2）（４０５）、full resume IDをRRC Connection Resume Requestメッセージに含める（４０６）。なお、既に説明したように、高いCEレベルで使用される送信繰り返し回数及び受信繰り返し回数は、低いCEレベルで使用されるそれらに比べて大きい。すなわち、CEレベルが高いほどUE１とeNB２の間の伝搬損失が大きいことを意味する。

なお、図４に示された“fullResumeID”は、RRC Connection Resume Requestメッセージにおいてfull resume IDを送信することを指示する情報（値、名称）の例であり、“fullResumeID”に代えて他の情報（値、名称）（e.g., “fullID”, “full”, “non-truncatedID” or “non-truncated”）が使用されてもよい。同様に、Resume ID type indicationは、上記”fullResumeID”を含む情報要素（IE）の例であり、他のIE（e.g., ResumeID-Type, ResumeID or ResumeIdentity）でもよい。さらに、これらは、SIB Type1の代わりに、SIB Type2またはMIB（Master Information Block）で送信されてもよい。

さらに、図４は“fullResumeID”が送信（通知）される例を示しているが、これに代えて“truncatedResumeID”が送信（通知）されてもよい。例えば、”truncatedResumeID”が通知された場合、かつUE１が高CEレベルであるとき（alt. 1）又はUE１のCEレベルがCEレベルXかそれ以上であるとき（alt. 2）、UE１は“resumeIdentity”に“TruncatedResumeIdentiy”を設定する。もし、”truncatedResumeID”が送信されていない場合、UE１は“resumeIdentity”に“FullResumeIdentiy”を設定するようにしてもよい。

第２の例では、full resume ID及びtruncated resume IDのいずれか一方と各CEレベルとの関連付けをeNB２がUE１に明示的に通知する。図５は、full resume ID及びtruncated resume IDのいずれか一方と各CEレベルとの関連付けを特定するためにシステム情報（SIB）に含まれる情報要素（information element（IE））の一例を示している。図５に示された“Resume-CE-LevelInfoList” IEは、各CEレベルの“Resume-CE-LevelInfo” IEを含む。“Resume-CE-LevelInfo” IEは、“reportResumeIdentity-CE” IE（５０１）を含む。“reportResumeIdentity-CE” IE（５０１）は、full resume ID（full）又はtruncated resume ID（truncated）を示す。

UE１のCEレベルに対応する“reportResumeIdentity-CE” IE（５０１）がfull resume IDを示す場合、UE１はfull resume IDをRRC Connection Resume Requestメッセージで送信するよう動作する。これに対して、UE１は、UE１のCEレベルに対応する“reportResumeIdentity-CE” IE（５０１）がtruncated resume IDを示す場合、UE１はtruncated resume IDをRRC Connection Resume Requestメッセージで送信するよう動作する。

第３の例では、eNB２は、各CEレベル内でPRACHパーティショニングが使用されるか否かをRACH configuration（RACH-Config）によって指定する。RACH configurationは、システム情報（SIB）でセル２１内に報知（ブロードキャスト）される。すなわち、eNB２は、あるCEレベル内でPRACHパーティショニングを使用する場合、当該CEレベルに割り当てる複数のPRACHプリアンブルをさらに２つに区分する。あるCEレベルのための２つのPRACHプリアンブルグループは、異なるMsg3サイズが設定される。

図６Ａ及び図６Ｂは、RACH configuration（RACH-Config）の一例を示している。図６Ａ及び図６Ｂの例では、“RACH-CE-LevelInfo”IE（６０１）内の“preambleMappingInfo”IE（６０２）は、各CEレベルに割り当てられるPRACHプリアンブル（preambles）を指定する。さらに、図６Ａ及び図６Ｂの例では、“RACH-CE-LevelInfo”IE（６０１）は、“preamblesGroupAConfig-CE”IE（６０３）を含んでもよい。“preamblesGroupAConfig-CE”IE（６０３）は、各CEレベル内でのPRACHパーティショニング（プリアンブル・グルーピング）の設定を指定する。“messageSizeGroupA-CE”IE（６０４）は、各CEレベル内でのpreamble group AのMsg3サイズ閾値を指定する。例えば、preamble group AのMsg3サイズ閾値が56ビット（b56）であり、RRC Connection Resume Requestメッセージを送信する場合、UE１は、当該CEレベルのpreamble group Bを使用するランダムアクセス手順を、full resume IDを包含するRRC Connection Resume Requestメッセージの送信のために使用できることを理解できる。

第３の例では、UE１のCEレベルに対してPRACHパーティショニングが設定されている場合に、UE１は、full resume IDをRRC Connection Resume Requestメッセージで送信するよう動作する。これに対して、UE１のCEレベルに対してPRACHパーティショニングが設定されていない場合に、UE１はtruncated resume IDをRRC Connection Resume Requestメッセージで送信するよう動作する。

すなわち、第３の例では、full resume IDとtruncated resume IDのどちらがRRC Connection Resume Requestメッセージ（i.e., Msg3）で送信されるべきかをCEレベル毎に特定するために、CEレベルごとのプリアンブル・グルーピング設定が使用される。図６の例では、CEレベルごとのプリアンブル・グルーピング設定は、RACH configuration（RACH-Config）に含まれ、各CEレベルに割り当てられた複数のランダムアクセス・プリアンブルが２又はそれ以上のサブセットに更に区分されているか否かを示す。

以上の説明から理解されるように、本実施形態に係るUE１は、UE１のCEレベルに基づいてtruncated resume ID又はfull resume IDを選択する。言い換えると、UE１によるfull resume ID又はtruncated resume IDの選択が当該UE１のCEレベルに関連付けられる。したがって、本実施形態に係るeNB２は、UE１のCEレベルを知ることによって、UE１（e.g., Category M UE）によって希望されているMsg3サイズも容易に知ることができる。したがって、本実施形態に係るUE１及びeNB２は、カバレッジ向上をサポートするUEs１（e.g., Category M UEs）のために、UEs１が希望するMsg3サイズとeNB ２からのMsg2内のULグラントによるMsg3送信に対するアップリンク・リソース割り当てを適切に関連付けることができる。また、カバレッジ・レベルが高い（必要となる繰り返し数が大きい）場合、Msg3サイズを抑えることで、カバレッジを保障することができる。

＜その他の実施形態＞
上述の第１の実施形態は、例えば以下のように定義変形されることができる。

幾つかの実装において、UE１は、UE１のCEレベルに応じて、ランダムアクセス手順で送信されるMsg3のサイズを変更するよう動作してもよい。ここで、Msg3のサイズの変更は、当該Msg3に含まれる（含むべき）情報要素（IE）の種類または数を、送信可能な（送信すべき）Msg3のビット数に応じて、所定の規則に基づき変更することに相当してもよい。例えば、ある目的の為のMsg3のコンテンツとして5種類のIEが存在するケースでは、UE１は、Msg3に割り当てられるUL grantサイズに応じて、最低限必要な3個のIEのみをMsg３に含めるか、又は4個若しくは5個全てのIEをMsg3に含めるかを判定してもよい。なお、所定の規則は、仕様に予め規定されていてもよいし、ネットワーク（e.g., eNB, or Operation and Maintenance (O&M) system）から通知されてもよい。

幾つかの実装において、UE１は、CEレベルに代えて、CEモードをfull resume ID又はtruncated resume IDの選択のために使用してもよい。すなわち、UE１は、RRCコネクションを休止するときにRRC_CONNECTEDのUE１に設定されていたCEモードに基づいて、full resume ID及びtruncated resume IDのどちらか一方をRRC Connection Resume Requestメッセージに含めるために選択してもよい。これに代えて、UE１は、RRCコネクションを再開するときにRRC_IDLEのUE１に設定されているCEモードに基づいて、full resume ID又はtruncated resume IDを選択してもよい。

例えば、RRCプロトコルに関する3GPP仕様書に図７に示すUE動作が規定され、UE１は規定されたUE動作に従って動作してもよい。図７の例では、もしUE１がBL UEであるか又はCEであり（７０１）、且つ“fullResumeID”がシステム情報（SIB Type 1）内の所定の情報要素（e.g., Resume ID type indication IE）に含まれているとき（７０２）、UE１は以下のように動作する。なお、システム情報内の“fullResumeID”は、UE１によるfull resume IDのMsg3での送信をeNB２がセル２１内で許可していることを示す。UE１は、UE１に設定されているCEモードがCEモードBであるとき（７０３）、 “resumeIdentity”に“TruncatedResumeIdentiy”をセットし（７０４）、そうでない場合（７０５）、UE１は、“resumeIdentity”に“FullResumeIdentiy”をセットする（７０６）。一方、そうでなければ（つまり”fullResumeID”がシステム情報に含まれていない場合）（７０７）、UE１は“resumeIdentity”を“TruncatedResumeIdentiy”にセットする（７０８）。

言い換えると、UE１は、UE１に設定されているCEモードがCEモードBであるとき（７０３）、truncated resume IDをRRC Connection Resume Requestメッセージに含める（７０４）。一方、UE１は、UE１に設定されているCEモードがCEモードAであるとき（７０５）、full resume IDをRRC Connection Resume Requestメッセージに含める（７０６）。

幾つかの実装において、UE１は、CEレベルに代えて、UE１とeNB２との間のパスロス・レベルをfull resume ID又はtruncated resume IDの選択のために使用してもよい。

幾つかの実装において、UE１は、上述されたfull resume ID又はtruncated resume IDの選択動作を、他の情報をランダムアクセス手順のMsg3で送信するために利用してもよい。すなわち、UE１は、（ａ）UE１とeNB２との間のパスロス・レベル、（ｂ）UE１のCEレベル、又は（ｃ）UE１に設定されているCEモード、を判定してもよい。そして、UE１は、判定されたパスロス・レベル、CEレベル、又はCEモードに基づいて、非短縮の第１の情報と当該非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちどちらか一方をランダムアクセス手順内で送信される最初のアップリンクRRCメッセージに含めるために選択するよう構成されてもよい。

これにより、UE１による非短縮の第１の情報又は短縮された第１の情報の選択が当該UE１のCEレベル（又はパスロス・レベル又はCEモード）に関連付けられる。したがって、本実施形態に係るeNB２は、UE１のCEレベル（又はパスロス・レベル又はCEモード）を知ることによって、UE１（e.g., Category M UE）によって希望されているMsg3サイズも容易に知ることができる。したがって、本実施形態に係るUE１及びeNB２は、カバレッジ向上をサポートするUEs１（e.g., Category M UEs）のために、UEs１が希望するMsg3サイズとeNB 2からのMsg2内のULグラントによるMsg3送信に対するアップリンク・リソース割り当てを適切に関連付けることができる。

一例として、3GPPで議論されている簡易なRRC接続（light RRC connection）が想定される。当該議論において、RRC_Connected状態とRRC_Idle状態と間に新規RRC状態（またはRRCサブ状態）を導入すること、これに対応してRRC_Connected状態又はRRC_Idle状態のUE動作（と関連するネットワーク動作）を最適化することにより、signaling量の削減、及び端末バッテリ消費を低減することが目標とされている。例えば、上述の実施形態で説明されたUE１によるfull resume ID又はtruncated resume IDの選択動作及びこれに対応するeNB２の動作は、新規RRC状態（またはRRCサブ状態）とRRC_Connected状態の間、又はRRC_Idle状態と新規RRC状態（またはRRCサブ状態）との間の状態遷移のための情報をランダムアクセス手順のMsg3で送信するために利用されてもよい。

幾つかの実装において、休止されていたRRCコネクションの再開のためにUE１によって送信されるTruncated resume IDがFull resume IDの下位数ビット（e.g., LSB 25 bits）である場合、eNB２はUE１のモビリティを考慮してFull resume IDを割り当てるようにしてもよい。例えばeNB２は、モビリティが低い（i.e., 移動する可能性が低い）と予想され且つCEレベルが相対的に高い（i.e., 信号を送信するときに繰り返し回数が多い）UEsのTruncated resume IDsを、これらのTruncated resume IDsが隣接eNBsの隣接セルで使用されるTruncated resume IDsと区別されることができるように設定してもよい。例えば、Resume IDが上述の実施形態のように20 bits eNB IDおよび20 bits UE IDから構成される場合、隣接eNBsのeNB IDsは、下位5 bitsが完全に同一にならないように設定されてもよい。これにより、モビリティが低いUE１は、RRCコネクションが休止（suspend）の間に、電波環境の変化などによりセル再選択（cell reselection）を行って滞在する（camped cell, serving cell）を変更しても、Truncated resume IDでRRCコネクションの再開（resume）が成功する可能性が高くなることが期待される。

幾つかの実装において、休止されていたRRCコネクションの再開のためにUE１によって送信されるTruncated resume IDは、Full resume IDのLSB 25 bitsの代わりに、eNB２によって指定されるFull resume IDの他の部分（例えば、上位11 番目から35番目の25 bits）でもよい。eNB２は、Truncated resume IDとして使用されるFull resume IDの部分を示す設定（full resume IDからの切り出し方法）をUE１に送信する。これは、システム情報（SIB）で送信されてもよいし、個別情報（dedicated RRC signalling）で送信されてもよい。この場合も、例えばeNB２は、モビリティが低い（i.e., 移動する可能性が低い）と予想されるCEレベルが相対的に高い（i.e., 信号を送信するときに繰り返し回数が多い）UEsのTruncated resume IDsを、これらのTruncated resume IDsが隣接eNBsの隣接セルで使用されるTruncated resume IDsと区別されることができるように設定してもよい。さらに、eNBは隣接eNBとX2コネクションを確立するときに、X2 SETUP REQUEST/ X2 SETUP RESPONSEメッセージにて、当該切り出し方法を共有するようにしてもよい。

幾つかの実装において、UE１の休止されていたRRCコネクションの再開（resume）が、eNB２において失敗する（または拒絶される）場合も想定される。この場合、eNB２はRRC Connection Resume Requestメッセージ（e.g., 図３のステップ３０９）に応答して、RRC Connection Setupメッセージを送信してもよい。UE１は、RRC Connection Setupメッセージを受信するとRRCコネクションの再開（resume）が失敗したことを認識し、新規RRCコネクションの確立と同様にRRC Connection Setup Completeメッセージを送信してもよい。従って、Truncated resume IDを用いることで、万が一RRCコネクションの再開（resume）に失敗したとしても、新規RRCコネクションの確立を行うことで、遅延なくデータ送信を開始することができる。

最後に、上述の複数の実施形態に係るUE１及びeNB２の構成例について説明する。図８は、UE１の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ８０１は、eNB２と通信するためにアナログRF信号処理を行う。RFトランシーバ８０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ８０１は、アンテナ８０２及びベースバンドプロセッサ８０３と結合される。すなわち、RFトランシーバ８０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ８０３から受信し、送信RF信号を生成し、送信RF信号をアンテナ８０２に供給する。また、RFトランシーバ８０１は、アンテナ８０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ８０３に供給する。

ベースバンドプロセッサ８０３は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リソース管理、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。

例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ８０３によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、Medium Access Control（MAC）レイヤ、およびPhysical（PHY）レイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ８０３によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、RRCプロトコル、及びMAC Control Element（MAC CE）の処理を含んでもよい。

ベースバンドプロセッサ８０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）、又はMicro Processing Unit（MPU））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ８０４と共通化されてもよい。

アプリケーションプロセッサ８０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ８０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ８０４は、メモリ８０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、UE１の各種機能を実現する。

いくつかの実装において、図８に破線（８０５）で示されているように、ベースバンドプロセッサ８０３及びアプリケーションプロセッサ８０４は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ８０３及びアプリケーションプロセッサ８０４は、１つのSystem on Chip（SoC）デバイス８０５として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。

メモリ８０６は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ８０６は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ８０６は、ベースバンドプロセッサ８０３、アプリケーションプロセッサ８０４、及びSoC８０５からアクセス可能な外部メモリデバイスを含んでもよい。メモリ８０６は、ベースバンドプロセッサ８０３内、アプリケーションプロセッサ８０４内、又はSoC８０５内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ８０６は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。

メモリ８０６は、上述の複数の実施形態で説明されたUE１による処理を行うための命令群およびデータを含む１又は複数のソフトウェアモジュール（コンピュータプログラム）８０７を格納してもよい。いくつかの実装において、ベースバンドプロセッサ８０３又はアプリケーションプロセッサ８０４は、当該１又は複数のソフトウェアモジュール８０７をメモリ８０６から読み出して実行することで、上述の実施形態で説明されたUE１の処理を行うよう構成されてもよい。

図９は、上述の実施形態に係るeNB２の構成例を示すブロック図である。図９を参照すると、eNB２は、RFトランシーバ９０１、ネットワークインターフェース９０３、プロセッサ９０４、及びメモリ９０５を含む。RFトランシーバ９０１は、無線端末１と通信するためにアナログRF信号処理を行う。RFトランシーバ９０１は、複数のトランシーバを含んでもよい。RFトランシーバ９０１は、アンテナ９０２及びプロセッサ９０４と結合される。RFトランシーバ９０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ９０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ９０２に供給する。また、RFトランシーバ９０１は、アンテナ９０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ９０４に供給する。

ネットワークインターフェース９０３は、ネットワークノード（e.g., MME、C-SGN、S-GW）と通信するために使用される。ネットワークインターフェース９０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ９０４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ９０４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、プロセッサ９０４によるコントロールプレーン処理は、S1プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

プロセッサ９０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ９０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

メモリ９０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ９０５は、プロセッサ９０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ９０４は、ネットワークインターフェース９０３又は図示されていないI/Oインタフェースを介してメモリ９０５にアクセスしてもよい。

メモリ９０５は、上述の複数の実施形態で説明されeNB２による処理を行うための命令群およびデータを含む１又は複数のソフトウェアモジュール（コンピュータプログラム）９０６を格納してもよい。いくつかの実装において、プロセッサ９０４は、当該１又は複数のソフトウェアモジュール９０６をメモリ９０５から読み出して実行することで、上述の実施形態で説明されたeNB２の処理を行うよう構成されてもよい。

図８及び図９を用いて説明したように、上述の実施形態に係るUE１及びeNB２が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

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

（付記１）
無線端末であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
（ａ）前記無線端末と基地局との間のパスロス・レベル、（ｂ）前記パスロス・レベルに基づくカバレッジ向上レベル、又は（ｃ）前記無線端末に設定されているカバレッジ向上モードを判定するよう構成され、且つ
前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちどちらか一方をランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含めるために選択するよう構成されている、
無線端末。

（付記２）
前記少なくとも１つのプロセッサは、Radio Resource Control（RRC）レイヤ・モジュール及びMedium Access Control（MAC）レイヤ・モジュールを実行するよう構成され、
前記RRCレイヤ・モジュールは、前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、前記非短縮の第１の情報と前記短縮された第１の情報のうちどちらか一方を前記最初のアップリンクRRCメッセージに含めるために選択するよう動作し、
前記RRCレイヤ・モジュールは、前記最初のアップリンクRRCメッセージの送信を前記MACレイヤ・モジュールを含む下位レイヤに要求するよう動作し、
前記MACレイヤ・モジュールは、前記RRCレイヤからの前記最初のアップリンクRRCメッセージの送信の要求に応答して、前記ランダムアクセス手順を実行するよう動作する、
付記１に記載の無線端末。

（付記３）
前記少なくとも１つのプロセッサは、前記ランダムアクセス手順を実行するよう構成され、
前記ランダムアクセス手順は、
前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、ランダムアクセスのリソースを選択すること、
前記選択されたランダムアクセスのリソースに従って、ランダムアクセス・プリアンブルを前記基地局に送信すること、
前記ランダムアクセス・プリアンブルに対するランダムアクセス・レスポンスを前記基地局から受信すること、及び
前記ランダムアクセス・レスポンスによって指定されたアップリンク・リソースを用いて、前記非短縮の第１の情報又は前記短縮された第１の情報を包含する前記最初のアップリンクRRCメッセージを送信すること、
を含む、
付記２に記載の無線端末。

（付記４）
前記非短縮の第１の情報は、AS context cachingのために前記基地局又は他の基地局から前記無線端末に送られたResume IDであり、
前記短縮された第１の情報は、前記Resume IDから導かれるTruncated Resume IDであり、
前記最初のRRCメッセージは、RRC Connection Resume Requestメッセージである、
付記１～３のいずれか１項に記載の無線端末。

（付記５）
無線端末における方法であって、
（ａ）前記無線端末と基地局との間のパスロス・レベル、（ｂ）前記パスロス・レベルに基づくカバレッジ向上レベル、又は（ｃ）前記無線端末に設定されているカバレッジ向上モードを判定すること、及び
前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちのどちらか一方をランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含めるために選択すること、
を備える、方法。

（付記６）
Radio Resource Control（RRC）レイヤ・モジュール及びMedium Access Control（MAC）レイヤ・モジュールを実行することをさらに備え、
前記RRCレイヤ・モジュールは、前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、前記非短縮の第１の情報と前記短縮された第１の情報のうちどちらか一方を前記最初のアップリンクRRCメッセージに含めるために選択するよう動作し、
前記RRCレイヤ・モジュールは、前記最初のアップリンクRRCメッセージの送信を前記MACレイヤを含む下位レイヤに要求するよう動作し、
前記MACレイヤ・モジュールは、前記RRCレイヤからの前記最初のアップリンクRRCメッセージの送信の要求に応答して、前記ランダムアクセス手順を実行するよう動作する、
付記５に記載の方法。

（付記７）
前記ランダムアクセス手順は、
前記判定されたパスロス・レベル、カバレッジ向上レベル、又はカバレッジ向上モードに基づいて、ランダムアクセスのリソースを選択すること、
前記選択されたランダムアクセスのリソースに従って、ランダムアクセス・プリアンブルを前記基地局に送信すること、
前記ランダムアクセス・プリアンブルに対するランダムアクセス・レスポンスを前記基地局から受信すること、及び
前記ランダムアクセス・レスポンスによって指定されたアップリンク・リソースを用いて、前記非短縮の第１の情報又は前記短縮された第１の情報を包含する前記最初のアップリンクRRCメッセージを送信すること、
を含む、
付記６に記載の方法。

（付記８）
前記非短縮の第１の情報は、AS context cachingのために前記基地局又は他の基地局から前記無線端末に送られたResume IDであり、
前記短縮された第１の情報は、前記Resume IDから導かれるTruncated Resume IDであり、
前記最初のRRCメッセージは、RRC Connection Resume Requestメッセージである、
付記５～７のいずれか１項に記載の方法。

（付記９）
付記５～８のいずれか１項に記載の方法をコンピュータに行わせるためのプログラム。

（付記１０）
基地局であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、報知情報を送信するセル内に送信するよう構成され、
前記報知情報は、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちのどちらがランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含まれるべきかを、（ａ）無線端末と前記基地局との間のパスロス・レベルごと、（ｂ）カバレッジ向上レベルごと、又は（ｃ）カバレッジ向上モードごと、に特定する、
基地局。

（付記１１）
前記非短縮の第１の情報は、AS context cachingのために前記基地局又は他の基地局から前記無線端末に送られたResume IDであり、
前記短縮された第１の情報は、前記Resume IDから導かれるTruncated IDであり、
前記最初のRRCメッセージは、RRC Connection Resume Requestメッセージである、
付記１０に記載の基地局。

（付記１２）
前記報知情報は、ランダムアクセス設定を含み、
前記ランダムアクセス設定は、前記非短縮の第１の情報と前記短縮された第１の情報のうちのどちらが前記最初のアップリンクRadio Resource Control（RRC）メッセージに含まれるべきかをカバレッジ向上レベルごとに特定するために使用される、カバレッジ向上レベルごとのプリアンブル・グルーピング設定を含み、
前記プリアンブル・グルーピング設定は、各カバレッジ向上レベルに割り当てられた複数のランダムアクセス・プリアンブルが２又はそれ以上のサブセットに更に区分されているか否かを示す、
付記１０又は１１に記載の基地局。

（付記１３）
基地局における方法であって、
報知情報を生成すること、及び
報知情報を送信するセル内に送信すること、
を備え、
前記報知情報は、非短縮の第１の情報と前記非短縮の第１の情報より小さいビット長を持つ短縮された第１の情報のうちのどちらがランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージに含まれるべきかを、（ａ）無線端末と前記基地局との間のパスロス・レベルごと、（ｂ）カバレッジ向上レベルごと、又は（ｃ）カバレッジ向上モードごと、に特定する、
方法。

（付記１４）
前記非短縮の第１の情報は、AS context cachingのために前記基地局又は他の基地局から前記無線端末に送られたResume IDであり、
前記短縮された第１の情報は、前記Resume IDから導かれるTruncated IDであり、
前記最初のRRCメッセージは、RRC Connection Resume Requestメッセージである、
付記１３に記載の方法。

（付記１５）
前記報知情報は、ランダムアクセス設定を含み、
前記ランダムアクセス設定は、前記非短縮の第１の情報と前記短縮された第１の情報のうちのどちらが前記最初のアップリンクRadio Resource Control（RRC）メッセージに含まれるべきかをカバレッジ向上レベルごとに特定するために使用される、カバレッジ向上レベルごとのプリアンブル・グルーピング設定を含み、
前記プリアンブル・グルーピング設定は、各カバレッジ向上レベルに割り当てられた複数のランダムアクセス・プリアンブルが２又はそれ以上のサブセットに更に区分されているか否かを示す、
付記１０又は１１に記載の基地局。

（付記１６）
付記１３～１５のいずれか１項に記載の方法をコンピュータに行わせるためのプログラム。

この出願は、２０１６年５月１２日に出願された日本出願特願２０１６－０９６５１６を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ 無線端末（UE）
２ 基地局（eNB）
８０１ radio frequency（RF）トランシーバ
８０３ ベースバンドプロセッサ
８０４ アプリケーションプロセッサ
８０６ メモリ
９０１ RFトランシーバ
９０４ プロセッサ
９０５ メモリ

Claims (4)

1. 無線端末であって、
   メモリと、
   前記メモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   前記無線端末と基地局との間のパスロス・レベルに基づくカバレッジ向上レベルを判定するよう構成され、且つ
   前記判定されたカバレッジ向上レベルに基づいて、ランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージのサイズを変更するよう構成され、
   前記カバレッジ向上レベルが第１のレベルであるなら、前記最初のアップリンクRRCメッセージのサイズを第１のサイズとし、前記カバレッジ向上レベルが前記第１のレベルよりも前記パスロス・レベルが大きい場合に対応する第２のレベルであるなら、前記最初のアップリンクRRCメッセージのサイズを前記第１のサイズよりも小さい第２のサイズとするよう構成される、
   無線端末。
2. 前記少なくとも１つのプロセッサは、前記アップリンクRRCメッセージのサイズの変更を、当該RRCメッセージに包含する情報要素（Information Element（IE））の種類または数を変更することで実行する、
   請求項１に記載の無線端末。
3. 無線端末における方法であって、
   前記無線端末と基地局との間のパスロス・レベルに基づくカバレッジ向上レベルを判定すること、及び
   前記判定されたカバレッジ向上レベルに基づいて、ランダムアクセス手順内で送信される最初のアップリンクRadio Resource Control（RRC）メッセージのサイズを変更すること、
   を備え、
   前記変更することは、前記カバレッジ向上レベルが第１のレベルであるなら、前記最初のアップリンクRRCメッセージのサイズを第１のサイズとし、前記カバレッジ向上レベルが前記第１のレベルよりも前記パスロス・レベルが大きい場合に対応する第２のレベルであるなら、前記最初のアップリンクRRCメッセージのサイズを前記第１のサイズよりも小さい第２のサイズとすることを含む、
   方法。
4. 前記変更することは、前記アップリンクRRCメッセージに包含する情報要素（Information Element（IE））の種類または数を変更することを含む、
   請求項３に記載の方法。

Images