(移動通信システム)
実施形態に係る移動通信システムの構成について説明する。図1は、実施形態に係る移動通信システムであるLTE(Long Term Evolution)システムの構成を示す図である。LTEシステムは、3GPP規格に基づく移動通信システムである。
LTEシステムは、無線端末(UE:User Equipment)100、無線アクセスネットワーク(E−UTRAN:Evolved−UMTS Terrestrial Radio Access Network)10、及びコアネットワーク(EPC:Evolved Packet Core)20を備える。
UE100は、移動型の通信装置である。UE100は、自身が在圏するセル(サービングセル)を管理するeNB200との無線通信を行う。
E−UTRAN10は、基地局(eNB:evolved Node−B)200を含む。eNB200は、X2インターフェイスを介して相互に接続される。eNB200は、1又は複数のセルを管理している。eNB200は、自セルとの接続を確立したUE100との無線通信を行う。eNB200は、無線リソース管理(RRM)機能、ユーザデータ(以下、単に「データ」という)のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、UE100との無線通信を行う機能又はリソースを示す用語としても用いられる。
EPC20は、モビリティ管理エンティティ(MME)及びサービングゲートウェイ(S−GW)300を含む。MMEは、UE100に対する各種モビリティ制御等を行う。MMEは、NAS(Non−Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するトラッキングエリア(TA)の情報を管理する。トラッキングエリアは、複数のセルからなるエリアである。S−GWは、データの転送制御を行う。MME及びS−GWは、S1インターフェイスを介してeNB200と接続される。
図2は、UE100(無線端末)の構成を示す図である。UE100は、受信部110、送信部120、及び制御部130を備える。
受信部110は、制御部130の制御下で各種の受信を行う。受信部110は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部130に出力する。
送信部120は、制御部130の制御下で各種の送信を行う。送信部120は、アンテナ及び送信機を含む。送信機は、制御部130が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部130は、UE100における各種の制御を行う。制御部130は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPU(Central Processing Unit)と、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
図3は、eNB200(基地局)の構成を示す図である。eNB200は、送信部210、受信部220、制御部230、及びバックホール通信部240を備える。
送信部210は、制御部230の制御下で各種の送信を行う。送信部210は、アンテナ及び送信機を含む。送信機は、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
受信部220は、制御部230の制御下で各種の受信を行う。受信部220は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。
制御部230は、eNB200における各種の制御を行う。制御部230は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPUと、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
バックホール通信部240は、X2インターフェイスを介して隣接eNBと接続される。バックホール通信部240は、S1インターフェイスを介してMME/S−GW300と接続される。バックホール通信部240は、X2インターフェイス上で行う通信及びS1インターフェイス上で行う通信等に用いられる。
MMEは、制御部及びネットワーク通信部を有する。制御部は、MMEにおける各種の制御を行う。制御部は、少なくとも1つのプロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPUと、を含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。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とeNB200のRRCとの間に接続(RRC接続)がない場合、UE100はRRCアイドルモードである。
RRCレイヤの上位に位置するNASレイヤは、セッション管理及びモビリティ管理等を行う。UE100のNASレイヤとMME300CのNASレイヤとの間では、NASシグナリングが伝送される。UE100は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等の機能を有する。
図5は、LTEシステムにおいて用いられる無線フレームの構成を示す図である。無線フレームは、時間軸上で10個のサブフレームで構成される。各サブフレームは、時間軸上で2個のスロットで構成される。各サブフレームの長さは1msである。各スロットの長さは0.5msである。各サブフレームは、周波数軸上で複数個のリソースブロック(RB)を含む。各サブフレームは、時間軸上で複数個のシンボルを含む。各リソースブロックは、周波数軸上で複数個のサブキャリアを含む。具体的には、12個のサブキャリア及び1つのスロットにより1つのRBが構成される。1つのシンボル及び1つのサブキャリアにより1つのリソースエレメント(RE)が構成される。UE100に割り当てられる無線リソース(時間・周波数リソース)のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム(又はスロット)により特定できる。
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御情報を伝送するための物理下りリンク制御チャネル(PDCCH)として用いられる領域である。各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル(PDSCH)として用いることができる領域である。
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル(PUCCH)として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル(PUSCH)として用いることができる領域である。
(特定状態)
実施形態に係る特定状態について説明する。特定状態は、UE100用のS1接続が維持されつつUE100用のシグナリングが抑制される状態である。S1接続は、S1ベアラと称されてもよい。S1接続は、S1インターフェイス上でeNB200とEPC20との間に確立される接続である。S1インターフェイスは、ユーザプレーン用のS1−Uインターフェイスと制御プレーン用のS1−MMEインターフェイスとを含む。S1接続は、S1−Uインターフェイス上でeNB200とS−GWとの間に確立されるS1−U接続と、S1−Cインターフェイス上でeNB200とMMEとの間に確立されるS1−MME接続と、を含んでもよい。
特定状態は、RRCコネクティッドモードの一状態又はRRCアイドルモードの一状態であってもよい。特定状態によれば、一般的なRRCコネクティッドモードに比べてシグナリングが削減される。特定状態によれば、一般的なRRCアイドルモードに比べてUE100が迅速にデータ通信を開始することができる。以下において、特定状態を「Light Connection状態(Light Connection substate)」と称する。特定状態がRRCコネクティッドモードの一状態であるケースを「モデリングA」と称する。特定状態がRRCアイドルモードの一状態であるケースを「モデリングB」と称する。
Light Connection状態にあるUE100には、RANページングが適用される。RANページングは、E−UTRAN10(eNB200)によりページングが制御されるRANページングエリア単位でページングを行う。RANページングエリアは、トラッキングエリアよりも狭いエリアであってもよい。RANページングエリアを導入することにより、1のUE100に対してページングを行うセルの数を削減することができる。そのため、シグナリングを削減することができる。一例として、RANページングエリアは、Light Connection状態にあるUE100のS1接続を維持するアンカーeNBのセルと当該アンカーeNBの周辺のeNB200のセルとにより構成される。周辺のeNB200は、アンカーeNBとのX2インターフェイスを有するeNB200であってもよい。当該アンカーeNBは、Light Connection状態にあるUE100宛てのデータ又はNASシグナリングをMME/S−GW300から受信すると、RANページングを行うと判断し、周辺のeNB200と共にUE100のページングを行ってもよい。当該ページングは、RRCページングメッセージを送信することにより行われてもよい。
Light Connection状態に関する基本的な動作を以下に列記する。
・Light Connection状態(Light Connection動作)をサポートするUE100は、UE能力情報(UE−EUTRA−Capability)中でその旨を通知する。
・UE100は、RRCシグナリングによりLight Connection状態に遷移する。具体的には、UE100は、ユニキャストRRCシグナリング(RRC reconfigurationメッセージ又はRRC releaseメッセージ)によりLight Connection状態に設定される。
・Light Connection状態にあるUE100のS1接続は、「アンカーeNB」に維持され、アクティブである。アンカーeNBは、UE100をLight Connection状態に遷移させたeNB200であってもよい。UE100が他のRANページングエリアに移動する場合、アンカーeNBが切り替えられてもよい。
・Light Connection状態は、ネットワークの観点からは、ECM(EPS Connection Management)コネクティッド状態である。ECMは、UE100とコアネットワーク(MME)との間の接続状態を示す。
・Light Connection状態にあるUE100に対しては、RAN(E−UTRAN10)始動でページング(RANページング)を行うことができる。RANページングは、アンカーeNBにより始動されてもよい。RANページングエリアは、1又は複数のセルにより構成される。当該複数のセルは、異なるeNBにより管理されていてもよい。ページングメッセージは、一般的なRRCページングメッセージを再利用して規定される。
・ページング処理(RANページング)は、アンカーeNBにより制御される。
・RANページングエリアは、UE固有に設定することができる。UE固有のRANページングエリアは、ユニキャストシグナリング又はブロードキャストシグナリングによりeNB200からUE100に設定される。RANページングエリアは、セルのリスト又はページングエリアIDにより指定される。RANページングエリアは、単一のセルであってもよい。RANページングエリアは、トラッキングエリアと同一のエリアであってもよい。
・Light Connection状態にあるUE100は、RRCアイドルモードと同様なセル再選択メカニズムを実行する。
・Light Connection状態にあるUE100のコンテキスト情報(UE ASコンテキスト)は、当該UE及びアンカーeNBの両方で保持される。
・Light Connection状態にあるUE100がページングを検知した場合又はデータ送信を開始する場合には、当該UE100は、eNB200との接続を復旧する。もしくは、UE100はRRCコネクティッドモードへ遷移してもよい。
・Light Connection状態にあるUE100は、設定されたRANページングエリアの外に移動したときにネットワークに通知する。
・Light Connection状態にあるUE100は、RRCアイドルモードのDRX動作と同様なパラメータを用いてDRX動作を行う。ページング機会を決定するためのパラメータは、UEのID(例えば、IMSI、S−TMSI、Resume ID等)を含み得る。
・Light Connection状態にあるUE100は、RRCプロシージャにより、一般的なRRCコネクティッドモードの動作に移行する。モデリングAにおいて、当該プロシージャは、RRC復旧(resume)プロシージャ又はRRC再確立(reestablishment)プロシージャである。モデリングBにおいて、当該プロシージャは、RRC復旧(resume)プロシージャである。
(第1実施形態)
上述したような移動通信システムを前提として第1実施形態について説明する。
第1実施形態において、各eNB200(又は各セル)が、自身が属するRANページングエリアの識別子をブロードキャストシグナリングにより送信するシナリオを想定する。このようなシナリオにおいて、UE100に設定するRANページングエリア識別子をeNB200がユニキャストシグナリングで送信する方法が考えられる。
しかしながら、このような方法は、eNB200がRANページングエリア識別子を明示的にUE100に設定することにより、RANページングエリア識別子を管理するための処理負荷が増加する虞がある。また、eNB200が、UE100が在圏するセルを含まないRANページングエリアの識別子をUE100に設定し得る。この場合、UE100はLight Connection状態になった際に、設定されたRANページングエリア外に居ることになるため、直ちにネットワークに通知する必要がある。第1実施形態は、このような問題点を解決可能とする実施形態である。
第1実施形態に係るUE100(受信部110)は、UE100をLight Connection状態に遷移させるユニキャストシグナリングをeNB200からサービングセルを介して受信する。UE100(制御部130)は、当該ユニキャストシグナリングの受信に応じて、Light Connection状態に遷移する。Light Connection状態は、eNB200を含むRANによりページングが管理されるRANページングエリアを示すRANページングエリア識別子がUE100に設定された状態である。UE100(制御部130)は、RANページングエリア識別子が当該ユニキャストシグナリングに含まれなくても、Light Connection状態において、UE100に設定されたRANページングエリア識別子として所定エリアの識別子を保持する。所定エリアは、サービングセル、又はサービングセルが属するRANページングエリアである。
第1実施形態によれば、eNB200がRANページングエリア識別子を明示的にUE100に設定しなくても、UE100は、Light Connection状態に遷移した際のサービングセル又は当該サービングセルが属するRANページングエリアを自身に設定されたRANページングエリアとして認識する。すなわち、UE100に適用するRANページングエリアとして、UE100がLight Connection状態に遷移した際のサービングセル又は当該サービングセルが属するRANページングエリアを暗示的に設定する。これにより、eNB200がRANページングエリア識別子を明示的にUE100に設定する場合の問題を解決することができる。
第1実施形態の動作パターン1において、UE100(受信部110)は、サービングセルが属するRANページングエリアの識別子を含むブロードキャストシグナリングをeNB200から受信する。UE100(制御部130)は、Light Connection状態において、UE100に設定されたRANページングエリア識別子として、ブロードキャストシグナリング中の識別子を保持する。
第1実施形態の動作パターン2において、Light Connection状態への遷移を指示するユニキャストシグナリングは、UE100に設定されるRANページングエリアが現在のサービングセルのみからなることを示す情報を含む。UE100(制御部130)は、Light Connection状態において、UE100に設定されたRANページングエリア識別子として、当該サービングセルの識別子を保持する。動作パターン2によれば、RANページングエリアが1つのセルのみからなる場合に、UE100に明示的にRANページングエリアを設定することを不要とすることができる。また、セル識別子をRANページングエリア識別子として流用することにより、RANページングエリア識別子が枯渇することを防止することができる。セル識別子は、例えばPCI(Physical Cell ID)又はECGI(E−UTRAN Cell Global ID)等である。PCIは、eNB200が送信する同期信号に基づき特定される。ECGIは、eNB200が送信するSIBに含まれる。
第1実施形態において、UE100(制御部130)は、Light Connection状態において、UE100に設定されたRANページングエリア(所定エリア)に属しない他のセルにUE100が移動したか否かを判定する。UE100(制御部130)は、当該他のセルにUE100が移動したと判定したことに応じて、当該他のセルに通知を送信する。
・動作パターン1
図6は、第1実施形態の動作パターン1に係るUE100の動作例を示す図である。
ステップS10において、UE100(受信部110)は、サービングセルが属するRANページングエリアの識別子を含むブロードキャストシグナリングをサービングセルから受信する。ブロードキャストシグナリングは、ブロードキャストRRCシグナリング(SIB:System Information Block)であってもよい。UE100(制御部130)は、サービングセルが属するRANページングエリアの識別子を記憶する。
ステップS12において、UE100(受信部110)は、UE100をLight Connection状態に遷移させるユニキャストシグナリングをサービングセルから受信する。ユニキャストシグナリングは、ユニキャストRRCシグナリング(RRC reconfigurationメッセージ又はRRC releaseメッセージ)であってもよい。
ステップS14において、UE100(制御部130)は、Light Connection状態に遷移する。また、UE100は、UE100に設定されたRANページングエリア識別子としてブロードキャストシグナリング中の識別子(すなわち、ステップS10で受信したRANページングエリア識別子)を保持する。
このように、UE100は、Light Connection状態に遷移する指示(RRC Connection Reconfiguration又はReleaseメッセージ)を受けた場合、現在ブロードキャストされているRANページングエリア識別子を取得又は既に保持しているRANページングエリア識別子が有効であれば読み出して、自身に割り当てられたRANページングエリア識別子として保持する。UE100が保持する変数にRANページングエリア識別子が格納されてもよい。
図7は、第1実施形態の動作パターン1に係る動作シーケンス例を示す図である。
ステップS101において、eNB200は、自セル(又は自eNB)が属するRANページングエリア識別子(Paging Area ID)を含むSIBを送信する。UE100は、SIBを受信する。
ステップS102において、UE100は、SIB中のRANページングエリア識別子(Paging Area ID)を記憶する。
ステップS103において、eNB200は、UE100をLight Connection状態に遷移させるユニキャストシグナリング(Instruction to enter LC)をUE100に送信する。なお、UE100は、当該ユニキャストシグナリングを受信する際にRRCコネクティッドモードにある。
ステップS104において、UE100は、Light Connection状態に遷移するとともに、自身に設定されたRANページングエリア識別子としてSIB中の識別子(すなわち、ステップS102で記憶したRANページングエリア識別子)を保持する。言い換えると、UE100は、SIB中のRANページングエリア識別子を自身に設定されたRANページングエリア識別子とみなす。
その後、UE100は、Light Connection状態に遷移した際のセルに滞在し続ける、又はLight Connection状態に遷移した際のセルから他のセルに移動する。ここでは、UE100がLight Connection状態に遷移した際のセルから他のセルに移動するケースを主として想定する。UE100は、RRCアイドルモードと同様なセル再選択メカニズムを用いて、当該他のセルを再選択する。
ステップS105において、eNB200は、自セル(又は自eNB)が属するRANページングエリア識別子(Paging Area ID)を含むSIBを送信する。UE100は、SIBを受信する。
ステップS106において、UE100は、保持しているRANページングエリア識別子を読み出し、現在の(新しい)セルがブロードキャストしているRANページングエリア識別子(すなわち、ステップS105で受信したRANページングエリア識別子)と比較する。
これらが異なる場合(ステップS106:No)、ステップS107において、UE100は、自身に設定されたRANページングエリアを出たことを示す通知(Report it moved across the configured paging area)を現在の(新しい)セルに送信する。一方、ステップS106で「Yes」の場合、UE100は、当該通知を行なわない。
・動作パターン2
図8は、第1実施形態の動作パターン2に係るUE100の動作例を示す図である。図8において、図6に示す動作パターン1と同様な処理については、図6と同じステップ番号を付している。
ステップS12において、UE100(受信部110)は、Light Connection状態に遷移させるユニキャストシグナリングをサービングセルから受信する。ユニキャストシグナリングは、ユニキャストRRCシグナリング(RRC reconfigurationメッセージ又はRRC releaseメッセージ)であってもよい。動作パターン2において、当該ユニキャストシグナリングは、UE100に設定されるRANページングエリアが現在のサービングセルのみからなるか否かを示す情報を含む。
ステップS13において、UE100(制御部130)は、ユニキャストシグナリングに含まれる情報に基づいて、自身に設定されるRANページングエリアが現在のサービングセルのみからなるか否かを判定する。
ステップS13で「NO」の場合、ステップS10において、UE100(受信部110)は、サービングセルが属するRANページングエリアの識別子を含むブロードキャストシグナリングをサービングセルから受信する。ブロードキャストシグナリングは、ブロードキャストRRCシグナリング(SIB:System Information Block)であってもよい。UE100(制御部130)は、受信したRANページングエリア識別子を記憶する。そして、ステップS14において、UE100(制御部130)は、Light Connection状態に遷移するとともに、UE100に設定されたRANページングエリア識別子としてブロードキャストシグナリング中の識別子(すなわち、ステップS10で受信したRANページングエリア識別子)を保持する。
ステップS13で「YES」の場合、ステップS15において、UE100(制御部130)は、Light Connection状態に遷移するとともに、UE100に設定されたRANページングエリア識別子として、現在のサービングセルの識別子(セル識別子)を保持する。UE100は、UE100に設定されたRANページングエリアが現在のサービングセルのみからなる旨の情報を保持してもよい。
(第1実施形態の変更例1)
第1実施形態の変更例1について、第1実施形態との相違点を主として説明する。
第1実施形態の変更例に係るUE100の基本的な動作は第1実施形態と同様である。UE100(受信部110)は、UE100をLight Connection状態(特定状態)に遷移させるユニキャスト信号をeNB200から受信する。UE100(受信部110)は、eNB200がブロードキャストするRANページングエリア識別子をさらに受信する。UE100(制御部130)は、ユニキャスト信号の受信に応じて、UE100をLight Connection状態に遷移させる。Light Connection状態は、eNB主導のページング方式(すなわち、RANページング)において用いられるページングエリアを示すページングエリア情報がUE100に設定された状態である。ページングエリア情報は、ページングエリア設定と称されてもよい。
第1実施形態の変更例において、UE100(制御部130)は、所定の条件が満たされたことに応じて、自身に設定されたページングエリア情報としてRANページングエリア識別子を保持する。所定の条件は、以下の第1の条件乃至第3の条件のうちの1つであってもよいし、2以上の条件の組み合わせであってもよい。
第1の条件は、RANページングエリア識別子がeNB200からブロードキャストされているという条件である。RANページングエリア識別子がeNB200からブロードキャストされている場合に、UE100は、ページングエリア情報としてRANページングエリア識別子がeNB200から指定されたと認識する。
第2の条件は、ページングエリア情報としてRANページングエリア識別子がeNB200から指定されたという条件である。このような指定は、Light Connection状態に遷移させるユニキャスト信号(例えばRRC Connection Releaseメッセージ)により行なわれてもよい。例えば、RRC Connection Releaseメッセージ中に「ran−pagingAreaId=TRUE」といった情報が含まれる場合に、UE100は、ページングエリア情報としてRANページングエリア識別子がeNB200から指定されたと認識する。
第3の条件は、ページングエリア情報としてRANページングエリア識別子以外の情報がeNB200から指定されなかったという条件である。RANページングエリア識別子以外の情報とは、例えば、セルのリスト、単一セル、及びトラッキングエリアのうち少なくとも1つである。ページングエリア情報としてRANページングエリア識別子以外の情報がeNB200から指定されなかった場合に、UE100は、ページングエリア情報としてRANページングエリア識別子がeNB200から指定されたと認識する。
(第1実施形態の変更例2)
第1実施形態の変更例1において、ページングエリア情報としてRANページングエリア識別子をUE100に設定する一例を説明したが、セルのリスト、単一セル、又はトラッキングエリアをUE100に設定するケースを想定してもよい。例えば、UE100は、ページングエリア情報としてセルのリスト又はトラッキングエリアがeNB200から指定されなかった場合、ページングエリア情報として単一セルがeNB200から指定されたと認識してもよい。この場合、UE100は、自身に設定されたページングエリア情報として単一セルの情報を保持してもよい。
(第2実施形態)
第2実施形態について、第1実施形態との相違点を主として説明する。
図9は、第2実施形態に係る想定シナリオを示す図である。Light Connection状態にあるUE100は、複数のセルを跨いで移動する。しかしながら、Light Connection状態を取り扱う機能を有しないセル(eNB200)も存在し得る。Light Connection状態を取り扱う機能とは、例えばRANページングの機能及びLight Connection状態からUE100を復旧させる機能等である。以下において、このような機能を有しないセルを適宜「Light Connectionをサポートしないセル」と称する。
図9において、eNB200−1乃至200−3により管理されるセルA乃至Cのうち、セルBは、Light Connectionをサポートしないセルである。UE100は、セルA,B,Cの順に移動する。各eNB200(各セル)は、Light Connectionをサポートしているか否かを示す情報をブロードキャストしていてもよい。一例として、eNB200(送信部210)は、当該情報をSIBにより送信する。このような情報は、暗示的な情報であってもよい。例えば、UE100(制御部130)は、RANページングエリア識別子をブロードキャストしているセルをLight Connectionをサポートするセルとみなしてもよい。もしくは、選択したセルが、UEに設定されたCell IDのリスト(RANページングエリアに含まれるセルのリスト)に含まれている場合にはLight Connectionをサポートするセルとみなし、含まれていない場合にはLight Connectionをサポートしないセルとみなしてもよい。
第2実施形態において、UE100(制御部130)は、RANページングエリアが設定されたLight Connection状態において、Light Connection状態を取り扱う機能をサービングセルがサポートするか否かを判定する。UE100(制御部130)は、当該機能をサービングセルがサポートしないと判定した場合でも、サービングセルにおいてLight Connection状態を維持する。よって、Light Connection状態のUE100は、図9に示すセルAからセルBに移動しても、Light Connection状態を維持する。言い換えると、UE100は、Light Connectionをサポートしないセルを再選択しても、Light Connection動作を中止せずに継続する。
比較例として、セルAからセルBに移動した際に、Light Connection動作を中止し、通常のRRCアイドルモードの動作を行うことが考えられる。しかしながら、その後にUE100がセルBからセルCに移動するシナリオを想定すると、UE100は、セルBにおいてLight Connection動作を継続することが好ましい。
第2実施形態において、UE100(制御部130)は、Light Connection状態から復旧すべき所定イベントを検知する。Light Connection状態からの復旧とは、Light Connection動作を中止して通常のRRCコネクティッドモードの動作を行うことを意味する。所定イベントは、UE100がページングを受信したことであってもよいし、UE100がデータ又はシグナリングを送信する必要が生じたことであってもよい。
UE100(制御部130)は、サービングセルがLight Connectionをサポートすると判定した場合において、所定イベントを検知したことに応じて、Light Connection状態からの復旧を要求する第1のRRCメッセージをサービングセルに送信する。第1のRRCメッセージは、RRC復旧(resume)要求メッセージであってもよいし、RRC再確立(reestablishment)要求メッセージであってもよい。
UE100(制御部130)は、サービングセルがLight Connectionをサポートしないと判定した場合において、所定イベントを検知したことに応じて、サービングセルとのRRC接続の確立を要求する第2のRRCメッセージをサービングセルに送信する。第2のRRCメッセージは、RRC接続要求メッセージであってもよい。言い換えると、UE100(制御部130)は、Light ConnectionをサポートしないセルにおいてLight Connection状態から復旧するために、自身がRRCアイドルモードであるとみなして、RRC接続要求メッセージを送信する。RRC接続要求メッセージは、一般的なUE100がRRCアイドルモードからRRCコネクティッドモードに遷移する際に用いられるメッセージであるため、Light Connectionをサポートしないセルであっても当該メッセージを取り扱うことができる。
なお、Light Connection状態にあるUE100は、Light Connectionをサポートしないセルでは、トラッキングエリアを用いた従来のページング(すなわち、MME主導によるページング)をモニタしない場合、UE100が呼び出し出来なく虞がある。そこで、Light Connection状態にあるUE100は、現在選択しているセルがLight Connectionをサポートしている場合はRANページングをモニタし、サポートしていない場合は従来のMME主導によるページングをモニタする。もしくは、Light Connection状態にあるUE100は、Light Connectionをサポートするセルの配下においては、RANページング及びMME主導ページングの両方をモニタしてもよい。
MME主導ページングにおいて、UE100は、自身の識別子であるUE_IDとしてのIMSI(International Mobile Subscriber Identity)によって特定されるタイミング、例えば、「SFN mod T= (T div N)*(UE_ID mod N)」においてモニタを行う。一方で、RANページングにおけるモニタのタイミングは、MME主導ページングにおけるモニタのタイミングとは異なるタイミングで定義されてもよい(少なくとも異なるパラメータが設定できる)。
MME主導によるページングにおいては、UE100は、ページング(呼び出し)に係る識別子(すなわち、ページングレコード)として、事前設定もしくはコアネットワークが割り当てた識別子(例えばIMSI、S−TMSI)を検出する。一方、RANページングにおいては、UE100は、RANノード(例えば基地局)が割り当てた(又は管理する)識別子(例えば、”Cell ID+C−RNTI”、Resume ID等)の検出を行う。
(第2実施形態の変更例)
第2実施形態の変更例について、第2実施形態との相違点を主として説明する。
第2実施形態の変更例に係るUE100(制御部130)は、eNB主導の第1のページング方式(すなわち、RANページング)において用いられるページングエリアを示すページングエリア情報がUE100に設定されたLight Connection状態において、現在のサービングセルがLight Connection状態を取り扱う機能を有しているか否か(すなわち、現在のサービングセルがLight Connectionをサポートしているか否か)を判断する。現在のサービングセルがLight Connectionをサポートしていないことに応じて、UE100(制御部130)は、以下の第1の処理乃至第3の処理のうちの少なくとも1つを行う。
第1の処理は、Light Connection状態からの復旧を要求するためのプロシージャを現在のサービングセルにおいて行うことができないと判断する処理である。当該プロシージャは、RRC Resumeプロシージャであってもよい。第1の処理は、復旧要求メッセージ(上述した第1のRRCメッセージ)を現在のサービングセルに送信することが許可されていないと判断する処理であってもよい。言い換えると、UE100は、現在のサービングセルがLight Connectionをサポートしている場合のみ、復旧要求メッセージを現在のサービングセルに送信することができる。復旧要求メッセージは、RANページングエリアの更新(PAU:Paging Area Update)に関するRANページングエリア更新情報を含んでもよい。RANページングエリア更新情報は、復旧要求メッセージに含まれてもよい。RANページングエリア更新情報は、復旧要求メッセージの送信後に送信されるメッセージ(例えば、RRC Resume Completeメッセージ)に含まれてもよい。
第2の処理は、RRCアイドルモードに遷移する処理である。UE100において、ASレイヤは、「RRC Connection failure」をNAS(上位レイヤ)に通知してもよい。その結果、UE100は、RRCアイドルモードに遷移する。ASレイヤは、セル再選択動作により、Light Connectionをサポートしないセルを再選択した直後において、「RRC Connection failure」をNASレイヤに通知してもよい。ASレイヤは、セル再選択動作により、Light Connectionをサポートしないセルを再選択した後において、MT(Mobile Terminated)及び/又はMO(Mobile Originated)が発生した際に、「RRC Connection failure」をNASレイヤに通知してもよい。MTは、ページング受信を含む。MOは、上りリンクのデータ又はシグナリングの必要が生じたことを含む。UE100は、MT及び/又はMOが発生した際に、現在のサービングセルがLight Connectionをサポートするか否かを判断してもよい。UE100は、MT及び/又はMOが発生した時に、現在のサービングセルのSIBを確認し、Light Connectionサポートが通知されていなければ、NASレイヤに「RRC Connection failure」の通知を行ってもよい。
第3の処理は、コアネットワーク主導の第2のページング方式(すなわち、MME主導のページング)を用いるページングをモニタする処理である。このようなページングは、RRCアイドルモード用のページングであってもよい。具体的には、UE100は、アイドルモード用のDRXのページングオケージョン(PF/PO)に従ってページングをモニタする。なお、このようなページングオケージョンについては第5実施形態において説明する。また、第3の処理において、UE100は、ページングメッセージを受信し、受信したページングメッセージ中のIMSI(International Mobile Subscriber Identity)及び/又はS−TMSI(SAE Temporary Mobile Subscriber Identity)を確認し、自身宛のページングメッセージであるか否かを判断する。第3の処理において、UE100は、受信したページングメッセージについて、RANページング用の識別子(例えば、Resume ID)の確認を行わなくてもよい。第3の処理において、UE100は、Light Connection状態を維持する(すなわち、RRCアイドルモードに遷移せず、通常のRRCコネクティッドモードに戻らない)としてもよい。UE100は、MT又はMOが発生した場合に、Light Connection状態から抜けて通常のRRCコネクティッドモードに戻ってもよい。或いは、UE100は、MT又はMOが発生した場合に、例えばASレイヤからNASレイヤに「RRC Connection Failure」に通知することにより、RRCアイドルモードに遷移してもよい。
UE100は、現在のサービングセルがLight Connectionをサポートしていないことに応じて、Light Connection状態のために用いるメッセージを現在のサービングセルに送信することができないと判断してもよい。このようなメッセージとしては、例えば、UE100においてデータ通信が発生していない(又は発生する見込みが無い)ことを示す通知メッセージであってもよい。
(第3実施形態)
第3実施形態について、第1及び第2実施形態との相違点を主として説明する。第3実施形態は、Light Connection状態にあるUE100のセル再選択動作に関する実施形態である。
第3実施形態に係るUE100は、Light Connection状態においてセル再選択動作を行う制御部130を備える。制御部130は、当該セル再選択動作において、Light Connection状態からの復旧をサポートするセルをUE100のサービングセルとして優先的に選択する。
一般的なセル再選択動作は、セルが属する周波数の優先度及びセルの無線品質に基づくランキングにより、適切なセルを選択する動作である。
第3実施形態に係るセル再選択動作おいて、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”)を意味する。
第3実施形態に係るセル再選択動作おいて、UE100(制御部130)は、ランキングにオフセットを導入することにより、Light Connectedをサポートするセルを優先してもよい。例えば、Light Connectedをサポートするセルにはプラスのオフセットを加算する、及び/又はLight Connectedをサポートしないセルにはマイナスのオフセットを加算する。当該オフセット値は、予め定義された値でもよく、eNB200から設定された値であってもよい。eNB200から設定される場合、eNB200は、当該オフセット値をブロードキャストしてもよい。eNB200から設定される場合、eNB200は、UE個別に専用シグナリングにより当該オフセット値を設定してもよい。
第3実施形態において、eNB200は、Light Connection状態からの復旧をサポートするセルの優先制御を行うか否かをUE100に設定してもよい。当該設定は、Light Connection状態に遷移する時に設定されてもよい。当該設定は、RRC Connection Reconfiguration又はRRC Connection Releaseに含まれていてもよい。
各eNB200(各セル)は、Light Connection状態(具体的には、Light Connection状態からの復旧)をサポートしているか否かを示す情報をブロードキャストしていてもよい。一例として、eNB200は、当該情報をSIBにより送信する。このような情報は、暗示的な情報であってもよい。例えば、UE100は、RANページングエリアの識別子を送信しているセルをLight Connection状態をサポートしているセルとみなしてもよい。
第3実施形態において、UE100は、Light Connection状態からの復旧をサポートし、かつ所定の無線品質基準(例えばS criterion)を満たすセルが検出されないことに応じて、RRCアイドルモードに遷移してもよい。一例として、UE100は、S criterionを満たすセルがlegacyセル(すなわち、Light Connection状態をサポートしていないセル)だけであった場合などにおいて、RRCアイドルモードに遷移してもよい。
(第3実施形態の変更例)
第3実施形態の変更例について、第3実施形態との相違点を主として説明する。
第3実施形態の変更例に係るUE100(制御部130)は、eNB主導の第1のページング方式(RANページング)において用いられるページングエリアを示すページングエリア情報がUE100に設定されたLight Connection状態において、UE100の移動先にある隣接セルがLight Connection状態を取り扱う機能を有しているか否か(すなわち、隣接セルがLight Connectionをサポートしているか否か)を判断する。UE100(送信部120)は、隣接セルがLight Connectionをサポートしていないことに応じて、UE100のサービングセルを現在のサービングセルから隣接セルに変更するセル再選択を行う前において、復旧要求メッセージを現在のサービングセルに送信する。復旧要求メッセージは、Light Connection状態からの復旧を要求するためのメッセージ(RRC Connection Resumeメッセージ)である。
第3実施形態の変更例において、UE100(受信部110)は、隣接セルがLight Connectionをサポートしているか否かを示す情報を現在のサービングセルから受信してもよい。UE100(制御部130)は、現在のサービングセルから受信した情報に基づいて、隣接セルがLight Connectionをサポートしているか否かを判断してもよい。
図10は、第3実施形態の変更例に係る動作例を示す図である。
ステップS301において、Light Connection状態にあるUE100は、隣接セルに対する測定結果等に基づいて、隣接セルへのセル再選択を行う必要が生じたか否かを判断する。当該判断は、実際にセル再選択を行うより以前の所定のタイミングにおいて実施される。所定のタイミングは、セル再選択の直前のタイミングであってもよく、ある一定期間の猶予をもったタイミングであってもよい。測定結果とは、受信レベル(RSRP:Reference Signal Received Power)の測定結果であってもよい。測定結果とは、RSRQ(Reference Signal Received Power)及び/又はRS−SINR(Reference signal−signal to noise and interference ratio)の測定結果であってもよい。UE100は、eNB200から設定された閾値(例えば、RSRP閾値、RSRQ閾値、及び/又はRS−SINR閾値)により、セル再選択の直前であることを認識してもよい。当該閾値は、Light Connectionを指示するユニキャストシグナリング(例えば、RRC Connection Releaseメッセージ)で設定されてもよく、SIBでブロードキャストされていてもよい。
隣接セルへのセル再選択を行う必要が生じたと判断した場合(ステップS301:YES)、ステップS302において、UE100は、当該隣接セルがLight Connectionをサポートするか否かを判断する。UE100は、現在のサービングセルから、隣接セルがLight Connectionをサポートしているか否かを示すリストを受信する。UE100は、当該リストに基づいて当該判断を行なってもよい。当該リストは、Light Connectionをサポートする隣接セルの識別子のリストでもよいし。当該リストは、Light Connectionをサポートしない隣接セルの識別子のリストであってもよい。或いは、UE100は、隣接セルがブロードキャストする情報(例えば、SIB)に基づいて当該判断を行なってもよい。隣接セルがブロードキャストする情報は、Light Connectionをサポートするか否かを示す情報であってもよい。S302の処理は、S301よりも以前に行なわれてもよい。
隣接セルがLight Connectionをサポートすると判断した場合(ステップS302:YES)、ステップS303において、UE100は、当該隣接セルへのセル再選択を行う。
隣接セルがLight Connectionをサポートしないと判断した場合(ステップS302:NO)、ステップS304において、UE100は、通常のRRCコネクティッドモードに遷移するために、復旧要求メッセージを現在のサービングセルに送信する。
復旧要求メッセージは、UE100がLight Connection状態に遷移する際にeNB200からUE100に割り当てられた識別子(例えば、Resume ID)を含んでもよい。当該識別子は、Light Connectionを指示するユニキャストシグナリング(例えば、RRC Connection Releaseメッセージ)でUE100に設定されてもよい。
復旧要求メッセージは、隣接セルがLight Connectionをサポートしていないことを示す情報を含んでもよい。当該情報は、復旧要求の理由を示す「Resume Cause」として復旧要求メッセージに含まれてもよい。
復旧要求メッセージは、隣接セルを識別する識別情報を含んでもよい。当該識別情報は、PCI(Physical Cell Identity)及び/又はECGI(E−UTRAN Cell Global Identifier)等である。復旧要求メッセージは、隣接セルに対する測定結果を含んでもよい。測定結果は、RSRPであってもよい。測定結果は、RSRQ(Reference Signal Received Quality)であってもよい。隣接セルの識別情報及び/又は測定結果は、eNB200(例えば、現在のサービングセル)からのユニキャストシグナリング又はSIBにより指示された場合に限り復旧要求メッセージに含めるとしてもよい。UE100は、eNB200から指示がない場合には、隣接セルの識別情報及び/又は測定結果を復旧要求メッセージに含めなくてもよい。例えば、eNB200は、UE100を通常のRRCコネクティッドモードに戻した直後にUE100の測定報告をトリガさせる予定であれば、当該指示を行わない。
ステップS304の結果、UE100は、通常のRRCコネクティッドモードに遷移する。その後、現在のサービングセル(eNB200)は、UE100にRRC Connection Releaseメッセージを送信することにより、UE100をRRCアイドルモードに遷移させてもよい。eNB200は、RRC Connection RejectメッセージをUE100に送信することにより、UE100を通常のRRCコネクティッドモードに遷移させずにLight Connection状態からRRCアイドルモードに遷移させてもよい。eNB200は、UE100をRRCコネクティッドモードに遷移させた後、復旧要求メッセージに含まれる隣接セルの識別情報及び/又は測定結果等に基づいて、当該隣接セルに対してUE100をハンドオーバしてもよい。eNB200は、UE100のハンドオーバを行うか否かの判断の際に、UE100の過去のデータ通信履歴等を考慮してもよい。eNB200は、復旧要求メッセージを送信したUE100のコンテキスト情報(UEコンテキスト)を削除してもよいし、隣接セル(隣接eNB)に転送してもよい。
(第4実施形態)
第4実施形態について、第1乃至第3実施形態との相違点を主として説明する。第4実施形態は、eNB200がRANページングを行う動作に関する実施形態である。
第4実施形態に係るeNB200は、Light Connection状態にあるUE100に対してRANページングを行い、RANページングが成功したか否かを判断する制御部230と、RANページングの失敗に応じて、RANページングの失敗を示す失敗通知をMME300Cに送信する送信部(バックホール通信部240)と、を備える。RANページングは、RANページングエリア単位でRANがUE100のページングを行う動作である。失敗通知は、UE100が在圏するトラッキングエリアに基づくページングをMME300Cに実行させるためのメッセージであってもよい。よって、RANページングが失敗した場合でも、MME300Cが通常のページングを実行することができる。
第4実施形態に係るeNB200は、RANページングエリア内の他のeNB200がページングに成功したか否かに関する情報を当該他のeNB200から受信する受信部(バックホール通信部240)を備えてもよい。制御部230は、自eNB200及び他のeNB200の両方でページングに失敗したことに応じて、RANページングが失敗したと判断する。
図11は、第4実施形態に係る動作例を示す図である。図11において、アンカーeNB200−1及びeNB200−2は、同一のRANページングエリアに属する。アンカーeNB200−1及びeNB200−2は、X2インターフェイスを介して接続されていてもよい。初期状態において、UE100は、RRCコネクティッドモードにある(S2001、S2002)。図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に送信する。ページング要求は、ページングタイミングを特定するための情報を含んでもよい(第5実施形態参照)。
ステップ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 Connection状態から復旧することを要求するメッセージ(RRC Connection Boot request)をeNB200(例えばアンカーeNB200−1)に送信する。
(第4実施形態の変更例1)
第4実施形態の変更例1について、第4実施形態との相違点を主として説明する。
図12は、第4実施形態の変更例1に係る動作例を示す図である。図12に示すeNB200−1乃至200−nは、同一のトラッキングエリアに属するeNB200である。
図12に示すように、ステップS201において、eNB200−1は、UE100をLight Connection状態に遷移させる。
ステップS202において、eNB200−1は、Light Connection状態に遷移させるUE100に関する遷移通知(Light Connection Indication)をMME300Cに送信する。遷移通知は、Light Connection状態に遷移させるUE100(特定のUE100)を識別するための識別子(例えば、MME UE S1AP ID)を含む。
ステップS203において、MME300Cは、遷移通知の受信に応じて、監視要求(Notify DL data Request)をS−GW300Uに送信する。監視要求は、特定のUE100宛てのDLデータがあるか否かを監視するよう要求するメッセージである。当該メッセージは、特定のUE100を識別するための識別子(例えば、GTP TEID)を含む。S−GW300Uは、監視要求の受信に応じて、特定のUE100宛てのDLデータの監視を開始する。S−GW300Uは、監視を開始する場合に、MME300Cに対して、監視要求に対する肯定応答(ACK)を送信してもよい。
ステップS204において、S−GW300Uは、特定のUE100宛てのDLデータをP−GWから受信する。S−GW300Uは、S1−U接続を用いて、特定のUE100宛てのDLデータをeNB200−1に転送してもよい(ステップS205)。或いは、S−GW300Uは、特定のUE100宛てのDLデータの転送を暫定的に停止してもよい。MME300Cは、監視要求と同じメッセージ又は監視要求とは異なるメッセージを用いて、このような停止を要求する監視要求をS−GW300Uに送信してもよい。
特定のUE100宛てのDLデータを受信した場合(ステップS206:YES)、ステップS207において、S−GW300Uは、特定のUE100宛てのDLデータが存在することを示す通知(Notify DL data)をMME300Cに送信する。
ステップS208において、MME300Cは、特定のUE100宛てのDLデータ又はNASシグナリングを送信する必要が生じたか否かを判定する。MME300Cは、S−GW300Uからの通知に基づいて、特定のUE100宛てのDLデータを送信する必要が生じたか否かを判定する。
ステップS208において「YES」である場合、MME300Cは、遷移通知に含まれるUE識別子に基づいて、特定のUE100の登録トラッキングエリアを判定し、登録トラッキングエリアに属するeNB200に対して、S1ページングメッセージを送信する。その後、ページング(Paging)プロシージ及びRRC接続復旧(RRC Connection Resume)プロシージャが行われる。
(第4実施形態の変更例2)
第4実施形態の変更例2について、第4実施形態及びその変更例1との相違点を主として説明する。
第4実施形態において、eNB主導の第1のページング方式を用いるページング(RANページング)の失敗に応じて、コアネットワーク(MME)主導の第2のページング方式を用いるページング(MMEページング)を行う一例を説明した。第4実施形態の変更例は、RANページングと並行してMMEページングを行う変更例である。
第4実施形態の変更例2に係るeNB200(制御部230)は、eNB主導の第1のページング方式を用いてUE100に対する第1のページング(RANページング)を行う。第4実施形態の変更例に係るeNB200は、アンカーeNBであってもよい。eNB200(制御部230)は、RANページングがUE100に到達しない可能性があると判断したことに応じて、UE100に対するMMEページングを開始させるための所定の情報をコアネットワーク(MME)に通知する。UE100(制御部230)は、RANページングの実行前又はRANページングの実行中のタイミングにおいて、所定の情報をコアネットワーク(MME)に通知する。所定の情報は、MMEページングの実行要求であってもよい。所定の情報は、第4実施形態の変更例1と同様な通知であってもよい。
第4実施形態の変更例2において、eNB200(制御部230)は、所定の地理的エリア内において、RANページングにおいて用いるページングエリア(すなわち、RANページングエリア)がカバーしない領域が存在することに応じて、RANページングがUE100に到達しない可能性があると判断してもよい。所定の地理的エリアは、RANページングエリアに対応する地理的範囲のエリアであってもよい。所定の地理的エリアは、トラッキングエリアであってもよい。所定の地理的エリアに含まれるセルの中にRANページングをサポートしないセルが存在する場合、当該セルの地理的範囲はRANページングエリアによりカバーされないことになる。言い換えると、所定の地理的エリア内において、RANページングのカバレッジホールが生じる。このようなケースにおいて、eNB200(制御部230)は、RANページングがUE100に到達しない可能性があると判断し、RANページングと並行してMMEページングを行うよう制御する。
eNB200は、UE100にLight Connectionを設定した際にその旨をMME300Cに通知してもよい。eNB200は、UE100にLight Connectionを設定する前において、UE100がLight Connectionをサポートしていると判断した際に、その旨をMME300Cに通知してもよい。eNB200は、OAMからの設定に基づいて、MME300Cに対する通知を行なってもよい。
MME300Cは、当該通知を受けた後において、S−GW300Uからの通知(図12のステップS207参照)に応じてS1ページングメッセージを送信してもよい。MME300Cは、定期的にS1ページングメッセージを送信してもよい。
S−GW300Uは、DLデータが到着した場合(図12のステップS204参照)において、RANページングのためにアンカーeNBにDLデータを転送するとともに、MMEページングのために当該DLデータ(のコピー)を保持してもよい。
MME300CからS1ページングメッセージを受信したeNB200は、受信したS1ページングメッセージ(MMEページングメッセージ)とRANページングメッセージをマージして、UE100に送信するページングメッセージ(RRCメッセージ)を生成してもよい。例えば、S1ページングメッセージ中のIMSIとRANページングメッセージ中のResume IDとの両方を含むページングメッセージ(RRCメッセージ)を生成してもよい。
UE100は、MMEページングメッセージのみを受信する、RANページングメッセージのみを受信する、又は両方のメッセージを受信する。或いは、UE100は、MMEページングメッセージとRANページングメッセージとがマージされたページングメッセージを受信し得る。UE100は、受信したページングメッセージ中のUE識別情報(例えば、TMGI、S−TMSI、Resume ID)を確認し、UE識別情報の種類に応じてページングメッセージの種類を判断してもよい。
例えば、UE100は、受信したページングメッセージに、自身に割り当てられたResume ID(及びS−TMSI)が含まれていれば、RANページングメッセージを受信したと判断してもよい。UE100は、受信したページングメッセージに、自身に割り当てられたResume ID(及びS−TMSI)が含まれてなければ、MMEページングメッセージを受信したと判断してもよい。UE100は、ページングメッセージの受信に応じて、RRC Connection Resumeプロシージャを開始してもよい。
UE100は、受信したページングメッセージの種類に対応する応答をネットワークに送信してもよい。例えば、UE100は、MMEページングメッセージを受信したと判断した場合には、ページング応答(NASシグナリング)をMME300Cに送信してもよい。UE100は、RANページングメッセージを受信したと判断した場合には、RRC Connection ResumeメッセージをeNB200に送信してもよい。UE100は、RRC Connection Resumeメッセージに、ページングを受信したことを示す情報(Cause=MT access)を含めてもよい。UE100は、UE100は、RRC Connection Resumeメッセージに、自身に割り当てられたResume IDを含めてもよい。
UE100は、RANページング及びMMEページングの両方のページングメッセージ(又はマージされたページングメッセージ)を受信したと判断した場合、MMEページングへの応答を優先してもよいし、RANページングへの応答を優先してもよい。UE100は、RANページング及びMMEページングの両方のページングメッセージ(又はマージされたページングメッセージ)を受信したと判断した場合、当該両方のページングメッセージに対応する2つの応答を送信してもよい。
MME300Cは、ページング応答をUE100から受信した場合に、アンカーeNBに対して、当該応答があった旨を通知してもよい。eNB200は、RANページングに対する応答をUE100から受信した場合に、MME300Cに対して、当該応答があった旨を通知してもよい。
(第4実施形態の変更例3)
MME300Cは、トラッキングエリア更新メッセージ(NASシグナリング)をUE100から受信した場合に、アンカーeNBに対して通知を行ってもよい。MME300Cは、RANページングエリアをトラッキングエリアと同じに設定している場合に限って当該通知を送信してもよい。MME300Cは、eNB200からUE100をLight Connectionに設定している旨の通知を受けていた場合のみ当該通知を送信してもよい。MME300Cは、現在UE100が接続しているeNBの識別子を当該通知に含めてもよい。アンカーeNBは、当該通知に基づいて、現在UE100が接続しているeNBに対してUEコンテキストを転送してもよい。或いは、当該通知は、UE Context Releaseであってもよい。UE Context Releaseを受信したeNB200は、UEコンテキストを解放する。
(第5実施形態)
第5実施形態について、第1乃至第4実施形態との相違点を主として説明する。第5実施形態は、Light Connection状態にあるUE100のDRX動作に関する実施形態である。
一般的なアイドルモードDRX動作について説明する。消費電力を削減するために、間欠受信(DRX:Discontinuous Reception)がUE100に設定され得る。DRX動作において、RRCアイドルモードのUE100は、所定の時間間隔(DRXサイクル)で発生するページング受信機会(ページングオケージョン)においてページングメッセージをモニタする。DRX動作において、UE100は、ページングを受信するためにPDCCHを間欠的にモニタする。UE100は、ページング用の識別子(P−RNTI:Paging Radio Network Temporary Identifier)を用いてPDCCHをデコードし、ページングチャネルの割り当て情報を取得する。UE100は、割当情報に基づいて、ページングメッセージを取得する。UE100におけるPDCCHモニタタイミングは、UE100の識別子(IMSI:International Mobile Subscriber Identity)に基づいて定められる。DRX動作におけるPDCCHモニタタイミング(PDCCHモニタサブフレーム)は、ページングオケージョン(PO)と称される。POは、ページングの受信機会に相当する。
UE100及びeNB200は、ページングオケージョン(PO)、及び、ページングオケージョンを含みうる無線フレームであるPaging Frame(PF)を下記のように計算する。
PFのシステムフレーム番号(SFN)は、下記の式(1)から求められる。
SFN mod T = (T div N) * (UE_ID mod N) …(1)
Tは、ページングをモニタするためのUE100のDRXサイクルである。Tは、無線フレームの数で表される。また、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 mod 1024」により求められる値である。
このようにして求められたPFのうち、下記の式(2)により、インデックスi_sを求め、インデックスi_sに対応するPOのサブフレーム番号を求める。
i_s = floor(UE_ID/N) mod Ns …(2)
但し、Nsは、1とnB/Tのうち最大値である。
第5実施形態に係る動作について説明する。図13は、第5実施形態に係る動作例を示す図である。
第5実施形態の動作パターン1に係るUE100は、Light Connection状態に遷移するよう指示する遷移指示をサービングセルから受信する受信部110と、サービングセルにおいてLight Connection状態に遷移し、RRCコネクティッドモードのDRX動作を行う制御部130と、を備える。図13(a)に示すように、UE100は、Light Connection状態に遷移した時点のサービングセルに在圏する間は、RRCコネクティッドモードのDRX動作を継続する。図13(b)に示すように、UE100の制御部130は、RANページングエリア内で当該サービングセルから他のセルにUE100が移動したことに応じて、RRCコネクティッドモードのDRX動作を中止する。UE100の制御部130は、RRCコネクティッドモードのDRX動作を中止するとともに、RRCアイドルモードのDRX動作に基づく動作を開始する。RRCアイドルモードのDRX動作に基づく動作とは、RRCアイドルモードのDRX動作におけるページングフレーム(PF)及びページング機会(PO)の計算式又はこれを流用した計算式によりPF及びPOを決定する動作である。図13(c)に示すように、UE100の制御部130は、異なるRANページングエリアに移動した際に通知を行う。
第5実施形態の動作パターン2に係るUE100は、Light Connection状態に遷移した時点のサービングセルから他のセルに移動しても、当該他のセルが同一RANページングエリアに属するのであれば、RRCコネクティッドモードのDRX動作を継続する。この場合、図13(a)及び(b)に示すように、UE100は、同一RANページングエリア内でRRCコネクティッドモードのDRX動作を継続することができる。すなわち、UE100は、他のセルに移動しても、コネクティッドモードDRXに準じて受信動作を行う。
ここで、このような動作をeNB200単位で行なってもよい。すなわち、第5実施形態の動作パターン1及び2において、「サービングセル」を「サービングeNB」又は「アンカーeNB」と読み替え、「他のセル」を「他のeNB」と読み替えてもよい。
第5実施形態の動作パターン1及び2において、アンカーeNB以外のUE100はUE100のコンテキスト情報を保持しているとは限らない。よって、同一RANページングエリア内の他のeNBは、ページングのタイミングを決定するための情報をアンカーeNBから取得することが望ましい。他のeNBは、Light Connection状態にあるUE100に対してRANページングを行う。他のeNBは、RANページングのためのページングメッセージをUE100に送信するタイミングを決定するための情報をアンカーeNBから取得する。当該タイミングを決定するための情報は、UE100の識別情報(例えば、IMSI、S−TMSI、Resume ID等)及びRRCコネクティッドモードのDRX設定のうち少なくとも一方を含む。アンカーeNBは、このような情報をページング要求(Paging Request)に含めて他のeNBに送信してもよい。
ページングのタイミングを決定するための識別情報は、ECGI(E−UTRAN Cell Global Identifier)及びC−RNTI(Cell−Radio. Network Temporary Identifier)であってもよい。アンカーeNB200−1は、UE100をLight Connection状態に遷移させる際に、当該識別情報をUE100に割り当ててもよい。
(第5実施形態の変更例1)
RANページングが送信されるタイミングがIMSIによって特定される場合において、eNB200は、RANページングを行うためのUE100のIMSIを知らない為、UE100からIMSIが通知されてもよい。UE100は、自身のIMSIを、自身がLight Connection機能をサポートする旨の能力情報として基地局に通知してもよい。eNB200は、UE100の能力情報においてIMSIが通知された場合は、当該UE100がLight Connection機能をサポートしていると判断し、当該IMSIをRANページングタイミングの特定に用いてもよい。
(第5実施形態の変更例2)
第5実施形態の変更例2について、第5実施形態及びその変更例1との相違点を主として説明する。
第5実施形態の変更例2に係るeNB200(制御部230)は、eNB主導のページング方式を用いてUE100に対するページング(RANページング)を行う。eNB主導のページング方式において、eNB200(制御部230)は、UE100を識別する識別情報を用いて、UE100にページングメッセージを送信する候補タイミングを示すページングオケージョン(PF/PO)を決定する。eNB200(制御部230)は、当該識別情報を、UE100又はコアネットワーク(例えば、MME300C)から取得する。eNB200(アンカーeNB)は、当該識別情報、IMSI、Resume ID、C−RNTI、及びUE Contextを関連付けて保存してもよい。
eNB200(アンカーeNB)は、eNB主導のページング方式において用いられるページングエリア(RANページングエリア)内の他のeNB200に対して当該識別情報を通知してもよい。eNB200は、X2 Pagingメッセージ(図11のステップS2006参照)で識別情報を通知してもよい。
ページングオケージョン(PF/PO)の決定に用いる識別情報は、IMSIであってもよいし、他の識別情報(例えば、S1ページングメッセージ中の「UE Identity Index Value」であってもよい。当該識別情報は、IMSIから所定の計算式(例えば、IMSI mod 1024)を用いて算出されるUE IDであってもよい。
・MME300Cから識別情報を取得するケース
MME300Cは、S1メッセージの一種であるUE CONTEXT MODIFICATION REQUESTメッセージによって、当該識別情報をeNB200に通知してもよい。UE CONTEXT MODIFICATION REQUESTメッセージは、既に確立したUEコンテキスト(すなわち、eNB200に存在するUEコンテキスト)の一部を変更するメッセージである。MME300Cは、他のS1メッセージ(例えば、INITIAL CONTEXT SETUP REQUEST、UE RADIO CAPABILITY MATCH RESPONSE)によって、当該識別情報をeNB200に通知してもよい。INITIAL CONTEXT SETUP REQUESTメッセージは、UEコンテキストを確立(すなわち、eNB200内にUEコンテキストを作成)することを要求するメッセージである。UE RADIO CAPABILITY MATCH REQUESTメッセージは、UE100の無線能力(capability)情報がMME300CとeNB200とで一致しているかを確認する為にMME300CからeNB200に通知される要求メッセージである。
MME300Cは、当該UE100がLight Connectionをサポートしている場合に限って識別情報をeNB200に通知するとしてもよい。
MME300Cは、eNB200から、識別情報の問い合わせがあった場合(新たなメッセージ)に限って識別情報をeNB200に通知するとしてもよい。例えば、eNB200は、RANページングが必要になった場合、及び/又はUE100をLight Connectionに遷移させた場合に、MME300Cに対して問い合わせを行う。
・UE100から識別情報を取得するケース
UE100は、eNB200からのRRC Connection Releaseメッセージに対する応答メッセージであるRRC Connection Release Completeメッセージで識別情報をeNB200に通知してもよい。UE100は、RRC Connection Releaseメッセージ中でLight Connectionへの遷移が指示されている場合に限って識別情報をRRC Connection Release Completeメッセージに含めるとしてもよい。
UE100は、RRC Connection Releaseプロシージャ以外のプロシージャを用いてもよい。例えば、UE100は、RRCのプロシージャの一種であるUE Informationプロシージャを用いてもよい。UE100は、eNB200から問い合わせに対して、応答(UE Informationメッセージ)に識別情報を含めてもよい。UE100は、RRCのプロシージャの一種であるUE Capability Transferプロシージャを用いてもよい。UE100は、自身がLight Connectionをサポートしている場合に限って、識別情報を含むUE CapabilityメッセージをeNB200に送信してもよい。UE100は、RRCのプロシージャの一種であるUE Assistance Informationプロシージャを用いてもよい。UE100は、Light Connection状態のために用いるメッセージに識別情報を含めてもよい。このようなメッセージは、例えば、UE100においてデータ通信が発生していない(又は発生する見込みが無い)ことを示す通知メッセージであってもよい。
・NASメッセージを解読するケース
eNB200は、UE100とMME300Cとの間で送受信されるNASメッセージ(例えば、ATTACH REQUEST又はATTACH ACCEPT)を解読し、NASメッセージ中のIMSIを読みとる。eNB200は、読みとったIMSIをそのまま保存せず、PF/POを計算可能な数値情報に変換してから保存してもよい。
(その他の実施形態)
上述した実施形態において、PLMN(Public Land Mobile Network)について特に触れなかった。eNB200は、UE100に設定するRANページングエリアとして、RANページングエリア識別子又はセル識別子と共に、1以上のPLMN識別子(例えば、PLMN識別子のリスト)を設定してもよい。UE100は、自身に設定されたRANページングエリア識別子又はセル識別子をブロードキャストするセルであって、自身に設定されたPLMN識別子をブロードキャストするセルを、当該RANページングエリア内のセルと認識してもよい。
上述した各実施形態を別個独立に実施する場合に限らず、2以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の動作を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の動作を他の実施形態の一部の動作と置換してもよい。
上述した各実施形態において、移動通信システムとしてLTEシステムを例示した。しかしながら、実施形態はLTEシステムに限定されない。LTEシステム以外のシステムに実施形態を適用してもよい。例えば、第5世代通信システム(5Gシステム)に対して実施形態を応用してもよい。5Gシステムにおいて、新たなRRCの状態としてInactive状態(Inactiveモード)が検討されており、実施形態におけるLight Connection状態をInactive状態と読み替えてもよい。また、5Gシステムにおいてコアネットワークページングを行う主体はMME以外のエンティティであってもよい。また、5Gシステムに実施形態を適用する場合、RANページングをRANノティフィケーションに、RANページングエリアをRANノティフィケーションエリアにそれぞれ読み替えてもよい。
(付記)
(1.はじめに)
本付記では、議論されている問題について検討する。
(2.検討)
(2.1.RAN開始ページングメッセージにおけるS−TMSI受信)
論点1は、Resume IDがRANによって開始されたページングメッセージで使用されるという作業仮定に合意した。UEはページングメッセージ中のS−TMSIとResume IDの両方をチェックする必要がある。S−TMSI受信時のUEの動作については更なる検討が必要である。
現仕様で述べられているように、ページングメッセージは、ページング情報、SI変更通知、ETWS/CMAS通知、EABパラメータ変更、及びE−UTRANのインター周波数再分配トリガをUEに通知するために使用される。ページング情報及びETWS/CMAS通知のためのUuページングメッセージは、通常、S1ページング及びS1書き込み−置き換え警告要求によってトリガされ、他の目的のためのものはeNBによって開始される。
eNBの観点からは、S−TMSIはRRC Connection Request、RRC Connection Setup Complete又はS1 PAGING内でのみ提供される。S−TSMIはSA3によって通知されるように、セキュリティ上の理由で頻繁に更新されている。したがって、eNBは、特定のUEの現在のS−TSMIの知識を有していない可能性がある。
したがって、ライトコネクション内のUEへのRAN開始ページングメッセージがS−TMSIを含む場合、ページングメッセージはMMEによって実際にトリガされる、すなわちS1PAGINGである。これは何らかの異常状態とみなすことができ、例えば何らかの理由でRAN開始ページングが到達不能であり、(アンカー)eNBがMMEにレガシーCN制御ページングを開始するように要求する。
したがって、UEのS−TMSI受信時の動作について議論する前に、UEがRANによって開始されるページングメッセージ内でそのS−TMSIを受信するケースがどのようなものかどうか、及びそのケースを明確にすべきである。
提案1:RAN2は、「S−TMSIの受信時のUE動作」を識別する必要がある場合、UEがRANによって開始されるページングメッセージ内でそのS−TMSIを受信するケースあるか否か及びどのようなケースであるかを明確にすべきである。
S−TMSIを含む既存のメッセージを図14に示す。
(2.2.RANページングエリアID)
これは、「RAN設定ページングエリアを定義する別のオプションとして、新しいRAN設定のページングエリア識別子(ID)を考慮する必要があるか」という点に関連する。
設定されたRANページングエリアは、次のいずれかのオプションになる。
・セルのリスト
・単一のセル
・CNトラッキングエリアと同じ
FFS:IDで示されるページングエリア
これらのオプション(「RANページングエリアID」を含む)は、さまざまなシナリオで有用と考えることができる。例えば、ネットワークは、各UEに対して柔軟な設定を必要とする場合には「セルのリスト」を使用し、シグナリングオーバヘッドを最小限に抑えたい場合には「RANページングエリアID」を使用し得る。したがって、RANページングエリアの設定に1つ以上のオプションを導入することが望ましい。
提案2:RAN2は、ブロードキャストされるRANページングエリアIDを導入すべきである。
提案2が納得できる場合、問題は複数のRANページングエリアIDが有用か否かである。例えば、セルが2つのRANページングエリア、例えばより大きなエリア及び別のより小さいエリアに属する場合、サービングセルは、どのRANページングエリアが各UEに適しているかを選択することができる。例えば、高モビリティUEには、頻繁な通知を避けるためのより広いエリアを設定し、静止UEには、RANページングによるシグナリングオーバヘッドを低減するために、より小さいエリアで設定されてもよい。別の例として、セルごとに単一のRANページングエリアIDのみがブロードキャストされると仮定すれば、UEのRANページングエリアを複数のRANページングエリアIDで設定することは可能であり、RANページングエリアは個々のエリアの組み合わせである。両方の場合において、UEは、必要に応じて、異なるサイズのRANページングエリアで設定されてもよい。したがって、複数のRANページングエリアIDをブロードキャスト及び/又は設定できるようにするかどうかについて検討する価値がある。
提案3:RAN2は、複数のRANページングエリアID(ブロードキャスト及び/又は設定)を許可するかどうかについて議論する必要がある。
単一のRANページングエリアIDのみがブロードキャストされ、設定されている、すなわち、提案3が合意できないと判断された場合、RANページングエリアに明示されているので、ライトコネクションに入ると、UEをRANページングエリアIDで明示的に設定する必要はない。設定されるIDは、UEをライトコネクションに送信するアンカーeNBによってブロードキャストされるものと同じであるからである。さもなければ、いくつかのピンポンが懸念されるかもしれない。例えば、異なるRANページングエリアIDがUEに設定されている場合、通知を送信するために直ちにRRC Connectedに戻らなければならない、そのため、TS36.331のCRのRAN−PagingAreaInfo−r14には、ID自体ではなく、「run−pagingAreaId」がENUMERATED{true}と定義されている必要がある。
提案4:セルが単一のRANページングエリアIDだけをブロードキャストできる場合、UEは、RANページングエリアIDの明示的な設定なしに、UEをトリガする「アンカーeNB」によってブロードキャストされるRANページングエリアIDを暗黙的に使用してライトコネクションに進む。
複数のRANページングエリアIDの例を図15に示す。
(2.3.NASとの相互作用)
論点8は、「UE NASがライトRRC接続にあるときにUE NASが認識する必要があるか」であり、NASとASの間に何らかの追加の相互作用の可能性を暗示しているようである。
RAN2は、MMEとUEとの間のECM状態の不一致、すなわちECM Connectedに留まることを回避するために有益なModeling A−2、すなわちRRC Connectedに基づくモデルに合意した。したがって、Light ConnectionのUEの間に、NASが現状のようにECM Connectedプロシージャを実行するだけであると仮定できる。言い換えれば、Light ConnectionはNASの観点からは透過的であるかもしれない。例えば、NASシグナリングが起こるとき、ASは、「完全な」RRC接続状態を取り戻すためにRRC接続再開手順を開始する。
考察1:ベースラインとしてLight Connectionは、NASの観点からは透過的である。
しかし、RRC Connection Resume手順が失敗した、すなわちUEがRRC Connection Rejectを受信するなど、何らかの異常な場合があり得る。NASの観点からは「RRC Connection failure」状態であると見なすことができる。なぜなら、それはASの単なるエラーであるからである。「リリース8以降、CT1は、AS層からの「RRC Connection failure」インジケーションに基づいて、EMM−CONNECTEDモードでUEのRRC接続を再確立するために、TAUトリガ(TS24.301の5.3.1.3節)を有するというCT1の情報と整合しているようである。
「CT1はモデリングAの場合にRRC接続確立へのフォールバックをどのように実装するかについて詳しく調べるのに時間がかかるが、上記の理由から、フォールバックにはASとNASの間の明白な相互作用が必要であると仮定している。したがって、現在のCT1仕様で指定されているサービス要求に対して、上記のTAUトリガ又は同様のトリガと類似している可能性がある。」という情報を考慮すると、同様のメカニズムに追加の機能を指定することは避けるべきであり、ASは、ライトコネクションからRRCコネクションへの移行中にRRC Connection Rejectを受信した際に「RRC Connection failure」とみなして通知する。
提案5:RAN2は、UEがライトコネクションから「完全な」RRCコネクティッドに戻るのに失敗した場合に、ASが「RRC接続失敗」をNASに通知することに同意すべきである。
(2.4.ライトコネクションサポートのインジケーション)
論点9は、「eNBはライトRRC接続をブロードキャストする必要があるか」であり、「UEはライトコネクションの機能がセル内でサポートされているかどうかを知るべきである」かは未だFFSである。ライトコネクションのUEは、ネットワーク内のすべてのeNBがライトコネクションからRRC接続への復帰をサポートしている限り、「RRCアイドルにおけるセル再選択ベースの移動性、RRCアイドルにおける同じセル再選択メカニズムを実行する」と仮定することができる。一方、リリース13はネットワーク内のすべてのeNBが新しい機能をサポートしていると想定していなかったため、新しい機能の開始が許可されているかどうかのインジケーションを有し、例えばeDRX−VoLTE確立のためのeDRX、voiceServiceCauseIndication、RRC接続再開のためのUp−CIoT−EPS最適化、NAS上のデータである。
UEがライトコネクション中にRRC接続再開を開始する、すなわち「完全な」RRC接続に戻すため及びRANページングエリア更新(PAU)のためにUEが開始する2つの可能なケースがある。前者の場合は、RANページングエリアにライトコネクションをサポートしないセルが含まれていないと可能ではないかもしれないが、後者の場合はまだ問題がある。UEは、RANページングエリア外のセルに入るたびにPAUのための特別なRRC接続再開手順を開始する。すなわち、PAUに対するASによってトリガされたRRC接続再開手順はPAUに関する追加の指示を含む。しかし、UEはセルがPAU手順を受け入れることが許容されるかどうかを知らない。従って、セルがライトコネクションをサポートしているか否かは、UEにSIBで通知されるべきである。
提案6:RAN2は、セルがライトコネクションをサポートする場合、すなわちUEがライトコネクション中にRRC接続再開要求を送信することが許可されている場合、SIB2中にインジケーションを導入すべきである。
提案6が合理的である場合、疑問点は、ライト接続のUEがそのようなeNBに属するセルに入るときにどのように振る舞うかである。UEは、MT呼のRAN開始ページングから到達できなくなる可能性があり、かつ/又はMO呼のためにRRC接続再開を開始しない可能性があるためである。
可能な解決策の1つが、セル再選択手順において考慮され得る。例えば、UEは、Light Connectionをサポートするセルに優先順位をつけることができ、それによって、例えば、セルのリストを有する設定されたRANページングエリア又はSIB(提案6)によってセルを決定することができる。この強化は、例えば、1つの周波数層のみがライトコネクションをサポートしない場合など、問題のある状態を可能な限り避けることが期待される。したがって、UEは、ライトコネクション中のセル再選択において、ライトコネクションをサポートするセルの優先順位付けを許可されるべきである。
提案7:RAN2は、UEがセル再選択手順においてライトコネクションをサポートしているセルに優先順位を付けることが許されることに同意すべきである。
提案7が適用可能であっても、ライトコネクションをサポートするセルがUEのロケーション上に見つからないので、ライトコネクションのUEは最終的にライトコネクションをサポートしないセルを最終的に再選択する可能性がある。この場合、Light ConnectionのUEは自律的にRRC アイドルに移行する必要があり、おそらくASはセクション2.3で説明した障害の場合と同様に、NAS回復をトリガするためにNASに「RRC Connection failure」を通知する。さらに、UEがアイドルに移行する必要があるとき、すなわち、即座に、又はMOシグナリング/データが発生したときのみ、又はMTアクセスが受信されたときにのみであるかを議論すべきである。
・オプション1:UEがライトコネクションをサポートしていないセルに入るとすぐにアイドルへ遷移する。
長所:これはUEの視点から見れば最も簡単な動作である。
短所:ライトコネクションに滞在する機会を最小限に抑える。したがって、UEがライトコネクションをサポートしていないセルを通過するときはいつでも、アイドルからRRC Connectedへの追加シグナリングとNAS回復のための追加シグナリングが必要である。
・オプション2:ライトコネクションをサポートしていないセルでMO/MT呼が発生した場合のみアイドルに遷移する。
長所:ライトコネクションをサポートしていないセルでMO/MT呼が発生しない限り、UEはライトコネクションを維持できる。
短所:ライトコネクションのUEは、アイドルの場合と同様に、ページングメッセージ内のレガシーページング、つまりIMSI又はS−TMSIを監視する必要がある。
あるいは、UEが以下のようにセル再選択の前にアクションをとることも可能である。
オプション3:ライトコネクションをサポートしていないセルを再選択する前にRRC接続再開を開始する。
長所:(アンカー)eNBは、UEのRRC状態の移行を制御する。また、他のオプションと比較して、呼の再設定の遅延を最小限に抑えることも期待される。さらに、(アンカー)eNBは、UEコンテキストの必要性を判断する(すなわち、コンテキストを除去するか、又はコンテキストを転送する)ことができる。
短所:オプション1と同様にライトコネクションの時間が短くなる。例えば、サービングセルがライトコネクションをサポートしていない隣接セルのリストを提供し、UEがRRC Resume手順などを使用してLight Connectionをサポートしていないセルに再選択しようとするときをeNBに通知する必要がある場合など、いくつかの追加の標準化努力が必要になり得る。
このWIの目的を考慮すると、オプション2はシグナリングの低減に好適である。
提案8:RAN2は、Light Connectionをサポートしていないセル内にあるMO/MT呼が発生したときにLight ConnectionのUEがアイドルに移行する(及び/又はASがNASに「RRC Connection failure」を通知する)ことに合意すべきである。
オプション3では問題はないが、オプション1と2では、NWのRAN開始ページングの「フォールバック」メカニズムを想定する必要がある。eNBはライトコネクションをサポートしていないため、たとえば「アンカーeNB」がRANによって開始されたUEへのページングが到達不能であることに気付いたときにMMEにS1 PAGINGを開始するように要求する必要がある。
提案9:RAN2は、レガシーページングに対する「フォールバック」メカニズムが必要かどうかを議論する必要がある。
ライトコネクションをサポートしていないセルのUE動作のオプションを図16に示す。
(2.5.ページング機会(IMSI mod x))
「UE ID(IMSI mod x)がRANベースのページングにおけるPO/PF計算に使用される」ことが合意された。しかし、UEのPF/POを決定するために、eNBがライトコネクションにおける特定のUEのIMSIをどのように知るかは依然として不明である。現在、eNBがS1 PAGING、すなわちUE_ID、すなわちIMSI mod 1024又は4096である「(拡張)UEアイデンティティインデックス値」を受信すると、それは知ることができる。しかし、eNBがライトコネクションでUEにRANによって開始されたページングを送信したいときはいつでも、eNBがメッセージを送信するようにMMEに依頼しなければならないことは幾分奇妙である。
考察2:Light ConnectionでeNBがUEのPF/POをどのように決定するかはまだ不明である。
3つの選択肢は以下のように考えることができる。
選択肢1:eNBはUEをLight Connectionに移すとき、MMEから「UE Identity Index Value」を取得する。
選択肢2:UEは、そのIMSI又はUE_IDのいずれかをeNBに通知する。
選択肢3:eNBは、ATTACH REQUESTのように、NAS PDU内のUEのIMSIを把握する。
選択肢1は、現在のコンセプト、すなわち、「(拡張)UEアイデンティティインデックス値」は、MMEによって管理され提供される。しかし、WIの目標である「S1からのインターフェイスへのCNへのシグナリングの減少は、CNからそれらを隠すことによって、モビリティと状態遷移によってシグナリングを削減すること」に類似しており、他のWGの標準化の努力が必要である。
選択肢2はRAN2内で決定されるが、問題はどのメッセージが情報を伝えるべきかである。通常、UEがライトコネクションに入ったとき、すなわち「Complete」メッセージを使用するときには、IMSI又はUE_IDを通知するのが自然かもしれないが、RRC Connection Release手順は応答メッセージを持たない。別の可能性は、UE情報手順又はUE能力転送手順を使用することであるが、情報を得るためにeNBが常に要求/照会を必要とする。
選択肢3は実装に依存するため、仕様への最小限の影響が期待される。しかし、そのような実装、すなわちクロスレイヤ相互作用を想定することが許容できるかどうかは不明である。
これらの選択肢には長所と短所があるが、期限までにWIを完了するためには、選択肢2が望ましいかもしれない。
提案10:RAN2は、eNBがPF/POを決定するために、UEがそのIMSI又はUE_IDのいずれかをeNBに通知してもよいことに同意すべきである。
提案11:RAN2は、情報転送のためにどのメッセージを使用すべきかを議論すべきである。
さらに、「アンカー」eNBは、例えば「X2ページング」を介して、異なるeNBのカバレッジにおいてUEにMT呼が発生したときに、IMSI、UE_ID又は「UEアイデンティティインデックス値」を他のeNBに転送する必要がある。
考察3:IMSI又はUE_IDは、RAN開始ページングプロセス中に、「アンカー」eNBから他のeNBに転送する必要がある。
(2.6.RRC接続中のデータ非アクティブの認識)
UEはRRCシグナリングによって軽く接続されているため、サービングセルはUEをトリガしてライトコネクションに入るタイミングを決定する必要がある。実現可能な実装の1つは、サービングセルがトラフィックの挙動を監視し、UEが一定時間(例えば、一定期間)非アクティブであるために、ライトコネクションに入るようにトリガすることである。このメカニズムは予想されるトラフィックの振る舞いに依存するため、予想されるトラフィックの推定が不正確である場合、例えばライトコネクションとRRC接続との間の頻繁な遷移によりシグナリングオーバヘッドが実際に増加するか、ライトコネクションに入る機会が失われる。予想されるMTCタイプのトラフィックは容易に推定できるが、LTEタイプのトラフィックは、スマートフォンのトラフィック挙動は、NWが予測するのは簡単ではないかもしれない。したがって、UEは、そのトラフィック挙動のより良い知識/制御を有するので、UEが何らかの支援情報を提供することが必要な場合がある。したがって、サービングセルがUEを設定して、eNBがUEをライトコネクションにトリガするためのより良い決定を行うことを可能にする特定の支援情報を提供するかどうかを検討する価値がある。
提案12:RAN2は、サービングセルが支援情報を提供するようにUEを設定することができるか否かを議論して、UEがライトコネクションに入るようにトリガするタイミングをeNBがより良好に決定できるようにすべきである。
提案12に納得できる場合、支援情報は、既存の電力嗜好インジケーション(PPI)及び/又はMBMS関心インジケーション(MII)と類似している可能性がある。PPIを用いる場合、UEは、その消費電力が、例えばより長いDRXサイクルによって最適化されることが好ましい場合、低消費電力を通知することができる。MIIは、例えば、周波数へのハンドオーバが好ましい場合に、ユニキャストとMBMSとの間の関心のあるMBMS周波数及び優先順位を通知するために使用された。この場合、UEは、UEがライトコネクションに入ることが適切であるとき、サービングセルに通知することができる。言い換えれば、UEは、データ送受信が一定の期間内に非アクティブであった場合、又は非アクティブである場合に支援情報を送信することができる。追加の援助の詳細及び必要性、例えばUEの予想非アクティブ時間については更なる検討が必要である。
RAN2は、UEがデータ非アクティブ時に支援情報を送信すべきかどうかを考慮すべきである。
(相互参照)
本願は米国仮出願第62/454177号(2017年2月3日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。