[移動通信システム]
(移動通信システムの構成)
以下において、実施形態に係る移動通信システムの構成について説明する。図1は、実施形態に係る移動通信システムであるLTE(Long Term Evolution)システムの構成を示す図である。LTEシステムは、3GPP規格に基づく移動通信システムである。
図1に示すように、LTEシステムは、無線端末(UE:User Equipment)100、無線アクセスネットワーク(E−UTRAN:Evolved−UMTS Terrestrial Radio Access Network)10、及びコアネットワーク(EPC:Evolved Packet Core)20を備える。
UE100は、移動型の通信装置であり、自身が在圏するセル(サービングセル)を管理するeNB200との無線通信を行う。
E−UTRAN10は、基地局(eNB:evolved Node−B)200を含む。eNB200は、X2インターフェイスを介して相互に接続される。eNB200は、1又は複数のセルを管理しており、自セルとの接続を確立したUE100との無線通信を行う。eNB200は、無線リソース管理(RRM)機能、ユーザデータ(以下、単に「データ」という)のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる他に、UE100との無線通信を行う機能又はリソースを示す用語としても用いられる。
EPC20は、モビリティ管理エンティティ(MME)300C及びサービングゲートウェイ(S−GW)300Uを含む(図6等参照)。MME300Cは、UE100に対する各種モビリティ制御等を行う。MME300Cは、NAS(Non−Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するトラッキングエリア(TA)の情報を管理する。トラッキングエリアは、複数のセルからなるエリアである。S−GW300Uは、データの転送制御を行う。MME300C及びS−GW300Uは、S1インターフェイスを介してeNB200と接続される。
図2は、UE100(無線端末)の構成を示す図である。図2に示すように、UE100は、受信部110、送信部120、及び制御部130を備える。
受信部110は、制御部130の制御下で各種の受信を行う。受信部110は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部130に出力する。
送信部120は、制御部130の制御下で各種の送信を行う。送信部120は、アンテナ及び送信機を含む。送信機は、制御部130が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部130は、UE100における各種の制御を行う。制御部130は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うCPU(Central Processing Unit)と、を含んでもよい。プロセッサは、後述する処理を実行する。
図3は、eNB200(基地局)の構成を示す図である。図3に示すように、eNB200は、送信部210、受信部220、制御部230、及びバックホール通信部240を備える。
送信部210は、制御部230の制御下で各種の送信を行う。送信部210は、アンテナ及び送信機を含む。送信機は、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
受信部220は、制御部230の制御下で各種の受信を行う。受信部220は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。
制御部230は、eNB200における各種の制御を行う。制御部230は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うCPUと、を含んでもよい。プロセッサは、後述する処理を実行する。
バックホール通信部240は、X2インターフェイスを介して隣接eNBと接続され、S1インターフェイスを介してMME/S−GW300と接続される。バックホール通信部240は、X2インターフェイス上で行う通信及びS1インターフェイス上で行う通信等に用いられる。
なお、MME300Cは、制御部及びネットワーク通信部を有する。制御部は、MME300Cにおける各種の制御を行う。制御部は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行うベースバンドプロセッサと、メモリに記憶されるプログラムを実行して各種の処理を行うCPUと、を含んでもよい。プロセッサは、後述する処理を実行する。ネットワーク通信部は、S1インターフェイスを介してeNB200と接続される。ネットワーク通信部は、S1インターフェイス上で行う通信等に用いられる。
図4は、LTEシステムにおける無線インターフェイスのプロトコルスタックの構成を示す図である。図4に示すように、無線インターフェイスプロトコルは、OSI参照モデルの第1レイヤ乃至第3レイヤに区分されており、第1レイヤは物理(PHY)レイヤである。第2レイヤは、MAC(Medium Access Control)レイヤ、RLC(Radio Link Control)レイヤ、及びPDCP(Packet Data Convergence Protocol)レイヤを含む。第3レイヤは、RRC(Radio Resource Control)レイヤを含む。PHYレイヤ、MACレイヤ、RLCレイヤ、PDCPレイヤ、及びRRCレイヤは、AS(Access Stratum)レイヤを構成する。
PHYレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。UE100のPHYレイヤとeNB200のPHYレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
MACレイヤは、データの優先制御、ハイブリッドARQ(HARQ)による再送処理、及びランダムアクセスプロシージャ等を行う。UE100のMACレイヤとeNB200のMACレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。eNB200のMACレイヤは、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS))及びUE100への割当リソースブロックを決定するスケジューラを含む。
RLCレイヤは、MACレイヤ及びPHYレイヤの機能を利用してデータを受信側のRLCレイヤに伝送する。UE100のRLCレイヤとeNB200のRLCレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
PDCPレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
RRCレイヤは、制御情報を取り扱う制御プレーンでのみ定義される。UE100のRRCレイヤとeNB200のRRCレイヤとの間では、各種設定のためのRRCシグナリングが伝送される。RRCレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。UE100のRRCとeNB200のRRCとの間に接続(RRC接続)がある場合、UE100はRRCコネクティッドモードであり、そうでない場合、UE100はRRCアイドルモードである。
RRCレイヤの上位に位置するNASレイヤは、セッション管理及びモビリティ管理等を行う。UE100のNASレイヤとMME300CのNASレイヤとの間では、NASシグナリングが伝送される。なお、UE100は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等の機能を有する。
図5は、LTEシステムにおいて用いられる無線フレームの構成を示す図である。図5に示すように、無線フレームは、時間軸上で10個のサブフレームで構成される。各サブフレームは、時間軸上で2個のスロットで構成される。各サブフレームの長さは1msであり、各スロットの長さは0.5msである。各サブフレームは、周波数軸上で複数個のリソースブロック(RB)を含み、時間軸上で複数個のシンボルを含む。各リソースブロックは、周波数軸上で複数個のサブキャリアを含む。具体的には、12個のサブキャリア及び1つのスロットにより1つのRBが構成される。1つのシンボル及び1つのサブキャリアにより1つのリソースエレメント(RE)が構成される。また、UE100に割り当てられる無線リソース(時間・周波数リソース)のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム(又はスロット)により特定できる。
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル(PDCCH)として用いられる領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル(PDSCH)として用いることができる領域である。
eNB200は、基本的には、PDCCHを用いて下りリンク制御情報(DCI)をUE100に送信し、PDSCHを用いて下りリンクデータをUE100に送信する。PDCCHが搬送するDCIは、上りリンクスケジューリング情報、下りリンクスケジューリング情報、TPCコマンドを含む。上りリンクスケジューリング情報は上りリンク無線リソースの割当てに関するスケジューリング情報(UL grant)であり、下りリンクスケジューリング情報は、下りリンク無線リソースの割当てに関するスケジューリング情報である。TPCコマンドは、上りリンクの送信電力の増減を指示する情報である。eNB200は、DCIの送信先のUE100を識別するために、送信先のUE100の識別子(RNTI:Radio Network Temporary ID)でスクランブリングしたCRCビットをDCIに含める。各UE100は、自UE宛ての可能性があるDCIについて、自UEのRNTIでデスクランブリング後、CRCチェックをすることにより、PDCCHをブラインド復号(Blind decoding)し、自UE宛のDCIを検出する。PDSCHは、下りリンクスケジューリング情報が示す下りリンク無線リソース(リソースブロック)により下りリンクデータを搬送する。
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル(PUCCH)として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル(PUSCH)として用いることができる領域である。
UE100は、基本的には、PUCCHを用いて上りリンク制御情報(UCI)をeNB200に送信し、PUSCHを用いて上りリンクデータをeNB200に送信する。PUCCHが運搬するUCIは、CQI(Channel Quality Indicator)、PMI(Precoding Matrix Indicator)、RI(Rank Indicator)、スケジューリング要求(SR)、HARQ ACK/NACKを含む。CQIは、下りリンクのチャネル品質を示すインデックスであり、下りリンク伝送に用いるべきMCSの決定等に用いられる。PMIは、下りリンクの伝送のために用いることが望ましいプレコーダマトリックスを示すインデックスである。RIは、下りリンクの伝送に用いることが可能なレイヤ数(ストリーム数)を示すインデックスである。SRは、PUSCHリソースの割り当てを要求する情報である。HARQ ACK/NACKは、下りリンクデータを正しく受信したか否かを示す送達確認情報である。
(特定状態)
以下において、実施形態に係る特定状態について説明する。特定状態は、UE100用のS1接続が維持されつつUE100用のシグナリングが抑制される状態である。S1接続は、S1ベアラと称されてもよい。S1接続は、S1インターフェイス上でeNB200とEPC20との間に確立される接続である。S1インターフェイスは、ユーザプレーン用のS1−Uインターフェイスと制御プレーン用のS1−MMEインターフェイスとを含む。S1接続は、S1−Uインターフェイス上でeNB200とS−GW300Uとの間に確立されるS1−U接続と、S1−Cインターフェイス上でeNB200とMME300Cとの間に確立されるS1−MME接続と、を含んでもよい。
特定状態は、RRCコネクティッドモードの一状態又はRRCアイドルモードの一状態であってもよい。或いは、特定状態は、RRCアイドルモード及びRRCアイドルモードとは異なるRRC状態であってもよい。実施形態の動作パターン1において、特定状態は、RRCコネクティッドモードの一状態(substate)である。これに対し、実施形態の動作パターン2において、特定状態は、RRCコネクティッドモードの一状態(substate)である。特定状態によれば、一般的なRRCコネクティッドモードに比べてシグナリングが削減される。また、特定状態によれば、一般的なRRCアイドルモードに比べてUE100が迅速にデータ通信を開始することができる。以下において、特定状態を「Light Connected状態(Light Connected substate)」と称する。
図6は、Light Connected状態(特定状態)への遷移に係る動作の概要を示す図である。図6の初期状態において、UE100はRRCコネクティッドモードであり、UE100とeNB200との間にRRC接続(RRC Connection)が確立されている。また、eNB200とMME300Cとの間にS1−MME接続(S1−MME Connection)が確立されている。eNB200とS−GW300Uとの間にS1−U接続(S1−U Connection)が確立されている。UE100は、eNB200とのデータ通信を行う。
図6に示すように、ステップS1において、eNB200は、Light Connected状態への遷移を指示する遷移指示(Request to Light Conn.)をUE100に送信する。
ステップS2において、UE100は、遷移指示の受信に応じて、肯定応答(Ack)メッセージをeNB200に送信する。但し、ステップS2は必須ではなく、省略してもよい。
ステップS3において、UE100及びeNB200は、RRC接続を維持又は解放する。具体的には、実施形態の動作パターン1において、UE100及びeNB200は、RRC接続を維持する。これに対し、実施形態の動作パターン2において、UE100及びeNB200は、RRC接続を解放する。
ステップS4において、eNB200及びMME300Cは、S1−MME接続を維持する。ステップS5において、eNB200及びS−GW300Uは、S1−U接続を維持する。ステップS6において、UE100は、Light Connected状態に遷移し、eNB200とのデータ通信を中断する。
eNB200は、Light Connected状態に遷移したUE100のコンテキスト情報(UEコンテキスト)を破棄せずに維持する。UEコンテキストは、UE100に対する各種の設定及び能力等に関する情報を含む。各種の設定は、AS(Access Stratum)の設定を含む。
Light Connected状態にあるUE100は、維持されているS1接続及びUEコンテキストを活用して、少ないシグナリングでeNB200とのデータ通信を再開することができる。
第1のeNB200のセルにおいてLight Connected状態に遷移したUE100は、第1のeNB200のセルから第2のeNB200のセルに移動してもよい。第2のeNB200のセルにおいてUE100がデータ通信を再開する場合、第2のeNB200は、UE100のUEコンテキストを第1のeNB200からX2インターフェイス上で取得し、取得したUEコンテキストをUE100とのデータ通信に利用してもよい。
実施形態において、Light Connected状態にあるUE100には、RANページングが適用される。RANページングは、E−UTRAN10(eNB200)によりページングが制御される所定ページングエリア単位でページングを行う。所定ページングエリアは、トラッキングエリアよりも狭いエリアである。所定ページングエリアを導入することにより、1のUE100に対してページングを行うセルの数を削減することができるため、シグナリングを削減することができる。以下において、このような所定ページングエリアを「RANページングエリア」と称する。
一例として、RANページングエリア(所定ページングエリア)は、Light Connected状態にあるUE100のS1接続を維持する特定のeNB200のセルと当該特定のeNB200の周辺のeNB200のセルとにより構成される。周辺のeNB200は、特定のeNB200とのX2インターフェイスを有するeNB200であってもよい。特定のeNB200は、Light Connected状態にあるUE100宛てのデータ又はNASシグナリングをMME/S−GW300から受信すると、RANページングを行うと判断し、周辺のeNB200と共にUE100のページングを行う。当該ページングは、RRCページングメッセージを送信することにより行われてもよいし、UE100宛てのデータをページングメッセージとして送信することにより行われてもよい。当該特定のeNB200は、アンカーeNBと称されてもよい。
(動作パターン1)
以下において、実施形態の動作パターン1について説明する。
動作パターン1において、RRCコネクティッドモードにあるUE100は、RRC接続の設定変更を指示するメッセージをeNB200から受信し、当該メッセージの受信に応じて設定変更を行う。一例として、当該メッセージは、RRC Connection Reconfigurationメッセージである。他の例として、当該メッセージは、RRC Connection Reconfigurationメッセージとは異なるメッセージである。動作パターン1において、当該メッセージがRRC Connection Reconfigurationメッセージであるケースを想定する。eNB200は、RRC Connection ReconfigurationメッセージをUE100に送信することによりUE100のRRC設定を変更させる。
eNB200は、Light Connected状態への遷移を指示する情報をRRC Connection Reconfigurationメッセージに含めることにより、UE100をLight Connected状態に遷移させる。UE100は、Light Connected状態への遷移を指示する情報がRRC Connection Reconfigurationメッセージに含まれることに応じて、Light Connected状態に遷移する。動作パターン1において、Light Connected状態は、RRC接続を維持しつつ、UE100の複数の機能のうちeNB200とのシグナリングを発生させる少なくとも1つの機能が非活性化された状態である。
ここで、複数の機能(features)は、データ(ユーザデータ)の送受信機能、スケジューリング要求(SR)の送信機能、チャネル状態情報(CSI)の送信(すなわち、CSIフィードバック)機能、サウンディング参照信号(SRS)の送信機能、キャリアアグリゲーション機能、デュアルコネクティビティ機能、セミパーシステントスケジューリング(SPS)機能、WLANアグリゲーション機能、無線リンク監視(RLM)機能、通知(In−device Coexistence Indication UE Assistance information、MBMS Interest Indicaiton、Sidelink UE Informaiton等)機能、アイドルモード間欠受信(DRX)機能、ブロードキャストシグナリングを用いるWLANインターワーキング機能を含んでもよい。但し、Light Connected状態において、セル再選択機能、コネクティッドモードDRX機能、専用シグナリングを用いるWLANインターワーキング機能のうち少なくとも1つは、非活性化されずに活性化状態を維持してもよい。これらの機能の詳細については、例えば3GPP技術仕様書「TS36.300 V13.4.0」を参照されたい。
図7は、実施形態の動作パターン1を示す図である。図7の初期状態において、UE100は、RRCコネクティッドモードにあり、eNB200とのデータ通信を行っている。なお、図7において破線で示す処理は必須ではなく省略可能な処理である。
図7に示すように、ステップS101において、UE100は、eNB200とのデータ通信の中断を検知する。
データ通信の中断とは、下りリンク(DL)データを受信していない(又は受信する見込みがない)場合、及び/又は上りリンク(UL)データを送信していない(又はする見込みがない)場合であってもよい。ここで、見込みとは、ある一定期間においてデータが発生しないと予測される状態であってもよい。当該一定期間は、eNB200から設定されてもよい。eNB200からUE100に対する設定は、RRCシグナリングにより行われる。RRCシグナリングは、UE個別シグナリング(例えば、RRC Connection Reconfigurationメッセージ)であってもよいし、ブロードキャストシグナリング(例えば、システム情報ブロック(SIB))であってもよい。
一例として、UE100のRRCレイヤは、RRCレイヤよりも上位のレイヤ(例えば、アプリケーションレイヤ)の情報に基づいて、eNB200とのデータ通信の中断を検知する。一例として、UE100のRRCレイヤは、現在最も通信の頻度が高いアプリケーションがシャットダウンしたことに応じて、データ通信の中断を検知してもよい。他の例として、UE100のRRCレイヤは、オペレーションシステム(OS)が通信規制を行ったこと、フォアグラウンドで動作するアプリケーションが無くなったこと(すなわち、バックグラウンド処理のみになったこと)、OSがデータ通信中断状態と判断したことに応じて、データ通信の中断を検知してもよい。
ステップS102において、UE100は、データ通信の中断を示す通知をeNB200に送信する。UE100は、RRCレイヤのシグナリングにより当該通知を送信してもよい。RRCレイヤのシグナリングは、UE Assistance Informationメッセージであってもよいし、他のメッセージであってもよい。データ通信の中断を示す通知がUE Assistance Informationメッセージ中で送信される場合、当該通知は、Extended Power Preference Indicator(Extended PPI)と称されてもよい。
ステップS103において、eNB200は、データ通信の中断を示す通知の受信に応じて、UE100をLight Connected状態に遷移させることを決定する。
ステップS104において、eNB200は、Light Connected状態への遷移を指示する情報を含むRRC Connection Reconfigurationメッセージ(又は他のメッセージ)をUE100に送信する。言い換えると、eNB200は、Light Connected状態への遷移指示を、RRC接続の設定変更として送信する。
Light Connected状態への遷移を指示する情報は、例えば「Light Connected=Setup」である。また、RRC Connection Reconfigurationメッセージは、上述した複数の機能のうち非活性化させる機能を指定する情報を含んでもよい。一例として、eNB200は、非活性化する機能を個別に指定するために、活性維持機能のリスト又は非活性化機能のリストをRRC Connection Reconfigurationメッセージに含める。
ステップS105において、UE100は、Light Connected状態への遷移を指示する情報を含むRRC Connection Reconfigurationメッセージの受信に応じて、上述した複数の機能(features)のうち所定の機能を非活性化(deactivate)する。UE100は、非活性化させる機能がRRC Connection Reconfigurationメッセージにより指定された場合、指定された機能のみを非活性化させる。
ステップS106において、UE100は、所定の機能を非活性化させても、当該所定の機能の設定情報(AS Context)を保持する。言い換えると、UE100は、Light Connected状態に遷移する場合でも、非活性化させる機能の設定情報を破棄せずに維持する。
ステップS107において、UE100は、Light Connected状態に遷移する。動作パターン1において、Light Connected状態は、RRCコネクティッドモードの一状態(substate)である。Light Connected状態にあるUE100は、RANページングエリア内で送信されるページングメッセージを受信するための処理を行う。
その後、ステップS108において、Light Connected状態にあるUE100は、UE100における所定のイベントを検知する。所定のイベントは、eNB200からページングメッセージを受信したこと、eNB200に送信するULデータが発生したこと、の何れかである。所定のイベントは、ULデータが発生し、かつ、当該ULデータの量が閾値以上であることであってもよい。当該閾値はeNB200からUE100に設定されていてもよい。
ステップS109において、Light Connected状態にあるUE100は、所定のイベントを検知したことに応じて、非活性化された機能の活性化を要求する活性化要求(RRC Activation Request)をeNB200に送信する。
活性化要求は、非活性機能の全部の活性化を要求するものであってもよいし、非活性機能の一部の機能の活性化を要求するものであってもよい。非活性機能の全部の活性化を要求する場合、活性化要求は、Light Connected状態の中止要求(すなわち、通常のRRC Connectedモードへの遷移要求)であってもよい。これに対し、非活性機能の全部の活性化を要求する場合、活性化要求は、活性化する機能のリストを含んでもよいし、非活性状態を維持させる機能のリストを含んでもよい。
ステップS110において、eNB200は、活性化要求の受信に応じて、当該要求の受け入れ可否を判断する。ここでは、eNB200が当該要求を受け入れ可と判断したと仮定して説明を進める。なお、eNB200が当該要求を受け入れ不可と判断した場合、eNB200は、否定応答(Nack)又は拒否通知(Reject)をUE100に送信してもよい。
ステップS111において、eNB200は、活性化要求に対する肯定応答(RRC Activation Acknowledge)をUE100に送信する。なお、eNB200は、活性化要求を受け入れるか否かを機能ごとに判断してもよい。この場合、eNB200は、活性化を許可する機能のリスト及び/又は活性化を拒否する機能のリストを肯定応答(RRC Activation Acknowledge)に含めてもよい。或いは、当該肯定応答に代えて、RRC Connection Reconfigurationメッセージを用いてもよい。
ステップS112において、UE100は、eNB200から受信した応答の内容に基づいて、非活性化された機能を活性化させるか否かを判断する。UE100は、肯定応答を受信した場合に、許可された機能を活性化する。UE100は、肯定応答を受信した時点(サブフレーム)から当該機能を活性化する。或いは、UE100は、肯定応答を受信した後、ある一定期間内(例えば8サブフレーム以内)に当該機能を活性化してもよい。
(動作パターン2)
以下において、実施形態の動作パターン2について、動作パターン1との相違点を主として説明する。
動作パターン2において、RRCコネクティッドモードにあるUE100は、RRC接続の解放を指示するRRC接続解放(RRC Connection Release)メッセージをeNB200から受信し、RRC接続解放メッセージの受信に応じてRRC接続を解放する。RRC接続解放メッセージは、RRC接続を解放する理由を示すフィールド(Release Cause)を含む。UE100は、Light Connected状態への遷移を指示する情報(例えばRRC−LightConnected)がフィールドに含まれることに応じて、Light Connected状態に遷移する。eNB200は、Light Connected状態への遷移を指示する情報を当該フィールドに含めることにより、UE100をLight Connected状態に遷移させる。もしくは、当該Light Connected状態は、ネットワーク(つまり、eNBとMME/S−GW)における一状態であってもよい。この場合、UE100のRRC状態はアイドルとなる。但し、eNB200は、コンテキスト(設定情報)をUEに保持させてもよい。この場合、eNB200は、RRC Connection ReleaseのRelease Causeをrrc−Suspendに設定し、これに対応する識別子であるResume ID(resumeIdentity)をUE100に通知する。当該状態を、RRC接続がサスペンドされた状態と称してもよい。
動作パターン2において、Light Connected状態は、RRC接続が解放された状態であって、かつ、UE100用のS1接続がeNB200とコアネットワーク(EPC20)との間に維持される状態である。動作パターン2において、Light Connected状態は、さらに、上述した複数の機能のうち少なくとも一部が非活性化された状態であってもよい。
図8は、実施形態の動作パターン2を示す図である。以下において、図7に示す動作パターン1との相違点を主として説明し、重複する説明を省略する。
図8に示すように、ステップS201乃至S203は、動作パターン1と同様である。
ステップS204において、eNB200は、Light Connected状態への遷移を指示する情報をRelease Causeとして含むRRC Connection ReleaseメッセージをUE100に送信する。RRC Connection Releaseメッセージは、上述した複数の機能のうち非活性化させる機能を指定する情報を含んでもよい。この場合、非活性化させる機能の取り扱いについては動作パターン1と同様である。RRC Connection Releaseメッセージは、復旧用識別子(Resume ID)を含んでもよい。eNB200は、UEコンテキストを復旧用識別子と関連付けて保持する。
ステップS205において、UE100は、Light Connected状態への遷移を指示する情報をRelease Causeとして含むRRC Connection Releaseメッセージの受信に応じて、eNB200とのRRC接続を解放する。
ステップS206において、UE100は、Light Connected状態に遷移する。動作パターン2において、Light Connected状態は、RRCアイドルモードの一状態(substate)である。Light Connected状態にあるUE100は、RANページングエリア内で送信されるページングメッセージを受信するための処理を行う。
その後、ステップS207において、Light Connected状態にあるUE100は、UE100における所定のイベントを検知する。
ステップS208において、Light Connected状態にあるUE100は、所定のイベントを検知したことに応じて、RRC接続の復旧を要求するRRC接続復旧要求(RRC Connection Resume Request)をeNB200に送信する。RRC Connection Resume Requestは、非活性機能の活性化を要求する情報を含んでもよい。RRC Connection Resume Requestは、復旧用識別子を含んでもよい。
ステップS209において、eNB200は、RRC接続復旧要求の受信に応じて、当該要求の受け入れ可否を判断する。ここでは、eNB200が当該要求を受け入れ可と判断したと仮定して説明を進める。
ステップS210において、eNB200は、RRC接続復旧(RRC Connection Resume)メッセージをUE100に送信する。eNB200は、活性化を許可する機能のリスト及び/又は活性化を拒否する機能のリストをRRC接続復旧メッセージに含めてもよい。
ステップS211において、UE100は、eNB200から受信したRRC接続復旧メッセージに基づいて、RRC接続を復旧させる。なお、eNB200は、復旧用識別子に基づいてUEコンテキストの使用を再開する。
(移動状態情報)
動作パターン1及び2において、データ通信の中断を示す通知は、UE100の移動速度に関する移動状態情報を含んでもよい。eNB200は、UE100の移動速度に関する移動状態情報をUE100から受信し、移動状態情報に基づいて、UE100に対応するRANページングエリアの範囲を決定する。
或いは、UE100は、以下の何れかのタイミングで移動状態情報をeNB200に送信してもよい。
第1に、UE100は、トラッキングエリア又はRANページングエリアの更新をトリガとして移動状態情報を送信する。この場合、UE100は、トラッキングエリア更新メッセージ又はRANページングエリア更新メッセージに移動状態情報を含めてもよい。
第2に、UE100は、セルリセレクションをトリガとして移動状態情報を送信する。この場合、UE100は、セル更新メッセージに移動状態情報を含めてもよい。
第3に、UE100は、eNB200からの問い合わせをトリガとして移動状態情報を送信する。
第4に、UE100は、移動状態情報を周期的に送信する。当該周期は、eNB200からUE100に設定されてもよい。
図9は、RANページングエリアを決定するための動作を示す図である。
図9に示すように、ステップS301において、UE100は、移動状態情報(Mobility Status Information)を生成する。移動状態情報は、以下の情報の少なくとも1つを含む。
1)ある一定時間内のハンドオーバ回数又はセルリセレクション回数。一定時間は、eNB200からUE100に設定されてもよい。
2)ある一定時間内の平均移動速度。移動速度は、UE100の位置情報から得ることができる。直接的な移動速度の値(例えば、xxx km/h)に限らず、移動速度のインデックス(例えばHigh/Mid/Low)であってもよい。一定時間は、eNB200からUE100に設定されてもよい。
3)移動速度が閾値を超えたか否かを示す1ビット識別子。ここで、移動速度としては、上記の1)又は2)を利用できる。閾値は、eNB200からUE100に設定されてもよい。
4)UE100のセル履歴情報。セル履歴情報は、セルのIDと当該セルでの滞在時間との組み合わせを複数含む。
ステップS302において、UE100は、移動状態情報を含むメッセージをeNB200に送信する。UE100は、さらに自身の位置情報をメッセージに含めてもよい。UE100は、さらに自身のカテゴリ(UEカテゴリ)をメッセージに含めてもよい。
ステップS303において、eNB200は、移動状態情報に基づいて、RANページングエリアの範囲を決定する。eNB200は、決定したRANページングエリアに属するセル(及びeNB)のリストをMME300Cに通知してもよい。
一例として、eNB200は、移動速度が速いUE100に対しては、ページングの取り逃しを防止する為に、広めのRANページングエリアを設定する。これに対し、移動速度が遅いUE100に対しては、ページングメッセージによるシグナリング数を削減する為に、狭めのRANページングエリアを設定する。
他の例として、eNB200は、カテゴリM1のUE100に対しては、省電力化の為に、広めのRANページングエリアを設定する。カテゴリM1とは、マシンタイプ通信向けのUEカテゴリであり、省電力動作が必要とされるものである。これにより、RANページングエリアを出る際に必要なRANページングエリア更新メッセージを削減することができる。
[第1実施形態]
以下において、上述したLTEシステムを前提として、第1実施形態について説明する。第1実施形態は、Light Connected状態におけるモビリティに関する実施形態である。
ここで、Light Connected状態におけるモビリティの基本的な動作について説明する。
・Light Connected状態にあるUE100のS1接続は、「アンカーeNB」に維持され、アクティブである。アンカーeNBは、UE100をLight Connected状態に遷移させたeNB200であってもよい。UE100が他のRANページングエリアに移動する場合、アンカーeNBが切り替えられてもよい。
・Light Connected状態にあるUE100に対しては、RAN(E−UTRAN10)始動でページング(RANページング)を行うことができる。RANページングは、アンカーeNBにより始動されてもよい。
・ページング処理(RANページング)は、アンカーeNBにより制御される。
・RANページングエリアは、UE固有に設定することができる。
・Light Connected状態にあるUE100は、RRCアイドルモードと同様なセル再選択メカニズムを実行する。
・Light Connected状態にあるUE100のコンテキスト情報(UE ASコンテキスト)は、当該UE及びアンカーeNBの両方で保持される。
・Light Connected状態は、ネットワークの観点からは、ECM(EPS Connection Management)コネクティッド状態である。ECMは、UE100とコアネットワーク(MME300C)との間の接続状態を示す。
・Light Connected状態にあるUE100がページングを検知した場合又はデータ送信を開始する場合には、当該UE100は、eNB200との接続を復旧する。もしくは、UE100はRRCコネクティッドモードへ遷移してもよい。
・UE100は、RRCシグナリングによりLight Connected状態に遷移する。
・UE固有のRANページングエリアは、専用シグナリング又はブロードキャストシグナリングによりeNB200からUE100に設定される。RANページングエリアは、セルのリスト又はページングエリアIDにより指定される。
・Light Connected状態にあるUE100は、設定されたRANページングエリアの外に移動したときにネットワークに通知する。
・RANページングエリアは、1又は複数のセルにより構成される。当該複数のセルは、異なるeNBにより管理されていてもよい。
・Light Connected状態にあるUE100は、RRCアイドルモードのDRX動作と同様なパラメータを用いてDRX動作を行う。ページング機会を決定するためのパラメータは、UEのID(例えば、IMSI、S−TMSI、Resume ID等)を含み得る。
第1実施形態に係るeNB200は、移動通信システムのRANに含まれるeNB200である。eNB200は、Light Connected状態にあるUE100から、RANページングエリアを出たことを示すメッセージを受信する受信部220と、当該メッセージの受信に応じて、RANページングエリアの更新に関するページングエリア情報をMME300C(モビリティ管理エンティティ)に送信する送信部(バックホール通信部240)と、を備える。Light Connected状態は、RANページングエリア内のアンカーeNBがUE100用のS1接続を維持する状態であって、RANページングエリアがUE100に設定された状態である。
第1実施形態に係るeNB200において、送信部(バックホール通信部240)は、ページングエリア情報を含む切り替え要求メッセージをMME300Cに送信してもよい。切り替え要求メッセージは、S1接続を自eNB200に切り替えることを要求するためのメッセージである。
また、ページングエリア情報は、UE100のための新たなRANページングエリアを示す情報を含んでもよい。新たなRANページングエリアは、自eNB200のエリア(セル)を含む。
図10は、第1実施形態に係る動作例を示す図である。図10の初期状態において、UE100は、RRCコネクティッドモードにある(S1001)。また、UE100とコアネットワーク(MME300C)との間の接続状態はECM Connectedであり、eNB200とMME300Cとの間にUE100用のS1接続(S1−MME接続)が存在する。なお、図示を省略しているが、eNB200とS−GW300Uとの間にUE100用のS1接続(S1−U接続)も存在する。
図10に示すように、ステップS1003において、アンカーeNB200−1は、Light Connected状態への遷移を指示する遷移指示(Light Connection Instruction)をUE100に送信する。上述したように、遷移指示は、RRC Connection Reconfigurationメッセージ又はRRC Connection Releaseメッセージ中で送信される。アンカーeNB200−1は、UE100に固有のRANページングエリアをUE100に設定してもよい。
ステップS1004において、UE100は、アンカーeNB200−1のセル(サービングセル)からの遷移指示の受信に応じて、Light Connected状態に遷移する。
ステップS1005において、UE100は、例えばRANページングエリア外のeNB200−2が送信するセル識別子又はページングエリアID等に基づいて、自身に設定されたRANページングエリアの外に出たことを検知する。なお、eNB200−2は、アンカーeNB200−1との間にX2インターフェイスを有していなくてもよい。
ステップS1006において、UE100は、自身に設定されたRANページングエリアの外に出たことを示すメッセージをeNB200−2に送信する。当該メッセージは、RANページングエリアの更新を示すメッセージ(Paging Area Update)であってもよい。当該メッセージは、Light Connected状態から復旧することを要求するメッセージ(RRC Connection Boot request)であってもよい。当該メッセージは、RRC Connection Resume Requestメッセージであってもよい。
当該メッセージは、Resume ID、Short Resume MAC−I、Resume Causeを含んでもよい。
或いは、Resume IDに代えて、セル識別子(セルID)及びC−RNTI(Cell−Radio. Network Temporary Identifier)の組み合わせからなる識別子を用いてもよい。セルIDは、ECGI(E−UTRAN Cell Global Identifier)、ECI(E−UTRAN Cell Identifier)、又はPCI(Physical Cell Identifier)であってもよい。セルID及び/又はC−RNTIは、Light Connectedへ遷移するための指示(例えばRRC Connection Release)で明示的に与えられなくてもよい。UE100は、当該Light Connectedへの遷移指示を受信した場合、当該セルのセルIDと現在割り当てられているC−RNTIを保存してもよい。UE100は、Resumeする時は、この値を読み出し、eNB200に通知する。
ECGIはECIとPLMN IDとの組み合わせからなる。すなわち、ECIは、PLMN IDを有しない。よって、セル識別子としてECIを用いる場合、当該組み合わせからなる識別子は同一PLMN(Public Land Mobile Network)内でのみ有効であってもよい。
セル識別子としてPCIを用いる場合、eNB200は、UE100から受信したPCIと、自身が有する隣接セルリスト(Neighbor Relation Table)とを用いて、前記特定のeNB(アンカーeNB)を発見してもよい。
前記どの組み合わせからなる識別子をUE100が通知すべきかは、eNB200から指定されてもよい。例えば、eNB200はECIとC−RNTIとの組み合わせからなる識別子を通知するようにSIBで報知する。もしくは、eNB200は、UE100個別に設定してもよい。
また、図では省略しているが、ECI、PCIを用いた場合でも、eNB200は、前記特定のeNB(アンカーeNB)を特定できるため、eNB200は当該特定のeNBからUEコンテキスト(設定情報)をX2若しくはS1インターフェイスを用いて取得することができる。
図では省略しているが、当該組み合わせからなる識別子は、ページングにおいて、呼び出しUEを特定する為に用いてもよい。UE100は、ページングメッセージを受信した場合に、当該識別子を読みだして、ページングメッセージ中の識別子と一致する場合には自身が呼び出されていると判定する。この場合、UE100は、RRC接続を確立する動作(例えばRRC Connection Requestの送信)を開始してもよい。
また、Resume Causeに代えて、Light Connectedからの復旧に関するBoot Causeを用いてもよい。或いは、Resume Causeとして、Light Connectedからの復旧に関するLightConnected−Access等の新たな値が定義されてもよい。
ステップS1007において、eNB200−2は、UE100からのメッセージの受信に応じて、S1接続をeNB200−2に切り替えることを要求するためのメッセージ(S1 Path Switch Request)をS1インターフェイス上でMME300Cに送信する。メッセージ(S1 Path Switch Request)は、パス切替を行うE−RABのID・アドレス、ソースMME UE S1AP ID、セルID等を含む。eNB200−2は、UE100のための新たなRANページングエリアを示すページング情報(PA info.)をメッセージ(Path Switch Request)に含める。ページング情報(PA info.)は、新たなRANページングエリアに含まれるセルのリスト(Recommended Cell List)であってもよい。
ステップS1008において、MME300Cは、eNB200−2から受信したメッセージ(Path Switch Request)に基づいて、UE100の新たなRANページングエリアを把握又は決定する。すなわち、MME300Cは、ページング情報(PA info.)に基づいて、UE100が在圏するRANページングエリアを管理することができる。また、MME300Cは、UE100のためのS1接続をアンカーeNB200−1からeNB200−2に切り替える処理を行う。
なお、本シーケンスは、アンカーeNB200−1とeNB200−2との間にX2インターフェイスが存在しないことを想定している。しかしながら、アンカーeNB200−1とeNB200−2との間にX2インターフェイスが存在する場合、eNB200−2は、UE100からのメッセージの受信に応じて、UE Context Release又はUE Context RetrieveをX2インターフェイス上でアンカーeNB200−1に送信してもよい。UE Context Releaseは、UE100のコンテキスト情報の解放を要求するためのメッセージである。UE Context Retrieveは、UE100のコンテキスト情報を取得するためのメッセージである。eNB200−2は、これらのメッセージにページング情報(PA info.)を含めてもよい。アンカーeNB200−1は、eNB200−2から受信したページング情報(PA info.)をMME300Cに転送してもよい。
[第2実施形態]
以下において、第2実施形態について、第1実施形態との相違点を主として説明する。第2実施形態は、eNB200がRANページングを行う動作に関する実施形態である。
第2実施形態に係るeNB200は、Light Connected状態にあるUE100に対してRANページングを行い、RANページングが成功したか否かを判断する制御部230と、RANページングの失敗に応じて、RANページングの失敗を示す失敗通知をMME300Cに送信する送信部(バックホール通信部240)と、を備える。RANページングは、RANページングエリア単位でRANがUE100のページングを行う動作である。失敗通知は、UE100が在圏するトラッキングエリアに基づくページングをMME300Cに実行させるためのメッセージであってもよい。よって、RANページングが失敗した場合でも、MME300Cが通常のページングを実行することができる。
第2実施形態に係るeNB200は、RANページングエリア内の他のeNB200がページングに成功したか否かに関する情報を当該他のeNB200から受信する受信部(バックホール通信部240)を備えてもよい。制御部230は、自eNB200及び他のeNB200の両方でページングに失敗したことに応じて、RANページングが失敗したと判断する。
図11は、第2実施形態に係る動作例を示す図である。図11において、アンカーeNB200−1及びeNB200−2は、同一のRANページングエリアに属する。アンカーeNB200−1及びeNB200−2は、X2インターフェイスを介して接続されていてもよい。図11の初期状態において、UE100は、RRCコネクティッドモードにある(S2001、S2002)。なお、図11において、破線で示す動作は必須ではない。
図11に示すように、ステップS2003及びS2004の動作は第1実施形態と同様である。
ステップS2005において、アンカーeNB200−1は、UE100用のS1接続を介して、UE100宛てのデータ(DL data)をS−GW300Uから受信する。アンカーeNB200−1は、当該データの受信に応じて、UE100のページングを開始すると判断する。
ステップS2006において、アンカーeNB200−1は、UE100のページング(RANページング)の実施を要求するページング要求(Paging Request)をeNB200−2に送信する。ページング要求は、ページングタイミングを特定するための情報を含んでもよい(第3実施形態参照)。
ステップS2007において、アンカーeNB200−1は、ページングを開始すると判断した際に、又はページング要求を送信した際に、タイマを開始させる。アンカーeNB200−1は、UE100からページング応答を受信した際に、又はeNB200−2からページング成功通知を受信した際に、タイマを停止させてもよい。
ステップS2008において、アンカーeNB200−1及びeNB200−2は、UE100に設定されたRANページングエリア内で、UE100宛てのページングメッセージ(Ran paging)を送信する。ここでは、UE100がページングメッセージ(Ran paging)の受信に失敗したと仮定して説明を進める。
ステップS2009において、eNB200−2は、UE100のページング(RANページング)に失敗したことを示す失敗通知(Paging Failure)をアンカーeNB200−1に送信する。
ステップS2010において、アンカーeNB200−1は、タイマが満了したか否か、及び/又は失敗通知(Paging Failure)を受信したか否かを判断する。ここでは、タイマが満了した、及び/又は失敗通知(Paging Failure)を受信したと仮定して、説明を進める。
ステップS2011において、アンカーeNB200−1は、RANページングの失敗を示す失敗通知(RAN Paging Failure)をS1インターフェイス上でMME300Cに送信する。失敗通知(RAN Paging Failure)は、当該UE100をMME300Cが識別するための識別子(例えば、eNB UE S1AP ID)を含む。失敗通知(RAN Paging Failure)は、MME UE S1AP ID、Cause(例えばRAN Paging Failed)等を含んでもよい。なお、失敗通知(RAN Paging Failure)に代えて、ページングの実施を要求するページング要求(Paging Request)を用いてもよい。
ステップS2012において、MME300Cは、アンカーeNB200−1からの失敗通知(RAN Paging Failure)の受信に応じて、UE100が在圏するトラッキングエリアに属する各eNB200にページングメッセージ(PAGING)を送信する。UE100が在圏するトラッキングエリアに属する各eNB200は、当該ページングメッセージを自セル内に送信する。但し、MME300Cは、UE100が在圏するトラッキングエリアに属する全てのeNB200にページングメッセージを送信することに変えて、当該トラッキングエリアに属する一部のeNB200にのみページングメッセージを送信してもよい。
ステップS2013において、UE100は、ページングメッセージ(PAGING)の受信に応じて、Light Connected状態から復旧することを要求するメッセージ(RRC Connection Boot request)をeNB200(例えばアンカーeNB200−1)に送信する。
[第3実施形態]
以下において、第3実施形態について、第1及び第2実施形態との相違点を主として説明する。第3実施形態は、Light Connected状態にあるUE100のDRX動作に関する実施形態である。
まず、一般的なアイドルモードDRX動作について説明する。消費電力を削減するために、間欠受信(DRX:Discontinuous Reception)がUE100に設定され得る。DRX動作において、RRCアイドルモードのUE100は、所定の時間間隔(DRXサイクル)で発生するページング受信機会(Paging Occasion)においてページングメッセージを監視する。DRX動作において、UE100は、ページングを受信するためにPDCCHを間欠的に監視する。UE100は、ページング用の識別子(P−RNTI:Paging Radio Network Temporary Identifier)を用いてPDCCHをデコードし、ページングチャネルの割り当て情報を取得する。UE100は、割当情報に基づいて、ページングメッセージを取得する。UE100におけるPDCCH監視タイミングは、UE100の識別子(IMSI:International Mobile Subscriber Identity)に基づいて定められる。DRX動作におけるPDCCH監視タイミング(PDCCH監視サブフレーム)は、Paging Occasion(PO)と称される。POは、ページングの受信機会に相当する。
UE100及びeNB200は、Paging Occasion(PO)、及び、Paging Occasionを含みうる無線フレームであるPaging Frame(PF)を下記のように計算する。
PFのシステムフレーム番号(SFN)は、下記の式(1)から求められる。
SFN mod T = (T div N) * (UE_ID mod N) …(1)
但し、Tは、ページングを監視するためのUE100のDRXサイクルであり、無線フレームの数で表される。また、Tは、eNB200がSIB(System Information Block)によりブロードキャストするデフォルトDRX値、及びNASメッセージによりUE100に設定されるUE固有DRX値のうち、何れか小さい方である。なお、UE固有DRX値が設定されていない場合、UE100は、デフォルトDRX値を適用する。また、Nは、TとnBのうち最小値である。nBは、4T, 2T, T, T/2, T/4, T/8, T/16, T/32から選択される値である。UE_IDは、「IMSI mod1024」により求められる値である。
このようにして求められたPFのうち、下記の式(2)により、インデックスi_sを求め、インデックスi_sに対応するPOのサブフレーム番号を求める。
i_s = floor(UE_ID/N) mod Ns …(2)
但し、Nsは、1とnB/Tのうち最大値である。
次に、第3実施形態に係る動作について説明する。図12は、第3実施形態に係る動作を示す図である。
第3実施形態の動作パターン1に係るUE100は、Light Connected状態に遷移するよう指示する遷移指示をサービングセルから受信する受信部110と、サービングセルにおいてLight Connected状態に遷移し、RRCコネクティッドモードのDRX動作を行う制御部130と、を備える。すなわち、図12(a)に示すように、UE100は、Light Connected状態に遷移した時点のサービングセルに在圏する間は、RRCコネクティッドモードのDRX動作を継続する。図12(b)に示すように、UE100の制御部130は、RANページングエリア内で当該サービングセルから他のセルにUE100が移動したことに応じて、RRCコネクティッドモードのDRX動作を中止する。UE100の制御部130は、RRCコネクティッドモードのDRX動作を中止するとともに、RRCアイドルモードのDRX動作に基づく動作を開始する。RRCアイドルモードのDRX動作に基づく動作とは、RRCアイドルモードのDRX動作におけるページングフレーム(PF)及びページング機会(PO)の計算式又はこれを流用した計算式によりPF及びPOを決定する動作である。図12(c)に示すように、UE100の制御部130は、異なるRANページングエリアに移動した際に通知を行う。
或いは、第3実施形態の動作パターン2に係るUE100は、Light Connected状態に遷移した時点のサービングセルから他のセルに移動しても、当該他のセルが同一RANページングエリアに属するのであれば、RRCコネクティッドモードのDRX動作を継続する。この場合、図12(a)及び(b)に示すように、UE100は、同一RANページングエリア内でRRCコネクティッドモードのDRX動作を継続することができる。すなわち、UE100は、他のセルに移動しても、コネクティッドモードDRXに準じて受信動作を行う。後述するように、ページング要求において、コネクティッドモードDRXの設定値(DRX Config)がeNB200−2に転送されてもよい。
ここで、このような動作をeNB200単位で行なってもよい。すなわち、第3実施形態の動作パターン1及び2において、「サービングセル」を「サービングeNB」又は「アンカーeNB」と読み替え、「他のセル」を「他のeNB」と読み替えてもよい。
第3実施形態の動作パターン1及び2において、アンカーeNB以外のUE100はUE100のコンテキスト情報を保持しているとは限らない。よって、同一RANページングエリア内の他のeNBは、ページングのタイミングを決定するための情報をアンカーeNBから取得することが望ましい。
第3実施形態に係るeNB200−2(図11参照)は、Light Connected状態にあるUE100に対してRANページングを行う制御部230を備える。制御部230は、RANページングのためのページングメッセージをUE100に送信するタイミングを決定するための情報をアンカーeNB200−1(図11参照)から取得する。当該タイミングを決定するための情報は、UE100の識別情報(例えば、IMSI、S−TMSI、Resume ID等)及びRRCコネクティッドモードのDRX設定のうち少なくとも一方を含む。アンカーeNB200−1は、このような情報をページング要求(Paging Request)に含めてeNB200−2に送信してもよい(図11のステップS2006参照)。
第3実施形態において、ページングのタイミングを決定するための識別情報は、ECGI(E−UTRAN Cell Global Identifier)及びC−RNTI(Cell−Radio. Network Temporary Identifier)であってもよい。アンカーeNB200−1は、UE100をLight Connected状態に遷移させる際に、当該識別情報をUE100に割り当ててもよい。
[第4実施形態]
以下において、第4実施形態について、第1乃至第3実施形態との相違点を主として説明する。第4実施形態は、UE100をLight Connected状態に遷移させるためのメッセージに関する実施形態である。
図13は、第4実施形態の動作パターン1を示す図である。第4実施形態の動作パターン1において、UE100は、RRC Connection Reconfigurationメッセージをサービングセルから受信する受信部110と、Light Connected状態に遷移するよう指示する遷移指示がRRC Connection Reconfigurationメッセージに含まれないことに応じて、RRC Connection Reconfigurationメッセージに対する応答メッセージであるRRC Connection Reconfiguration Completeメッセージをサービングセルに送信する送信部120と、遷移指示がRRC Connection Reconfigurationメッセージに含まれることに応じて、RRC Connection Reconfiguration Completeメッセージの送信を中止する制御部130と、を備える。ここで、遷移指示は、Light Connectionに関連する設定情報であってもよい。動作パターン1によれば、UE100は、RRC Connection ReconfigurationにおいてLight ConnectionがSetupされた場合は、RRC Connection Reconfiguration Completeメッセージを送信しない。これにより、シグナリングを削減することができる。
図14は、第4実施形態の動作パターン2を示す図である。第4実施形態の動作パターン2において、UE100は、RRC Connection Releaseメッセージをサービングセルから受信する受信部110と、Light Connected状態に遷移するよう指示する遷移指示がRRC Connection Releaseメッセージに含まれないことに応じて、RRC Connection Releaseメッセージに対する応答メッセージの送信を中止する制御部130と、遷移指示がRRC Connection Releaseメッセージに含まれることに応じて、応答メッセージであるRRC Connection Release Completeメッセージをサービングセルに送信する送信部120と、を備える。ここで、遷移指示は、Light Connectionに関連する設定情報であってもよい。UE100の制御部130は、RRC Connection Release Completeメッセージが送達されたことを例えばHARQ ACKに基づいて確認できた際に、Light Connected状態へ遷移する。動作パターン2によれば、UE100は、RRC Connection ReleaseにおいてLight Connected状態への遷移が指示された場合は、RRC Connection Release Completeメッセージを送信する。これにより、eNB200は、UE100がLight Connected状態に遷移したことをより確実に確認することができる。
[第5実施形態]
以下において、第5実施形態について、第1乃至第4実施形態との相違点を主として説明する。第5実施形態は、UE100がLight Connected状態から復旧するためのメッセージに関する実施形態である。
第5実施形態に係るUE100は、Light Connected状態から復旧することを示す情報をサービングセルに送信する送信部120と、サービングセルからRRC Connection Reconfigurationメッセージを受信することなく、Light Connected状態から復旧する制御部130と、を備える。Light Connected状態から復旧することを示す情報とは、例えば、上述したRRC Activation Request、RRC Connection Resume Request、RRC Connection Boot request等である。
図15は、第5実施形態に係る動作例を示す図である。
図15(a)に示すように、従来のアプローチ(Legacy approach)によれば、Light Connected状態にあるUE100は、Light Connected状態から復旧するための要求(Request)をeNB200に送信する。次に、UE100は、eNB200からRRC Connection Reconfigurationメッセージを受信し、RRC Connection Reconfiguration CompleteメッセージをeNB200に送信することにより、Light Connected状態から復旧する(RRCコネクティッドモードに遷移する)。
図15(b)に示すように、第5実施形態の第1のアプローチ(One−step approach)によれば、Light Connected状態にあるUE100は、Light Connected状態から復旧することを示す通知(Indication)をeNB200に送信するのみで、Light Connected状態から復旧する(RRCコネクティッドモードに遷移する)。通知(Indication)は、無線リソースの割り当てを要求する情報(スケジューリング要求)及び/又は上りリンクのバッファ状態を報告する情報(バッファ状態報告)を含んでもよい。UE100は、通知(Indication)が送達されたことをHARQ ACK等に基づいて確認できない場合には、Light Connected状態を維持するか、又はRRCアイドルモードに遷移してもよい。
図15(c)に示すように、第5実施形態の第2のアプローチ(Two−step approach)によれば、Light Connected状態にあるUE100は、Light Connected状態から復旧するための要求(Request)をeNB200に送信し、当該要求に対する肯定応答(Acknowledge)をeNB200から受信するのみで、Light Connected状態から復旧する(RRCコネクティッドモードに遷移する)。要求(Request)は、無線リソースの割り当てを要求する情報(スケジューリング要求)及び/又は上りリンクのバッファ状態を報告する情報(バッファ状態報告)を含んでもよい。eNB200は、要求(Request)に対して否定応答をUE100に送信してもよい。UE100は、否定応答を受信した場合、Light Connected状態を維持するか、又はRRCアイドルモードに遷移してもよい。Light Connected状態を維持するか又はRRCアイドルモードに遷移するかは、当該否定応答で指定されてもよい。
よって、第5実施形態によれば、従来のアプローチに比べてシグナリングを削減することができる。RRC Connection Reconfigurationが不要な理由としては次の理由が挙げられる。具体的には、Light Connected状態はRRCコネクティッドモードに類似する状態であると仮定すると、eNB200が新たにリソースを準備する必要がない(すなわち、拒否する理由が無い)。また、UEが新たに設定を適用する必要がない(すなわち、設定失敗が無い)。さらに、RRC状態遷移がなく、eNB200とUE100とが認識を合わせなくてもよい。例えば、UE100がRRCコネクティッドモードのDRXに従って動作していれば、Light Connected状態でもRRCコネクティッドモードでもUE100の受信タイミングは同じである為、データ通信ができない状態にはならない。
但し、UE100は、Light Connected状態に遷移した時点のセルに在圏する場合のみ第5実施形態に係る動作を行なってもよい。UE100は、Light Connected状態に遷移した時点のセルから同一RANページングエリア内の他のセルに移動した場合には、従来のアプローチに係る動作を行なってもよい。
第5実施形態に係る通知(Indication)及び要求(Request)は、ランダムアクセスプロシージャ中にeNB200に送信されてもよい。一例として、通知(Indication)及び要求(Request)は、ランダムアクセスプロシージャのMsg1(ランダムアクセスプリアンブル/PRACH送信)又はMsg3(scheduled transmission)中でUE100からeNB200に送信されてもよい。また、肯定応答(Acknowledge)又は否定応答は、ランダムアクセスプロシージャのMsg2(ランダムアクセス応答)又はMsg4(contention resolution)中でeNB200からUE100に送信されてもよい。
[第6実施形態]
以下において、第6実施形態について、第1乃至第5実施形態との相違点を主として説明する。第6実施形態は、データ通信の中断を示す通知(Extended PPI)に関する実施形態である。
上述したように、UE100は、データ通信が発生していない(又は発生する見込みが無い)場合に通知(Extended PPI)をeNB200に送信していた。これに対し、第6実施形態では、通知(Extended PPI)を以下のように改良する。
第6実施形態に係るUE100は、サービングセル(eNB200)とのデータ通信の中断を検知する制御部130と、データ通信の中断(Data inactive)を検知したことに応じて、データ通信の中断を示す通知(Extended PPI)をサービングセルに送信する送信部120と、を備える。制御部130は、データ通信の中断の予想時間を推定する。送信部120は、当該予想時間を含む通知(Extended PPI)を送信する。
UE100(制御部130)は、上述と同様にアプリケーションレイヤからの情報によってデータ通信の中断時間を予想してもよい。具体的には、アプリケーションレイヤから通知された時間がそのまま予想時間になってもよい。或いは、アプリケーションレイヤからどのアプリケーションが起動していて、どのアプリケーションがシャットダウンされたのかというような情報や、現在ユーザが操作を行っているか否か(もしくはフォアグラウンド通信が想定されるか、バックグラウンド通信のみが想定されるか)などの情報を用いてUE100(AS側)で予想してもよいです。AS(Access Stratum)は、RRC層以下の各プロトコルからなる。例えば、AS側でトラフィック発生パターンを事前に収拾しておき、アプリケーションレイヤからの情報等も必要に応じて使いながら、トラフィック予測を行い、予測時間を推定する。
第6実施形態において、通知(Extended PPI)は、Light Connected状態に入りたい旨の直接的な通知又はLight Connected状態に入ることが可能である旨の直接的な通知であってもよい。
第6実施形態において、eNB200は、通知(Extended PPI)を送信してよいか否かをUE100に明示的又は暗示的に設定できてもよい。例えば、UE100は、SIBで通知(Extended PPI)の送信を許可する旨の識別子を報知している場合、又はeNB200が通知(Extended PPI)の送信を設定(setup)している場合には、UE100は、通知(Extended PPI)の送信が許可されていると判断する。また、通知(Extended PPI)が、1)過去の状態によって判定される(すなわち、データが発生していない)、2)未来の予想によって判定される(すなわち、発生する見込みが無い)、3)過去及び未来の両方を含めて判定されるかは、eNB200からUE100に設定されてもよい。さらに、通知(Extended PPI)のprohibit timer値及び/又はレポート周期などがeNB200からUE100に設定されてもよい。prohibit timerは、UE100が通知(Extended PPI)を送信した後に次の通知(Extended PPI)の送信を可能とするまでの時間を規定するタイマである。
第6実施形態において、通知(Extended PPI)は、Light Connection用DRXの推奨サイクル又は希望するDRXサイクルを含んでもよい。UE100(制御部130)は、当該DRXサイクル希望値を、上述したデータ通信の中断の予想時間に基づいて判断してもよい。具体的には、UE100は、自身の状況に基づいて適切なDRXサイクルを判断し、当該DRXサイクルを通知(Extended PPI)中で送信する。UE100は、当該通知を行った時点で、通知したDRXサイクルを適用してもよい。或いは、UE100は、eNB200による応答(RRC接続再構成など)によってDRXサイクルを設定されてもよい。当該通知を行ってDRXサイクルを適用する場合は、当該適用をもってLight Connectedに遷移したとみなされてもよい。
なお、eNB200は、Light Connectedに遷移するまでのタイマ値をUE100に設定(例えばブロードキャスト又はユニキャスト)してもよい。UE100は、データ通信が行われた時に当該タイマをリセット(再スタート)し、当該タイマが満了した場合にLight Connectedに遷移する。UE100は、当該タイマが動作している間において、データ通信が中断された場合(例えば前記予想時間がタイマ満了よりも後となる場合)に、eNB200に対してデータ中断を通知してもよい。
[第7実施形態]
以下において、第7実施形態について、第1乃至第6実施形態との相違点を主として説明する。第7実施形態は、Light Connected状態にあるUE100のセル再選択動作に関する実施形態である。
第7実施形態に係るUE100は、Light Connected状態においてセル再選択動作を行う制御部130を備える。制御部130は、当該セル再選択動作において、Light Connected状態からの復旧をサポートするセルをUE100のサービングセルとして優先的に選択する。
一般的なセル再選択動作は、セルが属する周波数の優先度及びセルの無線品質に基づくランキングにより、適切なセルを選択する動作である。
第7実施形態に係るセル再選択動作おいて、UE100(制御部130)は、Light Connectedをサポートするセルを最高優先度(Highest priority)としてもよい。UE100(制御部130)は、Light Connectedをサポートしないセルを最低優先度(Lowest priority)としてもよい。ここで、Highest/Lowestとは、eNB200からブロードキャストされている優先度(CellReselectionPriority:0〜7)又は当該優先度とサブ優先度(CellReselectionSubPriority:0.2、0.4、0.6、0.8)を加算した値よりも、高い/低い優先度(例えば、“8”、“−1”)を意味する。
或いは、第7実施形態に係るセル再選択動作おいて、UE100(制御部130)は、ランキングにオフセットを導入することにより、Light Connectedをサポートするセルを優先してもよい。例えば、Light Connectedをサポートするセルにはプラスのオフセットを加算する、及び/又はLight Connectedをサポートしないセルにはマイナスのオフセットを加算する。当該オフセット値は、予め定義された値でもよく、eNB200から設定された値であってもよい。eNB200から設定される場合、eNB200は、当該オフセット値をブロードキャストしてもよいし、UE個別に専用シグナリングにより当該オフセット値を設定してもよい。
第7実施形態において、eNB200は、Light Connected状態からの復旧をサポートするセルの優先制御を行うか否かをUE100に設定してもよい。当該設定は、Light Connected状態に遷移する時に設定されてもよい。当該設定は、RRC Connection Reconfiguration又はRRC Connection Releaseに含まれていてもよい。
各eNB200(各セル)は、Light Connected状態(具体的には、Light Connected状態からの復旧)をサポートしているか否かを示す情報をブロードキャストしていてもよい。一例として、eNB200は、当該情報をSIBにより送信する。このような情報は、暗示的な情報であってもよい。例えば、UE100は、RANページングエリアの識別子を送信しているセルをLight Connected状態をサポートしているセルとみなしてもよい。
第7実施形態において、UE100は、Light Connected状態からの復旧をサポートし、かつ所定の無線品質基準(例えばS criterion)を満たすセルが検出されないことに応じて、RRCアイドルモードに遷移してもよい。一例として、UE100は、S criterionを満たすセルがlegacyセル(すなわち、Light Connected状態をサポートしていないセル)だけであった場合などにおいて、RRCアイドルモードに遷移してもよい。
[その他の実施形態]
上述した各実施形態を別個独立に実施する場合に限らず、2以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の動作を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の動作を他の実施形態の一部の動作と置換してもよい。
上述した実施形態において、MBMS(Multimedia Broadcast Multicast Service)をUE100が受信する又は受信に興味を持つケースについて特に触れなかった。しかしながら、eNB200は、UE100におけるMBMS(Multimedia Broadcast Multicast Service)の受信状況等に基づいて、UE100をLight Connectedに遷移させるか否かを判断してもよい。一例として、Light Connected状態においてSC−PTM(Single−cell Point−to−Multipoint)受信が実施されない場合(例えば、SC−PTM受信が許可されない場合、UE能力が不足している場合など)には、eNB200は、UE100をLight Connectedに遷移させない。他の例として、MBMS Interest IndicationにおいてMBMSサービス受信(例えばSC−PTM受信)への興味が示されていた時は、eNB200は、UE100をLight Connectedに遷移させない。また、一部のUE100は、RRC Connected状態でMBMSを受信できない。当該UE100がLight ConnectedでのMBMS受信が可能である場合、eNB200は、MBMSサービス受信(例えばSC−PTM受信)への興味を当該UE100が示すことに応じて、当該UE100をLight Connectedに遷移させてもよい。
また、上述した第1実施形態において、セルID及びC−RNTIの組み合わせからなる識別子をページングメッセージに含める一例を説明した。
ところで、優先度が高いMTデータ(UE100における着呼)が発生した場合においても、現在のページングでは当該状況を示す手段がない。よって、MBMS受信(例えばSC−PTM受信)を優先しているUE100に対してページングが発生した場合、MBMS受信を継続するか、MBMS受信を中断してRRC接続を優先するかを適切に判断できない虞がある。
よって、ページングメッセージに優先度情報を付与することによって、適切な判断ができるようにする。当該優先度情報は、Establishment Causeの値(例えば、high priority access)でもよく、優先度の高い着呼である事を示す識別子でもよく、優先度を示す数値(例えば、0〜7)でもよく、当該着呼に紐付いたベアラ識別子でもよい。また、当該優先度情報は、リストによって提供されてもよく、当該リストの各エントリは、ページングメッセージ内のUE識別子のリスト(Paging Record List)の各エントリと対応していてもよい。もしくは、当該優先度情報は、前記Paging Record Listのエントリ(すなわちPaging Record)に組み込まれていてもよい。当該優先度情報は、eNB200が決定してもよく、MME300Cが決定してもよい。
当該優先度情報を含んだページングメッセージを受信したUE100は、当該優先度情報を用いてRRC接続開始処理(例えば、RRC Connection Request送信)の要否を決定する。当該RRC接続処理を開始する場合、当該RRC接続処理のメッセージにおいて、優先度情報に基づく処理である旨(例えば、“prioritized MT call”)をeNB200に通知してもよく、当該通知はEstablishment Causeに含まれてもよい。
一方で、UE100は、優先度情報を含んだページングよりも、MBMS受信を優先する場合、当該ページングに対して応答を行わなくてもよい。
上述した各実施形態において、所定のイベントの発生を契機としてLight Connected状態を終了させる一例を説明した。Light Connected状態は、eNB200からUE100に設定されたタイマが動作中である期間にのみ有効であってもよい。この場合、所定のイベントは、タイマの満了であってもよい。或いは、Light Connected状態は、UE100が所定周波数内に存在する期間にのみ有効であってもよい。例えば、あるセルにおいてLight Connected状態の指示を受けたUE100は、当該セルが属する周波数とは異なる周波数のセルに移動したことに応じてLight Connected状態を終了してもよい。
上述した各実施形態において、移動通信システムとしてLTEシステムを例示した。しかしながら、本発明はLTEシステムに限定されない。LTEシステム以外のシステムに本発明を適用してもよい。
(付記1)
(1.はじめに)
RAN2#95はライトコネクティッドの基本的な機能/特性を以下のように合意した。
合意事項:
ライトコネクティッドUEの機能は以下を含む。
−S1接続は、「アンカーeNB」内で維持されアクティブである。
−RANがページングを開始することのサポート。
−ページングプロセスは、「アンカーNB」によって制御される。
−eNB制御のRANベースのページング領域。
−RANベースのページングエリア更新メカニズム。RANベースのページング領域は、UE固有のものとして構成可能であり得る。
−RRCアイドルにおけるものと同じセル再選択メカニズムである、セル再選択ベースの移動性を実行する。
−UEのASコンテキストは、UEと「アンカーeNB」側の両方に保持される。
−ECM状態は、ネットワークの観点から、ECMコネクティッドである。UEの観点からの状態は更なる検討が必要である。
−(ライトコネクティッド)UEが(RAN開始ページングを介して)ページングされるか又は任意のMOデータ/シグナリングがトリガされると、UEはeNBに接続するように戻る。関連する手順は更なる検討が必要である。
−UEは、RRCシグナリングによって「軽度に接続」される。詳細は更なる検討が必要である。
この付記では、ライトコネクティッドの詳細について説明する。
(2.検討)
(2.1.モデリングの原則)
(2.1.1.RRC状態とサブ状態)
LTEは、2つのRRC状態、すなわち、RRCコネクティッド及びRRCアイドルを有する。RRC接続Suspend/Resume手順がリリース13に導入された場合でも、2つの状態のモデリングが維持された。RRC接続を中断しているUEは、状態の観点から、すなわち、ASコンテキスト及び再開ID(resume ID)を記憶しているアイドルUEの「サブ状態」であるから、RRCアイドルにある。2つの状態のモデリングは、レガシーシステムでは少し複雑な状態遷移とこれらの状態を単純化するためにうまく機能する。したがって、RAN2は、ライトコネクティッドが導入されてもRRCモデリングに固執すべきである。つまり、RRCコネクティッド又はアイドルの一部であるライトコネクティッド「サブ状態」として定義すべきであり、RAN2によって決定される所望の動作に応じて特定の機能が追加又は制限される。
提案1:RAN2は、ライトコネクティッドがRRCで定義されている場合、既存の2つの状態モデリング、すなわち、RRCコネクティッド及びアイドルに固執すべきである。
(2.1.2.ベースライン状態)
提案1が合意可能であれば、ライトコネクティッド「サブ状態」はRRCコネクティッド又はRRCアイドル上に構築される。
RAN2#95では、RRC Suspended/Resumeがライトコネクティッドのベースラインであることが示唆された。ライトコネクティッドは、UEの視点からのRRC接続を中断する機能と、CNの観点からS1接続をアクティブに維持する新しい機能を組み合わせたものである。UEコンテキストの中断/再開の要求/応答を排除するS1には依然として有益であるが、リリース13手順に依存しているため、Uuでは、リリース13と比較してリリース14ではシグナリング及び遅延の削減という点で利益が得られない。さらに、NWとライトコネクティッドのUEとの間でECM状態の不一致が生じ得る。すなわち、ネットワークの観点からECM状態がECMコネクティッドであるが、RRC接続がサスペンド中はUEがRRCアイドルであるため、UEの観点からはECMアイドルである。ミスマッチが他のWGに受け入れられるかどうかは不明である。
考察1:RRCサスペンドベースのライトコネクティッドは、Uuのシグナリング/レイテンシの削減に関して何の利得もないことがあり得る。
考察2:NWとライトコネクティッドのUE間のECM状態のミスマッチが許容可能かどうかは不明である。
一方、RRCコネクティッドに基づく手法も提案されている。RRCコネクティッドの最大のメリットは、MO呼とMT呼のアクセスレイテンシが低いことである。潜在的に、MT呼にはページングは必要ないが、ライトコネクティッドのための「RANによって開始されたページングのサポート」を導入することはすでに合意されている。さらに、ECM状態は、NWとUEとの間で自然に合わせられる。したがって、RRCコネクティッドベースのライトコネクティッドは、Uuのシグナリングとレイテンシを向上させる可能性がある。これは、上位レイヤ、つまりNASに不必要な影響を与えることはない。しかしながら、UEをレガシーRRCコネクティッドに保つだけで、UEの電力消費が明らかに悪い。すなわち、「解決策は、UEの電力消費をRRCアイドルの電力消費と同等にすることができる」という目的を達成できない。したがって、RRCコネクティッドベースのライトコネクティッドが必要な場合は、いくつかの最適化が必要になる。
考察3:RRCコネクティッドベースのライトコネクティッドは、UEの電力消費を最小限に抑えるために標準化の取り組みがRAN2で必要となるが、Uuのシグナリングオーバーヘッドとアクセスレイテンシを上位レイヤへの不要な影響なしに改善する可能性がある。
WIの目標の最初のステートメントは、この作業項目の目的は、無線及びネットワークインタフェースのシグナリングオーバーヘッドを削減し、すべてのデバイスタイプのUEアクセス待ち時間及びUEの消費電力を改善することであり、すべてのデバイスタイプ、すなわちMTC UEだけでなく、スマートフォンのような通常のLTE UEも考慮すべきである。MTCタイプのトラフィックに関しては、リリース13のRRC接続Suspend/Resumeによって既に最適化されていたが、もちろん通常のLTE UEにも適用できる。したがって、リリース14作業は、むしろスマートフォントラフィックなどの通常のLTE UEに焦点を当てるべきである。
考察4:ライトコネクティッドは、リリース13で既に最適化されているMTCタイプのトラフィックだけでなく、リリース14の主な課題であるスマートフォンのような通常のLTEトラフィックに対しても効率的でなければならない。
上記の考察、すなわちECM状態のミスマッチ、さらにスマートフォントラフィックのシグナリング/レイテンシ及びアダプテーションの最適化を考慮すると、RAN2はライトコネクティッド「サブステート」のベースラインとしてRRCコネクティッド状態をとる必要がある。
提案2:RAN2は、RRCコネクティッド状態をライトコネクティッドのベースラインとして使用すべきである。
(2.2.RRCシグナリング)
(2.2.1.ライトコネクティッドへの移行)
RAN2#95は、「UEはRRCシグナリングによって「ライトコネクティッド」に入ることに同意した。詳細は更なる検討が必要である。提案2が合理的である場合、RRC接続中断のためのRRC接続解放がRRCアイドルにUEを移行させるので、ライトコネクティッドの設定にRRC接続再設定メッセージを使用することは素直である。
提案3:RAN2は、ライトコネクティッドの設定にRRC接続再設定メッセージを使用すべきである。
しかし、RRC接続再設定メッセージの1つの欠点は、RRC接続解放では必要ないが、RRC接続再設定完了でハンドシェイクを実行することである。シグナリング低減の観点から、UEは、RRC接続再設定完了を送信しないことが好ましい。しかしながら、RRC接続解放メッセージの場合のような肯定応答がなければ、サービングセルとUEとの間の状態ミスマッチの確率が増加するであろう。対照的に、RRCコネクティッドベースのライトコネクティッドが既にRRC接続状態のサブ状態である場合、状態遷移の不一致を伴う問題は重大な懸念事項ではない。したがって、RAN2は、UEライトコネクティッドに移行する際に、RRC接続再設定完了が必要であるか否かについて議論すべきである。
提案4:RAN2は、UEがライトコネクティッドに移行する際に、UEからの確認応答、例えばRRC接続再設定完了が必要であるか否かについて議論すべきである。
ライトコネクティッドへの自律的な移行を許可するかどうか検討する価値もある。サービングセルは、ブロードキャスト/専用シグナリングを介してUEに「非活動(inactivity)」タイマを設定し、タイマが終了すると自律的に「ライトコネクティッド」に進むことができる。Uuのライトコネクティッド制御のオーバーヘッドをさらに減らすことができる。
提案5:RAN2は、さらなるシグナリング削減のために、例えば、「非活動タイマ」を用いて自律的にライトコネクティッドに入ることを可能にするか否かについて議論すべきである。
(2.2.2.ライトコネクティッドから離れる)
「ライトコネクティッド」UEが(RAN開始ページングを介して)ページングされるか、又は任意のMOデータ/シグナリングがトリガされると、UEはeNBに接続されるように戻ることに同意された。関連する手順は更なる検討が必要である。したがって、ライトコネクティッドからRRCコネクティッドに戻る方法を検討する価値がある。
従来のアプローチでは、RRC接続を得るためのハンドシェイクには、(1)RRC接続再開要求、(2)RRC接続再開、(3)RRC接続再開完了の3つのステップが必要である。(図15の(b)及び(c))。一方、ハンドシェイクが最小化されると、シグナリング及びレイテンシが減少する可能性がある(図15の(b)及び(c))。
例えば、図15の(b)のようなUEからの指示を伴うワンステップアプローチは、シグナリング及びレイテンシを最小にするのに有益である。提案4で議論された状態ミスマッチ問題に関しては、メッセージの到達可能性の観点から、UEの無線問題に起因してDLだけが問題になる(すなわち、T310実行中の受信エラーはUEだけで見え、サービングセルは見えない)。したがって、ワンステップアプローチは技術的に実現可能である。
提案2が合理的である場合、すなわちRRCコネクティッドベースの「サブ状態」である場合、サービングセルは、図15の(c)のように、RRCコネクティッドに戻るUEを拒否すべきであるかどうかを考慮することができる。ライトコネクティッドのUEはすでにRRCコネクティッドの一部であるため、拒否メッセージを送信する必要は無いと思われる。何らかの理由でRRC接続の数を減らす必要がある場合、サービングセルは、いつでもRRC接続解放を開始することができる。
したがって、ワンステップアプローチを我々は好むが、RAN2はライトコネクティッドからRRCコネクティッドへの復帰中にシグナリングを最適化するかどうかについて議論すべきである。
提案6:RAN2はライトコネクティッドからRRCコネクティッドへの復帰のためのハンドシェイクを最小限にすることを考慮すべきである。
(2.2.3.RRCコネクティッド中の非アクティブの認識)
UEはRRCシグナリングによってライトコネクティッドに入っているため、サービングセルは、ライトコネクティッドに入るタイミングを決定すべきである。実現可能な実装の1つは、サービングセルがトラフィックの挙動を監視し、UEのパケットがある期間にわたって送受信されないときにUEがライトコネクティッドに入ることである。予測されるトラフィックの挙動に依存するので、予測が正確でない場合、シグナリングのオーバーヘッドが実際に増加する可能性がある。例えば、ライトコネクティッドとRRCコネクティッドの間の頻繁な切り替え、又はライトコネクティッドへの移行が失敗する。MTCタイプのトラフィックはやや容易に予測されるが、LTEタイプのトラフィック、スマートフォンのトラフィック行動は、NWが予測するのは容易ではないかもしれない。したがって、UEは、そのトラフィック挙動のより良い知識/制御を有するので、UEが何らかの支援情報を提供することが必要な場合がある。したがって、サービングセルが、ライトコネクティッドをトリガするためのアシスト情報を提供するようにUEを設定するかどうかを検討する価値がある。
提案7:RAN2は、RRCシグナリングでUEをライトコネクティッドに入るように決定するために、支援情報を提供するようにサービングセルがUEを設定することができるかどうか議論すべきである。
提案7が合意可能である場合、支援情報は、既存のPower Preference Indicator(PPI)及び/又はMBMS Interest Indication(MII)といくつかの類似点を有する可能性がある。PPIを用いる場合、UEは、その消費電力が、例えば、より長いDRXサイクルによって最適化されることが好ましい場合、低電力消費を通知することができる。MIIは、例えば、周波数へのハンドオーバが優先される場合に、ユニキャストとMBMSとの間の関心のあるMBMS周波数及び優先度を通知するために使用される。この場合、UEは、サービングセルにライトコネクティッドに入る可能性を通知することができる。換言すれば、UEは、データ送信/受信が一定期間中に既に非アクティブである又は非アクティブになる場合に、支援情報を送信することができる。追加の支援の詳細及び必要性は更なる検討が必要であり、例えば、UEが予想する非アクティブ時間である。
提案8:RAN2は、UEがデータ非活性時に支援情報を送信すべきかどうか検討すべきである。
(2.3.ライトコネクティッド中のアクティビティ)
(2.3.1.ページング監視)
RAN2#95は、RANによって開始されるページングをサポートすることで合意しているため、UEは、RANによって開始されるページングにリリース13レガシーPO/PF計算が使用されるベースラインとして決定されたサブフレームでライトコネクティッド中に監視すべきである。
一方、図12に示すように、UEがUEの移動性に関連するRRCコネクティッドに戻るとき、3つのシナリオを考慮することができる。
シナリオ1:UEは、ライトコネクティッドに入った場所と同じセルに留まる。
このシナリオは、スマートフォンの場合を想定すると、頻繁に起こる。ライトコネクティッドがRRCコネクティッドの一部、すなわち提案2である場合、C−RNTIは依然としてアクティブで有効であり、UEをページングするためにまだ再利用することができる。したがって、UEは、既存のコネクティッドモードDRX(C−DRX)によって決定された機会でページングを監視することができる。
シナリオ2:UEは、ライトコネクティッドに入った同じRANページングエリア(PA)内の異なるセルにある。
異なるセルでは、C−RNTIはセル固有のIDであるため、もはや有効ではない。したがって、UEをページングするために、(a)NAS UE ID(すなわちS−TMSI)、(b)リリース13のUEレジュームID、(c)新しいRAN UE ID、又は(d)(d)IMSIモードなどの他のIDが必要であり得る。しかしながら、「ページング機会」は、DRX−Configが、例えば「X2ページング」内でターゲットセルに転送される場合、C−DRXによって依然として決定される。
シナリオ3:UEはRANページングエリアの外部にあり、そこでライトコネクティッドに入る。
この場合、ライトコネクティッドUEがネットワークに通知ることが必要とされる。UEは、通知が送信されるセル内でライトコネクティッドに入るように指示されてもよい。したがって、このシナリオはシナリオ1と同じ条件であり、これ以上考慮する必要はない。
ライトコネクティッドにおけるUEのページング機会に関しては、UEの移動性を考慮に入れても、C−DRXメカニズムを再利用することができる。このアプローチでは、RAN2の観点からは、リリース13レガシーPO/PF計算がRANで開始されたページングに使用されるベースラインとされるが、このアプローチでは仕様の影響は予見されない。PO/PF計算のための入力パラメータは、必要に応じて変更することができることは、いくつかの影響と複雑さを意味する。したがって、RAN2はPF/PO計算のベースラインを再利用すべきである。
提案9:RAN2は、ページング機会のために、既存のコネクティッドモードDRXメカニズムを再利用することを決定すべきである。
提案9が合意可能である場合、「ページング計算のためのUEIDを定義する、例えば(a)NAS UE ID(すなわちS−TMSI)、(b)リリース13のUEレジュームID、(c)新しいRANUEID又は(d)IMSIモード」という合意事項はもはや必要でない。C−DRXは、OnDurationを計算するためにIDを入力する必要がないためである。
提案10:提案9が合意可能である場合、RAN2はページング機会の計算にIDを使用すべきではない。
UEをページングするIDに関しては、C−RNTIはシナリオ1では使用されるが、シナリオ2では使用されない。したがって、特にシナリオ2では、「ページングメッセージで搬送されるUEIDを定義する」必要がある。(a)NAS UE ID(すなわちS−TMSI)、(b)リリース13UEレジュームID、(c)新しいRAN UE ID又は(d)IMSIモードからUEIDを選択する。ライトコネクティッドがCNにできるだけ透過的である必要がある場合は、RANで管理できるIDからIDを選択すべきである。したがって、候補は「(b)リリース13UEレジュームID」又は「(c)新しいRAN UE ID」である。レジュームIDは、eNBが「アンカーNB」からUEコンテキストを取得するために使用されるが、レジュームIDの正確な内容はUEには見えない。つまり、ビットサイズのみが定義される。
UEは、ECGI(すなわち、「アンカーeNB」内のCell Global Id EUTRA)及びC−RNTI(ECGIを有するセルによって割り当てられた)からなるIDによって識別することができる。メッセージサイズを最小にするために、ECI(すなわち、Cell Identity又は「eNBID+PCI」)又はPCI(すなわち、PhysCellId)のいずれかをECGIの代わりに使用することも考えられる。これらの最適化では、IDがPLMN内で有効であると仮定すべきである。
IDの内容が明示的に指定されている場合、UEは、RRCシグナリング(例えば、UEがライトコネクティッドに入るときのRRC接続再設定又は解放)を介してIDが明示的に割り当てられていなくてもページングされたかどうかを判断するためにUEがそれを使用する。
提案11:RAN2は、「ページングメッセージ」において、新たなRAN IDとして「ECGI+C−RNTI」、「ECI+C−RNTI」及び/又は「PCI+C−RNTI」を定義すべきである。
提案12:提案11が合意可能である場合、UEがライトコネクティッドに入ったときに、IDは「アンカーeNB」内のセルから明示的に割り当てられる必要はない。
(2.3.2.UEベースのモビリティ)
RAN2は、「RRCアイドルにおける同じセル再選択メカニズム、セル再選択ベースの移動性を実行する」に同意した。したがって、UEの動作はセル再選択の点でアイドルモード手順に従い、ネットワーク内のすべてのeNBがライトコネクティッドからRRCコネクティッドへの復帰をサポートしている限り、ライトコネクティッドのUEにとって問題にはならない。ネットワーク実装に依存するが、リリース13は、ネットワーク内のすべてのeNBが新たな機能(eDRXのためのeDRX許可、VoLTEの確立のためのvoiceServiceCauseIndication、Up−CIoT−EPS−Optimization及びcp−RRC接続再開のためのCIoT−EPS最適化)をサポートすると想定しない。したがって、ネットワーク内のすべてのeNBがライトコネクティッドをサポートしていると推測できるかどうかは議論の余地がある。
提案13:RAN2は、ネットワーク内のすべてのeNBがライトコネクティッドをサポートしていると推測できるかどうかについて議論すべきである。
一部のeNBがライトコネクティッドをサポートしていない場合、UEはRANページングから到達不能になる可能性があるため、UEがどのように動作すべきかが問題である。可能性の1つは、UEがライトコネクティッドをサポートするセルに可能な限り優先度を付けることである。別の可能性は、ライトコネクティッドをサポートしていないセルを再選択するときに、UEがRRCアイドルに遷移することである。RAN2は、ライトコネクティッド中のUEベースのモビリティの詳細を考慮すべきである。
提案14:1又は複数のeNBがライトコネクティッドをサポートしていない場合、RAN2は、ライトコネクティッド中のUEベースのモビリティの詳細、例えばセル再選択中にセルの優先度を解除すべきであるかどうか、及びUEがそのようなセルが再選択された場合にRRCアイドルに遷移するべきかについて議論すべきである。
(付記2)
1.ページングは、オプションとして、UEごとにいくつかの優先度情報を含むことができる。
A)優先度情報は、以下であり得る。
・EstablishmentCauseの値。
・このページングが優先呼(MTボイスなど)用であることを識別する1ビットのフラグ。
・番号がMT呼の優先度を示す(例えば、セル再選択の絶対優先度のように、0〜7)。
・このページングに関連付けられたベアラID。
B)優先度情報はリストとして形成され、リスト内の各エントリはページング内のPagingRecordList内の対応するエントリを示す。
・優先度情報は、既存のPagingRecord内に統合することができる。
C)優先度情報は、eNB(例えばeVoLTE MTビデオ呼の場合)又はMME(例えば、S1ページングにおける既存のページング優先度IEを介して)によって決定されてもよい。
2.ページングにおいてページング優先度を受信すると、UEは、
A)これを使用して、RRC接続要求(又はライトコネクティッドのためのもの)を開始するかどうかを決定する、すなわち、UE実装、又は、
B)優先度情報が優先度の高い呼を示す場合、RRC接続要求(又はライトコネクティッドのためのもの)を開始する。
・要求の確立原因は、優先度情報、例えば「優先されるMT呼」と整合することができる。
[相互参照]
本願は米国仮出願第62/397453号(2016年9月21日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。