(移動通信システムの構成)
以下において、実施形態に係る移動通信システムの構成について説明する。図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)及びサービングゲートウェイ(S−GW)300を含む。MMEは、UE100に対する各種モビリティ制御等を行う。MMEは、NAS(Non−Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するトラッキングエリア(TA)の情報を管理する。トラッキングエリアは、複数のセルからなるエリアである。S−GWは、データの転送制御を行う。MME及びS−GWは、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インターフェイス上で行う通信等に用いられる。
なお、MMEは、制御部及びネットワーク通信部を有する。制御部は、MMEにおける各種の制御を行う。制御部は、少なくとも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レイヤとMMEのNASレイヤとの間では、NASシグナリングが伝送される。なお、UE100は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等の機能を有する。
図5は、LTEシステムにおいて用いられる無線フレームの構成を示す図である。図5に示すように、無線フレームは、時間軸上で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により指定される。
・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の動作フローを示す図である。
図6に示すように、ステップ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に設定されたRANページングエリア識別子としてブロードキャストシグナリング中の識別子(すなわち、ステップS10で受信したRANページングエリア識別子)を保持する。
このように、UE100は、Light Connection状態に遷移する指示(RRC Connection Reconfiguration又はReleaseメッセージ)を受けた場合、現在ブロードキャストされているRANページングエリア識別子を取得又は既に保持しているRANページングエリア識別子が有効であれば読み出して、自身に割り当てられたRANページングエリア識別子として保持する。UE100が保持する変数にRANページングエリア識別子が格納されてもよい。
図7は、第1実施形態の動作パターン1に係る動作シーケンス例を示す図である。
図7に示すように、ステップ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と同じステップ番号を付している。
図8に示すように、ステップ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ページングエリアが現在のサービングセルのみからなる旨の情報を保持してもよい。
(第2実施形態)
第2実施形態について、第1実施形態との相違点を主として説明する。
図9は、第2実施形態に係る想定シナリオを示す図である。図9に示すように、eNB200−1はセルA,Bを管理しており、eNB200−2はセルC,D,Eを管理しており、eNB200−3はセルF,Gを管理している。
セルA,B,C,D,Eは1つのRANページングエリアを形成し、当該RANページングエリアの識別子として「PA ID=1」が割り当てられている。セルA,B,C,D,Eのそれぞれは、「PA ID=1」をブロードキャストする。
セルF,Gは1つのRANページングエリアを形成し、当該RANページングエリアの識別子として「PA ID=2」が割り当てられている。セルA,B,C,D,Eのそれぞれは、「PA ID=1」をブロードキャストする。
セルA,B,C,D,E,F,Gは1つのRANページングエリアを形成し、当該RANページングエリアの識別子として「PA ID=3」が割り当てられている。セルA,B,C,D,E,F,Gのそれぞれは、「PA ID=3」をさらにブロードキャストする。
このように、1つのセルに複数のRANページングエリア識別子を割り当てることにより、同一地域内において、広さの異なる複数のRANページングエリアを設けることができる。
図10は、第2実施形態に係る動作を示す図である。図10に示すように、eNB200(送信部210)は、自セル(又は自eNB)に複数のRANページングエリアが割り当てられた場合において、複数のRANページングエリア識別子を含むリスト(PA IDリスト)を、自セルを介してUE100に送信する。
・動作パターン1
第2実施形態の動作パターン1において、eNB200(送信部210)は、自セル(又は自eNB)に割り当てられた複数のRANページングエリア識別子を含むリストをブロードキャストシグナリングにより送信する。ブロードキャストシグナリングは、ブロードキャストRRCシグナリング(SIB:System Information Block)であってもよい。
一例として、Light Connection状態にあるUE100は、RRCアイドルモードと同様なセル再選択メカニズムを用いて他のセルを再選択する際に、当該他のセル(新たなセル)からブロードキャストされるPA IDリストを受信する。UE100(制御部130)は、自身に設定されたRANページングエリア識別子を、当該リスト中の各RANページングエリア識別子と比較する。UE100(制御部130)は、自身に設定されているRANページングエリア識別子が、当該リスト中の全てのRANページングエリア識別子と異なる場合、自身に設定されたRANページングエリアを出た旨を当該他のセル(新たなセル)に通知する。
また、1つのセルが複数のRANページングエリアに属する場合、当該UE100に対して適切なRANページングエリアを設定することが好ましい。一例として、eNB200(制御部230)は、UE100をLight Connection状態に遷移させる場合において、当該UE100の移動状態に基づいて、自セルが属する複数のRANページングエリア識別子の中からUE100に設定するRANページングエリア識別子を選択する。UE100の移動状態とは、UE100が静止しているか又は移動しているか、及び/又はUE100の移動速度であってもよい。UE100の移動状態は、UE100からeNB200に通知されてもよいし、MME300からeNB200に通知されてもよい。eNB200(制御部230)は、UE100が移動(又は高速移動)している場合に、UE100に設定するRANページングエリアとして、より広いRANページングエリアを選択してもよい。eNB200(送信部210)は、UE100の移動状態に基づき選択されたRANページングエリア識別子をユニキャストシグナリングによりUE100に送信する。
・動作パターン2
第2実施形態の動作パターン2において、eNB200(送信部210)は、UE100に設定する複数のRANページングエリア識別子を含むリスト(PA IDリスト)をユニキャストシグナリングにより送信する。ユニキャストシグナリングは、Light Connection状態に遷移させるユニキャストRRCシグナリング(RRC reconfigurationメッセージ又はRRC releaseメッセージ)であってもよい。UE100は、Light Connection状態に遷移するとともに、UE100に設定されたRANページングエリア識別子としてPA IDリストを保持する。
複数のRANページングエリア(PA IDリスト)が設定されたUE100(制御部130)は、当該複数のRANページングエリア間を跨いで移動する際には、ネットワークへの通知を行なわなくてもよい。一例として、UE100(受信部110)は、RRCアイドルモードと同様なセル再選択メカニズムを用いて他のセルを再選択する際に、当該他のセル(新たなセル)からブロードキャストされるページングエリア識別子を受信する。UE100(制御部130)は、自身に設定された複数のRANページングエリア識別子を、当該他のセル(新たなセル)のRANページングエリア識別子と比較する。UE100(制御部130)は、自身に設定されている全てのRANページングエリア識別子が、当該他のセル(新たなセル)のRANページングエリア識別子と異なる場合、自身に設定されたRANページングエリアを出た旨を当該他のセル(新たなセル)に通知する。
なお、第2実施形態の動作パターン1及び2を組み合わせて実施してもよい。また、第2実施形態に係る動作を第1実施形態に係る動作と組み合わせて実施してもよい。一例として、eNB200は、自セルでブロードキャストしているRANページングエリア識別子と自セルでブロードキャストしていないRANページングエリア識別子とをUE100に設定する場合に、自セルでブロードキャストしていないRANページングエリア識別子のみを、Light Connection状態に遷移させるユニキャストRRCシグナリングに含めて明示的に設定してもよい。UE100は、当該セルでブロードキャストされているRANページングエリア識別子と明示的に設定されたRANページングエリア識別子とを保持する。
(第3実施形態)
第3実施形態について、第1及び第2実施形態との相違点を主として説明する。
図11は、第3実施形態に係る想定シナリオを示す図である。図11に示すように、Light Connection状態にあるUE100は、複数のセルを跨いで移動する。しかしながら、Light Connection状態を取り扱う機能を有しないセル(eNB200)も存在し得る。Light Connection状態を取り扱う機能とは、例えばRANページングの機能及びLight Connection状態からUE100を復旧させる機能等である。以下において、このような機能を有しないセルを「Light Connectionをサポートしないセル」と称する。
図11において、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をサポートしないセルとみなしてもよい。
第3実施形態において、UE100(制御部130)は、RANページングエリアが設定されたLight Connection状態において、Light Connection状態を取り扱う機能をサービングセルがサポートするか否かを判定する。UE100(制御部130)は、当該機能をサービングセルがサポートしないと判定した場合でも、サービングセルにおいてLight Connection状態を維持する。よって、Light Connection状態のUE100は、図11に示すセルAからセルBに移動しても、Light Connection状態を維持する。言い換えると、UE100は、Light Connectionをサポートしないセルを再選択しても、Light Connection動作を中止せずに継続する。
比較例として、セルAからセルBに移動した際に、Light Connection動作を中止し、通常のRRCアイドルモードの動作を行うことが考えられる。しかしながら、その後にUE100がセルBからセルCに移動するシナリオを想定すると、UE100は、セルBにおいてLight Connection動作を継続することが好ましい。
第3実施形態において、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等)の検出を行う。
(その他の実施形態)
上述した実施形態において、PLMN(Public Land Mobile Network)について特に触れなかった。eNB200は、UE100に設定するRANページングエリアとして、RANページングエリア識別子又はセル識別子と共に、1以上のPLMN識別子(例えば、PLMN識別子のリスト)を設定してもよい。UE100は、自身に設定されたRANページングエリア識別子又はセル識別子をブロードキャストするセルであって、自身に設定されたPLMN識別子をブロードキャストするセルを、当該RANページングエリア内のセルと認識してもよい。
上述した実施形態において、RANページングが送信されるタイミングがIMSIによって特定される場合について特に触れなかった。この場合、基地局は、RANページングを行うためのUE100のIMSIを知らない為、UE100からIMSIを通知してもらう必要がある。そこで、UE100は、自身のIMSIを、自身がLight Connection機能をサポートする旨の能力情報として基地局に通知する。言い換えると、基地局は、UE100の能力情報においてIMSIが通知された場合は、当該UE100がLight Connection機能をサポートしていると判断し、当該IMSIをRANページングタイミングの特定に用いる。
上述した各実施形態を別個独立に実施する場合に限らず、2以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の動作を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の動作を他の実施形態の一部の動作と置換してもよい。
上述した各実施形態において、移動通信システムとしてLTEシステムを例示した。しかしながら、本発明はLTEシステムに限定されない。LTEシステム以外のシステムに本発明を適用してもよい。
[付記1]
(1.はじめに)
この付記では、これらのモデリングについてのさらなる検討が議論される。
(2.検討)
(2.1.モデリング)
図12、図13、図14に、(1)UEがLight Connectionに入ったときの手順、(2)RRC Connectedに正常に戻り、(3)拒否されてフォールバックを実行するときの手順をそれぞれ示す。
モデリングAでは、RRC接続再開要求またはRRC接続再確立要求のいずれを使用してLight ConnectionからRRC Connectedに戻すかは依然としてFFSである。概念的には、メッセージングの観点からは、RRC接続が維持されている、すなわち、RRC Connectedに入るためのRRC接続再構成の使用により中断されていないので、RRC接続再確立要求がより適切である。さらに、RRC Connection Reestablishment Rejectの場合、従来のNASリカバリが再利用されることはすでに合意された。また、RAN2がRRC Connection Resume Requestを使用している場合、CT1は、「モデルAの場合のRRC Connection確立へのフォールバックの可能性についてのRAN2の質問に関して、CT1は、EMM−IDLEモードでUEにのみ使用されるRel−13で定義される。したがって、UEがRRC Connectedに戻るとき、RRC Connection Reestablishment Requestを使用することが望ましい。
提案1:モデリングAでは、UEがLight ConnectionからRRC Connectedに戻る必要がある場合、RRC Connection Reestablishment Requestを送信すべきである。
RAN2がモデリングの問題を支援するためにCT1に依頼するアプローチがあるが、CT1はAとBのモデリングの両方について予備的な議論を行い、AとBのモデリングの潜在的な影響を観察した。この問題について深い分析をしなければ迅速に回答を提供することは難しいであろう。したがって、RAN2は、どのモデリングを使用するかを独自に決定する必要がある。
考察1:RAN2はLight connectionに適用するモデリングを決定し、決定と詳細をCT1に通知すべきである。
WIの目標の最初の声明は、この作業項目の目的は、無線とネットワークインタフェースのシグナリングオーバーヘッドを削減し、すべてのデバイスタイプのUEアクセスレイテンシとUE消費電力を改善することである。すなわち、MTC UEだけでなくスマートフォンなどの通常のLTE UEのようなすべてのデバイスタイプと同様に、無線シグナリングオーバーヘッドおよびUEアクセス待ち時間削減を考慮すべきである。MTCタイプのトラフィックに関しては、Rel−13のRRC Connection Suspend/Resumeによってすでに最適化されたが、もちろん通常のLTE UEにも適用できる。しかし、例えば、一時的にデータが非アクティブという条件を仮定して、非MTCタイプのトラフィックについては同じではない。したがって、リリース14作業は、代わりにモデリングAに基づく典型的なLTE UE(例えば、スマートフォントラフィック)のシグナリングおよびアクセス待ち時間の低減に焦点を当てるべきである。
考察2:Light Connectionは、スマートフォンの使用に適用可能なものを含め、リリース13で既に最適化されているMTCタイプのトラフィックに限らず、すべてのタイプのトラフィックに対する無線オーバーヘッドとUEアクセスレイテンシの削減を考慮すべきである。
提案2:RAN2はLight ConnectionのモデリングAと一致するはずである。
(2.2.Light Connectedをサポートしていないセル)
モデリングの選択にかかわらず、UEがLight Connected機能がサポートされているかどうかをUEが知っておくべきであることはFFSである。RAN2は、RRC IDLEと同様のセル再選択メカニズムに同意した。したがって、ネットワーク内のすべてのeNBがLight ConnectionからRRC Connectedへの復帰をサポートしている限り、UEの動作はセル再選択の点でアイドルモード手順に従う。NW実装であるが、リリース13は、ネットワーク内のすべてのeNBが新たな特徴(例えば、eDRXのためのeDRX−Allowed、VoLTE確立のためのvoiceServiceCauseIndication、Up−CIoT−EPS−Optimization及びcp−CIoT−EPS最適化をサポートすると想定していない。したがって、ネットワーク内のすべてのeNBがLight Connectionをサポートしていると推測できるかどうかについて検討する価値はある。
提案3:RAN2は、セルがLight connectionをサポートする場合、すなわちUEがLight connectionからRRC接続に戻る要求に対するRRCメッセージを送信することが許可されている場合、SIB2にインジケーションを導入すべきである。
一部のeNBがLight Connectionをサポートしていない場合、UEはRANページングから到達不能になる可能性があるため、UEがどのように動作すべきかが問題である。可能性の1つは、UEがLight connectionをサポートするセルに可能な限り優先順位を付けることである。別の可能性は、Light connectionをサポートしていないセルを再選択するたびに、UEがRRC IDLEに遷移することである。RAN2は、Light connection中のUEベースの移動性の詳細を考慮すべきである。
提案4:提案3が合理的である場合、RAN2は、アイドルモード手順、例えば、セル再選択中の予想されるUE動作を議論すべきである。
(2.3.RRC接続中のデータ非アクティブの認識)
UEはRRCシグナリングによって軽く接続されているため、サービングセルはUEをトリガしてRRC Connectedに入るタイミングを決定すべきである。可能な実装の1つは、サービングセルがトラフィックの挙動を監視し、UEが一定時間(例えば、一定時間)活動しないためにRRC Connectedに入るようトリガすることである。このメカニズムは予想されるトラフィックの振る舞いに依存するため、予想されるトラフィックの推定が不正確である場合、例えばRRC ConnectedとRRC接続との間の頻繁な遷移によりシグナリングオーバーヘッドが実際に増加するか、RRC Connectedに入る機会が失われる。予想されるMTCタイプのトラフィックは容易に推定できるが、LTEタイプのトラフィックは、スマートフォンのトラフィック行動は、NWが予測するのは簡単ではないかもしれない。したがって、UEは、そのトラフィック動作のより良い知識/制御を有するので、UEが何らかの支援情報を提供することが必要な場合がある。したがって、サービングセルがUEを設定して、eNBがUEをLight connectionにトリガするためのより良い決定を行うことを可能にする特定の支援情報を提供するかどうかを検討する価値がある。
提案5:RAN2は、サービングセルが、支援情報を提供するようにUEを設定することができるか否かを議論して、eNBがいつUEをLight connectionに入るようにトリガするかをより良く決定できるようにするべきである。
提案5が妥当である場合、支援情報は、既存の電力嗜好指標(PPI)及び/またはMBMS関心表示(MII)と類似している可能性がある。PPIを用いる場合、UEは、その消費電力が、例えばより長いDRXサイクルによって最適化されることが好ましい場合、低電力消費を通知することができる。MIIは、例えば、周波数へのハンドオーバーが好ましい場合に、ユニキャストとMBMSとの間の関心のあるMBMS周波数及び優先順位を通知するために使用された。この場合、UEは、UEがLight connectionに入ることが適切であるとき、サービングセルに通知することができる。言い換えれば、UEは、データ送受信が一定の期間内に非アクティブであった場合、または非アクティブである場合に支援情報を送信することができる。追加の援助の詳細及び必要性は、FFS、例えば、UEの予想非アクティブ時間である。
提案6:RAN2は、UEがデータ非活性時に支援情報を送信すべきかどうかを検討すべきである。
[付記2]
(1.はじめに)
本付記は、モデリングAの詳細について説明する。
(2.1.RANページングエリア)
RANページングエリアでUEを設定する方法はまだFFSである。2つの選択肢が議論されている。
オプション1:ベースラインとして、提案2をとる。eNBは、RANベースのページングエリアを示すためにRRC専用シグナリングを介してグローバルセル識別リストをUEにオプションでシグナリングすることができる。シグナリングと設定のオーバーヘッドを最小限に抑えることを目的とすべきである(たとえば、グローバルセルIDの代わりにcellIdentityを使用することもできる)。
オプション2:eNBは、専用シグナリング(使用すべきRANベースのページングエリアをUEに設定するために)及びブロードキャスト(eNBが属しているRANベースのページングエリアを示すために)を送る。
これらのオプションは、それぞれ異なるシナリオで有用とみなされる可能性がある。例えば、ネットワークは、各UEに柔軟な設定が必要な場合はオプション1を使用し、シグナリングオーバーヘッドを最小限に抑えたい場合はオプション2を使用することもできる。したがって、RANページングエリアの設定には2つのオプションを導入すべきである。
提案1:RAN2は、セルIDリストとブロードキャストされたRANページングエリアIDとを有する、RANページングエリア設定のための2つのオプションを導入すべきである。
提案1が合理的である場合、異なる実装のために、2つのオプションが混在したネットワーク内の異なるUEに同時に設定される場合に、1つの懸念が生じる可能性がある。RANページングエリア内のセルが、X2を介して「アンカーeNB」、すなわちX2ページング到達可能セルと接続されたeNBのみを含むと仮定することができる場合、そのような混合配置は、アンカーeNBが設定されたRANベースのページングエリア外に移動したときに軽度に接続されたUEがネットワークに通知すべきであるため、両方のオプションで同時にUEを設定することは禁止される。設定されたRANページングエリア外のUEはRRC接続に戻り、必要に応じて新しいRANページングエリアで再設定される。したがって、UEの到達可能性の観点からは問題がないと少なくとも考えられる可能性がある。
提案2:提案1が納得のいくものである場合、UEは両方のオプションを同時に設定すべきではない。
オプション1(セルIDリスト)については、どのセルIDが適用されるべきかFFSである(ECGI(「PLMN ID+ECI」)、ECI(「eNB ID+CI」:CellIdentity])又は物理セルID(PhysCellId)。長いIDはUEの混同を避けることができるが、シグナリングオーバーヘッドが増え、短いIDほど混同する可能性がある。したがって、妥協したソリューションとして、RAN2はリスト内のCellIdentityの使用を検討すべきである。混同の懸念が依然として存在する場合、PLMN ID(又はそのリスト)は、セルIDリストとともにオプションで設定されてもよい。
提案3:オプション1の場合、RAN2はセルIDリストがCellIdentityで設定されるべきであることに同意すべきである。
オプション2(すなわち、ブロードキャストされたRANページングエリアIDを有する)に関して、提案は、「新たに定義されたRANベースのページングエリア識別子」、すなわち、サービングセルによってブロードキャストされるべき1つのRANページングエリアIDがあり、UEに設定されると解釈することができる。問題は、複数のRANページングエリアIDが有用かどうかである。例えば、セルが2つのRANページングエリア、例えばより大きなエリア及び別のより小さいエリアに属する場合、サービングセルは、どのRANページングエリアが各UEに適しているかを選択することができる。例えば、頻繁な通知を避けるために高移動性のUEはより広いエリアが設定され、RANページングによるシグナリングオーバーヘッドを低減するために静止UEはより小さいエリアで設定されてもよい。別の例として、単一のRANページングエリアIDのみがセルごとにブロードキャストされることができると仮定すれば、UEのRANページングエリアが複数のRANページングエリアIDで設定することは可能であり、それにより個別のエリアの組み合わせにより効率的にUEのRANページングエリアを設定する。両方の場合において、UEは、必要に応じて、異なるサイズのRANページングエリアで設定されてもよい。したがって、複数のRANページングエリアIDをブロードキャスト及び/又は設定できるようにするかどうかについて検討する価値がある。
提案4:オプション2では、RAN2は、複数のRANページングエリアID(ブロードキャスト及び/又は設定)を許可するかどうかについて議論すべきである。
単一のRANページングエリアIDだけがブロードキャストされ、設定されているというオリジナルの提案に固執することが決定された場合、RRC Connectedに入るときにRANページングエリアIDでUEを明示的に設定する必要はない。設定されるRANページングエリアIDは、UEをLight connectionに送信するアンカーeNBによってブロードキャストされるものと同じである。さもなければ、ブロックサイズされる異なるRANページングエリアIDがUEに設定されている場合、通知を送信するために直ちにRRC Connectedに戻らなければならない、いくつかのピンポンが懸念されるかもしれない。
提案5:オプション2では、セルが単一のRANページングエリアIDのみをブロードキャストできる場合、UEはRANページングエリアIDの明示的な設定なしに、UEをトリガーする「アンカーeNB」によってブロードキャストされるRANページングエリアIDを暗黙的に使用してLight Connectedに進む。
(2.2.RANページングメッセージ)
RRCのRAN始動のページングメッセージは、(必要に応じて拡張子を用いて)レガシーRRCページングメッセージを再利用することが定義されているが、S−TMSIを使用するか新しいRAN IDを使用するかは依然としてFFSである。
S−TMSIの使用には現在、セキュリティ上の懸念がある。RAN2は、MMEを制御せずにRANで開始されたページングのためのRRCメッセージでS−TMSIを公開する潜在的なセキュリティ問題に関するフィードバックをSA3に求める。したがって、RAN2はSA3の応答を最終的な決定前に待つ必要があるが、モデリングAとモデリングBと同様に、新しいRAN IDを導入するという前提で進めることは可能かもしれない。
議論されているように、新しいRAN IDはシグナリング削減のために明示的に定義されるべきである。RRC ConnectedのUEがC−RNTIで識別されていることを考慮すると、Light ConnectionのUEは、セル内のセルID(「アンカーeNB」に属する)+C−RNTIによって、設定済みのRANページングエリア内で識別することもできる。IDの内容が明示的に指定されている場合、UEは、RRCシグナリングを介してIDが明示的に設定されていなくてもページングされたかどうかを判断するために使用する。
提案6:新しいRAN IDが導入された場合、RAN2はそれを「セルID(CellIdentity)+C−RNTI」と定義すべきである。
提案7:提案6が納得できる場合、UEがLight Connectedに入ったときに、IDを「アンカーeNB」のセルからUEに明示的に割り当てる必要はない。
(2.3.RANページング機会)
RAN始動のページング機会の計算では、優先UE IDは「IMSI mod x」デザイン(従来のページング計算と同様)であると結論づけられた。このアプローチは、「オープンIssue5:RANページング失敗の場合の到達不能UEのeNBハンドリング」の場合に、UEがMME始動ページング及びRAN始動ページングの「二重チェック」を回避するのに有用である。eNBハンドリングは、eNBがS1 UEコンテキストリリースをトリガし、その前に、必要であればMMEにNAS NON DELIVERY INDICATIONを送信することであり、UEの観点から見えない。
FFSは、UE又はIMSによってのみ知られているので、UEのIMSIがサービングセルにどのように通知されるかである。RAN2は、「UEがビューのMME点からECM_CONNECTEDにあるときeNBに対して、『UE IMSI MOD X』を提供するためのシグナリングを可能にする任意の懸念があるかどうか」を求めているが、RAN2は既に、CNからの移動性と状態遷移を隠蔽するために、Light Connected状態が維持され、UEのS1コネクションがアクティブになっていると合意した。また、RAN3は、MMEがUEが軽いかどうか接続かどうかをMMEは気付いていないと考えられる。したがって、IMSIは、MMEではなくUEから通知されるべきである。
RAN2は、「UE−EUTRA−Capability IE内に新しいオプションの無線能力を定義して、UEがリリース14Light connection動作をサポートすることを示す」ことも合意した。したがって、IMSIにはLWAのwlan−MAC−Address−r13と同様の概念のように、Light Connectionサポート用の新しいUE機能を介して通知されることが妥当である。
提案8:「IMSI mod x」デザインが決定された場合、RAN2は、IMSIがUEによってLight connectionサポートのためのUE能力によって通知されることに同意すべきである。
しかしながら、提案8におけるIMSIのシグナリングが好ましくない場合、RAN2は、IDを持たない、すなわちC−DRXを再利用する解決策を検討すべきである。この解決策の関心事は、I−DRX PF/PO及びC−DRX OnDuration内のページングメッセージをUEが「二重チェック」すべきであることである。Light Connectionが一時的なデータ非活性の間に設定される。そのような短い期間は、Light connected UEが、専用のRRCシグナリングを介してeNBによって設定されることができる特定のDRX(これは、RANによって始動されるページングPO/PF計算に使用される)サイクルで設定され、少なくとも320,640,1280、及び2560msを含み、他の値も定義されるかはFFSである。
提案9:「IMSI mod x」デザインが決定されない場合、RAN2はC−DRXがRANページング機会に再利用されるべきであることに同意すべきである。
[相互参照]
本願は米国仮出願第62/417532号(2016年11月4日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。