特開 2023-36923 基地局及び無線端末

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023036923

(43)【公開日】2023-03-14

(54)【発明の名称】基地局及び無線端末

(51)【国際特許分類】

   H04W 76/27 20180101AFI20230307BHJP

【ＦＩ】

H04W76/27

【審査請求】有

【請求項の数】3

【出願形態】ＯＬ

(21)【出願番号】P 2023000142

(22)【出願日】2023-01-04

(62)【分割の表示】P 2021109820の分割

【原出願日】2017-09-21

(31)【優先権主張番号】62/397,453

(32)【優先日】2016-09-21

(33)【優先権主張国・地域又は機関】US

(71)【出願人】

【識別番号】000006633

【氏名又は名称】京セラ株式会社

(74)【代理人】

【識別番号】110001106

【氏名又は名称】弁理士法人キュリーズ

(72)【発明者】

【氏名】藤代 真人

(72)【発明者】

【氏名】守田 空悟

(72)【発明者】

【氏名】チャン ヘンリー

(57)【要約】      （修正有）

【課題】移動通信システムにおいて用いられるシグナリングを削減する方法、基地局及び無線端末を提供する。
【解決手段】移動通信システムのＲＡＮに含まれる基地局は、特定状態にある無線端末から、ＲＡＮページングエリアを出たことを示すメッセージを受信する受信部と、前記メッセージの受信に応じて、ＲＡＮページングエリアの更新に関するページングエリア情報をモビリティ管理エンティティに送信する送信部と、を備える。前記特定状態は、ＲＡＮページングエリア内のアンカー基地局が無線端末用のＳ１接続を維持する状態であって、ＲＡＮページングエリアが無線端末に設定された状態である。
【選択図】図８

【特許請求の範囲】

【請求項1】

ユーザ装置であって、
前記ユーザ装置の好ましいＲＲＣ状態に関して基地局に知らせるための補助情報を提供するよう前記ユーザ装置に設定する設定情報を前記基地局から受信し、
前記ユーザ装置の好ましいＲＲＣ状態を示す補助情報を前記基地局に送信する、制御部を備え、
前記制御部は、さらに、前記補助情報を送信した後に前記ユーザ装置が前記補助情報を送信可能になるまでの時間を規定するタイマを開始するユーザ装置。

【請求項2】

ユーザ装置を制御するプロセッサであって、
前記ユーザ装置の好ましいＲＲＣ状態に関して基地局に知らせるための補助情報を提供するよう前記ユーザ装置に設定する設定情報を前記基地局から受信する処理と、
前記ユーザ装置の好ましいＲＲＣ状態を示す補助情報を前記基地局に送信する処理と、
前記補助情報を送信した後に前記ユーザ装置が前記補助情報を送信可能になるまでの時間を規定するタイマを開始する処理と、を実行するプロセッサ。

【請求項3】

ユーザ装置が実行する方法であって、
前記ユーザ装置の好ましいＲＲＣ状態に関して基地局に知らせるための補助情報を提供するよう前記ユーザ装置に設定する設定情報を前記基地局から受信するステップと、
前記ユーザ装置の好ましいＲＲＣ状態を示す補助情報を前記基地局に送信するステップと、
前記補助情報を送信した後に前記ユーザ装置が前記補助情報を送信可能になるまでの時間を規定するタイマを開始するステップと、を備える方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動通信システムにおいて用いられる基地局及び無線端末に関する。

【背景技術】

【0002】

近年、多数のアプリケーションを実行可能なスマートフォン等の無線端末の普及により、無線端末がネットワークに接続する頻度及びネットワークが無線端末のページングを行う頻度が増加している。

【0003】

このため、移動通信システムにおいて、シグナリングに伴うネットワークの負荷が高まっている。このような状況に鑑み、移動通信システムの標準化プロジェクトである３ＧＰＰ（登録商標。以下同じ）（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、シグナリングを削減するための技術の検討が進められている。

【発明の概要】

【0004】

無線端末は、ＲＲＣコネクティッドモードの一状態であるライトコネクティッド状態に遷移するよう指示するライトコネクティッド指示子を含むＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージをネットワークから受信する受信部と、前記ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージの受信後、前記ライトコネクティッド状態においてセル再選択動作を行う制御部と、を備える。前記制御部は、前記セル再選択動作において前記ライトコネクティッド状態をサポートしていないセルが再選択された場合に、前記ＲＲＣコネクティッドモードからＲＲＣアイドルモードに遷移する動作を行う。

【0005】

前記ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージは、ＲＡＮページングエリアを示す情報を含んでもよい。前記無線端末は、前記ユーザ端末が前記ＲＡＮページングエリアを出た場合に、ＲＡＮページングエリア更新情報を含むＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージを前記ネットワークに送信する送信部をさらに備えてもよい。

【図面の簡単な説明】

【0006】

【図1】実施形態に係るＬＴＥシステムの構成を示す図である。

【図2】実施形態に係るＵＥ（無線端末）の構成を示す図である。

【図3】実施形態に係るｅＮＢ（基地局）の構成を示す図である。

【図4】実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。

【図5】実施形態に係るＬＴＥシステムにおいて用いられる無線フレームの構成を示す図である。

【図6】実施形態に係るＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態（特定状態）への遷移に係る動作の概要を示す図である。

【図7】実施形態の動作パターン１を示す図である。

【図8】実施形態の動作パターン２を示す図である。

【図9】実施形態に係るＲＡＮページングエリアを決定するための動作を示す図である。

【図10】第１実施形態に係る動作例を示す図である。

【図11】第２実施形態に係る動作例を示す図である。

【図12】第３実施形態に係る動作を示す図である。

【図13】第４実施形態の動作パターン１を示す図である。

【図14】第４実施形態の動作パターン２を示す図である。

【図15】第５実施形態に係る動作例を示す図である。

【発明を実施するための形態】

【0007】

［移動通信システム］
（移動通信システムの構成）
以下において、実施形態に係る移動通信システムの構成について説明する。図１は、実施形態に係る移動通信システムであるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムの構成を示す図である。ＬＴＥシステムは、３ＧＰＰ規格に基づく移動通信システムである。

【0008】

図１に示すように、ＬＴＥシステムは、無線端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ－ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びコアネットワーク（ＥＰＣ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。

【0009】

ＵＥ１００は、移動型の通信装置であり、自身が在圏するセル（サービングセル）を管理するｅＮＢ２００との無線通信を行う。

【0010】

Ｅ－ＵＴＲＡＮ１０は、基地局（ｅＮＢ：ｅｖｏｌｖｅｄ Ｎｏｄｅ－Ｂ）２００を含む。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる他に、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。

【0011】

ＥＰＣ２０は、モビリティ管理エンティティ（ＭＭＥ）３００Ｃ及びサービングゲートウェイ（Ｓ－ＧＷ）３００Ｕを含む（図６等参照）。ＭＭＥ３００Ｃは、ＵＥ１００に対する各種モビリティ制御等を行う。ＭＭＥ３００Ｃは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するトラッキングエリア（ＴＡ）の情報を管理する。トラッキングエリアは、複数のセルからなるエリアである。Ｓ－ＧＷ３００Ｕは、データの転送制御を行う。ＭＭＥ３００Ｃ及びＳ－ＧＷ３００Ｕは、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。

【0012】

図２は、ＵＥ１００（無線端末）の構成を示す図である。図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

【0013】

受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。

【0014】

送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

【0015】

制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、を含んでもよい。プロセッサは、後述する処理を実行する。

【0016】

図３は、ｅＮＢ２００（基地局）の構成を示す図である。図３に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。

【0017】

送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

【0018】

受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。

【0019】

制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵと、を含んでもよい。プロセッサは、後述する処理を実行する。

【0020】

バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢと接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ－ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。

【0021】

なお、ＭＭＥ３００Ｃは、制御部及びネットワーク通信部を有する。制御部は、ＭＭＥ３００Ｃにおける各種の制御を行う。制御部は、少なくとも１つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うＣＰＵと、を含んでもよい。プロセッサは、後述する処理を実行する。ネットワーク通信部は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。ネットワーク通信部は、Ｓ１インターフェイス上で行う通信等に用いられる。

【0022】

図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１レイヤ乃至第３レイヤに区分されており、第１レイヤは物理（ＰＨＹ）レイヤである。第２レイヤは、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤ、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤを含む。第３レイヤは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤを含む。ＰＨＹレイヤ、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤ、及びＲＲＣレイヤは、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤを構成する。

【0023】

ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｅＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。

【0024】

ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｅＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｅＮＢ２００のＭＡＣレイヤは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。

【0025】

ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｅＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。

【0026】

ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

【0027】

ＲＲＣレイヤは、制御情報を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとｅＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードであり、そうでない場合、ＵＥ１００はＲＲＣアイドルモードである。

【0028】

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＭＭＥ３００ＣのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等の機能を有する。

【0029】

図５は、ＬＴＥシステムにおいて用いられる無線フレームの構成を示す図である。図５に示すように、無線フレームは、時間軸上で１０個のサブフレームで構成される。各サブフレームは、時間軸上で２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数軸上で複数個のリソースブロック（ＲＢ）を含み、時間軸上で複数個のシンボルを含む。各リソースブロックは、周波数軸上で複数個のサブキャリアを含む。具体的には、１２個のサブキャリア及び１つのスロットにより１つのＲＢが構成される。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。

【0030】

下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ）として用いられる領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ）として用いることができる領域である。

【0031】

ｅＮＢ２００は、基本的には、ＰＤＣＣＨを用いて下りリンク制御情報（ＤＣＩ）をＵＥ１００に送信し、ＰＤＳＣＨを用いて下りリンクデータをＵＥ１００に送信する。ＰＤＣＣＨが搬送するＤＣＩは、上りリンクスケジューリング情報、下りリンクスケジューリング情報、ＴＰＣコマンドを含む。上りリンクスケジューリング情報は上りリンク無線リソースの割当てに関するスケジューリング情報（ＵＬ ｇｒａｎｔ）であり、下りリンクスケジューリング情報は、下りリンク無線リソースの割当てに関するスケジューリング情報である。ＴＰＣコマンドは、上りリンクの送信電力の増減を指示する情報である。ｅＮＢ２００は、ＤＣＩの送信先のＵＥ１００を識別するために、送信先のＵＥ１００の識別子（ＲＮＴＩ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ ＩＤ）でスクランブリングしたＣＲＣビットをＤＣＩに含める。各ＵＥ１００は、自ＵＥ宛ての可能性があるＤＣＩについて、自ＵＥのＲＮＴＩでデスクランブリング後、ＣＲＣチェックをすることにより、ＰＤＣＣＨをブラインド復号（Ｂｌｉｎｄ ｄｅｃｏｄｉｎｇ）し、自ＵＥ宛のＤＣＩを検出する。ＰＤＳＣＨは、下りリンクスケジューリング情報が示す下りリンク無線リソース（リソースブロック）により下りリンクデータを搬送する。

【0032】

上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ）として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ）として用いることができる領域である。

【0033】

ＵＥ１００は、基本的には、ＰＵＣＣＨを用いて上りリンク制御情報（ＵＣＩ）をｅＮＢ２００に送信し、ＰＵＳＣＨを用いて上りリンクデータをｅＮＢ２００に送信する。ＰＵＣＣＨが運搬するＵＣＩは、ＣＱＩ（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ Ｍａｔｒｉｘ Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ Ｉｎｄｉｃａｔｏｒ）、スケジューリング要求（ＳＲ）、ＨＡＲＱ ＡＣＫ／ＮＡＣＫを含む。ＣＱＩは、下りリンクのチャネル品質を示すインデックスであり、下りリンク伝送に用いるべきＭＣＳの決定等に用いられる。ＰＭＩは、下りリンクの伝送のために用いることが望ましいプレコーダマトリックスを示すインデックスである。ＲＩは、下りリンクの伝送に用いることが可能なレイヤ数（ストリーム数）を示すインデックスである。ＳＲは、ＰＵＳＣＨリソースの割り当てを要求する情報である。ＨＡＲＱ ＡＣＫ／ＮＡＣＫは、下りリンクデータを正しく受信したか否かを示す送達確認情報である。

【0034】

（特定状態）
以下において、実施形態に係る特定状態について説明する。特定状態は、ＵＥ１００用のＳ１接続が維持されつつＵＥ１００用のシグナリングが抑制される状態である。Ｓ１接続は、Ｓ１ベアラと称されてもよい。Ｓ１接続は、Ｓ１インターフェイス上でｅＮＢ２００とＥＰＣ２０との間に確立される接続である。Ｓ１インターフェイスは、ユーザプレーン用のＳ１－Ｕインターフェイスと制御プレーン用のＳ１－ＭＭＥインターフェイスとを含む。Ｓ１接続は、Ｓ１－Ｕインターフェイス上でｅＮＢ２００とＳ－ＧＷ３００Ｕとの間に確立されるＳ１－Ｕ接続と、Ｓ１－Ｃインターフェイス上でｅＮＢ２００とＭＭＥ３００Ｃとの間に確立されるＳ１－ＭＭＥ接続と、を含んでもよい。

【0035】

特定状態は、ＲＲＣコネクティッドモードの一状態又はＲＲＣアイドルモードの一状態であってもよい。或いは、特定状態は、ＲＲＣアイドルモード及びＲＲＣアイドルモードとは異なるＲＲＣ状態であってもよい。実施形態の動作パターン１において、特定状態は、ＲＲＣコネクティッドモードの一状態（ｓｕｂｓｔａｔｅ）である。これに対し、実施形態の動作パターン２において、特定状態は、ＲＲＣコネクティッドモードの一状態（ｓｕｂｓｔａｔｅ）である。特定状態によれば、一般的なＲＲＣコネクティッドモードに比べてシグナリングが削減される。また、特定状態によれば、一般的なＲＲＣアイドルモードに比べてＵＥ１００が迅速にデータ通信を開始することができる。以下において、特定状態を「Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態（Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ ｓｕｂｓｔａｔｅ）」と称する。

【0036】

図６は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態（特定状態）への遷移に係る動作の概要を示す図である。図６の初期状態において、ＵＥ１００はＲＲＣコネクティッドモードであり、ＵＥ１００とｅＮＢ２００との間にＲＲＣ接続（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ）が確立されている。また、ｅＮＢ２００とＭＭＥ３００Ｃとの間にＳ１－ＭＭＥ接続（Ｓ１－ＭＭＥ Ｃｏｎｎｅｃｔｉｏｎ）が確立されている。ｅＮＢ２００とＳ－ＧＷ３００Ｕとの間にＳ１－Ｕ接続（Ｓ１－Ｕ Ｃｏｎｎｅｃｔｉｏｎ）が確立されている。ＵＥ１００は、ｅＮＢ２００とのデータ通信を行う。

【0037】

図６に示すように、ステップＳ１において、ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する遷移指示（Ｒｅｑｕｅｓｔ ｔｏ Ｌｉｇｈｔ Ｃｏｎｎ．）をＵＥ１００に送信する。

【0038】

ステップＳ２において、ＵＥ１００は、遷移指示の受信に応じて、肯定応答（Ａｃｋ）メッセージをｅＮＢ２００に送信する。但し、ステップＳ２は必須ではなく、省略してもよい。

【0039】

ステップＳ３において、ＵＥ１００及びｅＮＢ２００は、ＲＲＣ接続を維持又は解放する。具体的には、実施形態の動作パターン１において、ＵＥ１００及びｅＮＢ２００は、ＲＲＣ接続を維持する。これに対し、実施形態の動作パターン２において、ＵＥ１００及びｅＮＢ２００は、ＲＲＣ接続を解放する。

【0040】

ステップＳ４において、ｅＮＢ２００及びＭＭＥ３００Ｃは、Ｓ１－ＭＭＥ接続を維持する。ステップＳ５において、ｅＮＢ２００及びＳ－ＧＷ３００Ｕは、Ｓ１－Ｕ接続を維持する。ステップＳ６において、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移し、ｅＮＢ２００とのデータ通信を中断する。

【0041】

ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移したＵＥ１００のコンテキスト情報（ＵＥコンテキスト）を破棄せずに維持する。ＵＥコンテキストは、ＵＥ１００に対する各種の設定及び能力等に関する情報を含む。各種の設定は、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）の設定を含む。

【0042】

Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、維持されているＳ１接続及びＵＥコンテキストを活用して、少ないシグナリングでｅＮＢ２００とのデータ通信を再開することができる。

【0043】

第１のｅＮＢ２００のセルにおいてＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移したＵＥ１００は、第１のｅＮＢ２００のセルから第２のｅＮＢ２００のセルに移動してもよい。第２のｅＮＢ２００のセルにおいてＵＥ１００がデータ通信を再開する場合、第２のｅＮＢ２００は、ＵＥ１００のＵＥコンテキストを第１のｅＮＢ２００からＸ２インターフェイス上で取得し、取得したＵＥコンテキストをＵＥ１００とのデータ通信に利用してもよい。

【0044】

実施形態において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００には、ＲＡＮページングが適用される。ＲＡＮページングは、Ｅ－ＵＴＲＡＮ１０（ｅＮＢ２００）によりページングが制御される所定ページングエリア単位でページングを行う。所定ページングエリアは、トラッキングエリアよりも狭いエリアである。所定ページングエリアを導入することにより、１のＵＥ１００に対してページングを行うセルの数を削減することができるため、シグナリングを削減することができる。以下において、このような所定ページングエリアを「ＲＡＮページングエリア」と称する。

【0045】

一例として、ＲＡＮページングエリア（所定ページングエリア）は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００のＳ１接続を維持する特定のｅＮＢ２００のセルと当該特定のｅＮＢ２００の周辺のｅＮＢ２００のセルとにより構成される。周辺のｅＮＢ２００は、特定のｅＮＢ２００とのＸ２インターフェイスを有するｅＮＢ２００であってもよい。特定のｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００宛てのデータ又はＮＡＳシグナリングをＭＭＥ／Ｓ－ＧＷ３００から受信すると、ＲＡＮページングを行うと判断し、周辺のｅＮＢ２００と共にＵＥ１００のページングを行う。当該ページングは、ＲＲＣページングメッセージを送信することにより行われてもよいし、ＵＥ１００宛てのデータをページングメッセージとして送信することにより行われてもよい。当該特定のｅＮＢ２００は、アンカーｅＮＢと称されてもよい。

【0046】

（動作パターン１）
以下において、実施形態の動作パターン１について説明する。

【0047】

動作パターン１において、ＲＲＣコネクティッドモードにあるＵＥ１００は、ＲＲＣ接続の設定変更を指示するメッセージをｅＮＢ２００から受信し、当該メッセージの受信に応じて設定変更を行う。一例として、当該メッセージは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージである。他の例として、当該メッセージは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージとは異なるメッセージである。動作パターン１において、当該メッセージがＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージであるケースを想定する。ｅＮＢ２００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００に送信することによりＵＥ１００のＲＲＣ設定を変更させる。

【0048】

ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報をＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含めることにより、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移させる。ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報がＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれることに応じて、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する。動作パターン１において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ＲＲＣ接続を維持しつつ、ＵＥ１００の複数の機能のうちｅＮＢ２００とのシグナリングを発生させる少なくとも１つの機能が非活性化された状態である。

【0049】

ここで、複数の機能（ｆｅａｔｕｒｅｓ）は、データ（ユーザデータ）の送受信機能、スケジューリング要求（ＳＲ）の送信機能、チャネル状態情報（ＣＳＩ）の送信（すなわち、ＣＳＩフィードバック）機能、サウンディング参照信号（ＳＲＳ）の送信機能、キャリアアグリゲーション機能、デュアルコネクティビティ機能、セミパーシステントスケジューリング（ＳＰＳ）機能、ＷＬＡＮアグリゲーション機能、無線リンク監視（ＲＬＭ）機能、通知（Ｉｎ－ｄｅｖｉｃｅ Ｃｏｅｘｉｓｔｅｎｃｅ Ｉｎｄｉｃａｔｉｏｎ ＵＥ Ａｓｓｉｓｔａｎｃｅ ｉｎｆｏｒｍａｔｉｏｎ、ＭＢＭＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｉｔｏｎ、Ｓｉｄｅｌｉｎｋ ＵＥ Ｉｎｆｏｒｍａｉｔｏｎ等）機能、アイドルモード間欠受信（ＤＲＸ）機能、ブロードキャストシグナリングを用いるＷＬＡＮインターワーキング機能を含んでもよい。但し、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態において、セル再選択機能、コネクティッドモードＤＲＸ機能、専用シグナリングを用いるＷＬＡＮインターワーキング機能のうち少なくとも１つは、非活性化されずに活性化状態を維持してもよい。これらの機能の詳細については、例えば３ＧＰＰ技術仕様書「ＴＳ３６．３００ Ｖ１３．４．０」を参照されたい。

【0050】

図７は、実施形態の動作パターン１を示す図である。図７の初期状態において、ＵＥ１００は、ＲＲＣコネクティッドモードにあり、ｅＮＢ２００とのデータ通信を行っている。なお、図７において破線で示す処理は必須ではなく省略可能な処理である。

【0051】

図７に示すように、ステップＳ１０１において、ＵＥ１００は、ｅＮＢ２００とのデータ通信の中断を検知する。

【0052】

データ通信の中断とは、下りリンク（ＤＬ）データを受信していない（又は受信する見込みがない）場合、及び／又は上りリンク（ＵＬ）データを送信していない（又はする見込みがない）場合であってもよい。ここで、見込みとは、ある一定期間においてデータが発生しないと予測される状態であってもよい。当該一定期間は、ｅＮＢ２００から設定されてもよい。ｅＮＢ２００からＵＥ１００に対する設定は、ＲＲＣシグナリングにより行われる。ＲＲＣシグナリングは、ＵＥ個別シグナリング（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）であってもよいし、ブロードキャストシグナリング（例えば、システム情報ブロック（ＳＩＢ））であってもよい。

【0053】

一例として、ＵＥ１００のＲＲＣレイヤは、ＲＲＣレイヤよりも上位のレイヤ（例えば、アプリケーションレイヤ）の情報に基づいて、ｅＮＢ２００とのデータ通信の中断を検知する。一例として、ＵＥ１００のＲＲＣレイヤは、現在最も通信の頻度が高いアプリケーションがシャットダウンしたことに応じて、データ通信の中断を検知してもよい。他の例として、ＵＥ１００のＲＲＣレイヤは、オペレーションシステム（ＯＳ）が通信規制を行ったこと、フォアグラウンドで動作するアプリケーションが無くなったこと（すなわち、バックグラウンド処理のみになったこと）、ＯＳがデータ通信中断状態と判断したことに応じて、データ通信の中断を検知してもよい。

【0054】

ステップＳ１０２において、ＵＥ１００は、データ通信の中断を示す通知をｅＮＢ２００に送信する。ＵＥ１００は、ＲＲＣレイヤのシグナリングにより当該通知を送信してもよい。ＲＲＣレイヤのシグナリングは、ＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージであってもよいし、他のメッセージであってもよい。データ通信の中断を示す通知がＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージ中で送信される場合、当該通知は、Ｅｘｔｅｎｄｅｄ Ｐｏｗｅｒ Ｐｒｅｆｅｒｅｎｃｅ Ｉｎｄｉｃａｔｏｒ（Ｅｘｔｅｎｄｅｄ ＰＰＩ）と称されてもよい。

【0055】

ステップＳ１０３において、ｅＮＢ２００は、データ通信の中断を示す通知の受信に応じて、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移させることを決定する。

【0056】

ステップＳ１０４において、ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報を含むＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（又は他のメッセージ）をＵＥ１００に送信する。言い換えると、ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移指示を、ＲＲＣ接続の設定変更として送信する。

【0057】

Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報は、例えば「Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ＝Ｓｅｔｕｐ」である。また、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、上述した複数の機能のうち非活性化させる機能を指定する情報を含んでもよい。一例として、ｅＮＢ２００は、非活性化する機能を個別に指定するために、活性維持機能のリスト又は非活性化機能のリストをＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含める。

【0058】

ステップＳ１０５において、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報を含むＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの受信に応じて、上述した複数の機能（ｆｅａｔｕｒｅｓ）のうち所定の機能を非活性化（ｄｅａｃｔｉｖａｔｅ）する。ＵＥ１００は、非活性化させる機能がＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにより指定された場合、指定された機能のみを非活性化させる。

【0059】

ステップＳ１０６において、ＵＥ１００は、所定の機能を非活性化させても、当該所定の機能の設定情報（ＡＳ Ｃｏｎｔｅｘｔ）を保持する。言い換えると、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する場合でも、非活性化させる機能の設定情報を破棄せずに維持する。

【0060】

ステップＳ１０７において、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する。動作パターン１において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ＲＲＣコネクティッドモードの一状態（ｓｕｂｓｔａｔｅ）である。Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、ＲＡＮページングエリア内で送信されるページングメッセージを受信するための処理を行う。

【0061】

その後、ステップＳ１０８において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、ＵＥ１００における所定のイベントを検知する。所定のイベントは、ｅＮＢ２００からページングメッセージを受信したこと、ｅＮＢ２００に送信するＵＬデータが発生したこと、の何れかである。所定のイベントは、ＵＬデータが発生し、かつ、当該ＵＬデータの量が閾値以上であることであってもよい。当該閾値はｅＮＢ２００からＵＥ１００に設定されていてもよい。

【0062】

ステップＳ１０９において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、所定のイベントを検知したことに応じて、非活性化された機能の活性化を要求する活性化要求（ＲＲＣ Ａｃｔｉｖａｔｉｏｎ Ｒｅｑｕｅｓｔ）をｅＮＢ２００に送信する。

【0063】

活性化要求は、非活性機能の全部の活性化を要求するものであってもよいし、非活性機能の一部の機能の活性化を要求するものであってもよい。非活性機能の全部の活性化を要求する場合、活性化要求は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態の中止要求（すなわち、通常のＲＲＣ Ｃｏｎｎｅｃｔｅｄモードへの遷移要求）であってもよい。これに対し、非活性機能の全部の活性化を要求する場合、活性化要求は、活性化する機能のリストを含んでもよいし、非活性状態を維持させる機能のリストを含んでもよい。

【0064】

ステップＳ１１０において、ｅＮＢ２００は、活性化要求の受信に応じて、当該要求の受け入れ可否を判断する。ここでは、ｅＮＢ２００が当該要求を受け入れ可と判断したと仮定して説明を進める。なお、ｅＮＢ２００が当該要求を受け入れ不可と判断した場合、ｅＮＢ２００は、否定応答（Ｎａｃｋ）又は拒否通知（Ｒｅｊｅｃｔ）をＵＥ１００に送信してもよい。

【0065】

ステップＳ１１１において、ｅＮＢ２００は、活性化要求に対する肯定応答（ＲＲＣ Ａｃｔｉｖａｔｉｏｎ Ａｃｋｎｏｗｌｅｄｇｅ）をＵＥ１００に送信する。なお、ｅＮＢ２００は、活性化要求を受け入れるか否かを機能ごとに判断してもよい。この場合、ｅＮＢ２００は、活性化を許可する機能のリスト及び／又は活性化を拒否する機能のリストを肯定応答（ＲＲＣ Ａｃｔｉｖａｔｉｏｎ Ａｃｋｎｏｗｌｅｄｇｅ）に含めてもよい。或いは、当該肯定応答に代えて、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いてもよい。

【0066】

ステップＳ１１２において、ＵＥ１００は、ｅＮＢ２００から受信した応答の内容に基づいて、非活性化された機能を活性化させるか否かを判断する。ＵＥ１００は、肯定応答を受信した場合に、許可された機能を活性化する。ＵＥ１００は、肯定応答を受信した時点（サブフレーム）から当該機能を活性化する。或いは、ＵＥ１００は、肯定応答を受信した後、ある一定期間内（例えば８サブフレーム以内）に当該機能を活性化してもよい。

【0067】

（動作パターン２）
以下において、実施形態の動作パターン２について、動作パターン１との相違点を主として説明する。

【0068】

動作パターン２において、ＲＲＣコネクティッドモードにあるＵＥ１００は、ＲＲＣ接続の解放を指示するＲＲＣ接続解放（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）メッセージをｅＮＢ２００から受信し、ＲＲＣ接続解放メッセージの受信に応じてＲＲＣ接続を解放する。ＲＲＣ接続解放メッセージは、ＲＲＣ接続を解放する理由を示すフィールド（Ｒｅｌｅａｓｅ Ｃａｕｓｅ）を含む。ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報（例えばＲＲＣ－ＬｉｇｈｔＣｏｎｎｅｃｔｅｄ）がフィールドに含まれることに応じて、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する。ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報を当該フィールドに含めることにより、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移させる。もしくは、当該Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ネットワーク（つまり、ｅＮＢとＭＭＥ／Ｓ－ＧＷ）における一状態であってもよい。この場合、ＵＥ１００のＲＲＣ状態はアイドルとなる。但し、ｅＮＢ２００は、コンテキスト（設定情報）をＵＥに保持させてもよい。この場合、ｅＮＢ２００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅのＲｅｌｅａｓｅ Ｃａｕｓｅをｒｒｃ－Ｓｕｓｐｅｎｄに設定し、これに対応する識別子であるＲｅｓｕｍｅ ＩＤ（ｒｅｓｕｍｅＩｄｅｎｔｉｔｙ）をＵＥ１００に通知する。当該状態を、ＲＲＣ接続がサスペンドされた状態と称してもよい。

【0069】

動作パターン２において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ＲＲＣ接続が解放された状態であって、かつ、ＵＥ１００用のＳ１接続がｅＮＢ２００とコアネットワーク（ＥＰＣ２０）との間に維持される状態である。動作パターン２において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、さらに、上述した複数の機能のうち少なくとも一部が非活性化された状態であってもよい。

【0070】

図８は、実施形態の動作パターン２を示す図である。以下において、図７に示す動作パターン１との相違点を主として説明し、重複する説明を省略する。

【0071】

図８に示すように、ステップＳ２０１乃至Ｓ２０３は、動作パターン１と同様である。

【0072】

ステップＳ２０４において、ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報をＲｅｌｅａｓｅ Ｃａｕｓｅとして含むＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信する。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージは、上述した複数の機能のうち非活性化させる機能を指定する情報を含んでもよい。この場合、非活性化させる機能の取り扱いについては動作パターン１と同様である。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージは、復旧用識別子（Ｒｅｓｕｍｅ ＩＤ）を含んでもよい。ｅＮＢ２００は、ＵＥコンテキストを復旧用識別子と関連付けて保持する。

【0073】

ステップＳ２０５において、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する情報をＲｅｌｅａｓｅ Ｃａｕｓｅとして含むＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージの受信に応じて、ｅＮＢ２００とのＲＲＣ接続を解放する。

【0074】

ステップＳ２０６において、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する。動作パターン２において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ＲＲＣアイドルモードの一状態（ｓｕｂｓｔａｔｅ）である。Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、ＲＡＮページングエリア内で送信されるページングメッセージを受信するための処理を行う。

【0075】

その後、ステップＳ２０７において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、ＵＥ１００における所定のイベントを検知する。

【0076】

ステップＳ２０８において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、所定のイベントを検知したことに応じて、ＲＲＣ接続の復旧を要求するＲＲＣ接続復旧要求（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ）をｅＮＢ２００に送信する。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔは、非活性機能の活性化を要求する情報を含んでもよい。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔは、復旧用識別子を含んでもよい。

【0077】

ステップＳ２０９において、ｅＮＢ２００は、ＲＲＣ接続復旧要求の受信に応じて、当該要求の受け入れ可否を判断する。ここでは、ｅＮＢ２００が当該要求を受け入れ可と判断したと仮定して説明を進める。

【0078】

ステップＳ２１０において、ｅＮＢ２００は、ＲＲＣ接続復旧（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ）メッセージをＵＥ１００に送信する。ｅＮＢ２００は、活性化を許可する機能のリスト及び／又は活性化を拒否する機能のリストをＲＲＣ接続復旧メッセージに含めてもよい。

【0079】

ステップＳ２１１において、ＵＥ１００は、ｅＮＢ２００から受信したＲＲＣ接続復旧メッセージに基づいて、ＲＲＣ接続を復旧させる。なお、ｅＮＢ２００は、復旧用識別子に基づいてＵＥコンテキストの使用を再開する。

【0080】

（移動状態情報）
動作パターン１及び２において、データ通信の中断を示す通知は、ＵＥ１００の移動速度に関する移動状態情報を含んでもよい。ｅＮＢ２００は、ＵＥ１００の移動速度に関する移動状態情報をＵＥ１００から受信し、移動状態情報に基づいて、ＵＥ１００に対応するＲＡＮページングエリアの範囲を決定する。

【0081】

或いは、ＵＥ１００は、以下の何れかのタイミングで移動状態情報をｅＮＢ２００に送信してもよい。

【0082】

第１に、ＵＥ１００は、トラッキングエリア又はＲＡＮページングエリアの更新をトリガとして移動状態情報を送信する。この場合、ＵＥ１００は、トラッキングエリア更新メッセージ又はＲＡＮページングエリア更新メッセージに移動状態情報を含めてもよい。

【0083】

第２に、ＵＥ１００は、セルリセレクションをトリガとして移動状態情報を送信する。この場合、ＵＥ１００は、セル更新メッセージに移動状態情報を含めてもよい。

【0084】

第３に、ＵＥ１００は、ｅＮＢ２００からの問い合わせをトリガとして移動状態情報を送信する。

【0085】

第４に、ＵＥ１００は、移動状態情報を周期的に送信する。当該周期は、ｅＮＢ２００からＵＥ１００に設定されてもよい。

【0086】

図９は、ＲＡＮページングエリアを決定するための動作を示す図である。

【0087】

図９に示すように、ステップＳ３０１において、ＵＥ１００は、移動状態情報（Ｍｏｂｉｌｉｔｙ Ｓｔａｔｕｓ Ｉｎｆｏｒｍａｔｉｏｎ）を生成する。移動状態情報は、以下の情報の少なくとも１つを含む。

【0088】

１）ある一定時間内のハンドオーバ回数又はセルリセレクション回数。一定時間は、ｅＮＢ２００からＵＥ１００に設定されてもよい。

【0089】

２）ある一定時間内の平均移動速度。移動速度は、ＵＥ１００の位置情報から得ることができる。直接的な移動速度の値（例えば、ｘｘｘ ｋｍ／ｈ）に限らず、移動速度のインデックス（例えばＨｉｇｈ／Ｍｉｄ／Ｌｏｗ）であってもよい。一定時間は、ｅＮＢ２００からＵＥ１００に設定されてもよい。

【0090】

３）移動速度が閾値を超えたか否かを示す１ビット識別子。ここで、移動速度としては、上記の１）又は２）を利用できる。閾値は、ｅＮＢ２００からＵＥ１００に設定されてもよい。

【0091】

４）ＵＥ１００のセル履歴情報。セル履歴情報は、セルのＩＤと当該セルでの滞在時間との組み合わせを複数含む。

【0092】

ステップＳ３０２において、ＵＥ１００は、移動状態情報を含むメッセージをｅＮＢ２００に送信する。ＵＥ１００は、さらに自身の位置情報をメッセージに含めてもよい。ＵＥ１００は、さらに自身のカテゴリ（ＵＥカテゴリ）をメッセージに含めてもよい。

【0093】

ステップＳ３０３において、ｅＮＢ２００は、移動状態情報に基づいて、ＲＡＮページングエリアの範囲を決定する。ｅＮＢ２００は、決定したＲＡＮページングエリアに属するセル（及びｅＮＢ）のリストをＭＭＥ３００Ｃに通知してもよい。

【0094】

一例として、ｅＮＢ２００は、移動速度が速いＵＥ１００に対しては、ページングの取り逃しを防止する為に、広めのＲＡＮページングエリアを設定する。これに対し、移動速度が遅いＵＥ１００に対しては、ページングメッセージによるシグナリング数を削減する為に、狭めのＲＡＮページングエリアを設定する。

【0095】

他の例として、ｅＮＢ２００は、カテゴリＭ１のＵＥ１００に対しては、省電力化の為に、広めのＲＡＮページングエリアを設定する。カテゴリＭ１とは、マシンタイプ通信向けのＵＥカテゴリであり、省電力動作が必要とされるものである。これにより、ＲＡＮページングエリアを出る際に必要なＲＡＮページングエリア更新メッセージを削減することができる。

【0096】

［第１実施形態］
以下において、上述したＬＴＥシステムを前提として、第１実施形態について説明する。第１実施形態は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態におけるモビリティに関する実施形態である。

【0097】

ここで、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態におけるモビリティの基本的な動作について説明する。

【0098】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００のＳ１接続は、「アンカーｅＮＢ」に維持され、アクティブである。アンカーｅＮＢは、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移させたｅＮＢ２００であってもよい。ＵＥ１００が他のＲＡＮページングエリアに移動する場合、アンカーｅＮＢが切り替えられてもよい。

【0099】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００に対しては、ＲＡＮ（Ｅ－ＵＴＲＡＮ１０）始動でページング（ＲＡＮページング）を行うことができる。ＲＡＮページングは、アンカーｅＮＢにより始動されてもよい。

【0100】

・ページング処理（ＲＡＮページング）は、アンカーｅＮＢにより制御される。

【0101】

・ＲＡＮページングエリアは、ＵＥ固有に設定することができる。

【0102】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、ＲＲＣアイドルモードと同様なセル再選択メカニズムを実行する。

【0103】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００のコンテキスト情報（ＵＥ ＡＳコンテキスト）は、当該ＵＥ及びアンカーｅＮＢの両方で保持される。

【0104】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ネットワークの観点からは、ＥＣＭ（ＥＰＳ Ｃｏｎｎｅｃｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ）コネクティッド状態である。ＥＣＭは、ＵＥ１００とコアネットワーク（ＭＭＥ３００Ｃ）との間の接続状態を示す。

【0105】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００がページングを検知した場合又はデータ送信を開始する場合には、当該ＵＥ１００は、ｅＮＢ２００との接続を復旧する。もしくは、ＵＥ１００はＲＲＣコネクティッドモードへ遷移してもよい。

【0106】

・ＵＥ１００は、ＲＲＣシグナリングによりＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する。

【0107】

・ＵＥ固有のＲＡＮページングエリアは、専用シグナリング又はブロードキャストシグナリングによりｅＮＢ２００からＵＥ１００に設定される。ＲＡＮページングエリアは、セルのリスト又はページングエリアＩＤにより指定される。

【0108】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、設定されたＲＡＮページングエリアの外に移動したときにネットワークに通知する。

【0109】

・ＲＡＮページングエリアは、１又は複数のセルにより構成される。当該複数のセルは、異なるｅＮＢにより管理されていてもよい。

【0110】

・Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、ＲＲＣアイドルモードのＤＲＸ動作と同様なパラメータを用いてＤＲＸ動作を行う。ページング機会を決定するためのパラメータは、ＵＥのＩＤ（例えば、ＩＭＳＩ、Ｓ－ＴＭＳＩ、Ｒｅｓｕｍｅ ＩＤ等）を含み得る。

【0111】

第１実施形態に係るｅＮＢ２００は、移動通信システムのＲＡＮに含まれるｅＮＢ２００である。ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００から、ＲＡＮページングエリアを出たことを示すメッセージを受信する受信部２２０と、当該メッセージの受信に応じて、ＲＡＮページングエリアの更新に関するページングエリア情報をＭＭＥ３００Ｃ（モビリティ管理エンティティ）に送信する送信部（バックホール通信部２４０）と、を備える。Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ＲＡＮページングエリア内のアンカーｅＮＢがＵＥ１００用のＳ１接続を維持する状態であって、ＲＡＮページングエリアがＵＥ１００に設定された状態である。

【0112】

第１実施形態に係るｅＮＢ２００において、送信部（バックホール通信部２４０）は、ページングエリア情報を含む切り替え要求メッセージをＭＭＥ３００Ｃに送信してもよい。切り替え要求メッセージは、Ｓ１接続を自ｅＮＢ２００に切り替えることを要求するためのメッセージである。

【0113】

また、ページングエリア情報は、ＵＥ１００のための新たなＲＡＮページングエリアを示す情報を含んでもよい。新たなＲＡＮページングエリアは、自ｅＮＢ２００のエリア（セル）を含む。

【0114】

図１０は、第１実施形態に係る動作例を示す図である。図１０の初期状態において、ＵＥ１００は、ＲＲＣコネクティッドモードにある（Ｓ１００１）。また、ＵＥ１００とコアネットワーク（ＭＭＥ３００Ｃ）との間の接続状態はＥＣＭ Ｃｏｎｎｅｃｔｅｄであり、ｅＮＢ２００とＭＭＥ３００Ｃとの間にＵＥ１００用のＳ１接続（Ｓ１－ＭＭＥ接続）が存在する。なお、図示を省略しているが、ｅＮＢ２００とＳ－ＧＷ３００Ｕとの間にＵＥ１００用のＳ１接続（Ｓ１－Ｕ接続）も存在する。

【0115】

図１０に示すように、ステップＳ１００３において、アンカーｅＮＢ２００－１は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する遷移指示（Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｉｏｎ Ｉｎｓｔｒｕｃｔｉｏｎ）をＵＥ１００に送信する。上述したように、遷移指示は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージ中で送信される。アンカーｅＮＢ２００－１は、ＵＥ１００に固有のＲＡＮページングエリアをＵＥ１００に設定してもよい。

【0116】

ステップＳ１００４において、ＵＥ１００は、アンカーｅＮＢ２００－１のセル（サービングセル）からの遷移指示の受信に応じて、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する。

【0117】

ステップＳ１００５において、ＵＥ１００は、例えばＲＡＮページングエリア外のｅＮＢ２００－２が送信するセル識別子又はページングエリアＩＤ等に基づいて、自身に設定されたＲＡＮページングエリアの外に出たことを検知する。なお、ｅＮＢ２００－２は、アンカーｅＮＢ２００－１との間にＸ２インターフェイスを有していなくてもよい。

【0118】

ステップＳ１００６において、ＵＥ１００は、自身に設定されたＲＡＮページングエリアの外に出たことを示すメッセージをｅＮＢ２００－２に送信する。当該メッセージは、ＲＡＮページングエリアの更新を示すメッセージ（Ｐａｇｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ）であってもよい。当該メッセージは、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧することを要求するメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｂｏｏｔ ｒｅｑｕｅｓｔ）であってもよい。当該メッセージは、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージであってもよい。

【0119】

当該メッセージは、Ｒｅｓｕｍｅ ＩＤ、Ｓｈｏｒｔ Ｒｅｓｕｍｅ ＭＡＣ－Ｉ、Ｒｅｓｕｍｅ Ｃａｕｓｅを含んでもよい。

【0120】

或いは、Ｒｅｓｕｍｅ ＩＤに代えて、セル識別子（セルＩＤ）及びＣ－ＲＮＴＩ（Ｃｅｌｌ－Ｒａｄｉｏ． Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）の組み合わせからなる識別子を用いてもよい。セルＩＤは、ＥＣＧＩ（Ｅ－ＵＴＲＡＮ Ｃｅｌｌ Ｇｌｏｂａｌ Ｉｄｅｎｔｉｆｉｅｒ）、ＥＣＩ（Ｅ－ＵＴＲＡＮ Ｃｅｌｌ Ｉｄｅｎｔｉｆｉｅｒ）、又はＰＣＩ（Ｐｈｙｓｉｃａｌ Ｃｅｌｌ Ｉｄｅｎｔｉｆｉｅｒ）であってもよい。セルＩＤ及び／又はＣ－ＲＮＴＩは、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄへ遷移するための指示（例えばＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ）で明示的に与えられなくてもよい。ＵＥ１００は、当該Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄへの遷移指示を受信した場合、当該セルのセルＩＤと現在割り当てられているＣ－ＲＮＴＩを保存してもよい。ＵＥ１００は、Ｒｅｓｕｍｅする時は、この値を読み出し、ｅＮＢ２００に通知する。

【0121】

ＥＣＧＩはＥＣＩとＰＬＭＮ ＩＤとの組み合わせからなる。すなわち、ＥＣＩは、ＰＬＭＮ ＩＤを有しない。よって、セル識別子としてＥＣＩを用いる場合、当該組み合わせからなる識別子は同一ＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）内でのみ有効であってもよい。

【0122】

セル識別子としてＰＣＩを用いる場合、ｅＮＢ２００は、ＵＥ１００から受信したＰＣＩと、自身が有する隣接セルリスト（Ｎｅｉｇｈｂｏｒ Ｒｅｌａｔｉｏｎ Ｔａｂｌｅ）とを用いて、前記特定のｅＮＢ（アンカーｅＮＢ）を発見してもよい。

【0123】

前記どの組み合わせからなる識別子をＵＥ１００が通知すべきかは、ｅＮＢ２００から指定されてもよい。例えば、ｅＮＢ２００はＥＣＩとＣ－ＲＮＴＩとの組み合わせからなる識別子を通知するようにＳＩＢで報知する。もしくは、ｅＮＢ２００は、ＵＥ１００個別に設定してもよい。

【0124】

また、図では省略しているが、ＥＣＩ、ＰＣＩを用いた場合でも、ｅＮＢ２００は、前記特定のｅＮＢ（アンカーｅＮＢ）を特定できるため、ｅＮＢ２００は当該特定のｅＮＢからＵＥコンテキスト（設定情報）をＸ２若しくはＳ１インターフェイスを用いて取得することができる。

【0125】

図では省略しているが、当該組み合わせからなる識別子は、ページングにおいて、呼び出しＵＥを特定する為に用いてもよい。ＵＥ１００は、ページングメッセージを受信した場合に、当該識別子を読みだして、ページングメッセージ中の識別子と一致する場合には自身が呼び出されていると判定する。この場合、ＵＥ１００は、ＲＲＣ接続を確立する動作（例えばＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔの送信）を開始してもよい。

【0126】

また、Ｒｅｓｕｍｅ Ｃａｕｓｅに代えて、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄからの復旧に関するＢｏｏｔ Ｃａｕｓｅを用いてもよい。或いは、Ｒｅｓｕｍｅ Ｃａｕｓｅとして、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄからの復旧に関するＬｉｇｈｔＣｏｎｎｅｃｔｅｄ－Ａｃｃｅｓｓ等の新たな値が定義されてもよい。

【0127】

ステップＳ１００７において、ｅＮＢ２００－２は、ＵＥ１００からのメッセージの受信に応じて、Ｓ１接続をｅＮＢ２００－２に切り替えることを要求するためのメッセージ（Ｓ１ Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）をＳ１インターフェイス上でＭＭＥ３００Ｃに送信する。メッセージ（Ｓ１ Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）は、パス切替を行うＥ－ＲＡＢのＩＤ・アドレス、ソースＭＭＥ ＵＥ Ｓ１ＡＰ ＩＤ、セルＩＤ等を含む。ｅＮＢ２００－２は、ＵＥ１００のための新たなＲＡＮページングエリアを示すページング情報（ＰＡ ｉｎｆｏ．）をメッセージ（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）に含める。ページング情報（ＰＡ ｉｎｆｏ．）は、新たなＲＡＮページングエリアに含まれるセルのリスト（Ｒｅｃｏｍｍｅｎｄｅｄ Ｃｅｌｌ Ｌｉｓｔ）であってもよい。

【0128】

ステップＳ１００８において、ＭＭＥ３００Ｃは、ｅＮＢ２００－２から受信したメッセージ（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）に基づいて、ＵＥ１００の新たなＲＡＮページングエリアを把握又は決定する。すなわち、ＭＭＥ３００Ｃは、ページング情報（ＰＡ ｉｎｆｏ．）に基づいて、ＵＥ１００が在圏するＲＡＮページングエリアを管理することができる。また、ＭＭＥ３００Ｃは、ＵＥ１００のためのＳ１接続をアンカーｅＮＢ２００－１からｅＮＢ２００－２に切り替える処理を行う。

【0129】

なお、本シーケンスは、アンカーｅＮＢ２００－１とｅＮＢ２００－２との間にＸ２インターフェイスが存在しないことを想定している。しかしながら、アンカーｅＮＢ２００－１とｅＮＢ２００－２との間にＸ２インターフェイスが存在する場合、ｅＮＢ２００－２は、ＵＥ１００からのメッセージの受信に応じて、ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ又はＵＥ Ｃｏｎｔｅｘｔ ＲｅｔｒｉｅｖｅをＸ２インターフェイス上でアンカーｅＮＢ２００－１に送信してもよい。ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅは、ＵＥ１００のコンテキスト情報の解放を要求するためのメッセージである。ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔｒｉｅｖｅは、ＵＥ１００のコンテキスト情報を取得するためのメッセージである。ｅＮＢ２００－２は、これらのメッセージにページング情報（ＰＡ ｉｎｆｏ．）を含めてもよい。アンカーｅＮＢ２００－１は、ｅＮＢ２００－２から受信したページング情報（ＰＡ ｉｎｆｏ．）をＭＭＥ３００Ｃに転送してもよい。

【0130】

［第２実施形態］
以下において、第２実施形態について、第１実施形態との相違点を主として説明する。第２実施形態は、ｅＮＢ２００がＲＡＮページングを行う動作に関する実施形態である。

【0131】

第２実施形態に係るｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００に対してＲＡＮページングを行い、ＲＡＮページングが成功したか否かを判断する制御部２３０と、ＲＡＮページングの失敗に応じて、ＲＡＮページングの失敗を示す失敗通知をＭＭＥ３００Ｃに送信する送信部（バックホール通信部２４０）と、を備える。ＲＡＮページングは、ＲＡＮページングエリア単位でＲＡＮがＵＥ１００のページングを行う動作である。失敗通知は、ＵＥ１００が在圏するトラッキングエリアに基づくページングをＭＭＥ３００Ｃに実行させるためのメッセージであってもよい。よって、ＲＡＮページングが失敗した場合でも、ＭＭＥ３００Ｃが通常のページングを実行することができる。

【0132】

第２実施形態に係るｅＮＢ２００は、ＲＡＮページングエリア内の他のｅＮＢ２００がページングに成功したか否かに関する情報を当該他のｅＮＢ２００から受信する受信部（バックホール通信部２４０）を備えてもよい。制御部２３０は、自ｅＮＢ２００及び他のｅＮＢ２００の両方でページングに失敗したことに応じて、ＲＡＮページングが失敗したと判断する。

【0133】

図１１は、第２実施形態に係る動作例を示す図である。図１１において、アンカーｅＮＢ２００－１及びｅＮＢ２００－２は、同一のＲＡＮページングエリアに属する。アンカーｅＮＢ２００－１及びｅＮＢ２００－２は、Ｘ２インターフェイスを介して接続されていてもよい。図１１の初期状態において、ＵＥ１００は、ＲＲＣコネクティッドモードにある（Ｓ２００１、Ｓ２００２）。なお、図１１において、破線で示す動作は必須ではない。

【0134】

図１１に示すように、ステップＳ２００３及びＳ２００４の動作は第１実施形態と同様である。

【0135】

ステップＳ２００５において、アンカーｅＮＢ２００－１は、ＵＥ１００用のＳ１接続を介して、ＵＥ１００宛てのデータ（ＤＬ ｄａｔａ）をＳ－ＧＷ３００Ｕから受信する。アンカーｅＮＢ２００－１は、当該データの受信に応じて、ＵＥ１００のページングを開始すると判断する。

【0136】

ステップＳ２００６において、アンカーｅＮＢ２００－１は、ＵＥ１００のページング（ＲＡＮページング）の実施を要求するページング要求（Ｐａｇｉｎｇ Ｒｅｑｕｅｓｔ）をｅＮＢ２００－２に送信する。ページング要求は、ページングタイミングを特定するための情報を含んでもよい（第３実施形態参照）。

【0137】

ステップＳ２００７において、アンカーｅＮＢ２００－１は、ページングを開始すると判断した際に、又はページング要求を送信した際に、タイマを開始させる。アンカーｅＮＢ２００－１は、ＵＥ１００からページング応答を受信した際に、又はｅＮＢ２００－２からページング成功通知を受信した際に、タイマを停止させてもよい。

【0138】

ステップＳ２００８において、アンカーｅＮＢ２００－１及びｅＮＢ２００－２は、ＵＥ１００に設定されたＲＡＮページングエリア内で、ＵＥ１００宛てのページングメッセージ（Ｒａｎ ｐａｇｉｎｇ）を送信する。ここでは、ＵＥ１００がページングメッセージ（Ｒａｎ ｐａｇｉｎｇ）の受信に失敗したと仮定して説明を進める。

【0139】

ステップＳ２００９において、ｅＮＢ２００－２は、ＵＥ１００のページング（ＲＡＮページング）に失敗したことを示す失敗通知（Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）をアンカーｅＮＢ２００－１に送信する。

【0140】

ステップＳ２０１０において、アンカーｅＮＢ２００－１は、タイマが満了したか否か、及び／又は失敗通知（Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）を受信したか否かを判断する。ここでは、タイマが満了した、及び／又は失敗通知（Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）を受信したと仮定して、説明を進める。

【0141】

ステップＳ２０１１において、アンカーｅＮＢ２００－１は、ＲＡＮページングの失敗を示す失敗通知（ＲＡＮ Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）をＳ１インターフェイス上でＭＭＥ３００Ｃに送信する。失敗通知（ＲＡＮ Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）は、当該ＵＥ１００をＭＭＥ３００Ｃが識別するための識別子（例えば、ｅＮＢ ＵＥ Ｓ１ＡＰ ＩＤ）を含む。失敗通知（ＲＡＮ Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）は、ＭＭＥ ＵＥ Ｓ１ＡＰ ＩＤ、Ｃａｕｓｅ（例えばＲＡＮ Ｐａｇｉｎｇ Ｆａｉｌｅｄ）等を含んでもよい。なお、失敗通知（ＲＡＮ Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）に代えて、ページングの実施を要求するページング要求（Ｐａｇｉｎｇ Ｒｅｑｕｅｓｔ）を用いてもよい。

【0142】

ステップＳ２０１２において、ＭＭＥ３００Ｃは、アンカーｅＮＢ２００－１からの失敗通知（ＲＡＮ Ｐａｇｉｎｇ Ｆａｉｌｕｒｅ）の受信に応じて、ＵＥ１００が在圏するトラッキングエリアに属する各ｅＮＢ２００にページングメッセージ（ＰＡＧＩＮＧ）を送信する。ＵＥ１００が在圏するトラッキングエリアに属する各ｅＮＢ２００は、当該ページングメッセージを自セル内に送信する。但し、ＭＭＥ３００Ｃは、ＵＥ１００が在圏するトラッキングエリアに属する全てのｅＮＢ２００にページングメッセージを送信することに変えて、当該トラッキングエリアに属する一部のｅＮＢ２００にのみページングメッセージを送信してもよい。

【0143】

ステップＳ２０１３において、ＵＥ１００は、ページングメッセージ（ＰＡＧＩＮＧ）の受信に応じて、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧することを要求するメッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｂｏｏｔ ｒｅｑｕｅｓｔ）をｅＮＢ２００（例えばアンカーｅＮＢ２００－１）に送信する。

【0144】

［第３実施形態］
以下において、第３実施形態について、第１及び第２実施形態との相違点を主として説明する。第３実施形態は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００のＤＲＸ動作に関する実施形態である。

【0145】

まず、一般的なアイドルモードＤＲＸ動作について説明する。消費電力を削減するために、間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）がＵＥ１００に設定され得る。ＤＲＸ動作において、ＲＲＣアイドルモードのＵＥ１００は、所定の時間間隔（ＤＲＸサイクル）で発生するページング受信機会（Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎ）においてページングメッセージを監視する。ＤＲＸ動作において、ＵＥ１００は、ページングを受信するためにＰＤＣＣＨを間欠的に監視する。ＵＥ１００は、ページング用の識別子（Ｐ－ＲＮＴＩ：Ｐａｇｉｎｇ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を用いてＰＤＣＣＨをデコードし、ページングチャネルの割り当て情報を取得する。ＵＥ１００は、割当情報に基づいて、ページングメッセージを取得する。ＵＥ１００におけるＰＤＣＣＨ監視タイミングは、ＵＥ１００の識別子（ＩＭＳＩ：Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）に基づいて定められる。ＤＲＸ動作におけるＰＤＣＣＨ監視タイミング（ＰＤＣＣＨ監視サブフレーム）は、Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎ（ＰＯ）と称される。ＰＯは、ページングの受信機会に相当する。

【0146】

ＵＥ１００及びｅＮＢ２００は、Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎ（ＰＯ）、及び、Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎを含みうる無線フレームであるＰａｇｉｎｇ Ｆｒａｍｅ（ＰＦ）を下記のように計算する。

【0147】

ＰＦのシステムフレーム番号（ＳＦＮ）は、下記の式（１）から求められる。

【0148】

ＳＦＮ ｍｏｄ Ｔ ＝ （Ｔ ｄｉｖ Ｎ） ＊ （ＵＥ＿ＩＤ ｍｏｄ Ｎ） …（１）

【0149】

但し、Ｔは、ページングを監視するためのＵＥ１００のＤＲＸサイクルであり、無線フレームの数で表される。また、Ｔは、ｅＮＢ２００がＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）によりブロードキャストするデフォルトＤＲＸ値、及びＮＡＳメッセージによりＵＥ１００に設定されるＵＥ固有ＤＲＸ値のうち、何れか小さい方である。なお、ＵＥ固有ＤＲＸ値が設定されていない場合、ＵＥ１００は、デフォルトＤＲＸ値を適用する。また、Ｎは、ＴとｎＢのうち最小値である。ｎＢは、４Ｔ， ２Ｔ， Ｔ， Ｔ／２， Ｔ／４， Ｔ／８， Ｔ／１６， Ｔ／３２から選択される値である。ＵＥ＿ＩＤは、「ＩＭＳＩ ｍｏｄ１０２４」により求められる値である。

【0150】

このようにして求められたＰＦのうち、下記の式（２）により、インデックスｉ＿ｓを求め、インデックスｉ＿ｓに対応するＰＯのサブフレーム番号を求める。

【0151】

ｉ＿ｓ ＝ ｆｌｏｏｒ（ＵＥ＿ＩＤ／Ｎ） ｍｏｄ Ｎｓ …（２）

【0152】

但し、Ｎｓは、１とｎＢ／Ｔのうち最大値である。

【0153】

次に、第３実施形態に係る動作について説明する。図１２は、第３実施形態に係る動作を示す図である。

【0154】

第３実施形態の動作パターン１に係るＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移するよう指示する遷移指示をサービングセルから受信する受信部１１０と、サービングセルにおいてＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移し、ＲＲＣコネクティッドモードのＤＲＸ動作を行う制御部１３０と、を備える。すなわち、図１２（ａ）に示すように、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移した時点のサービングセルに在圏する間は、ＲＲＣコネクティッドモードのＤＲＸ動作を継続する。図１２（ｂ）に示すように、ＵＥ１００の制御部１３０は、ＲＡＮページングエリア内で当該サービングセルから他のセルにＵＥ１００が移動したことに応じて、ＲＲＣコネクティッドモードのＤＲＸ動作を中止する。ＵＥ１００の制御部１３０は、ＲＲＣコネクティッドモードのＤＲＸ動作を中止するとともに、ＲＲＣアイドルモードのＤＲＸ動作に基づく動作を開始する。ＲＲＣアイドルモードのＤＲＸ動作に基づく動作とは、ＲＲＣアイドルモードのＤＲＸ動作におけるページングフレーム（ＰＦ）及びページング機会（ＰＯ）の計算式又はこれを流用した計算式によりＰＦ及びＰＯを決定する動作である。図１２（ｃ）に示すように、ＵＥ１００の制御部１３０は、異なるＲＡＮページングエリアに移動した際に通知を行う。

【0155】

或いは、第３実施形態の動作パターン２に係るＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移した時点のサービングセルから他のセルに移動しても、当該他のセルが同一ＲＡＮページングエリアに属するのであれば、ＲＲＣコネクティッドモードのＤＲＸ動作を継続する。この場合、図１２（ａ）及び（ｂ）に示すように、ＵＥ１００は、同一ＲＡＮページングエリア内でＲＲＣコネクティッドモードのＤＲＸ動作を継続することができる。すなわち、ＵＥ１００は、他のセルに移動しても、コネクティッドモードＤＲＸに準じて受信動作を行う。後述するように、ページング要求において、コネクティッドモードＤＲＸの設定値（ＤＲＸ Ｃｏｎｆｉｇ）がｅＮＢ２００－２に転送されてもよい。

【0156】

ここで、このような動作をｅＮＢ２００単位で行なってもよい。すなわち、第３実施形態の動作パターン１及び２において、「サービングセル」を「サービングｅＮＢ」又は「アンカーｅＮＢ」と読み替え、「他のセル」を「他のｅＮＢ」と読み替えてもよい。

【0157】

第３実施形態の動作パターン１及び２において、アンカーｅＮＢ以外のＵＥ１００はＵＥ１００のコンテキスト情報を保持しているとは限らない。よって、同一ＲＡＮページングエリア内の他のｅＮＢは、ページングのタイミングを決定するための情報をアンカーｅＮＢから取得することが望ましい。

【0158】

第３実施形態に係るｅＮＢ２００－２（図１１参照）は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００に対してＲＡＮページングを行う制御部２３０を備える。制御部２３０は、ＲＡＮページングのためのページングメッセージをＵＥ１００に送信するタイミングを決定するための情報をアンカーｅＮＢ２００－１（図１１参照）から取得する。当該タイミングを決定するための情報は、ＵＥ１００の識別情報（例えば、ＩＭＳＩ、Ｓ－ＴＭＳＩ、Ｒｅｓｕｍｅ ＩＤ等）及びＲＲＣコネクティッドモードのＤＲＸ設定のうち少なくとも一方を含む。アンカーｅＮＢ２００－１は、このような情報をページング要求（Ｐａｇｉｎｇ Ｒｅｑｕｅｓｔ）に含めてｅＮＢ２００－２に送信してもよい（図１１のステップＳ２００６参照）。

【0159】

第３実施形態において、ページングのタイミングを決定するための識別情報は、ＥＣＧＩ（Ｅ－ＵＴＲＡＮ Ｃｅｌｌ Ｇｌｏｂａｌ Ｉｄｅｎｔｉｆｉｅｒ）及びＣ－ＲＮＴＩ（Ｃｅｌｌ－Ｒａｄｉｏ． Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）であってもよい。アンカーｅＮＢ２００－１は、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移させる際に、当該識別情報をＵＥ１００に割り当ててもよい。

【0160】

［第４実施形態］
以下において、第４実施形態について、第１乃至第３実施形態との相違点を主として説明する。第４実施形態は、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移させるためのメッセージに関する実施形態である。

【0161】

図１３は、第４実施形態の動作パターン１を示す図である。第４実施形態の動作パターン１において、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをサービングセルから受信する受信部１１０と、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移するよう指示する遷移指示がＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれないことに応じて、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに対する応答メッセージであるＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅメッセージをサービングセルに送信する送信部１２０と、遷移指示がＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれることに応じて、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅメッセージの送信を中止する制御部１３０と、を備える。ここで、遷移指示は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｉｏｎに関連する設定情報であってもよい。動作パターン１によれば、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎにおいてＬｉｇｈｔ ＣｏｎｎｅｃｔｉｏｎがＳｅｔｕｐされた場合は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅメッセージを送信しない。これにより、シグナリングを削減することができる。

【0162】

図１４は、第４実施形態の動作パターン２を示す図である。第４実施形態の動作パターン２において、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージをサービングセルから受信する受信部１１０と、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移するよう指示する遷移指示がＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージに含まれないことに応じて、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージに対する応答メッセージの送信を中止する制御部１３０と、遷移指示がＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅメッセージに含まれることに応じて、応答メッセージであるＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ Ｃｏｍｐｌｅｔｅメッセージをサービングセルに送信する送信部１２０と、を備える。ここで、遷移指示は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｉｏｎに関連する設定情報であってもよい。ＵＥ１００の制御部１３０は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ Ｃｏｍｐｌｅｔｅメッセージが送達されたことを例えばＨＡＲＱ ＡＣＫに基づいて確認できた際に、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態へ遷移する。動作パターン２によれば、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｌｅａｓｅにおいてＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態への遷移が指示された場合は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅ Ｃｏｍｐｌｅｔｅメッセージを送信する。これにより、ｅＮＢ２００は、ＵＥ１００がＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移したことをより確実に確認することができる。

【0163】

［第５実施形態］
以下において、第５実施形態について、第１乃至第４実施形態との相違点を主として説明する。第５実施形態は、ＵＥ１００がＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧するためのメッセージに関する実施形態である。

【0164】

第５実施形態に係るＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧することを示す情報をサービングセルに送信する送信部１２０と、サービングセルからＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信することなく、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧する制御部１３０と、を備える。Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧することを示す情報とは、例えば、上述したＲＲＣ Ａｃｔｉｖａｔｉｏｎ Ｒｅｑｕｅｓｔ、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｂｏｏｔ ｒｅｑｕｅｓｔ等である。

【0165】

図１５は、第５実施形態に係る動作例を示す図である。

【0166】

図１５（ａ）に示すように、従来のアプローチ（Ｌｅｇａｃｙ ａｐｐｒｏａｃｈ）によれば、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧するための要求（Ｒｅｑｕｅｓｔ）をｅＮＢ２００に送信する。次に、ＵＥ１００は、ｅＮＢ２００からＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信し、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ ＣｏｍｐｌｅｔｅメッセージをｅＮＢ２００に送信することにより、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧する（ＲＲＣコネクティッドモードに遷移する）。

【0167】

図１５（ｂ）に示すように、第５実施形態の第１のアプローチ（Ｏｎｅ－ｓｔｅｐ ａｐｐｒｏａｃｈ）によれば、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧することを示す通知（Ｉｎｄｉｃａｔｉｏｎ）をｅＮＢ２００に送信するのみで、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧する（ＲＲＣコネクティッドモードに遷移する）。通知（Ｉｎｄｉｃａｔｉｏｎ）は、無線リソースの割り当てを要求する情報（スケジューリング要求）及び／又は上りリンクのバッファ状態を報告する情報（バッファ状態報告）を含んでもよい。ＵＥ１００は、通知（Ｉｎｄｉｃａｔｉｏｎ）が送達されたことをＨＡＲＱ ＡＣＫ等に基づいて確認できない場合には、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態を維持するか、又はＲＲＣアイドルモードに遷移してもよい。

【0168】

図１５（ｃ）に示すように、第５実施形態の第２のアプローチ（Ｔｗｏ－ｓｔｅｐ ａｐｐｒｏａｃｈ）によれば、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧するための要求（Ｒｅｑｕｅｓｔ）をｅＮＢ２００に送信し、当該要求に対する肯定応答（Ａｃｋｎｏｗｌｅｄｇｅ）をｅＮＢ２００から受信するのみで、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態から復旧する（ＲＲＣコネクティッドモードに遷移する）。要求（Ｒｅｑｕｅｓｔ）は、無線リソースの割り当てを要求する情報（スケジューリング要求）及び／又は上りリンクのバッファ状態を報告する情報（バッファ状態報告）を含んでもよい。ｅＮＢ２００は、要求（Ｒｅｑｕｅｓｔ）に対して否定応答をＵＥ１００に送信してもよい。ＵＥ１００は、否定応答を受信した場合、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態を維持するか、又はＲＲＣアイドルモードに遷移してもよい。Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態を維持するか又はＲＲＣアイドルモードに遷移するかは、当該否定応答で指定されてもよい。

【0169】

よって、第５実施形態によれば、従来のアプローチに比べてシグナリングを削減することができる。ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎが不要な理由としては次の理由が挙げられる。具体的には、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態はＲＲＣコネクティッドモードに類似する状態であると仮定すると、ｅＮＢ２００が新たにリソースを準備する必要がない（すなわち、拒否する理由が無い）。また、ＵＥが新たに設定を適用する必要がない（すなわち、設定失敗が無い）。さらに、ＲＲＣ状態遷移がなく、ｅＮＢ２００とＵＥ１００とが認識を合わせなくてもよい。例えば、ＵＥ１００がＲＲＣコネクティッドモードのＤＲＸに従って動作していれば、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態でもＲＲＣコネクティッドモードでもＵＥ１００の受信タイミングは同じである為、データ通信ができない状態にはならない。

【0170】

但し、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移した時点のセルに在圏する場合のみ第５実施形態に係る動作を行なってもよい。ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移した時点のセルから同一ＲＡＮページングエリア内の他のセルに移動した場合には、従来のアプローチに係る動作を行なってもよい。

【0171】

第５実施形態に係る通知（Ｉｎｄｉｃａｔｉｏｎ）及び要求（Ｒｅｑｕｅｓｔ）は、ランダムアクセスプロシージャ中にｅＮＢ２００に送信されてもよい。一例として、通知（Ｉｎｄｉｃａｔｉｏｎ）及び要求（Ｒｅｑｕｅｓｔ）は、ランダムアクセスプロシージャのＭｓｇ１（ランダムアクセスプリアンブル／ＰＲＡＣＨ送信）又はＭｓｇ３（ｓｃｈｅｄｕｌｅｄ ｔｒａｎｓｍｉｓｓｉｏｎ）中でＵＥ１００からｅＮＢ２００に送信されてもよい。また、肯定応答（Ａｃｋｎｏｗｌｅｄｇｅ）又は否定応答は、ランダムアクセスプロシージャのＭｓｇ２（ランダムアクセス応答）又はＭｓｇ４（ｃｏｎｔｅｎｔｉｏｎ ｒｅｓｏｌｕｔｉｏｎ）中でｅＮＢ２００からＵＥ１００に送信されてもよい。

【0172】

［第６実施形態］
以下において、第６実施形態について、第１乃至第５実施形態との相違点を主として説明する。第６実施形態は、データ通信の中断を示す通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）に関する実施形態である。

【0173】

上述したように、ＵＥ１００は、データ通信が発生していない（又は発生する見込みが無い）場合に通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）をｅＮＢ２００に送信していた。これに対し、第６実施形態では、通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）を以下のように改良する。

【0174】

第６実施形態に係るＵＥ１００は、サービングセル（ｅＮＢ２００）とのデータ通信の中断を検知する制御部１３０と、データ通信の中断（Ｄａｔａ ｉｎａｃｔｉｖｅ）を検知したことに応じて、データ通信の中断を示す通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）をサービングセルに送信する送信部１２０と、を備える。制御部１３０は、データ通信の中断の予想時間を推定する。送信部１２０は、当該予想時間を含む通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）を送信する。

【0175】

ＵＥ１００（制御部１３０）は、上述と同様にアプリケーションレイヤからの情報によってデータ通信の中断時間を予想してもよい。具体的には、アプリケーションレイヤから通知された時間がそのまま予想時間になってもよい。或いは、アプリケーションレイヤからどのアプリケーションが起動していて、どのアプリケーションがシャットダウンされたのかというような情報や、現在ユーザが操作を行っているか否か（もしくはフォアグラウンド通信が想定されるか、バックグラウンド通信のみが想定されるか）などの情報を用いてＵＥ１００（ＡＳ側）で予想してもよい。ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）は、ＲＲＣ層以下の各プロトコルからなる。例えば、ＡＳ側でトラフィック発生パターンを事前に収拾しておき、アプリケーションレイヤからの情報等も必要に応じて使いながら、トラフィック予測を行い、予測時間を推定する。

【0176】

第６実施形態において、通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に入りたい旨の直接的な通知又はＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に入ることが可能である旨の直接的な通知であってもよい。

【0177】

第６実施形態において、ｅＮＢ２００は、通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）を送信してよいか否かをＵＥ１００に明示的又は暗示的に設定できてもよい。例えば、ＵＥ１００は、ＳＩＢで通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）の送信を許可する旨の識別子を報知している場合、又はｅＮＢ２００が通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）の送信を設定（ｓｅｔｕｐ）している場合には、ＵＥ１００は、通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）の送信が許可されていると判断する。また、通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）が、１）過去の状態によって判定される（すなわち、データが発生していない）、２）未来の予想によって判定される（すなわち、発生する見込みが無い）、３）過去及び未来の両方を含めて判定されるかは、ｅＮＢ２００からＵＥ１００に設定されてもよい。さらに、通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）のｐｒｏｈｉｂｉｔ ｔｉｍｅｒ値及び／又はレポート周期などがｅＮＢ２００からＵＥ１００に設定されてもよい。ｐｒｏｈｉｂｉｔ ｔｉｍｅｒは、ＵＥ１００が通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）を送信した後に次の通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）の送信を可能とするまでの時間を規定するタイマである。

【0178】

第６実施形態において、通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｉｏｎ用ＤＲＸの推奨サイクル又は希望するＤＲＸサイクルを含んでもよい。ＵＥ１００（制御部１３０）は、当該ＤＲＸサイクル希望値を、上述したデータ通信の中断の予想時間に基づいて判断してもよい。具体的には、ＵＥ１００は、自身の状況に基づいて適切なＤＲＸサイクルを判断し、当該ＤＲＸサイクルを通知（Ｅｘｔｅｎｄｅｄ ＰＰＩ）中で送信する。ＵＥ１００は、当該通知を行った時点で、通知したＤＲＸサイクルを適用してもよい。或いは、ＵＥ１００は、ｅＮＢ２００による応答（ＲＲＣ接続再構成など）によってＤＲＸサイクルを設定されてもよい。当該通知を行ってＤＲＸサイクルを適用する場合は、当該適用をもってＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄに遷移したとみなされてもよい。

【0179】

なお、ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄに遷移するまでのタイマ値をＵＥ１００に設定（例えばブロードキャスト又はユニキャスト）してもよい。ＵＥ１００は、データ通信が行われた時に当該タイマをリセット（再スタート）し、当該タイマが満了した場合にＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄに遷移する。ＵＥ１００は、当該タイマが動作している間において、データ通信が中断された場合（例えば前記予想時間がタイマ満了よりも後となる場合）に、ｅＮＢ２００に対してデータ中断を通知してもよい。

【0180】

［第７実施形態］
以下において、第７実施形態について、第１乃至第６実施形態との相違点を主として説明する。第７実施形態は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態にあるＵＥ１００のセル再選択動作に関する実施形態である。

【0181】

第７実施形態に係るＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態においてセル再選択動作を行う制御部１３０を備える。制御部１３０は、当該セル再選択動作において、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態からの復旧をサポートするセルをＵＥ１００のサービングセルとして優先的に選択する。

【0182】

一般的なセル再選択動作は、セルが属する周波数の優先度及びセルの無線品質に基づくランキングにより、適切なセルを選択する動作である。

【0183】

第７実施形態に係るセル再選択動作おいて、ＵＥ１００（制御部１３０）は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄをサポートするセルを最高優先度（Ｈｉｇｈｅｓｔ ｐｒｉｏｒｉｔｙ）としてもよい。ＵＥ１００（制御部１３０）は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄをサポートしないセルを最低優先度（Ｌｏｗｅｓｔ ｐｒｉｏｒｉｔｙ）としてもよい。ここで、Ｈｉｇｈｅｓｔ／Ｌｏｗｅｓｔとは、ｅＮＢ２００からブロードキャストされている優先度（ＣｅｌｌＲｅｓｅｌｅｃｔｉｏｎＰｒｉｏｒｉｔｙ：０～７）又は当該優先度とサブ優先度（ＣｅｌｌＲｅｓｅｌｅｃｔｉｏｎＳｕｂＰｒｉｏｒｉｔｙ：０．２、０．４、０．６、０．８）を加算した値よりも、高い／低い優先度（例えば、“８”、“－１”）を意味する。

【0184】

或いは、第７実施形態に係るセル再選択動作おいて、ＵＥ１００（制御部１３０）は、ランキングにオフセットを導入することにより、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄをサポートするセルを優先してもよい。例えば、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄをサポートするセルにはプラスのオフセットを加算する、及び／又はＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄをサポートしないセルにはマイナスのオフセットを加算する。当該オフセット値は、予め定義された値でもよく、ｅＮＢ２００から設定された値であってもよい。ｅＮＢ２００から設定される場合、ｅＮＢ２００は、当該オフセット値をブロードキャストしてもよいし、ＵＥ個別に専用シグナリングにより当該オフセット値を設定してもよい。

【0185】

第７実施形態において、ｅＮＢ２００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態からの復旧をサポートするセルの優先制御を行うか否かをＵＥ１００に設定してもよい。当該設定は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態に遷移する時に設定されてもよい。当該設定は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｌｅａｓｅに含まれていてもよい。

【0186】

各ｅＮＢ２００（各セル）は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態（具体的には、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態からの復旧）をサポートしているか否かを示す情報をブロードキャストしていてもよい。一例として、ｅＮＢ２００は、当該情報をＳＩＢにより送信する。このような情報は、暗示的な情報であってもよい。例えば、ＵＥ１００は、ＲＡＮページングエリアの識別子を送信しているセルをＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態をサポートしているセルとみなしてもよい。

【0187】

第７実施形態において、ＵＥ１００は、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態からの復旧をサポートし、かつ所定の無線品質基準（例えばＳ ｃｒｉｔｅｒｉｏｎ）を満たすセルが検出されないことに応じて、ＲＲＣアイドルモードに遷移してもよい。一例として、ＵＥ１００は、Ｓ ｃｒｉｔｅｒｉｏｎを満たすセルがｌｅｇａｃｙセル（すなわち、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態をサポートしていないセル）だけであった場合などにおいて、ＲＲＣアイドルモードに遷移してもよい。

【0188】

［その他の実施形態］
上述した各実施形態を別個独立に実施する場合に限らず、２以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の動作を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の動作を他の実施形態の一部の動作と置換してもよい。

【0189】

上述した実施形態において、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）をＵＥ１００が受信する又は受信に興味を持つケースについて特に触れなかった。しかしながら、ｅＮＢ２００は、ＵＥ１００におけるＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）の受信状況等に基づいて、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄに遷移させるか否かを判断してもよい。一例として、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態においてＳＣ－ＰＴＭ（Ｓｉｎｇｌｅ－ｃｅｌｌ Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）受信が実施されない場合（例えば、ＳＣ－ＰＴＭ受信が許可されない場合、ＵＥ能力が不足している場合など）には、ｅＮＢ２００は、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄに遷移させない。他の例として、ＭＢＭＳ Ｉｎｔｅｒｅｓｔ ＩｎｄｉｃａｔｉｏｎにおいてＭＢＭＳサービス受信（例えばＳＣ－ＰＴＭ受信）への興味が示されていた時は、ｅＮＢ２００は、ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄに遷移させない。また、一部のＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態でＭＢＭＳを受信できない。当該ＵＥ１００がＬｉｇｈｔ ＣｏｎｎｅｃｔｅｄでのＭＢＭＳ受信が可能である場合、ｅＮＢ２００は、ＭＢＭＳサービス受信（例えばＳＣ－ＰＴＭ受信）への興味を当該ＵＥ１００が示すことに応じて、当該ＵＥ１００をＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄに遷移させてもよい。

【0190】

また、上述した第１実施形態において、セルＩＤ及びＣ－ＲＮＴＩの組み合わせからなる識別子をページングメッセージに含める一例を説明した。

【0191】

ところで、優先度が高いＭＴデータ（ＵＥ１００における着呼）が発生した場合においても、現在のページングでは当該状況を示す手段がない。よって、ＭＢＭＳ受信（例えばＳＣ－ＰＴＭ受信）を優先しているＵＥ１００に対してページングが発生した場合、ＭＢＭＳ受信を継続するか、ＭＢＭＳ受信を中断してＲＲＣ接続を優先するかを適切に判断できない虞がある。

【0192】

よって、ページングメッセージに優先度情報を付与することによって、適切な判断ができるようにする。当該優先度情報は、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅの値（例えば、ｈｉｇｈ ｐｒｉｏｒｉｔｙ ａｃｃｅｓｓ）でもよく、優先度の高い着呼である事を示す識別子でもよく、優先度を示す数値（例えば、０～７）でもよく、当該着呼に紐付いたベアラ識別子でもよい。また、当該優先度情報は、リストによって提供されてもよく、当該リストの各エントリは、ページングメッセージ内のＵＥ識別子のリスト（Ｐａｇｉｎｇ Ｒｅｃｏｒｄ Ｌｉｓｔ）の各エントリと対応していてもよい。もしくは、当該優先度情報は、前記Ｐａｇｉｎｇ Ｒｅｃｏｒｄ Ｌｉｓｔのエントリ（すなわちＰａｇｉｎｇ Ｒｅｃｏｒｄ）に組み込まれていてもよい。当該優先度情報は、ｅＮＢ２００が決定してもよく、ＭＭＥ３００Ｃが決定してもよい。

【0193】

当該優先度情報を含んだページングメッセージを受信したＵＥ１００は、当該優先度情報を用いてＲＲＣ接続開始処理（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ送信）の要否を決定する。当該ＲＲＣ接続処理を開始する場合、当該ＲＲＣ接続処理のメッセージにおいて、優先度情報に基づく処理である旨（例えば、“ｐｒｉｏｒｉｔｉｚｅｄ ＭＴ ｃａｌｌ”）をｅＮＢ２００に通知してもよく、当該通知はＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅに含まれてもよい。

【0194】

一方で、ＵＥ１００は、優先度情報を含んだページングよりも、ＭＢＭＳ受信を優先する場合、当該ページングに対して応答を行わなくてもよい。

【0195】

上述した各実施形態において、所定のイベントの発生を契機としてＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態を終了させる一例を説明した。Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ｅＮＢ２００からＵＥ１００に設定されたタイマが動作中である期間にのみ有効であってもよい。この場合、所定のイベントは、タイマの満了であってもよい。或いは、Ｌｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態は、ＵＥ１００が所定周波数内に存在する期間にのみ有効であってもよい。例えば、あるセルにおいてＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態の指示を受けたＵＥ１００は、当該セルが属する周波数とは異なる周波数のセルに移動したことに応じてＬｉｇｈｔ Ｃｏｎｎｅｃｔｅｄ状態を終了してもよい。

【0196】

上述した各実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外のシステムに本発明を適用してもよい。

【0197】

（付記１）
（１．はじめに）
ＲＡＮ２＃９５はライトコネクティッドの基本的な機能／特性を以下のように合意した。

【0198】

合意事項：
ライトコネクティッドＵＥの機能は以下を含む。

【0199】

－Ｓ１接続は、「アンカーｅＮＢ」内で維持されアクティブである。

【0200】

－ＲＡＮがページングを開始することのサポート。

【0201】

－ページングプロセスは、「アンカーＮＢ」によって制御される。

【0202】

－ｅＮＢ制御のＲＡＮベースのページング領域。

【0203】

－ＲＡＮベースのページングエリア更新メカニズム。ＲＡＮベースのページング領域は、ＵＥ固有のものとして構成可能であり得る。

【0204】

－ＲＲＣアイドルにおけるものと同じセル再選択メカニズムである、セル再選択ベースの移動性を実行する。

【0205】

－ＵＥのＡＳコンテキストは、ＵＥと「アンカーｅＮＢ」側の両方に保持される。

【0206】

－ＥＣＭ状態は、ネットワークの観点から、ＥＣＭコネクティッドである。ＵＥの観点からの状態は更なる検討が必要である。

【0207】

－（ライトコネクティッド）ＵＥが（ＲＡＮ開始ページングを介して）ページングされるか又は任意のＭＯデータ／シグナリングがトリガされると、ＵＥはｅＮＢに接続するように戻る。関連する手順は更なる検討が必要である。

【0208】

－ＵＥは、ＲＲＣシグナリングによって「軽度に接続」される。詳細は更なる検討が必要である。

【0209】

この付記では、ライトコネクティッドの詳細について説明する。

【0210】

（２．検討）
（２．１．モデリングの原則）
（２．１．１．ＲＲＣ状態とサブ状態）
ＬＴＥは、２つのＲＲＣ状態、すなわち、ＲＲＣコネクティッド及びＲＲＣアイドルを有する。ＲＲＣ接続Ｓｕｓｐｅｎｄ／Ｒｅｓｕｍｅ手順がリリース１３に導入された場合でも、２つの状態のモデリングが維持された。ＲＲＣ接続を中断しているＵＥは、状態の観点から、すなわち、ＡＳコンテキスト及び再開ＩＤ（ｒｅｓｕｍｅ ＩＤ）を記憶しているアイドルＵＥの「サブ状態」であるから、ＲＲＣアイドルにある。２つの状態のモデリングは、レガシーシステムでは少し複雑な状態遷移とこれらの状態を単純化するためにうまく機能する。したがって、ＲＡＮ２は、ライトコネクティッドが導入されてもＲＲＣモデリングに固執すべきである。つまり、ＲＲＣコネクティッド又はアイドルの一部であるライトコネクティッド「サブ状態」として定義すべきであり、ＲＡＮ２によって決定される所望の動作に応じて特定の機能が追加又は制限される。

【0211】

提案１：ＲＡＮ２は、ライトコネクティッドがＲＲＣで定義されている場合、既存の２つの状態モデリング、すなわち、ＲＲＣコネクティッド及びアイドルに固執すべきである。

【0212】

（２．１．２．ベースライン状態）
提案１が合意可能であれば、ライトコネクティッド「サブ状態」はＲＲＣコネクティッド又はＲＲＣアイドル上に構築される。

【0213】

ＲＡＮ２＃９５では、ＲＲＣ Ｓｕｓｐｅｎｄｅｄ／Ｒｅｓｕｍｅがライトコネクティッドのベースラインであることが示唆された。ライトコネクティッドは、ＵＥの視点からのＲＲＣ接続を中断する機能と、ＣＮの観点からＳ１接続をアクティブに維持する新しい機能を組み合わせたものである。ＵＥコンテキストの中断／再開の要求／応答を排除するＳ１には依然として有益であるが、リリース１３手順に依存しているため、Ｕｕでは、リリース１３と比較してリリース１４ではシグナリング及び遅延の削減という点で利益が得られない。さらに、ＮＷとライトコネクティッドのＵＥとの間でＥＣＭ状態の不一致が生じ得る。すなわち、ネットワークの観点からＥＣＭ状態がＥＣＭコネクティッドであるが、ＲＲＣ接続がサスペンド中はＵＥがＲＲＣアイドルであるため、ＵＥの観点からはＥＣＭアイドルである。ミスマッチが他のＷＧに受け入れられるかどうかは不明である。

【0214】

考察１：ＲＲＣサスペンドベースのライトコネクティッドは、Ｕｕのシグナリング／レイテンシの削減に関して何の利得もないことがあり得る。

【0215】

考察２：ＮＷとライトコネクティッドのＵＥ間のＥＣＭ状態のミスマッチが許容可能かどうかは不明である。

【0216】

一方、ＲＲＣコネクティッドに基づく手法も提案されている。ＲＲＣコネクティッドの最大のメリットは、ＭＯ呼とＭＴ呼のアクセスレイテンシが低いことである。潜在的に、ＭＴ呼にはページングは必要ないが、ライトコネクティッドのための「ＲＡＮによって開始されたページングのサポート」を導入することはすでに合意されている。さらに、ＥＣＭ状態は、ＮＷとＵＥとの間で自然に合わせられる。したがって、ＲＲＣコネクティッドベースのライトコネクティッドは、Ｕｕのシグナリングとレイテンシを向上させる可能性がある。これは、上位レイヤ、つまりＮＡＳに不必要な影響を与えることはない。しかしながら、ＵＥをレガシーＲＲＣコネクティッドに保つだけで、ＵＥの電力消費が明らかに悪い。すなわち、「解決策は、ＵＥの電力消費をＲＲＣアイドルの電力消費と同等にすることができる」という目的を達成できない。したがって、ＲＲＣコネクティッドベースのライトコネクティッドが必要な場合は、いくつかの最適化が必要になる。

【0217】

考察３：ＲＲＣコネクティッドベースのライトコネクティッドは、ＵＥの電力消費を最小限に抑えるために標準化の取り組みがＲＡＮ２で必要となるが、Ｕｕのシグナリングオーバーヘッドとアクセスレイテンシを上位レイヤへの不要な影響なしに改善する可能性がある。

【0218】

ＷＩの目標の最初のステートメントは、この作業項目の目的は、無線及びネットワークインタフェースのシグナリングオーバーヘッドを削減し、すべてのデバイスタイプのＵＥアクセス待ち時間及びＵＥの消費電力を改善することであり、すべてのデバイスタイプ、すなわちＭＴＣ ＵＥだけでなく、スマートフォンのような通常のＬＴＥ ＵＥも考慮すべきである。ＭＴＣタイプのトラフィックに関しては、リリース１３のＲＲＣ接続Ｓｕｓｐｅｎｄ／Ｒｅｓｕｍｅによって既に最適化されていたが、もちろん通常のＬＴＥ ＵＥにも適用できる。したがって、リリース１４作業は、むしろスマートフォントラフィックなどの通常のＬＴＥ ＵＥに焦点を当てるべきである。

【0219】

考察４：ライトコネクティッドは、リリース１３で既に最適化されているＭＴＣタイプのトラフィックだけでなく、リリース１４の主な課題であるスマートフォンのような通常のＬＴＥトラフィックに対しても効率的でなければならない。

【0220】

上記の考察、すなわちＥＣＭ状態のミスマッチ、さらにスマートフォントラフィックのシグナリング／レイテンシ及びアダプテーションの最適化を考慮すると、ＲＡＮ２はライトコネクティッド「サブステート」のベースラインとしてＲＲＣコネクティッド状態をとる必要がある。

【0221】

提案２：ＲＡＮ２は、ＲＲＣコネクティッド状態をライトコネクティッドのベースラインとして使用すべきである。

【0222】

（２．２．ＲＲＣシグナリング）
（２．２．１．ライトコネクティッドへの移行）
ＲＡＮ２＃９５は、「ＵＥはＲＲＣシグナリングによって「ライトコネクティッド」に入ることに同意した。詳細は更なる検討が必要である。提案２が合理的である場合、ＲＲＣ接続中断のためのＲＲＣ接続解放がＲＲＣアイドルにＵＥを移行させるので、ライトコネクティッドの設定にＲＲＣ接続再設定メッセージを使用することは素直である。

【0223】

提案３：ＲＡＮ２は、ライトコネクティッドの設定にＲＲＣ接続再設定メッセージを使用すべきである。

【0224】

しかし、ＲＲＣ接続再設定メッセージの１つの欠点は、ＲＲＣ接続解放では必要ないが、ＲＲＣ接続再設定完了でハンドシェイクを実行することである。シグナリング低減の観点から、ＵＥは、ＲＲＣ接続再設定完了を送信しないことが好ましい。しかしながら、ＲＲＣ接続解放メッセージの場合のような肯定応答がなければ、サービングセルとＵＥとの間の状態ミスマッチの確率が増加するであろう。対照的に、ＲＲＣコネクティッドベースのライトコネクティッドが既にＲＲＣ接続状態のサブ状態である場合、状態遷移の不一致を伴う問題は重大な懸念事項ではない。したがって、ＲＡＮ２は、ＵＥライトコネクティッドに移行する際に、ＲＲＣ接続再設定完了が必要であるか否かについて議論すべきである。

【0225】

提案４：ＲＡＮ２は、ＵＥがライトコネクティッドに移行する際に、ＵＥからの確認応答、例えばＲＲＣ接続再設定完了が必要であるか否かについて議論すべきである。

【0226】

ライトコネクティッドへの自律的な移行を許可するかどうか検討する価値もある。サービングセルは、ブロードキャスト／専用シグナリングを介してＵＥに「非活動（ｉｎａｃｔｉｖｉｔｙ）」タイマを設定し、タイマが終了すると自律的に「ライトコネクティッド」に進むことができる。Ｕｕのライトコネクティッド制御のオーバーヘッドをさらに減らすことができる。

【0227】

提案５：ＲＡＮ２は、さらなるシグナリング削減のために、例えば、「非活動タイマ」を用いて自律的にライトコネクティッドに入ることを可能にするか否かについて議論すべきである。

【0228】

（２．２．２．ライトコネクティッドから離れる）
「ライトコネクティッド」ＵＥが（ＲＡＮ開始ページングを介して）ページングされるか、又は任意のＭＯデータ／シグナリングがトリガされると、ＵＥはｅＮＢに接続されるように戻ることに同意された。関連する手順は更なる検討が必要である。したがって、ライトコネクティッドからＲＲＣコネクティッドに戻る方法を検討する価値がある。

【0229】

従来のアプローチでは、ＲＲＣ接続を得るためのハンドシェイクには、（１）ＲＲＣ接続再開要求、（２）ＲＲＣ接続再開、（３）ＲＲＣ接続再開完了の３つのステップが必要である。（図１５の（ｂ）及び（ｃ））。一方、ハンドシェイクが最小化されると、シグナリング及びレイテンシが減少する可能性がある（図１５の（ｂ）及び（ｃ））。

【0230】

例えば、図１５の（ｂ）のようなＵＥからの指示を伴うワンステップアプローチは、シグナリング及びレイテンシを最小にするのに有益である。提案４で議論された状態ミスマッチ問題に関しては、メッセージの到達可能性の観点から、ＵＥの無線問題に起因してＤＬだけが問題になる（すなわち、Ｔ３１０実行中の受信エラーはＵＥだけで見え、サービングセルは見えない）。したがって、ワンステップアプローチは技術的に実現可能である。

【0231】

提案２が合理的である場合、すなわちＲＲＣコネクティッドベースの「サブ状態」である場合、サービングセルは、図１５の（ｃ）のように、ＲＲＣコネクティッドに戻るＵＥを拒否すべきであるかどうかを考慮することができる。ライトコネクティッドのＵＥはすでにＲＲＣコネクティッドの一部であるため、拒否メッセージを送信する必要は無いと思われる。何らかの理由でＲＲＣ接続の数を減らす必要がある場合、サービングセルは、いつでもＲＲＣ接続解放を開始することができる。

【0232】

したがって、ワンステップアプローチを我々は好むが、ＲＡＮ２はライトコネクティッドからＲＲＣコネクティッドへの復帰中にシグナリングを最適化するかどうかについて議論すべきである。

【0233】

提案６：ＲＡＮ２はライトコネクティッドからＲＲＣコネクティッドへの復帰のためのハンドシェイクを最小限にすることを考慮すべきである。

【0234】

（２．２．３．ＲＲＣコネクティッド中の非アクティブの認識）
ＵＥはＲＲＣシグナリングによってライトコネクティッドに入っているため、サービングセルは、ライトコネクティッドに入るタイミングを決定すべきである。実現可能な実装の１つは、サービングセルがトラフィックの挙動を監視し、ＵＥのパケットがある期間にわたって送受信されないときにＵＥがライトコネクティッドに入ることである。予測されるトラフィックの挙動に依存するので、予測が正確でない場合、シグナリングのオーバーヘッドが実際に増加する可能性がある。例えば、ライトコネクティッドとＲＲＣコネクティッドの間の頻繁な切り替え、又はライトコネクティッドへの移行が失敗する。ＭＴＣタイプのトラフィックはやや容易に予測されるが、ＬＴＥタイプのトラフィック、スマートフォンのトラフィック行動は、ＮＷが予測するのは容易ではないかもしれない。したがって、ＵＥは、そのトラフィック挙動のより良い知識／制御を有するので、ＵＥが何らかの支援情報を提供することが必要な場合がある。したがって、サービングセルが、ライトコネクティッドをトリガするためのアシスト情報を提供するようにＵＥを設定するかどうかを検討する価値がある。

【0235】

提案７：ＲＡＮ２は、ＲＲＣシグナリングでＵＥをライトコネクティッドに入るように決定するために、支援情報を提供するようにサービングセルがＵＥを設定することができるかどうか議論すべきである。

【0236】

提案７が合意可能である場合、支援情報は、既存のＰｏｗｅｒ Ｐｒｅｆｅｒｅｎｃｅ Ｉｎｄｉｃａｔｏｒ（ＰＰＩ）及び／又はＭＢＭＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎ（ＭＩＩ）といくつかの類似点を有する可能性がある。ＰＰＩを用いる場合、ＵＥは、その消費電力が、例えば、より長いＤＲＸサイクルによって最適化されることが好ましい場合、低電力消費を通知することができる。ＭＩＩは、例えば、周波数へのハンドオーバが優先される場合に、ユニキャストとＭＢＭＳとの間の関心のあるＭＢＭＳ周波数及び優先度を通知するために使用される。この場合、ＵＥは、サービングセルにライトコネクティッドに入る可能性を通知することができる。換言すれば、ＵＥは、データ送信／受信が一定期間中に既に非アクティブである又は非アクティブになる場合に、支援情報を送信することができる。追加の支援の詳細及び必要性は更なる検討が必要であり、例えば、ＵＥが予想する非アクティブ時間である。

【0237】

提案８：ＲＡＮ２は、ＵＥがデータ非活性時に支援情報を送信すべきかどうか検討すべきである。

【0238】

（２．３．ライトコネクティッド中のアクティビティ）
（２．３．１．ページング監視）
ＲＡＮ２＃９５は、ＲＡＮによって開始されるページングをサポートすることで合意しているため、ＵＥは、ＲＡＮによって開始されるページングにリリース１３レガシーＰＯ／ＰＦ計算が使用されるベースラインとして決定されたサブフレームでライトコネクティッド中に監視すべきである。

【0239】

一方、図１２に示すように、ＵＥがＵＥの移動性に関連するＲＲＣコネクティッドに戻るとき、３つのシナリオを考慮することができる。

【0240】

シナリオ１：ＵＥは、ライトコネクティッドに入った場所と同じセルに留まる。

【0241】

このシナリオは、スマートフォンの場合を想定すると、頻繁に起こる。ライトコネクティッドがＲＲＣコネクティッドの一部、すなわち提案２である場合、Ｃ－ＲＮＴＩは依然としてアクティブで有効であり、ＵＥをページングするためにまだ再利用することができる。したがって、ＵＥは、既存のコネクティッドモードＤＲＸ（Ｃ－ＤＲＸ）によって決定された機会でページングを監視することができる。

【0242】

シナリオ２：ＵＥは、ライトコネクティッドに入った同じＲＡＮページングエリア（ＰＡ）内の異なるセルにある。

【0243】

異なるセルでは、Ｃ－ＲＮＴＩはセル固有のＩＤであるため、もはや有効ではない。したがって、ＵＥをページングするために、（ａ）ＮＡＳ ＵＥ ＩＤ（すなわちＳ－ＴＭＳＩ）、（ｂ）リリース１３のＵＥレジュームＩＤ、（ｃ）新しいＲＡＮ ＵＥ ＩＤ、又は（ｄ）（ｄ）ＩＭＳＩモードなどの他のＩＤが必要であり得る。しかしながら、「ページング機会」は、ＤＲＸ－Ｃｏｎｆｉｇが、例えば「Ｘ２ページング」内でターゲットセルに転送される場合、Ｃ－ＤＲＸによって依然として決定される。

【0244】

シナリオ３：ＵＥはＲＡＮページングエリアの外部にあり、そこでライトコネクティッドに入る。

【0245】

この場合、ライトコネクティッドＵＥがネットワークに通知ることが必要とされる。ＵＥは、通知が送信されるセル内でライトコネクティッドに入るように指示されてもよい。したがって、このシナリオはシナリオ１と同じ条件であり、これ以上考慮する必要はない。

【0246】

ライトコネクティッドにおけるＵＥのページング機会に関しては、ＵＥの移動性を考慮に入れても、Ｃ－ＤＲＸメカニズムを再利用することができる。このアプローチでは、ＲＡＮ２の観点からは、リリース１３レガシーＰＯ／ＰＦ計算がＲＡＮで開始されたページングに使用されるベースラインとされるが、このアプローチでは仕様の影響は予見されない。ＰＯ／ＰＦ計算のための入力パラメータは、必要に応じて変更することができることは、いくつかの影響と複雑さを意味する。したがって、ＲＡＮ２はＰＦ／ＰＯ計算のベースラインを再利用すべきである。

【0247】

提案９：ＲＡＮ２は、ページング機会のために、既存のコネクティッドモードＤＲＸメカニズムを再利用することを決定すべきである。

【0248】

提案９が合意可能である場合、「ページング計算のためのＵＥＩＤを定義する、例えば（ａ）ＮＡＳ ＵＥ ＩＤ（すなわちＳ－ＴＭＳＩ）、（ｂ）リリース１３のＵＥレジュームＩＤ、（ｃ）新しいＲＡＮＵＥＩＤ又は（ｄ）ＩＭＳＩモード」という合意事項はもはや必要でない。Ｃ－ＤＲＸは、ＯｎＤｕｒａｔｉｏｎを計算するためにＩＤを入力する必要がないためである。

【0249】

提案１０：提案９が合意可能である場合、ＲＡＮ２はページング機会の計算にＩＤを使用すべきではない。

【0250】

ＵＥをページングするＩＤに関しては、Ｃ－ＲＮＴＩはシナリオ１では使用されるが、シナリオ２では使用されない。したがって、特にシナリオ２では、「ページングメッセージで搬送されるＵＥＩＤを定義する」必要がある。（ａ）ＮＡＳ ＵＥ ＩＤ（すなわちＳ－ＴＭＳＩ）、（ｂ）リリース１３ＵＥレジュームＩＤ、（ｃ）新しいＲＡＮ ＵＥ ＩＤ又は（ｄ）ＩＭＳＩモードからＵＥＩＤを選択する。ライトコネクティッドがＣＮにできるだけ透過的である必要がある場合は、ＲＡＮで管理できるＩＤからＩＤを選択すべきである。したがって、候補は「（ｂ）リリース１３ＵＥレジュームＩＤ」又は「（ｃ）新しいＲＡＮ ＵＥ ＩＤ」である。レジュームＩＤは、ｅＮＢが「アンカーＮＢ」からＵＥコンテキストを取得するために使用されるが、レジュームＩＤの正確な内容はＵＥには見えない。つまり、ビットサイズのみが定義される。

【0251】

ＵＥは、ＥＣＧＩ（すなわち、「アンカーｅＮＢ」内のＣｅｌｌ Ｇｌｏｂａｌ Ｉｄ ＥＵＴＲＡ）及びＣ－ＲＮＴＩ（ＥＣＧＩを有するセルによって割り当てられた）からなるＩＤによって識別することができる。メッセージサイズを最小にするために、ＥＣＩ（すなわち、Ｃｅｌｌ Ｉｄｅｎｔｉｔｙ又は「ｅＮＢＩＤ＋ＰＣＩ」）又はＰＣＩ（すなわち、ＰｈｙｓＣｅｌｌＩｄ）のいずれかをＥＣＧＩの代わりに使用することも考えられる。これらの最適化では、ＩＤがＰＬＭＮ内で有効であると仮定すべきである。

【0252】

ＩＤの内容が明示的に指定されている場合、ＵＥは、ＲＲＣシグナリング（例えば、ＵＥがライトコネクティッドに入るときのＲＲＣ接続再設定又は解放）を介してＩＤが明示的に割り当てられていなくてもページングされたかどうかを判断するためにＵＥがそれを使用する。

【0253】

提案１１：ＲＡＮ２は、「ページングメッセージ」において、新たなＲＡＮ ＩＤとして「ＥＣＧＩ＋Ｃ－ＲＮＴＩ」、「ＥＣＩ＋Ｃ－ＲＮＴＩ」及び／又は「ＰＣＩ＋Ｃ－ＲＮＴＩ」を定義すべきである。

【0254】

提案１２：提案１１が合意可能である場合、ＵＥがライトコネクティッドに入ったときに、ＩＤは「アンカーｅＮＢ」内のセルから明示的に割り当てられる必要はない。

【0255】

（２．３．２．ＵＥベースのモビリティ）
ＲＡＮ２は、「ＲＲＣアイドルにおける同じセル再選択メカニズム、セル再選択ベースの移動性を実行する」に同意した。したがって、ＵＥの動作はセル再選択の点でアイドルモード手順に従い、ネットワーク内のすべてのｅＮＢがライトコネクティッドからＲＲＣコネクティッドへの復帰をサポートしている限り、ライトコネクティッドのＵＥにとって問題にはならない。ネットワーク実装に依存するが、リリース１３は、ネットワーク内のすべてのｅＮＢが新たな機能（ｅＤＲＸのためのｅＤＲＸ許可、ＶｏＬＴＥの確立のためのｖｏｉｃｅＳｅｒｖｉｃｅＣａｕｓｅＩｎｄｉｃａｔｉｏｎ、Ｕｐ－ＣＩｏＴ－ＥＰＳ－Ｏｐｔｉｍｉｚａｔｉｏｎ及びｃｐ－ＲＲＣ接続再開のためのＣＩｏＴ－ＥＰＳ最適化）をサポートすると想定しない。したがって、ネットワーク内のすべてのｅＮＢがライトコネクティッドをサポートしていると推測できるかどうかは議論の余地がある。

【0256】

提案１３：ＲＡＮ２は、ネットワーク内のすべてのｅＮＢがライトコネクティッドをサポートしていると推測できるかどうかについて議論すべきである。

【0257】

一部のｅＮＢがライトコネクティッドをサポートしていない場合、ＵＥはＲＡＮページングから到達不能になる可能性があるため、ＵＥがどのように動作すべきかが問題である。可能性の１つは、ＵＥがライトコネクティッドをサポートするセルに可能な限り優先度を付けることである。別の可能性は、ライトコネクティッドをサポートしていないセルを再選択するときに、ＵＥがＲＲＣアイドルに遷移することである。ＲＡＮ２は、ライトコネクティッド中のＵＥベースのモビリティの詳細を考慮すべきである。

【0258】

提案１４：１又は複数のｅＮＢがライトコネクティッドをサポートしていない場合、ＲＡＮ２は、ライトコネクティッド中のＵＥベースのモビリティの詳細、例えばセル再選択中にセルの優先度を解除すべきであるかどうか、及びＵＥがそのようなセルが再選択された場合にＲＲＣアイドルに遷移するべきかについて議論すべきである。

【0259】

（付記２）
１．ページングは、オプションとして、ＵＥごとにいくつかの優先度情報を含むことができる。

【0260】

Ａ）優先度情報は、以下であり得る。

【0261】

・ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの値。

【0262】

・このページングが優先呼（ＭＴボイスなど）用であることを識別する１ビットのフラグ。

【0263】

・番号がＭＴ呼の優先度を示す（例えば、セル再選択の絶対優先度のように、０～７）。

【0264】

・このページングに関連付けられたベアラＩＤ。

【0265】

Ｂ）優先度情報はリストとして形成され、リスト内の各エントリはページング内のＰａｇｉｎｇＲｅｃｏｒｄＬｉｓｔ内の対応するエントリを示す。

【0266】

・優先度情報は、既存のＰａｇｉｎｇＲｅｃｏｒｄ内に統合することができる。

【0267】

Ｃ）優先度情報は、ｅＮＢ（例えばｅＶｏＬＴＥ ＭＴビデオ呼の場合）又はＭＭＥ（例えば、Ｓ１ページングにおける既存のページング優先度ＩＥを介して）によって決定されてもよい。

【0268】

２．ページングにおいてページング優先度を受信すると、ＵＥは、
Ａ）これを使用して、ＲＲＣ接続要求（又はライトコネクティッドのためのもの）を開始するかどうかを決定する、すなわち、ＵＥ実装、又は、
Ｂ）優先度情報が優先度の高い呼を示す場合、ＲＲＣ接続要求（又はライトコネクティッドのためのもの）を開始する。

【0269】

・要求の確立原因は、優先度情報、例えば「優先されるＭＴ呼」と整合することができる。

【0270】

［相互参照］
本願は米国仮出願第６２／３９７４５３号（２０１６年９月２１日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】