[第1実施形態]
(セルラ通信システム)
第1実施形態に係るセルラ通信システムの構成について説明する。図1は、第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との無線通信を行う機能又はリソースを示す用語としても用いられる。1つのセルは1つのキャリア周波数に属する。
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インターフェイス上で行う通信等に用いられる。
図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:Physical Downlink Control Channel)として用いられる領域である。各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル(PDSCH:Physical Downlink Shared Channel)として用いることができる領域である。
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御情報を伝送するための物理上りリンク制御チャネル(PUCCH:Physical Uplink Control Channel)として用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル(PUSCH:Physical Uplink Shared Channel)として用いることができる領域である。
(適用シナリオ)
実施形態において、無人航空機向け又は飛行中のUE100がセルラ通信ネットワーク(E−UTRAN10)とのRRC接続を確立し、RRC接続を用いてセルラ通信を行うシナリオを想定する。かかる場合、UE100は、Aerial UE又はUAV UEと称されることがある。UE100が無人航空機に設けられてもよいし、UE100自身が無人航空機であってもよい。無人航空機は、図3に示す機能ブロックに加えて、バッテリ、GNSS(Global Navigation Satellite System)受信機、及び飛行用機構(例えば、モータ及びプロペラ等)を備える。或いは、UE100は、単に高度が高いところに位置するUE(例えば、高層ビルの最上階に居るUEなど)であってもよい。
図6は、実施形態に係るセルラ通信システムの適用シナリオの一例を示す図である。
図6に示すように、セルラ通信システム(LTEシステム)は、複数のeNB200a〜200fを備える。複数のeNB200a〜200fのそれぞれは6角形状の通信エリアを形成する。各通信エリアは、1又は複数のセルによって構成される。隣接する通信エリアを管理する一対のeNB200間には、基地局間インターフェイスであるX2インターフェイスが設定される。UE100は、接続先のセルを介してeNB200とのセルラ通信を行う。
現状のセルラ通信ネットワークは、Aerial UE又はUAV UEの存在を前提とせずにエリア設計がなされているため、Aerial UE又はUAV UEとセルラ通信ネットワークとの間で接続障害が発生しやすい。接続障害とは、無線リンク障害(RLF)及びハンドオーバ障害(HOF)等をいう。具体的には、通常のセルラ通信ネットワークは、地上(陸上)のUEに対してエリアを最適化している為、上空(高度が高い)UEに対しては、エリアが最適化されていない。また、上空(高度が高い)のUEはeNBに対して見通し内となり、アンテナゲインは高度が高いほど高くなるといった理由により、eNBの電波が上空では遠くまで飛びすぎる。
RRCコネクティッドモードにあるUE100がサービングセルとの接続障害を検知した場合、UE100は、セルサーチによって、新たな接続先の候補となる候補セルを発見し、以下の動作を行う。
第1に、UE100は、RRC接続を再確立することを要求するRRC Connection Reestablishment Requestメッセージを候補セルに送信する。RRC Connection Reestablishment Requestメッセージは、再確立要求メッセージに相当する。この候補セルを管理するeNB200は、このUE100のコンテキスト情報(UEコンテキスト)を利用可能であれば、RRC Connection Reestablishment Requestメッセージに対する肯定応答であるRRC Connection ReestablishmentメッセージをUE100に送信する。UEコンテキストは、UE100の識別情報及びUE100の設定情報等を含む。
一のeNBは、他のeNBからX2インターフェイス又はS1インターフェイスを介してUEコンテキストを取得することが可能である。しかしながら、一のeNBがUEコンテキストを取得可能な他のeNBの範囲は限定されると考えられる。以下においては、一のeNBが他のeNBからX2インターフェイスを介してUEコンテキストを取得する場合を主として想定する。かかる場合、X2インターフェイスを介して接続されていないeNB間ではUEコンテキストをやり取りすることができない。よって、接続障害発生時のセルを管理するeNBと、セルサーチによって発見された候補セルを管理するeNBとが隣接eNBの関係にあれば、この候補セルを管理するeNBは、このUE100のUEコンテキストを利用可能である。
RRC Connection ReestablishmentメッセージをUE100が受信する場合、UE100は、RRCアイドルモードに遷移することなくRRC接続を再確立し、RRCコネクティッドモードを維持する。一方、UEコンテキストをeNB200が利用可能ではない場合、eNB200は、RRC Connection Reestablishment Requestメッセージに対する否定応答(拒絶)であるRRC Connection Reestablishment RejectメッセージをUE100に送信する。
第2に、RRC Connection Reestablishment Rejectメッセージを受信したUE100は、RRCアイドルモードに遷移し、セルサーチによって候補セルを改めて探索する。
第3に、RRCアイドルモードに遷移したUE100は、新たにRRC接続を確立することを要求するRRC Connection Requestメッセージを候補セルに送信する。RRC Connection Requestメッセージは、接続要求メッセージに相当する。この候補セルを管理するeNB200は、UEコンテキストの有無にかかわらず、RRC Connection Requestメッセージに対する肯定応答であるRRC Connection SetupメッセージをUE100に送信する。RRC Connection SetupメッセージをUE100が受信する場合、UE100は、RRCアイドルモードからRRCコネクティッドモードに遷移する。また、eNB200は、UEコンテキストを新たに取得(生成)する。
このように、RRC Connection Reestablishment Requestメッセージの送信先のセルがUEコンテキストを利用可能であれば、UE100は、接続障害が生じてもRRCコネクティッドモードを維持しつつ速やかにセルラ通信を再開することができる。一方、RRC Connection Reestablishment Requestメッセージの送信先のセルがUEコンテキストを利用可能ではない場合、UE100は、新たな候補セルのサーチ、RRC Connection Requestの送信、及びRRC Connection Setupメッセージの受信を行わなければセルラ通信を再開することができないため、セルラ通信の中断時間が長くなる。よって、UE100は、UEコンテキストを利用可能なセルに対してRRC Connection Reestablishment Requestメッセージを送信することが望まれる。
図6に示す例において、UE100は、eNB200a、eNB200c、及びeNB200eのそれぞれの通信エリアの境界付近の上空に位置する。ここで、UE100がeNB200aとのセルラ通信中にRLFを検知した場合を想定する。かかる場合、UE100は、RRC Connection Reestablishment RequestメッセージをeNB200c又はeNB200eに送信すれば、eNB200c及びeNB200eのいずれもeNB200aとの間にX2インターフェイスを有しているため、X2インターフェイスを介してeNB200aからUEコンテキストを取得可能である。
しかしながら、UE100が上空に位置する場合、各eNB200の送信ビームのサイドローブが上空に飛び交い、遠くのeNB200(例えば、eNB200d)からの電波をUE100が強い強度で受信し得る。このため、UE100は、例えば、eNB200dのセルを選択してRRC Connection Reestablishment Requestメッセージを送信し得る。かかる場合、eNB200dはeNB200aとの間にX2インターフェイスを有していないため、X2インターフェイスを介してeNB200aからUEコンテキストを取得することができない。その結果、UE100は、RRC接続の再確立に失敗し、RRCアイドルモードに遷移する。そして、UE100は、セルラ通信を再開するためには、新たな候補セルのサーチ、RRC Connection Requestの送信、及びRRC Connection Setupメッセージの受信を行わななければならない。
(第1実施形態に係る動作)
上述したように、RRC Connection Reestablishment Requestメッセージが拒絶されることに起因して、セルラ通信の中断時間が長くなるという問題がある。第1実施形態においては、以下の動作によって、かかる問題を解決可能とする。
第1実施形態に係るUE100は、セルラ通信ネットワークとの無線接続を確立し、RRC接続を用いてセルラ通信を行う。UE100は、Aerial UE又はUAV UEであってもよい。例えば、UE100には、自身のカテゴリ又は属性がAerial UE又はUAV UEであることを示す情報が事前設定されており、かかる情報を有するUE100が以下の動作を行ってもよい。或いは、UE100は、Aerial UE又はUAV UEであるか否かにかかわらず、飛行中であることを示す条件が満たされた場合に以下の動作を行ってもよい。飛行中であることを示す条件は、例えば、UE100の高度及び移動速度、並びにそれらの変動量等に応じて定められてもよいし、UE100の実行中のアプリケーションの種別(例えば、遠隔監視・制御アプリケーション)に応じて定められてもよい。
UE100の制御部130は、セルラ通信ネットワークの第1のセルとの接続障害を検知した場合に、UE100に関する情報であってRRC接続を再確立するために必要なコンテキスト情報(UEコンテキスト)を利用可能な第2のセルを特定する。UE100の送信部120は、制御部130によって特定された第2のセルに対して、RRC接続を再確立することを要求するRRC Connection Reestablishment Requestメッセージを送信する。これにより、RRC Connection Reestablishment Requestメッセージが拒絶されることを防止することができるため、セルラ通信の中断時間が長くなるという問題を解決することができる。
第2のセルを特定するために、UE100は、自律的に第2のセルを特定する。UE100の制御部130は、接続障害が検知された第1のセルとUE100との間の距離を示す第1の値と、UE100が利用可能な他のセル(候補セル)とUE100との間の距離を示す第2の値とを算出する。第1の値及び第2の値としてはパスロスを用いることができる。パスロスは、参照信号の既知の送信電力と、この参照信号の受信電力との間の差に相当する。或いは、UE100の制御部130は、第1のセルの位置情報を第1のセルから受信し、第2のセルの位置情報を第2のセルから受信し、受信した位置情報とUE100の位置情報(例えば、GNSS位置情報)とに基づいて第1の値及び第2の値を算出してもよい。位置情報は、経度、緯度、及び高度を含む。そして、UE100の制御部130は、第1の値と第2の値との差が所定値(閾値)以下である場合に、他のセル(候補セル)を、RRC Connection Reestablishment Requestメッセージの送信先とする第2のセルとして特定する。なお、UE100からの距離(パスロス)が同等である2つのセルは隣接関係にあると仮定している。図6の例において、UE100は、例えば、eNB200aのセル(第1のセル)との接続障害を検知すると、eNB200aのセルとパスロスが同等であるeNB200c又はeNB200eのセルを第2のセルとして特定し、eNB200c又はeNB200eのセルに対してRRC Connection Reestablishment Requestメッセージを送信することができる。
但し、UE100は、UEコンテキストを利用可能な第2のセルを常に発見できるとは限らない。このため、UE100の制御部130は、第1のセルとの接続障害を検知し、かつ、UE100が利用可能な他のセルが第2のセルではない場合に、当該他のセルに対するRRC Connection Reestablishment Requestメッセージの送信をスキップすると判断してもよい。RRC Connection Reestablishment Requestメッセージの送信をスキップする場合、UE100の送信部120は、当該他のセルに対して、新たにRRC接続を確立することを要求するRRC Connection Requestメッセージを送信する。これにより、RRC Connection Reestablishment Requestメッセージが拒絶されることが想定される場合に、RRC Connection Reestablishment Requestメッセージに代えて、RRC Connection Requestメッセージを送信することができるため、セルラ通信の中断時間が長くなることを回避することができる。
図7は、実施形態におけるUE100の動作の一例を示す図である。
図7に示すように、ステップS101において、UE100は、第1のセルとの接続障害を検知する。
ステップS102において、UE100は、セルサーチを行って候補セルを発見する。候補セルは、1つであってもよいし、複数であってもよい。
ステップS103において、UE100は、UE100と第1のセルとの間のパスロス1と、UE100と候補セルとの間のパスロス2とを算出する。
ステップS104において、UE100は、パスロス1とパスロス2との間の差を閾値と比較する。この閾値は、セルラ通信ネットワークからUE100に設定されてもよい。例えば、閾値は、第1のセルからSIBによってブロードキャストされたものであってもよい。
パスロス1とパスロス2との間の差が閾値以下である場合(ステップS104:YES)、ステップS105において、UE100は、パスロス2に対応する候補セルを第2のセルとして特定し、RRC Connection Reestablishment Requestメッセージを送信する。
一方、パスロス1とパスロス2との間の差が閾値を超える場合(ステップS104:NO)、ステップS106において、UE100は、他に候補セルがあるか否かを判断する。
他に候補セルがある場合(ステップS106:YES)、UE100は、当該他の候補セルについてパスロス2を算出し(ステップS103)、ステップS104の判断を行う。
他に候補セルがない場合(ステップS106:NO)、UE100は、UEコンテキストを利用可能な第2のセルを発見できなかったことになる。かかる場合、ステップS107において、UE100は、発見された候補セルに対してRRC Connection Requestメッセージを送信する。
[第1実施形態の変更例]
第1実施形態において、第2のセルを管理する第2のeNBが、第1セルを管理する第1のeNBからUEコンテキストを取得する処理の詳細について説明しなかった。通常、第2のeNBは、UE100からRRC Connection Reestablishment Requestメッセージを受信すると、このメッセージに基づいて第1のeNBを特定し、特定した第1のeNBに対してX2インターフェイス上で通知を行う。第1のeNBは、当該通知に応じて、第2のeNBに対して、X2インターフェイスでUEコンテキストを転送する。かかるプロシージャは、UEコンテキストを取得する時間に起因して、第2のeNBがRRC Connection Reestablishment Requestメッセージを受信してからRRC Connection Reestablishmentメッセージを送信するまでの遅延時間が長くなる。第1実施形態の変更例において、かかる遅延時間を短縮可能とする動作について説明する。
第1実施形態の変更例において、第1のeNBは、接続障害が発生するよりも前において、UEコンテキストを第2のeNBに転送する。すなわち、第1のeNBは、UEコンテキストを予め第2のeNBと共有する。例えば、第1のeNBは、UEコンテキストを取得した際に、自身との間にX2インターフェイスを有する他のeNBに当該UEコンテキストを転送する。これにより、第2のeNBは、UE100からRRC Connection Reestablishment Requestメッセージを受信するとすぐにRRC Connection Reestablishmentメッセージを送信することができる。
図8は、第1実施形態の変更例における動作の一例を示す図である。
図8に示すように、ステップS301において、UE100は、eNB200aとRRC接続を確立する。ステップS302において、eNB200aは、UEコンテキストを取得する。ステップS303及びS304において、eNB200aは、UEコンテキストをX2インターフェイス上でeNB200b及び200cに転送する。
ステップS305及びS306において、eNB200b及び200cは、UEコンテキストの取得時にタイマを開始させる。タイマの値は、eNB200aから指定された値であってもよいし、MMEから指定された値であってもよいし、OAM(Operations Administration and Maintenance)から指定された値であってもよい。eNB200b及び200cは、タイマが動作中は、転送されたUEコンテキストを保持する。
ステップS307において、UE100とeNB200aとの間で接続障害が発生し、UE100は、第1実施形態に係る動作によってeNB200bのセルを第2のセルとして特定する。ステップS308において、UE100は、eNB200bに対してRRC Connection Reestablishment Requestメッセージを送信する。eNB200bは、RRC Connection Reestablishment Requestメッセージの受信に応じてタイマを停止させる。ステップS309において、eNB200bは、RRC Connection ReestablishmentメッセージをUE100に送信する。ステップS301においてUE100のRRC接続が再確立される。
一方、ステップS311において、eNB200cにおけるタイマが満了する。ステップS312において、eNB200cは、保持していたUEコンテキストを破棄する。
なお、eNB200bは、UE100との通信中はUEコンテキストを保持する。eNB200bは、UE100との通信終了に応じて、RRC接続を解放させるRRC Connection ReleaseメッセージをUE100に送信し、保持していたUEコンテキストを破棄してもよい。そして、eNB200bは、その旨をX2インターフェイス上で他のeNBに通知することにより、他のeNBがUEコンテキストを破棄可能としてもよい。
第1実施形態の変更例における動作を、第3実施形態における条件付きハンドオーバ(conditional handover)と組み合わせてもよい。例えば、ステップS303及びS304において送信されるUEコンテキストは、ハンドオーバ要求に含まれていてもよい。eNB200aは、ハンドオーバ要求に対するハンドオーバ要求確認応答を受信した場合に、ステップS307よりも前に、条件付きハンドオーバのためのハンドオーバ指令をUE100に送信してもよい。UE100は、RLFを検出(ステップS307)した場合に、ハンドオーバ指令で指定されたセルを優先して、RRC Connection Reestablishmentメッセージを送信してもよい。
[第2実施形態]
第2実施形態について、第1実施形態との相違点を主として説明する。第1実施形態においては、UE100は、発見された候補セルが第2のセルであるか否かに応じて、RRC Connection Reestablishment Requestメッセージを送信するか又はRRC Connection Requestメッセージを送信するかを選択することにより、RRC Connection Reestablishment Requestメッセージが拒絶されることを回避する一例を説明した。
これに対し、第2実施形態においては、RRC Connection Reestablishment Requestメッセージ及びRRC Connection Requestメッセージの両方の機能を有する新たなメッセージを導入する。このメッセージは、少なくともRRC接続を再確立することを要求する要求メッセージである。第2実施形態において、UE100の送信部120は、セルラ通信ネットワークのセルに対して、RRC接続を再確立することを要求する第1の要求情報と新たにRRC接続を確立することを要求する第2の要求情報とを含むメッセージを送信する。
eNB200(セル)は、かかるメッセージの送信を許可するか否かをSIB(所定のシステム情報)によってUE100に通知してもよい。UE100は、かかるメッセージの送信が許可されている場合に限り、かかるメッセージの送信を当該セルに対して行ってもよい。SIBは、エアリアルUE向けのSIBであってもよい。UE100は、あるセルからエアリアルUE向けのSIBを受信した場合に、当該セルに対してRRC Connection Dual Requestメッセージの送信が許可されていると判断してもよい。
図9は、第2実施形態に係るメッセージ(RRC Connection Dual Request)の一例を示す図である。
図9に示すように、第2実施形態に係るRRC Connection Dual Requestメッセージは、情報要素として、RRC接続を再確立することを要求する第1の要求情報(rrcConnectionReestablishment−r8)と新たにRRC接続を確立することを要求する第2の要求情報(rrcConnectionRequest−r8)とを含む。第1の要求情報は、RRC Connection Reestablishment Requestメッセージ中の全ての情報要素を含んでもよい。第2の要求情報は、RRC Connection Requestメッセージ中の全ての情報要素を含んでもよい。
RRC Connection Dual Requestメッセージは、RRC Connection Dual Requestメッセージを送信する1又は複数の原因を示す情報要素(Dual Request Cause)をさらに含んでもよい。UE100は、かかる原因に基づいてRRC Connection Dual Requestメッセージを送信する場合に、かかる原因をDual Request CauseとしてRRC Connection Dual Requestメッセージに含める。例えば、UE100は、次の情報要素の中から少なくとも1つを選択してDual Request Causeに含める。Dual Request Causeに含める情報要素の数(上限等)はeNB200からUE100に通知されてもよい。AerialUEであること(AerialUE)。高度が高いこと(HighAltitude)。飛行中であること(OnFlying)。高速移動中であること(HighSpeed)。自律運転中であること(AutomousMode)。X2インターフェイス(UEコンテキスト)を利用可能か不明であること(AvailabilityUnknown)。通信中断時間を短くすることが必要とされること(LowIntrruptionTimeRequired)。アプリケーションの要求(ApplicationRequest)。通話中であること(VoiceInProgress)。消費電力削減が必要とされること(PowerSavingPreference)。地理的位置(GeoLocation)。移動履歴(MobilityHistory)。加入者クラス(SubscriptionLevelGold、SubscriptionLevelSilver)。
第2実施形態において、eNB200の受信部220は、RRC Connection Dual RequestメッセージをUE100から受信する。eNB200の制御部230は、このUE100のUEコンテキストをeNB200が利用可能であるか否かを判断する。かかる判断の基準は、第1実施形態と同様である。eNB200の制御部230は、UEコンテキストをeNB200が利用可能である場合に、RRC Connection Dual Requestメッセージに対する応答として、RRC接続を再確立することを許可する旨をUE100に通知する。一方、eNB200の制御部230は、UEコンテキストをeNB200が利用可能ではない場合には、RRC Connection Dual Requestメッセージに対する応答として、新たにRRC接続を確立することを許可する旨をUE100に通知する。このように、RRC Connection Dual RequestメッセージはeNB200によって拒絶されることがない。
図10は、第2実施形態における動作の一例を示す図である。
図10に示すように、ステップS401において、UE100は、eNB200aとRRC接続を確立する。
ステップS402において、UE100とeNB200aとの間で接続障害が発生し、セルサーチを行ってeNB200bのセルを候補セルとして発見する。
ステップS403において、UE100は、RRC Connection Dual RequestメッセージをeNB200bに送信する。
ステップS404において、RRC Connection Dual Requestメッセージを受信したeNB200bは、UE100のUEコンテキストを利用可能であるか否かを判断する。
UEコンテキストをeNB200bが利用可能である場合(ステップS404:YES)、ステップS405において、eNB200bは、RRC Connection ReestablishmentメッセージをUE100に送信する。
一方、UEコンテキストをeNB200bが利用可能ではない場合(ステップS404:NO)、ステップS406において、eNB200bは、RRC Connection SetupメッセージをUE100に送信する。
RRC Connection Reestablishmentメッセージ及びRRC Connection Setupメッセージに代えて、共通化されたメッセージを用いてもよい。共通化されたメッセージは、例えばRRC Connection Dual Request Acknowledgeメッセージであってもよい。eNB200は、共通化されたメッセージに、RRC Connection Reestablishmentメッセージに対応する情報要素及びRRC Connection Setupメッセージに対応する情報要素のいずれか一方を含める。
[第2実施形態の変更例1]
第2実施形態において、RRC Connection Dual Requestメッセージを送信するUE100がRRCコネクティッドモードであることを想定していた。第2実施形態の変更例においては、RRC Connection Dual Requestメッセージを送信するUE100がRRCアイドルモードであることを想定する。具体的には、かかるUE100は、RRCサスペンド状態にある。RRCサスペンド状態は、RRCアイドルモードの一状態であって、UEコンテキストがセルラ通信ネットワークに維持される特殊な状態である。
第2実施形態の変更例1に係るRRC Connection Dual Requestメッセージは、情報要素として、RRC接続を復旧することを要求する第1の要求情報と新たにRRC接続を確立することを要求する第2の要求情報とを含む。第2の要求情報は、上述した第2実施形態と同様に、RRC Connection Requestメッセージ中の全ての情報要素を含んでもよい。
第2実施形態の変更例1において、第1の要求情報は、RRC Connection Resume Requestメッセージ中の全ての情報要素を含んでもよい。RRC Connection Resume Requestメッセージは、RRCサスペンド状態のUE100がRRC接続の復旧を要求するためのメッセージである。
[第2実施形態の変更例2]
第2実施形態において特に記載していないが、UE100は、RRC Connection Dual Requestメッセージをランダムアクセスプロシージャ中に送信する。具体的には、図10に示すステップS402とS403との間において、UE100からeNB200bにランダムアクセス信号(ランダムアクセスプリアンブル)を送信し、eNB200bは、ランダムアクセス信号の受信に応じてランダムアクセス応答をUE100に送信する。
ランダムアクセス応答は、上りリンク無線リソースの割り当てを示す上りリンクグラントを含む。そして、図10に示すS403において、UE100は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いてRRC Connection Dual RequestメッセージをeNB200bに送信する。
RRC Connection Dual Requestメッセージは、一般的なRRC Connection Requestメッセージに比べて情報量が多い。よって、eNB200bは、上りリンクグラントにより、多くの上りリンク無線リソース(すなわち、大きいデータサイズ)をUE100に割り当てる必要がある。
第2実施形態の変更例2において、UE100は、RRC Connection Dual Requestメッセージを送信する意図を通知するランダムアクセス信号を送信する。eNB200bは、ランダムアクセス信号に対する応答として、RRC Connection Dual Requestメッセージの送信に用いる上りリンク無線リソースを示す割り当て情報(上りリンクグラント)を含むランダムアクセス応答をUE100に送信する。UE100は、上りリンクグラントにより割り当てられた上りリンク無線リソースを用いてRRC Connection Dual RequestメッセージをeNB200bに送信する。
このように、RRC Connection Dual Requestメッセージを送信する意図を通知するランダムアクセス信号を送信することにより、eNB200bは、ランダムアクセス信号に基づいて、適切な量の上りリンク無線リソースをUE100に割り当てることができる。具体的には、eNB200bは、一般的なRRC Connection Requestメッセージの送信に用いる上りリンク無線リソース量よりも多い上りリンク無線リソースをUE100に割り当てる。
RRC Connection Dual Requestメッセージを送信する意図を通知するランダムアクセス信号とは、特定のプリアンブル系列(信号系列)及び/又は特定の時間・周波数リソースを用いて送信されるランダムアクセス信号をいう。
例えば、eNB200bは、特定のプリアンブル系列の候補(プリアンブル系列プール)及び/又は特定の時間・周波数リソースの候補(リソースプール)を示す情報をSIBにより自セル内にブロードキャストする。RRC Connection Dual Requestメッセージを送信する意図を有するUE100は、SIBに基づいて特定のプリアンブル系列のプール及び/又は特定の時間・周波数リソースのプールを把握し、特定のプリアンブル系列及び/又は特定の時間・周波数リソースを選択してランダムアクセス信号を送信する。ランダムアクセス信号を受信したeNB200は、当該ランダムアクセス信号に適用されているプリアンブル系列及び/又は時間・周波数リソースに基づいて、RRC Connection Dual Requestメッセージを送信する意図をUE100が有することを把握する。
[第3実施形態]
第3実施形態について、第1及び第2実施形態との相違点を主として説明する。第3実施形態は、条件付きハンドオーバ(conditional handover)に関する実施形態である。
一般的なハンドオーバプロシージャにおいて、UE100のハンドオーバをeNB200が決定する。例えば、UE100は、UE100とeNB200(ソースeNB)との間の無線状態が悪化したこと、及び/又はUE100とターゲットeNBとの間の無線状態が良化したことに応じて、無線状態に関する測定報告をeNB200(ソースeNB)に送信する。eNB200は、UE100から送信される測定報告に基づいてUE100のハンドオーバを決定し、その後、ターゲットeNBに対して、UEコンテキストを含むハンドオーバ要求を送信する。そして、eNB200(ソースeNB)は、ターゲットeNBからハンドオーバ要求確認応答を受信すると、UE100に対してハンドオーバ指令を送信する。UE100は、ハンドオーバ指令を受信すると、ターゲットeNBへのハンドオーバを実行し、ターゲットeNBに対してランダムアクセス信号を送信する。
これに対し、条件付きハンドオーバのプロシージャにおいて、UE100のハンドオーバをUE100自身が決定する。具体的には、eNB200は、ターゲットeNBに対してハンドオーバ要求を予め送信する。ここで、ターゲットeNBは、1つに限らず、複数であってもよい。よって、複数のターゲットeNBがハンドオーバ要求を受信し得る。また、eNB200(ソースeNB)は、UE100に対してハンドオーバ指令を予め送信する。UE100は、ハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときにハンドオーバを実行して1つのターゲットeNBに対してランダムアクセス信号を送信する。ハンドオーバ条件は、例えば、UE100とeNB200(ソースeNB)との間の無線状態が悪化したこと、及び/又はUE100とターゲットeNBとの間の無線状態が良化したことである。当該ハンドオーバ条件は、eNB200から設定されてもよく、当該設定は受信参照信号品質(RSRP、RSRQ、RS−SINR等)の閾値であってもよく、パケット再送回数(RLC再送回数)の閾値であってもよい。もしくは、当該ハンドオーバ条件は、無線リンク異常(Radio Link Failure)であってもよい。すなわち、RLFを検出したUEは、RLF状態であると認識するのではなく、ターゲットeNBへのハンドオーバをトリガ(具体的にはランダムアクセスプロシージャを開始)する。
かかる条件付きハンドオーバは、eNB200(ソースeNB)が測定報告に基づくハンドオーバ決定を行わずに、UE100自身でハンドオーバを決定するため、UE100とeNB200(ソースeNB)との間の無線状態が不安定である場合に好適である。第3実施形態において、UE100が航空ユーザ装置(エアリアルUE)であり、エアリアルUEに対して条件付きハンドオーバが適用される場合について説明する。なお、以下においてソースeNBを「ソースeNB200S」と表記し、ターゲットeNBを「ターゲットeNB200T」と表記する。
第3実施形態において、ソースeNB200Sは、1又は複数のターゲットeNB200Tに対して、UE100のコンテキスト情報(UEコンテキスト)を含むハンドオーバ要求を予め送信し、かつ、UE100に対してハンドオーバ指令を予め送信する。ターゲットeNB200Tは、ハンドオーバ要求の受信に応じて、ハンドオーバ要求確認応答をソースeNB200Sに送信する。UE100は、ソースeNB200Sからハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときにハンドオーバを実行する。
ここで、ハンドオーバの実行タイミングをUE100が決定するため、各ターゲットeNB200Tは、UE100がいつハンドオーバを実行するかを把握していない。よって、複数のターゲットeNB200Tが、UE100が自セルにハンドオーバするまでUEコンテキストを保持する必要があり得る。しかしながら、UE100により選択されなかったターゲットeNB200Tは、UE100が他のターゲットeNB200Tにハンドオーバを行ったのにもかかわらず、UEコンテキストを保持し続けてしまうという問題がある。
第3実施形態において、ハンドオーバ要求、ハンドオーバ要求確認応答、及びハンドオーバ指令の少なくとも1つには、ターゲットeNB200Tがコンテキスト情報を保持すべき保持時間に対応するタイマ値が含まれる。これにより、ターゲットeNB200Tがコンテキスト情報を保持すべき保持時間を適切に管理することができる。例えば、ターゲットeNB200Tは、保持時間内にUE100が自セルにハンドオーバした場合には、保持しているUEコンテキストをUE100との通信に用いる。一方、ターゲットeNB200Tは、保持時間内にUE100が自セルにハンドオーバしない場合には、保持しているUEコンテキストを破棄してもよい。
(1)動作例1
図11は、第3実施形態に係る動作例1を示す図である。
図11に示すように、ステップS501において、RRCコネクティッドモードのUE100(エアリアルUE)は、ソースeNB200Sのセルとの無線接続(RRC接続)を確立している。
ステップS502において、ソースeNB200Sは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス(X2インターフェイス)上でターゲットeNB200Tに送信する。
ターゲットeNB200Tは、ソースeNB200Sに隣接する隣接eNBであってもよい。ソースeNB200Sは、UE100が自セルと接続した際にハンドオーバ要求をターゲットeNB200Tに送信してもよい。ソースeNB200Sは、複数のeNB(複数のターゲットeNB)に対してハンドオーバ要求を送信してもよい。
ハンドオーバ要求メッセージは、UEコンテキストを含む。ハンドオーバ要求メッセージは、条件付きハンドオーバ専用の新たなメッセージであってもよい。或いは、ハンドオーバ要求メッセージは、条件付きハンドオーバを示す情報(情報要素)を含む既存のハンドオーバ要求メッセージであってもよい。
動作例1において、ソースeNB200Sは、ターゲットeNB200Tがコンテキスト情報を保持すべき保持時間を決定し、決定した保持時間に対応するタイマ値をハンドオーバ要求メッセージに含める。例えば、ソースeNB200Sは、統計情報及び/又はUE100の移動速度に基づいて保持時間を決定する。
ソースeNB200Sは、UE100がエアリアルUEであることを示す情報をハンドオーバ要求メッセージに含めてもよい。例えば、カテゴリ又は属性がAerial UEであることを示す情報であってもよいし、飛行中であることを示す情報であってもよいし、UE100の実行中のアプリケーションがエアリアルUE向けの種別(例えば、遠隔監視・制御アプリケーション)であることを示す情報であってもよい。かかる場合、ターゲットeNB200Tは、エアリアルUE情報に基づいて、UE100に割り当てるべき無線リソースを判断する。例えば、ターゲットeNB200Tは、エアリアルUE専用の周波数帯を割り当ててもよいし、1つの周波数帯を複数のサブバンドに分割し、エアリアルUE専用のサブバンドを割り当ててもよい。
ターゲットeNB200Tは、ハンドオーバ要求メッセージを受信すると、ステップS503において、ハンドオーバ要求メッセージに含まれるUEコンテキストを保持する。また、ハンドオーバ要求メッセージに含まれるタイマ値を設定したタイマを開始させる。
ステップS504において、ターゲットeNB200Tは、ハンドオーバ要求確認応答(Ack)メッセージをX2インターフェイス上でソースeNB200Sに送信する。
ソースeNB200Sは、ハンドオーバ要求確認応答メッセージを受信すると、ステップS505において、条件付きハンドオーバを示す情報(情報要素)を含むハンドオーバ指令(RRC connection reconfigurationメッセージ)をUE100に送信する。ハンドオーバ指令は、UE100がハンドオーバを実行すべき条件であるハンドオーバ条件を指定する情報を含んでもよい。
ソースeNB200Sは、保持時間に対応するタイマ値をハンドオーバ指令に含める。また、ソースeNB200Sは、ハンドオーバ対象の複数のセル(すなわち、1又は複数のターゲットeNB200Tのセル)を示すセルリストをハンドオーバ指令に含める。セルリスト中のセルごとにタイマ値が関連付けられていてもよい。かかる場合、セルリスト中のセルごとに異なるタイマ値を設定することができる。
ステップS506において、ソースeNB200Sは、タイマ値を設定したタイマを開始させる。ステップS506の処理は、ステップS504とステップS505との間に行なわれてもよい。
UE100は、ハンドオーバ指令を受信すると、条件付きハンドオーバが指示されたことを認識し、ステップS507において、ハンドオーバ指令に含まれるタイマ値を設定したタイマを開始させる。セルごとにタイマ値が提供される場合、UE100は、セルごとにタイマ値(保持時間)を管理する。
ステップS508において、UE100は、ハンドオーバ条件が満たされた否かを判定する。UE100は、かかる判定をセルリスト中のセルに限定して行なってもよい。ここでは、ハンドオーバ条件が満たされたと仮定して説明を進める。
UE100は、タイマ値に対応する保持時間内においてハンドオーバを実行する場合に、ステップS509において、ハンドオーバの実行を示す通知(ハンドオーバ実行通知)をソースeNB200Sに送信する。ソースeNB200Sは、ハンドオーバ実行通知に基づいて、UE100がハンドオーバを実行することを把握する。ハンドオーバ実行通知は、UE100がハンドオーバ先(すなわち、ランダムアクセス信号の送信先)として選択したセルを示す情報を含んでもよい。ソースeNB200Sは、ハンドオーバ実行通知に対する応答をUE100に送信してもよい。
ステップS510において、UE100は、ハンドオーバ先として選択したセル(ターゲットeNB200T)に対してランダムアクセスプロシージャを開始し、当該セルに対してランダムアクセス信号を送信する。
ここでは保持時間内にハンドオーバが実行される一例を説明したが、保持時間内にハンドオーバが実行されずにタイマが満了(保持時間が経過)した場合、UE100及びソースeNB200Sは、条件付きハンドオーバから通常のハンドオーバ(eNB主導のハンドオーバ)に切り替えてもよい。通常のハンドオーバに切り替える場合、UE100は、測定報告プロシージャを開始してもよい。また、ターゲットeNB200Tは、保持時間内にUE100が自セルにハンドオーバしない場合には、保持しているUEコンテキストを破棄する。
(2)動作例2
図12は、第3実施形態に係る動作例2を示す図である。ここでは、第3実施形態に係る動作例1との相違点を説明する。動作例2では、タイマ値をソースeNB200Sが決定することに代えて、タイマ値をターゲットeNB200Tが決定する。
図12に示すように、ステップS511において、RRCコネクティッドモードのUE100(エアリアルUE)は、ソースeNB200Sのセルとの無線接続(RRC接続)を確立している。
ステップS512において、ソースeNB200Sは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス(X2インターフェイス)上でターゲットeNB200Tに送信する。ソースeNB200Sは、複数のeNB(複数のターゲットeNB)に対してハンドオーバ要求を送信してもよい。ソースeNB200Sは、UE100がエアリアルUEであることを示す情報をハンドオーバ要求メッセージに含めてもよい。
ターゲットeNB200Tは、ハンドオーバ要求メッセージを受信すると、ステップS513において、ハンドオーバ要求メッセージに含まれるUEコンテキストを保持する。また、ターゲットeNB200Tは、自身がコンテキスト情報を保持すべき保持時間を決定する。
ステップS514において、ターゲットeNB200Tは、ハンドオーバ要求確認応答(Ack)メッセージをX2インターフェイス上でソースeNB200Sに送信する。ターゲットeNB200Tは、決定した保持時間に対応するタイマ値をハンドオーバ要求確認応答メッセージに含める。
ステップS515において、ターゲットeNB200Tは、タイマ値を設定したタイマを開始させる。
ソースeNB200Sは、ハンドオーバ要求確認応答メッセージを受信すると、ハンドオーバ要求確認応答メッセージに含まれるタイマ値を記憶する。ステップS516において、ソースeNB200Sは、条件付きハンドオーバを示す情報(情報要素)を含むハンドオーバ指令(RRC connection reconfigurationメッセージ)をUE100に送信する。その後の動作(ステップS517〜S521)については動作例1と同様である。
[第3実施形態の変更例1]
第3実施形態において、条件付きハンドオーバにおいて、UE100により選択されなかったターゲットeNB200TがUEコンテキストを保持し続けてしまうという問題点を、タイマを用いて解決する一例を説明した。第3実施形態の変更例1及び2は、かかる問題点を、基地局間メッセージであるコンテキスト解放通知(UE Context Release)を用いて解決するものである。
第3実施形態の変更例1において、ソースeNB200Sは、複数のターゲットeNB200Tに対して、UE100のコンテキスト情報を含むハンドオーバ要求を予め送信し、かつ、UE100に対してハンドオーバ指令を予め送信する。UE100は、ソースeNB200Sからハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときに複数のターゲットeNB200Tのうち1つのターゲットeNB200Tへのハンドオーバを実行する。この1つのターゲットeNB200Tは、かかるハンドオーバに応じて、ソースeNB200Sに対して、UE100のコンテキスト情報を解放可能であることを示す第1のコンテキスト解放通知を送信する。ソースeNB200Sは、第1のコンテキスト解放通知の受信に応じて、複数のターゲットeNB200Tのうち1つのターゲットeNB200T以外のターゲットeNB200Tに対して、UE100のコンテキスト情報を解放可能であることを示す第2のコンテキスト解放通知を送信する。
図13は、第3実施形態の変更例1を示す図である。ここでは、第3実施形態に係る動作(図11及び図12参照)との相違点を主として説明する。
図13に示すように、ステップS531において、RRCコネクティッドモードのUE100(エアリアルUE)は、ソースeNB200Sのセルとの無線接続(RRC接続)を確立している。
ステップS532及びS533において、ソースeNB200Sは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス(X2インターフェイス)上で複数のターゲットeNB200T(200T1、200T2、・・・)に送信する。ハンドオーバ要求メッセージは、UEコンテキストを含む。ハンドオーバ要求メッセージは、条件付きハンドオーバ専用の新たなメッセージであってもよい。或いは、ハンドオーバ要求メッセージは、条件付きハンドオーバを示す情報(情報要素)を含む既存のハンドオーバ要求メッセージであってもよい。ソースeNB200Sは、UE100がエアリアルUEであることを示す情報をハンドオーバ要求メッセージに含めてもよい。各ターゲットeNB200Tは、ハンドオーバ要求メッセージを受信すると、ハンドオーバ要求メッセージに含まれるUEコンテキストを保持する。
ステップS534及びS535において、各ターゲットeNB200Tは、ハンドオーバ要求確認応答(Ack)メッセージをX2インターフェイス上でソースeNB200Sに送信する。
ソースeNB200Sは、各ターゲットeNB200Tからハンドオーバ要求確認応答メッセージを受信すると、ステップS536において、条件付きハンドオーバを示す情報(情報要素)を含むハンドオーバ指令(RRC connection reconfigurationメッセージ)をUE100に送信する。ハンドオーバ指令は、UE100がハンドオーバを実行すべき条件であるハンドオーバ条件を指定する情報を含んでもよい。ソースeNB200Sは、ハンドオーバ対象の複数のセル(すなわち、複数のターゲットeNB200Tのセル)を示すセルリストをハンドオーバ指令に含める。
UE100は、ハンドオーバ指令を受信した後、ハンドオーバ条件が満たされた否かを判定する。UE100は、かかる判定をセルリスト中のセルに限定して行なってもよい。ここでは、ターゲットeNB200T1についてハンドオーバ条件が満たされたと仮定して説明を進める。UE100は、ハンドオーバを実行する場合に、ステップS538において、ハンドオーバの実行を示す通知(ハンドオーバ実行通知)をソースeNB200Sに送信する。
ステップS539において、UE100は、ハンドオーバ先として選択したセル(ターゲットeNB200T1)に対してランダムアクセスプロシージャを開始し、当該セルに対してランダムアクセス信号を送信する。
ランダムアクセスプロシージャが完了すると、ステップS540において、UE100は、ターゲットeNB200T1とのRRC接続を確立する。かかるハンドオーバの実行に応じて、ターゲットeNB200T1は、ステップS541において、ソースeNB200Sに対して、UE100のコンテキスト情報(UEコンテキスト)を解放可能であることを示す第1のコンテキスト解放通知をX2インターフェイス上で送信する。
ソースeNB200Sは、第1のコンテキスト解放通知を受信した後、ソースeNB200Sで保持しているUEコンテキストを破棄する前に、ステップS542において、第1のコンテキスト解放通知の送信元のターゲットeNB200T1以外のターゲットeNB200T2に対して、UEコンテキストを解放可能であることを示す第2のコンテキスト解放通知を送信する。そして、ソースeNB200Sは、ソースeNB200Sで保持しているUEコンテキストを破棄する。ターゲットeNB200T2は、第2のコンテキスト解放通知の受信に応じて、ターゲットeNB200T2で保持しているUEコンテキストを破棄する。
[第3実施形態の変更例2]
第3実施形態の変更例2において、ソースeNB200Sは、複数のターゲットeNB200Tに対して、UE100のコンテキスト情報と複数のターゲットeNB200Tに関するeNBリスト(基地局リスト)とを含むハンドオーバ要求を予め送信し、かつ、UE100に対してハンドオーバ指令を予め送信する。UE100は、ソースeNB200Sからハンドオーバ指令を受信した後、ハンドオーバ条件が満たされるまでハンドオーバを保留し、ハンドオーバ条件が満たされたときに複数のターゲットeNB200Tのうち1つのターゲットeNB200Tへのハンドオーバを実行する。1つのターゲットeNB200Tは、ハンドオーバに応じて、ソースeNB200Sと、eNBリストに対応する他のターゲットeNB200Tとに対して、UE100のコンテキスト情報を解放可能であることを示すコンテキスト解放通知を送信する。
図14は、第3実施形態の変更例2を示す図である。ここでは、第3実施形態の変更例1(図13参照)との相違点を主として説明する。
図14に示すように、ステップS551において、RRCコネクティッドモードのUE100(エアリアルUE)は、ソースeNB200Sのセルとの無線接続(RRC接続)を確立している。
ステップS552及びS553において、ソースeNB200Sは、条件付きハンドオーバのためのハンドオーバ要求メッセージを基地局間インターフェイス(X2インターフェイス)上で複数のターゲットeNB200T(200T1、200T2、・・・)に送信する。ハンドオーバ要求メッセージは、UEコンテキストを含む。第3実施形態の変更例2において、ハンドオーバ要求メッセージは、複数のターゲットeNB200Tのそれぞれの識別子を含むeNBリストを含む。但し、あるターゲットeNB200Tに送信されるeNBリストは、当該ターゲットeNB200Tの識別子を含まなくてもよい。各ターゲットeNB200Tは、ハンドオーバ要求メッセージを受信すると、ハンドオーバ要求メッセージに含まれるUEコンテキスト及びeNBリストを保持する。
ステップS554〜S560の各処理は、図13のステップS534〜540の各処理と同様である。
UE100がターゲットeNB200T1とのRRC接続を確立した後、ターゲットeNB200T1は、ステップS561において、ソースeNB200Sに対して、UE100のコンテキスト情報(UEコンテキスト)を解放可能であることを示すコンテキスト解放通知をX2インターフェイス上で送信する。また、ターゲットeNB200T1は、ステップS562において、ターゲットeNB200T1で保持しているeNBリストに基づいて、ターゲットeNB200T2に対して、UEコンテキストを解放可能であることを示すコンテキスト解放通知を送信する。そして、ソースeNB200S及びターゲットeNB200T2は、自身で保持しているUEコンテキストを破棄する。
[第4実施形態]
UE100は、ハンドオーバ失敗(Handover Failure)の発生等により、ターゲットセル(ターゲットeNB)200−2とのRRC接続の確立に失敗した場合に、ターゲットセル200−2とのRRC接続の確立をするために、ターゲットセル200−2とのRRC接続の再確立のための手順(RRC Connection Reestablishment Procedure)を実行する。
ここで、UE100は、UAV(Unmanned aerial vehicle)であると想定するが、UAVに限られない。
UE100はUAVであることから、UE100は、ハンドオーバ失敗後、RRCアイドルモードにおいて、ハンドオーバ失敗前に接続していたサービングセル200−1から遠くはなれたセルを再選択した後に、当該セルをターゲットセル200−2として、RRC接続の再確立のための手順を実行することが考えられる。
そのような場合には、サービングセル200−1とターゲットセル200−2との間でX2接続が無い場合もある。その場合には、ターゲットセル200−2は、X2インターフェイスを介したUE Context Fetchを利用して、サービングセル200−1からUE Contextを取得することができないため、UE100とターゲットセル200−2とのRRC接続の再確立の失敗(RRC Connection Reestablishment Failure)が起こる怖れがある。その場合、UE100の通信が切断されている時間が増えるという課題が存在する。
なお、UE Context(移動局情報)は、RRC接続の再確立(すなわち、再接続)時に、再接続先の基地局が移動局を特定するために必要な情報である。
UE Context Fetchとは、再接続先の基地局が、再接続手順の際に移動局から取得したUE Contextを、移動局が無線リンク障害前に通信をしていた基地局に照会し、当該移動局を特定することである。
上記の課題を解決し得る実施形態を、図15に沿って、以下に説明する。
UE100とRRC接続中のサービングセル200−2は、UE100のサービングセル200−1からターゲットセル200−2へのハンドオーバ手順の開始前又は実行中に、UE100に対して、UE100のUE Contextを送信する(ステップS601)。
なお、ステップS601において送信されるUE Contextは、カプセル化されていてもよい。具体的には、カプセル化されたUE Contextは、RRCメッセージ(RRC Connection Reconfigurationメッセージ等)内の専用のコンテナ(Container)に格納されてサービングセル200−1から送信されてもよい。なお、カプセル化されたUE Contextは、暗号化されていてもよい。当該暗号化の鍵及び方式等の情報は、ステップS601よりも前に、所定のノードからサービングセル200−2及びターゲットセル200−1へ送信されていてもよい。当該暗号化の鍵及び方式等の情報は、MMEからS1インターフェイスを介してサービングセル200−2及びターゲットセル200−1へ送信されてもよいし、OAMによってサービングセル200−2及びターゲットセル200−1に設定されてもよい。
なお、ステップS601において送信されるUE Contextは、サービングセル200−1のグローバルセルID(Global Cell ID)を含んでもよい。
UE100は、UE100のUE Contextを受信した後、サービングセル200−1からターゲットセル200−2へのハンドオーバに失敗した場合に、ターゲットセル200−1とのRRC接続を確立するために、RRC接続の再確立のための手順を開始する(ステップS602)。
UE100は、RRC接続の再確立要求(RRC Connection Reestablishment Request)をターゲットセル200−2に対して送信する(ステップS603)。UE100は、送信するRRC接続の再確立要求に、UE100がUE Contextを保持することを示す情報(Indication)を含める。
ターゲットセル200−2は、サービングセル200−1との間でX2接続が無いためにUE Context Fetchに失敗したこと等により、サービングセル200−1からUE100のUE Contextを取得できなかった場合、UE100に対して、UE100のUE Contextの送信を要求する(ステップS604)。なお、ターゲットセル200−2は、UE Context Fetchによりサービングセル200−1からUE100のUE Contextを取得できた場合には、UE100に対して、UE100のUE Contextの送信を要求しなくてもよい。
UE100は、ステップS604において、ターゲットセル200−2からUE Contextの送信の要求を受信した場合、ターゲットセル200−2に対して、UE Contextを送信する(ステップS605)。
なお、ステップS601において、UE100は、カプセル化されたUE Contextを受信した場合、ステップS605において、当該カプセル化されたUE Contextをそのままターゲットセル200−1に対して送信してもよい。
また、UE100は、ステップS601において受信したUE Contextにサービングセル200−1のグローバルセルID(Global Cell ID)が含まれていた場合、ステップS605において、ターゲットセル200−2に対して、UE100のUE Contextに加えてサービングセル200−1のグローバルセルIDを送信する。
なお、他の実施形態として、UE100は、UAVである場合には、複数の基地局間のリレーポイントとして機能してもよい。つまり、通常、X2インターフェイスを使用して基地局間で送受信しているメッセージ又は情報(各基地局の負荷情報(Load information)、RLF Indication(Radio Link Failure Indication)等))を、UE100を介して、X2インターフェイスを使用する代わりに、複数の基地局間で送受信することとしてもよい。
[その他の実施形態]
上述した実施形態において、Aerial UE又はUAV UEを用いる一例を説明した。しかしながら、本開示はAerial UE又はUAV UEに限定されない。Aerial UE又はUAV UE以外のUEに対して、上述した実施形態に係る動作を適用してもよい。例えば、車両向けのUE(Vehicle UE)は高速移動中に接続障害を頻発し得るため、Vehicle UEに対して、上述した実施形態に係る動作を適用してもよい。
上述した実施形態において、セルラ通信システムとしてLTEシステムを例示した。しかしながら、本開示はLTEシステムに限定されない。LTEシステム以外のセルラ通信システム(例えば、第5世代セルラ通信システム)に対して、上述した実施形態に係る動作を適用してもよい。
UE100及びeNB200が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD−ROMやDVD−ROM等の記録媒体であってもよい。UE100及びeNB200が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
[付記]
(はじめに)
本付記において、モビリティ管理の重要な機能の1つと考えられる接続再確立の問題を検討する。
(接続再確立に関する問題)
ほとんどの場合、特に高い高度及び高い速度で、地上UEよりも航空ハンドオーバ失敗率が高い。航空UEが異なるハンドオーバ特性、例えば、遠方のハンドオーバターゲットセルを有することも指摘されており、UAVで観測された隣接セルの数に基づいてDL干渉及びUL干渉に関連する測定報告をトリガするための移動度向上が検討されている。
大きなハンドオーバ失敗の影響と、UAVがハンドオーバのために遠方のターゲットセルを考慮する可能性を組み合わせると、起こりうる1つの潜在的な問題は、接続再確立失敗の可能性である。ハンドオーバ失敗の場合、UEは接続再確立を実行し、再確立プロセスの一部として、UEはセル選択を実行する。隣接セルの数及び強度に依存して、既存のセル選択手順は、選択されたセルが準備されたセルではない(すなわち、有効なUEコンテキストを有しない)ことがあり、接続再確立を成功させずに、UEがRLFを宣言する可能性がある。
観察1:多数の観測されるセルのために、UAVは、接続再確立中に、準備ができていないセルを選択しうる。
(干渉の問題を解決することによる問題解決)
X2インターフェイスがない場合、S1ハンドオーバが想定され、問題はない。
干渉問題を解決することはハンドオーバ失敗を減少させる可能性があるが、これまでの議論から、ハンドオーバ失敗を排除することは期待できない。ハンドオーバ失敗が現実的に地上UEが経験するレベルまで削減できるかどうかは疑問である。ハンドオーバ失敗率が地上UEのそれと同様であっても、UAVは考察1に記載された問題のために、より多くのRLFを経験する可能性が高い。
考察2:干渉問題を解決することはハンドオーバ失敗を緩和することができるが、これまで導入されたメカニズムのどれも、ハンドオーバ失敗を地上UEが経験するものよりも下げることは期待できない。
X2インターフェイスが利用可能でない場合、ターゲットセルが接続再確立手順の間にUEコンテキストを持たず、現在S1インターフェイスを介してUEコンテキストフェッチがサポートされていないので、S1ハンドオーバは使用できない。
考察3:現在、S1インターフェイスはUEコンテキストフェッチをサポートしていない。
S1上のUEコンテキストフェッチのサポートがなければ、ターゲットセルは接続再確立要求を拒絶する必要があり、UEはその後NASリカバリーを実行し始める。NASリカバリー手順の一部として、UEはアイドル状態に移行し、RLFハンドオーバ手順に対して追加の遅延を招き、その結果、サービスのより長い中断が生じる。さらに、データ転送及び順序通りの配信は実行できない。したがって、ソースeNBにバッファされたデータはすべて失われる。
考察4:NASリカバリーは、サービスの過度な遅延と中断を引き起こす可能性がある。
(潜在的な解決策)
改善されたモビリティ性能及び干渉検出をサポートするための拡張を仕様化するためには、接続再確立の失敗の問題も解決する必要がある。UAVが過度の接続再確立失敗を経験する場合、モビリティパフォーマンスの改善には限界がある。以下の候補の解決策を慎重に検討する必要がある。
a)サービングセルは、サービングセルとのX2インターフェイス接続を有する隣接セルのリストを提供する。
b)サービングセルは、UEコンテキストを受信することができる隣接セルのリストを提供する。
c)UAVは、二重の再確立の理由を再確立要求で示すことができる。第1の理由は通常の再確立要求であり、準備されたターゲットセルはUAVの再確立要求(レガシー)を受け入れることができる。第2の理由は、ターゲットセルによって新たな接続要求として解釈される可能性がある。ターゲットセルが(X2インターフェイスの不足のために)UAVのコンテキストをフェッチできない場合、ターゲットセルは再確立要求を拒絶する必要はなく、単にこれを新たな接続要求とみなす。
d)UE支援のUEコンテキスト転送。ハンドオーバの準備中、サービングセルは、UEコンテキスト情報をUAVに提供することができる。UAVは、再確立要求において、必要なUEコンテキスト情報を有することを示すことができる。再確立手順中に、ターゲットセルがソースセルからUEコンテキストを取得できない場合、ターゲットセルはUAVからUEコンテキスト情報を直接要求することができる(ターゲットセルが再確立要求を受け入れた後)。
e)RRC接続再開手順を再利用して、接続再確立失敗によって引き起こされる中断時間を減らす。
f)位置ベースの測定構成及び報告がUAVについて導入され、UAVが実行及び報告するための基準が、UAVと候補セルとの間の距離に基づいて構成され得る。
解決策a)は、ソースセルから(例えば、X2インターフェイスを介して)UEコンテキストをフェッチすることができる隣接セルのUAVに知らせる簡単な方法である。情報は、ブロードキャストまたは専用シグナリングを介してUEに提供されてもよい。この解決策では、UEは、最も高いランク付けされたセルを選択する必要はない。なぜなら、最も高いランク付けされたセルは、UEのコンテキストをフェッチする能力を有する隣接セルのリストにないからである。その代わりに、リストに載っているセルの中で最も高いランクのセルが考慮される可能性がある。
解決策b)は解決策a)と同様であるが、ソースセルへのX2インターフェイスを有する隣接セルに加えて、ソースセルは、ハンドオーバ準備フェーズの一部としてUEコンテキストを隣接セルに転送するオプションを有することができるUAVからの測定報告に基づいて隣接セルに送信する。ソースセルは、UAVに、UEのコンテキスト情報も有する可能性のある追加のセルを専用シグナリングを介して通知することができる。
解決策c)は、2段階のレガシーアプローチ(再確立拒否に続く新しい接続要求)と比較して、再確立の待ち時間を短縮するための方法であり、ネットワーク調整を必要としない。ターゲットセルがソースセルからUEコンテキストを取り出すことができない場合、ソースeNB内にバッファリングされたデータはすべて失われ、これは従来の場合と変わらない。
解決策d)では、UAVは、ターゲットセルとの自身のコンテキスト情報のリレーとして動作しているが、UEコンテキストをソースセルからフェッチできない場合にのみ動作する。
解決策e)では、ターゲットeNBがRRC接続再開要求からResume IDとShortResumeMAC−Iを抽出することが考えられる。ターゲットeNBは、ASセキュリティコンテキストを含むUEコンテキストを検索するために、Resume ID、TargetResumeMAC−I及びCell−IDを含むRetrieve UE Context RequestメッセージをX2インターフェイス上で送信することによって、Resume IDの情報に基づいてソースeNBにコンタクトする。しかし、ターゲットeNBがソースeNBとのX2インターフェイスを持たない場合、これがどのように達成されるかは明確ではない。
解決策f)では、近くの隣接セルがソースセルとX2インターフェイスを持つ可能性が高いという考えがある。X2インターフェイスを使用したネットワーク展開が厳密に距離ベースであるかどうかは不明である。これにより、X2インターフェイスを備えた特定の隣接セルが遠く離れてしまう可能性がある。
上記のすべての解決策の中で、解決策c)と解決策f)は、ネットワークコーディネーションに与える影響は最小限で、影響は最小限であると考えられる。解決策f)は、ターゲットセルを、地上UEに適用可能なターゲットセルにおそらく制限し、UAVにサービスするためにより良い候補である可能性があるUAVから遠くに潜在的なターゲットセルを制限することができる(例えば、UAVに適したアンテナ構成に基づく)。RAN2が(例えば、X2インターフェイスを用いて)拡張隣接セルリストを考慮し、UAVの再選択規則に対するいくつかの変更が接続再確立失敗を避けるために妥当である場合には、解決策a)またはb)を考慮することもできる。解決策e)は、概念的にはUEコンテキスト転送のための最も非従来的なアプローチであるが、再確立失敗(例えば、UL干渉を回避するための調整)を処理するための使用を超えてネットワーク調整を低減する上で重要な役割を果たすと考えられる。
提案:RAN2は、上記の解決策の1つを採用して、接続の再確立の失敗に対処するべきである。
[相互参照]
本願は、米国仮出願第62/586687号(2017年11月15日出願)、米国仮出願第62/630915号(2018年2月15日出願)、及び米国仮出願第62/652989号(2018年4月5日出願)の優先権を主張し、それらの内容のすべてが本願明細書に組み込まれている。